Date: Fri, 6 Jan 2023 05:41:36 +0100 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-arm@freebsd.org Subject: Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash] Message-ID: <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.com> In-Reply-To: <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com> References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg> <F4435E57-1F90-454D-8E75-01DF50DD37DA@googlemail.com> <np4qps4-2o34-3n9n-q4s4-4931p4s7p13@yvfgf.mnoonqbm.arg> <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com> <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark, thanks for the detailed hints ! I will investigate in that firmware issues/your suggested patch,=20 and will report back later. Regards K. > Am 05.01.2023 um 21:43 schrieb Mark Millard <marklmi@yahoo.com>: >=20 > On Jan 5, 2023, at 11:32, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: >=20 >> Hi Bj=C3=B6rn, >> ( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some = time..) >>=20 >> yes that was a "live=E2=80=9C 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 : >> =E2=80=94 >>=20 >> 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 =3D 0 >> time =3D 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 >>=20 >=20 > 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: >=20 > 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 >=20 > In: >=20 > = https://lists.freebsd.org/archives/freebsd-arm/2022-December/002115.html >=20 > 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. >=20 > 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. >=20 > 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. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?650C4A06-1205-489A-B69A-0BB657F1C0E5>