svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf

[Michael Tuexen]

> On 6. Jan 2018, at 15:24, Kyle Evans <kevans at freebsd.org> wrote:
> 
> On Sat, Jan 6, 2018 at 7:23 AM, Michael Tuexen <tuexen at freebsd.org> wrote:
>>> On 4. Jan 2018, at 23:37, Kyle Evans <kevans at FreeBSD.org> wrote:
>>> 
>>> Author: kevans
>>> Date: Thu Jan  4 22:37:15 2018
>>> New Revision: 327563
>>> URL: https://svnweb.freebsd.org/changeset/base/327563
>>> 
>>> Log:
>>> if_awg: Use syscon prop if it exists
>>> 
>>> The emac bindings that are landing in Linux 4.15 specify a syscon property
>>> on the emac node that point to /soc/syscon. Use this property if it's
>>> specified, but maintain backwards compatibility with the old method.
>>> 
>>> The older method is still used for boards that we get .dtb from u-boot, such
>>> as pine64, that did not yet have stable emac bindings.
>>> 
>>> Tested on:   Banana Pi-M3 (a83t)
>>> Tested on:   Pine64 (a64)
>>> Reviewed by: manu
>>> Differential Revision:       https://reviews.freebsd.org/D13296
>> This breaks booting on a RPi3. Please note that it is not only panic'ing,
>> but there are multiple errors before that.
> 
> Ugh, sorry about that.
No problem...
> 
>>>> FreeBSD EFI boot block
>>   Loader path: /boot/loader.efi
>> 
>>   Initializing modules: UFS
>>   Probing 3 block devices.....* done
>>    UFS found 1 partition
>> Consoles: EFI console
>> Command line arguments: loader.efi
>> Image base: 0x39ab8008
>> EFI version: 2.05
>> EFI Firmware: Das U-boot (rev 0.00)
>> 
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Wed Dec  6 19:13:14 CET 2017 root at bsd18.fh-muenster.de)
>> EFI boot environment
>> Loading /boot/defaults/loader.conf
>> /boot/kernel/kernel text=0x7f3b28 data=0xaac80+0x3a106d syms=[0x8+0x10e870+0x8+0x101345]
>> /boot/entropy size=0x1000
>> /boot/kernel/geom_label.ko text=0x2a80 text=0x2710 data=0x10118+0xfeec syms=[0x8+0x1548+0x8+0xef2]
>> 
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]...
>> Using DTB provided by EFI at 0x8004000.
>> KDB: debugger backends: ddb
>> KDB: current backend: ddb
>> Copyright (c) 1992-2018 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>        The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 12.0-CURRENT #21 r327563M: Sat Jan  6 14:16:20 CET 2018
>>    tuexen at bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP arm64
>> FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on LLVM 5.0.1)
>> VT: init without driver.
>> sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)!
>> module_register: cannot register g_label from kernel; already loaded from geom_label.ko
>> Module g_label failed to register: 17
>> Starting CPU 1 (1)
>> Starting CPU 2 (2)
>> Starting CPU 3 (3)
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> random: unblocking device.
>> module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error 12
>> random: entropy device external interface
>> kbd0 at kbdmux0
>> ofwbus0: <Open Firmware Device Tree>
>> simplebus0: <Flattened device tree simple bus> on ofwbus0
>> ofw_clkbus0: <OFW clocks bus> on ofwbus0
>> clk_fixed0: <Fixed clock> on ofw_clkbus0
>> clk_fixed1: <Fixed clock> on ofw_clkbus0
>> regfix0: <Fixed Regulator> on ofwbus0
>> regfix1: <Fixed Regulator> on ofwbus0
>> syscon_generic0: <syscon> mem 0x40000000-0x400000ff on simplebus0
>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>> local_intc0: <BCM2836 Interrupt Controller> mem 0x40000000-0x400000ff on simplebus0
>> local_intc0: could not allocate memory resource
>> device_attach: local_intc0 attach returned 6
> 
> Apologies for the breakage; this should be alleviated by r327621.
> There will still be some errors (syscon_generic cannot allocate memory
> resource), but that should be completely innocent in this case and
> will give me time to track down why syscon shares register space with
> local intc here.
I can confirm that r327621 boots again on RPi3 and the system is usable.

Thanks for the quick fix/workaround.

Best regards
Michael