Date: Thu, 5 Jan 2023 20:32:58 +0100 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-arm@freebsd.org Subject: Re: (RPi) db> reboot -> cpu_reset failed Message-ID: <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com> In-Reply-To: <np4qps4-2o34-3n9n-q4s4-4931p4s7p13@yvfgf.mnoonqbm.arg> References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg> <F4435E57-1F90-454D-8E75-01DF50DD37DA@googlemail.com> <np4qps4-2o34-3n9n-q4s4-4931p4s7p13@yvfgf.mnoonqbm.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Bj=C3=B6rn, ( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some = time..) 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 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 =E2=80=94 Regards K. > Am 05.01.2023 um 19:48 schrieb Bjoern A. Zeeb = <bzeeb-lists@lists.zabbadoz.net>: >=20 > On Thu, 5 Jan 2023, Klaus K=C3=BCchemann wrote: >=20 > Hi Klaus, >=20 >>> Am 05.01.2023 um 17:37 schrieb Bjoern A. Zeeb = <bzeeb-lists@lists.zabbadoz.net>: >>>=20 >>> Hi, >>>=20 >>> given I currently find myself debugging more PIs again, what is = needed >>> to be able to reset from the db> prompt? >>>=20 >>> Currently I get "cpu_reset failed" when trying. >>>=20 >>> Needing remote hands or an OOB PDU to cycle the PI is not = satisfying. >>>=20 >>> /bz >>>=20 >>> -- >>> Bjoern A. Zeeb = r15:7 >>>=20 >>=20 >>=20 >> you even cannot be sure to reach the ddb prompt at panic, like here : >>=20 >> -- >> .. >> KDB: stack backtrace: >> .. >> #14 0xffff0000000008b4 at virtdone+0x78 >> Uptime: 1s >> -- >> ..and good night Pi .. >>=20 >> halt/resume of CPU is more promising by setting up a JTAG controller. >=20 > does this mean you are running into the issue at boot as well or was > that just a (made up) example? >=20 > --=20 > Bjoern A. Zeeb = r15:7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B92299-2776-476D-A81F-7C8EB4D59A13>