Date: Thu, 5 Jan 2023 21:42:48 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: "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: <DEAFAC73-D63F-4B04-94D3-A89695DEE5F6@yahoo.com> In-Reply-To: <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.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> <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 5, 2023, at 20:41, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: > Mark, thanks for the detailed hints ! >=20 > I will investigate in that firmware issues/your suggested patch,=20 > and will report back later. >=20 > Regards >=20 > K. FYI: the crashing without the patch is tied to variations in the ordering of the material in the .dtb files. If bcm_dma is not set up in an earlier pass in the kernel, the modern ordering in some .dtb files ends up with a "used before defined" sequencing. Thus the move of bcm_dma to an earlier pass via the patching --so that bcm_dma is then always ready in time for its 1st use. >> 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?DEAFAC73-D63F-4B04-94D3-A89695DEE5F6>