Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash]

On Jan 5, 2023, at 20:41, Klaus Küchemann <maciphone2@googlemail.com> wrote:

> Mark, thanks for the detailed hints !
> 
> I will investigate in that firmware issues/your suggested patch, 
> and will report back later.
> 
> Regards
> 
> 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>:
>> 
>> 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