Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash]
Date: Fri, 06 Jan 2023 04:41:36 UTC
Mark, thanks for the detailed hints ! I will investigate in that firmware issues/your suggested patch, and will report back later. Regards K. > Am 05.01.2023 um 21:43 schrieb Mark Millard <marklmi@yahoo.com>: > > On Jan 5, 2023, at 11:32, Klaus Küchemann <maciphone2@googlemail.com> wrote: > >> Hi Björn, >> ( ..I had a JTAG setup on the PI, but didn’t use it for some time..) >> >> yes that was a "live“ boot example from today of the cm4(on orig. I/O-board), >> it hangs while initializing sdhci, while the boot partition is living on the emmc : >> — >> >> sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x7e300000-0x7e3000ff irq 24 on simplebus0 >> Fatal data abort: >> x0: ffffffff >> x1: ffff00000092b404 >> x2: 0 >> x3: 6 >> x4: ffff000000fdf77c >> x5: ffff000000fdf72c >> x6: 4000000 >> x7: 4000000 >> x8: ffff000000dfb6a0 >> x9: 20 >> x10: 0 >> x11: 1 >> x12: 300000000006e65 >> x13: fefefefeff0100 >> x14: 1d >> x15: 0 >> x16: 0 >> x17: 0 >> x18: ffff000000fdf7e0 >> x19: ffffffff >> x20: 0 >> x21: ffff000000bad000 >> x22: ffff000000bad000 >> x23: ffffa00000f8f038 >> x24: ffff00000091b5b2 >> x25: ffff0000008dfc9c >> x26: ffff0000009436b6 >> x27: ffffa00000f8b140 >> x28: 32000000 >> x29: ffff000000fdf7e0 >> sp: ffff000000fdf7e0 >> lr: ffff000000868040 >> elr: ffff0000008620d4 >> spsr: a00000c5 >> far: 20 >> esr: 96000004 >> panic: vm_fault failed: ffff0000008620d4 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> #0 0xffff000000516458 at kdb_backtrace+0x60 >> #1 0xffff0000004c24ac at vpanic+0x174 >> #2 0xffff0000004c2334 at panic+0x44 >> #3 0xffff0000007f48c0 at data_abort+0x204 >> #4 0xffff0000007d5010 at handle_el1h_sync+0x10 >> #5 0xffff00000086803c at bcm_sdhci_attach+0x314 >> #6 0xffff00000086803c at bcm_sdhci_attach+0x314 >> #7 0xffff000000502428 at device_attach+0x3fc >> #8 0xffff000000504514 at bus_generic_new_pass+0x120 >> #9 0xffff0000005044a4 at bus_generic_new_pass+0xb0 >> #10 0xffff0000005044a4 at bus_generic_new_pass+0xb0 >> #11 0xffff0000005044a4 at bus_generic_new_pass+0xb0 >> #12 0xffff0000005065f4 at root_bus_configure+0x40 >> #13 0xffff000000439ee8 at mi_startup+0x11c >> #14 0xffff0000000008b4 at virtdone+0x78 >> Uptime: 1s >> > > You are using modern enough RPI* firmware that the FreeBSD > kernel does not tolerate it. Same sort of backtrace as I > reported back in 2022-Apr when I explored what RPi* > firmware releases avoided kernel crashes on RPi4B's, > such as: > > KDB: stack backtrace: > #0 0xffff000000516268 at kdb_backtrace+0x60 > #1 0xffff0000004c22bc at vpanic+0x174 > #2 0xffff0000004c2144 at panic+0x44 > #3 0xffff0000007f4928 at data_abort+0x204 > #4 0xffff0000007d5010 at handle_el1h_sync+0x10 > #5 0xffff00000086809c at bcm_sdhci_attach+0x314 > #6 0xffff00000086809c at bcm_sdhci_attach+0x314 > #7 0xffff000000502238 at device_attach+0x3fc > #8 0xffff000000504324 at bus_generic_new_pass+0x120 > #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0 > #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0 > #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0 > #12 0xffff000000506404 at root_bus_configure+0x40 > #13 0xffff000000439cf8 at mi_startup+0x11c > #14 0xffff0000000008b4 at virtdone+0x78 > > In: > > https://lists.freebsd.org/archives/freebsd-arm/2022-December/002115.html > > I reported what I'm experimenting with (2nd version) for 13.1 and > main for allowing modern RPi* firmware. It basically leads to > bcm_dma being set up earlier so it is available for reference in > the bcm_sdhci_attach activity. > > If you build your own kernel with the type of patching that > I report, the specific crash should disappear and booting > with modern RPi* firmware seems to have worked for me so > far on the machines I've done the experimenting on. > > Expect more messages caused by new things in the .dtb files > that the kernel does not support but keeps rechecking during > boot. Sort of a noisy form of otherwise-ignored. > > === > Mark Millard > marklmi at yahoo.com