Trouble booting the April 23 snapshot for rpi3

[Glen Barber]

On Tue, Apr 28, 2020 at 01:11:58PM -0700, Mark Millard via freebsd-arm wrote:
> 
> 
> On 2020-Apr-28, at 12:57, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> > In trying to boot the April 23 RPI3 snapshot the machine is
> > reporting what looks like an old problem:
> > 
> > ---<<BOOT>>---
> > KDB: debugger backends: ddb
> > KDB: current backend: ddb
> > Copyright (c) 1992-2020 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > 	The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 13.0-CURRENT #0 r360211: Thu Apr 23 08:12:13 UTC 2020
> >    root at releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> > FreeBSD clang version 10.0.0 (git at github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)
> > WARNING: WITNESS option enabled, expect reduced performance.
> > VT(efifb): resolution 1920x1200
> > module firmware already present!
> > KLD file umodem.ko is missing dependencies
> > Starting CPU 1 (1)
> > panic: Failed to start CPU 1 (1), error -1
> > 
> > cpuid = 0
> > time = 1
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self_wrapper+0x28
> > 	 pc = 0xffff00000075c2d4  lr = 0xffff0000001088b8
> > 	 sp = 0xffff000000010590  fp = 0xffff000000010790
> > 
> > db_trace_self_wrapper() at vpanic+0x194
> > 	 pc = 0xffff0000001088b8  lr = 0xffff000000415a74
> > 	 sp = 0xffff0000000107a0  fp = 0xffff0000000107f0
> > 
> > vpanic() at panic+0x44
> > 	 pc = 0xffff000000415a74  lr = 0xffff00000041581c
> > 	 sp = 0xffff000000010800  fp = 0xffff0000000108b0
> > 
> > panic() at start_cpu+0x224
> > 	 pc = 0xffff00000041581c  lr = 0xffff00000076a5b0
> > 	 sp = 0xffff0000000108c0  fp = 0xffff0000000108c0
> > 
> > start_cpu() at cpu_init_fdt+0x34
> > 	 pc = 0xffff00000076a5b0  lr = 0xffff0000007698b0
> > 	 sp = 0xffff0000000108d0  fp = 0xffff000000010930
> > 
> > cpu_init_fdt() at ofw_cpu_early_foreach+0x180
> > 	 pc = 0xffff0000007698b0  lr = 0xffff00000020c648
> > 	 sp = 0xffff000000010940  fp = 0xffff000000010990
> > 
> > ofw_cpu_early_foreach() at mp_start+0x8c
> > 	 pc = 0xffff00000020c648  lr = 0xffff000000470490
> > 	 sp = 0xffff0000000109a0  fp = 0xffff0000000109f0
> > 
> > mp_start() at mi_startup+0x12c
> > 	 pc = 0xffff000000470490  lr = 0xffff0000003a9ac4
> > 	 sp = 0xffff000000010a00  fp = 0xffff000000010a20
> > 
> > mi_startup() at virtdone+0x5c
> > 	 pc = 0xffff0000003a9ac4  lr = 0xffff00000000108c
> > 	 sp = 0xffff000000010a30  fp = 0x0000000000000000
> > 
> > KDB: enter: panic
> > [ thread pid 0 tid 0 ]
> > Stopped at      0
> > db> 
> > db> bt
> > Tracing pid 0 tid 0 td 0xffff000000cedb80
> > db_trace_self() at db_stack_trace+0xfc
> >         pc = 0xffff00000075c2d4  lr = 0xffff000000105cbc
> >         sp = 0xffff000000010180  fp = 0xffff000000010190
> > 
> > db_stack_trace() at db_command+0x228
> >         pc = 0xffff000000105cbc  lr = 0xffff000000105920
> >         sp = 0xffff0000000101a0  fp = 0xffff000000010250
> > 
> > db_command() at db_command_loop+0x54
> >         pc = 0xffff000000105920  lr = 0xffff0000001056c8
> >         sp = 0xffff000000010260  fp = 0xffff0000000102b0
> > 
> > db_command_loop() at db_trap+0xf4
> >         pc = 0xffff0000001056c8  lr = 0xffff000000108a20
> >         sp = 0xffff0000000102c0  fp = 0xffff0000000104e0
> > 
> > db_trap() at kdb_trap+0x1cc
> >         pc = 0xffff000000108a20  lr = 0xffff00000045e10c
> >         sp = 0xffff0000000104f0  fp = 0xffff000000010550
> > 
> > kdb_trap() at do_el1h_sync+0xf4
> >         pc = 0xffff00000045e10c  lr = 0xffff00000077a8a4
> >         sp = 0xffff000000010560  fp = 0xffff0000000105b0
> > 
> > do_el1h_sync() at handle_el1h_sync+0x78
> >         pc = 0xffff00000077a8a4  lr = 0xffff00000075e878
> >         sp = 0xffff0000000105c0  fp = 0xffff000000010700
> > 
> > handle_el1h_sync() at kdb_enter+0x34
> >         pc = 0xffff00000075e878  lr = 0xffff00000045d730
> >         sp = 0xffff000000010710  fp = 0xffff000000010790
> > 
> > kdb_enter() at vpanic+0x1b0
> >         pc = 0xffff00000045d730  lr = 0xffff000000415a90
> >         sp = 0xffff0000000107a0  fp = 0xffff0000000107f0
> > 
> > vpanic() at panic+0x44
> >         pc = 0xffff000000415a90  lr = 0xffff00000041581c
> >         sp = 0xffff000000010800  fp = 0xffff0000000108b0
> > 
> > panic() at start_cpu+0x224
> >         pc = 0xffff00000041581c  lr = 0xffff00000076a5b0
> >         sp = 0xffff0000000108c0  fp = 0xffff0000000108c0
> > 
> > start_cpu() at cpu_init_fdt+0x34
> >         pc = 0xffff00000076a5b0  lr = 0xffff0000007698b0
> >         sp = 0xffff0000000108d0  fp = 0xffff000000010930
> > 
> > cpu_init_fdt() at ofw_cpu_early_foreach+0x180
> >         pc = 0xffff0000007698b0  lr = 0xffff00000020c648
> >         sp = 0xffff000000010940  fp = 0xffff000000010990
> > 
> > ofw_cpu_early_foreach() at mp_start+0x8c
> >         pc = 0xffff00000020c648  lr = 0xffff000000470490
> >         sp = 0xffff0000000109a0  fp = 0xffff0000000109f0
> > 
> > mp_start() at mi_startup+0x12c
> >         pc = 0xffff000000470490  lr = 0xffff0000003a9ac4
> >         sp = 0xffff000000010a00  fp = 0xffff000000010a20
> > 
> > mi_startup() at virtdone+0x5c
> >         pc = 0xffff0000003a9ac4  lr = 0xffff00000000108c
> >         sp = 0xffff000000010a30  fp = 0x0000000000000000
> > 
> > db> 
> > 
> > Reboot fails  with cpu reset failed. This looks to my eye like
> > the problem discussed in the thread "Re: Panic on Rpi3 at r358976"
> > but that conversation ended in mid-March and I thought was resolved.
> > 
> > Is anybody else having trouble with this snapshot? The filename is
> > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200423-r360211.img
> 
> What version of u-boot-rpi3 materials is in the snapshot? Is
> it based on: Quarterly packages? Latest packages? Its own
> build of the most-recent sysutils/u-boot-rpi3 source at
> the time?
> 
> My guess: Based on the quarterly package --and quarterly may
> not have been updated at the time of the snapshot build.
> 

It is based on the latest branch, but more specifically the port is
built from a checkout of head from the ports tree.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20200428/3d2ebea3/attachment.sig>