Created attachment 208124 [details] verbose console log Opened at @manu's request. cpsw0: bpf attached^M cpsw0: Ethernet address: 40:06:a0:21:b1:a7^M simplebus13: <target-module@180000> disabled compat ti,sysc (no driver attached)^M simplebus13: <target-module@200000> disabled compat ti,sysc (no driver attached)^M simplebus13: <target-module@300000> disabled compat ti,sysc (no driver attached)^M simplebus15: <target-module@0> disabled compat ti,sysc (no driver attached)^M simplebus15: <target-module@3000> disabled compat ti,sysc (no driver attached)^M simplebus0: <edma@49000000> mem 0x49000000-0x4900ffff irq 1,2,3 compat ti,edma3-tpcc (no driver attached)^M simplebus0: <tptc@49800000> mem 0x49800000-0x498fffff irq 4 compat ti,edma3-tptc (no driver attached)^M simplebus0: <tptc@49900000> mem 0x49900000-0x499fffff irq 5 compat ti,edma3-tptc (no driver attached)^M simplebus0: <tptc@49a00000> mem 0x49a00000-0x49afffff irq 6 compat ti,edma3-tptc (no driver attached)^M sdhci_ti2: <TI MMCHS (SDHCI 2.0)> mem 0-0xfff irq 54 on ti_sysc42^M Fatal kernel mode data abort: 'External Abort' on read^M trapframe: 0xc0e14c60^M FSR=00001008, FAR=ff910114, spsr=60000093^M r0 =c08d92c0, r1 =ff910000, r2 =00000114, r3 =00000000^M r4 =c24d8200, r5 =c24d8218, r6 =fffffc19, r7 =00000000^M r8 =c24d8200, r9 =0000d07c, r10=c2450a80, r11=c0e14d30^M r12=0000006e, ssp=c0e14cf0, slr=c068a8b8, pc =c068aa50^M ^M panic: Fatal abort^M cpuid = 0^M time = 1^M KDB: stack backtrace:^M db_trace_self() at db_trace_self^M pc = 0xc05cfc98 lr = 0xc007a1e8 (db_trace_self_wrapper+0x30)^M sp = 0xc0e14a40 fp = 0xc0e14b58^M db_trace_self_wrapper() at db_trace_self_wrapper+0x30^M pc = 0xc007a1e8 lr = 0xc02afae4 (vpanic+0x168)^M sp = 0xc0e14b60 fp = 0xc0e14b78^M r4 = 0x00000100 r5 = 0xc0b23720^M r6 = 0xc0727a61 r7 = 0x00000000^M vpanic() at vpanic+0x168^M pc = 0xc02afae4 lr = 0xc02af8ac (doadump)^M sp = 0xc0e14b80 fp = 0xc0e14b84^M See attachment for full console log
On TI chips, an external data abort on an address in the mmio range is almost certainly an attempt to read from a device register when that device's clocks aren't running. Probably fresh fallout from a recent DTS import.
A commit references this bug: Author: manu Date: Mon Oct 7 08:11:49 UTC 2019 New revision: 353172 URL: https://svnweb.freebsd.org/changeset/base/353172 Log: arm: dts: ti: Fix mmc3 instance by setting it to disabled DTS Import of Linux 5.3 added a patch that rework the L3 mmc instance in the AM335x SoC but removed the status = 'disabled' on the node. This cause the kernel to probe the device even if the board doesn't have this mmc used and since we don't correctly activate the clock for this module we panic with an external data abort. Beaglebone(s) don't have this device anyway so simply disabling it. Patch for the DTS was sent upstream. https://patchwork.kernel.org/patch/11176921/ PR: 241089 Reported by: phk Changes: head/sys/gnu/dts/arm/am33xx.dtsi
Re-opening this bug as Linux will likely won't apply my patch. TI have differents view on DTS than others. Also the real bug is that we probably don't handle the clock for mmc3 correctly. I won't work on this problem. ian@ suggested an dtb overlay auto-loading features if we have a <basedtb>-freebsd.dtbo where we would put things like that when they aren't accepted upstream, I'll likely more work on this.
I like the overload autoload thing, which could be useful in papering over differences of opinion on the proper role of DTB between the different vendors, Linux kernel folks and the ePAR successors who aren't always all on the same page...
Fixed now that we have proper clocks drivers.