Re: BeagleBone Black does not boot -current (DTB incompatibility?)

 Hi Mike,

On Mon, 09 Jan 2023 10:49:16 -0600
Mike Karels <[email protected]> wrote:

> The last couple of snapshots of -current fail to boot on BeagleBone
> Black (armv7 GENERICSD).  I have no idea how long this has been failing.
> (13.1 runs.)
> 
> It appears that a malloc from ti_sysc_attach or ti_sysc_attach_clocks
> is passing a size of 0, which maybe could happen if the FDT has a "clocks"
> node but no clocks are found.  The console output including backtrace is
> below.
> 
> I replaced the dtb directory with the one from 13.1, and the system boots
> and seems to run.  I don't know my way around the armv7 DTS files, but
> I'm happy to investigate if someone can point me in the right direction.
> 
> 		Mike
> 
> ...
> No PSCI/SMCCC call function found
> Texas Instruments AM335x Processor, Revision ES2.1
> arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled.
> random: entropy device external interface
> kbd0 at kbdmux0
> ofwbus0: <Open Firmware Device Tree>
> ti_sysc0: <TI SYSC Interconnect> on ofwbus0
> panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> 	 pc = 0xc05d793c  lr = 0xc007a9ec (db_trace_self_wrapper+0x30)
> 	 sp = 0xc0f14a98  fp = 0xc0f14bb0
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> 	 pc = 0xc007a9ec  lr = 0xc02e8880 (vpanic+0x140)
> 	 sp = 0xc0f14bb8  fp = 0xc0f14bd8
> 	 r4 = 0x00000100  r5 = 0x00000000
> 	 r6 = 0xc07395ef  r7 = 0xc0afb960
> vpanic() at vpanic+0x140
> 	 pc = 0xc02e8880  lr = 0xc02e8660 (dump_savectx)
> 	 sp = 0xc0f14be0  fp = 0xc0f14be4
> 	 r4 = 0x00000000  r5 = 0xc20e0000
> 	 r6 = 0x00000000  r7 = 0xc0f14c50
> 	 r8 = 0xc0b6db00  r9 = 0x00000002
> 	r10 = 0xc0f14c2c
> dump_savectx() at dump_savectx
> 	 pc = 0xc02e8660  lr = 0xc0358e14 (vmem_xalloc)
> 	 sp = 0xc0f14bec  fp = 0xc0f14c20
> vmem_xalloc() at vmem_xalloc
> 	 pc = 0xc0358e14  lr = 0xc059dae4 (kmem_malloc_domainset+0x9c)
> 	 sp = 0xc0f14c28  fp = 0xc0f14c70
> 	 r4 = 0xc0048cf4  r5 = 0xc0e0d108
> 	 r6 = 0xc0f14c18  r7 = 0x00000000
> 	 r8 = 0xc20e0000  r9 = 0x00000000
> 	r10 = 0xc0f14c50
> kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
> 	 pc = 0xc059dae4  lr = 0xc02c1b3c (malloc_large+0x2c)
> 	 sp = 0xc0f14c78  fp = 0xc0f14c88
> 	 r4 = 0xc08f5864  r5 = 0x00000dbc
> 	 r6 = 0x00000000  r7 = 0x00000002
> 	 r8 = 0x00000dbc  r9 = 0xc07a4919
> 	r10 = 0xc27506c0
> malloc_large() at malloc_large+0x2c
> 	 pc = 0xc02c1b3c  lr = 0xc06ad75c (ti_sysc_attach+0x19c)
> 	 sp = 0xc0f14c90  fp = 0xc0f14cd0
> 	 r4 = 0xd00d3e00  r5 = 0x00000dbc
> 	 r6 = 0xffffffff  r7 = 0xd00d3e28
> ti_sysc_attach() at ti_sysc_attach+0x19c
> 	 pc = 0xc06ad75c  lr = 0xc032873c (device_attach+0x4f0)
> 	 sp = 0xc0f14cd8  fp = 0xc0f14d20
> 	 r4 = 0xc2757d80  r5 = 0xc2758200
> 	 r6 = 0x2eb77a5c  r7 = 0x00000000
> 	 r8 = 0xc0b72564  r9 = 0xc078651d
> 	r10 = 0xc27506c0
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032873c  lr = 0xc03281b0 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14d28  fp = 0xc0f14d40
> 	 r4 = 0xc2757d80  r5 = 0xc276da80
> 	 r6 = 0x5e4a6f28  r7 = 0xffffffff
> 	 r8 = 0x00000000  r9 = 0x00000000
> 	r10 = 0xc27508e0
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc03281b0  lr = 0xc0329bb8 (bus_generic_attach+0x1c)
> 	 sp = 0xc0f14d48  fp = 0xc0f14d50
> 	 r4 = 0xc2757d80  r5 = 0x00000000
> 	 r6 = 0xc0f14d60 r10 = 0xc27508e0
> bus_generic_attach() at bus_generic_attach+0x1c
> 	 pc = 0xc0329bb8  lr = 0xc00e4ce0 (ofwbus_attach+0x138)
> 	 sp = 0xc0f14d58  fp = 0xc0f14d90
> 	 r4 = 0xc2758200 r10 = 0xc27508e0
> ofwbus_attach() at ofwbus_attach+0x138
> 	 pc = 0xc00e4ce0  lr = 0xc032873c (device_attach+0x4f0)
> 	 sp = 0xc0f14d98  fp = 0xc0f14de0
> 	 r4 = 0xc2758200  r5 = 0xc2758300
> 	 r6 = 0x2e0a372a  r7 = 0x00000000
> 	 r8 = 0xc0b72564  r9 = 0xc078651d
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032873c  lr = 0xc03281b0 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14de8  fp = 0xc0f14e00
> 	 r4 = 0xc2758200  r5 = 0xc276da80
> 	 r6 = 0x5e4a6f28  r7 = 0x00000000
> 	 r8 = 0xc0b094ac  r9 = 0xc0b094b0
> 	r10 = 0xc0aeb014
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc03281b0  lr = 0xc032a62c (bus_generic_new_pass+0xb4)
> 	 sp = 0xc0f14e08  fp = 0xc0f14e20
> 	 r4 = 0xc2758200  r5 = 0xc08eb898
> 	 r6 = 0xc08c602c r10 = 0xc0aeb014
> bus_generic_new_pass() at bus_generic_new_pass+0xb4
> 	 pc = 0xc032a62c  lr = 0xc032a678 (bus_generic_new_pass+0x100)
> 	 sp = 0xc0f14e28  fp = 0xc0f14e40
> 	 r4 = 0xc2758300  r5 = 0xc08eb898
> 	 r6 = 0xc2759680  r7 = 0x00000000
> 	 r8 = 0xc0b094ac r10 = 0xc0aeb014
> bus_generic_new_pass() at bus_generic_new_pass+0x100
> 	 pc = 0xc032a678  lr = 0xc03256b8 (bus_set_pass+0x54)
> 	 sp = 0xc0f14e48  fp = 0xc0f14e60
> 	 r4 = 0x7fffffff  r5 = 0xc08eb898
> 	 r6 = 0xc2759680  r7 = 0xc274f6c0
> 	 r8 = 0xc0b094ac r10 = 0xc0aeb014
> bus_set_pass() at bus_set_pass+0x54
> 	 pc = 0xc03256b8  lr = 0xc0271788 (mi_startup+0x2b0)
> 	 sp = 0xc0f14e68  fp = 0xc0f14e90
> 	 r4 = 0xc0aeb018  r5 = 0x0fffffff
> 	 r6 = 0xc27a3348  r7 = 0xc08bf85c
> 	 r8 = 0x00000000  r9 = 0x03800000
> mi_startup() at mi_startup+0x2b0
> 	 pc = 0xc0271788  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> 	 r4 = 0xc0000480  r5 = 0xc0ba8000
> 	 r6 = 0x00000005  r7 = 0x00c52078
> 	 r8 = 0xc0e25000  r9 = 0x9cf00168
> 	r10 = 0x00000000
> btext() at btext+0x144
> 	 pc = 0xc0000344  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
> 

 Unfortunatly TI is very good at breaking DTB compatibility at each
Linux update.
 It's been a while (maybe 4-5 years) since we've had breakage at each
update because they just don't care about downstream users.
 Some times it's easy to fix (just changing a compatible) but most of
the time they change so much that we require some new driver or other
things like that.
 CC Oskar who's been fixing some of the stuff.

 Cheers,

-- 
Emmanuel Vadot <[email protected]> <[email protected]>