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

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