Re: (RPi) db> reboot -> cpu_reset failed
Date: Thu, 05 Jan 2023 19:32:58 UTC
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 — Regards K. > Am 05.01.2023 um 19:48 schrieb Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>: > > On Thu, 5 Jan 2023, Klaus Küchemann wrote: > > Hi Klaus, > >>> Am 05.01.2023 um 17:37 schrieb Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>: >>> >>> Hi, >>> >>> given I currently find myself debugging more PIs again, what is needed >>> to be able to reset from the db> prompt? >>> >>> Currently I get "cpu_reset failed" when trying. >>> >>> Needing remote hands or an OOB PDU to cycle the PI is not satisfying. >>> >>> /bz >>> >>> -- >>> Bjoern A. Zeeb r15:7 >>> >> >> >> you even cannot be sure to reach the ddb prompt at panic, like here : >> >> -- >> .. >> KDB: stack backtrace: >> .. >> #14 0xffff0000000008b4 at virtdone+0x78 >> Uptime: 1s >> -- >> ..and good night Pi .. >> >> halt/resume of CPU is more promising by setting up a JTAG controller. > > does this mean you are running into the issue at boot as well or was > that just a (made up) example? > > -- > Bjoern A. Zeeb r15:7