Trouble booting the April 23 snapshot for rpi3

[Mark Millard]

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.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)