Re: RPi2 USB boot problems, maybe hardware?

On Dec 6, 2023, at 08:19, bob prohaska <fbsd@www.zefox.net> wrote:

> Since a recent build/install cycle a Pi2 v1.1 (armv7) has stopped
> booting stable/14. The machine uses bootcode.bin on the microSD,
> which finds and loads u-boot from the USB mechanical disk.

You missed a stage in that description, more software is involved:

A) bootcode.bin loads and starts the (other) RPi* firmware from the
    EFI partition
B) That (other) RPi* firmware in turn, eventually, finds, loads,
    and starts U-Boot.

You have not reported on the (other) RPi* firmware version that is
in use. Technically, you might have a different vintage of
bootcode.bin on the microsd card.

I'll note that I've not done any
RPi*-firmware/U-Boot/FreeBSD-loader/FreeBSD kernel combination
checking in a long time.

> U-boot
> fails to find the hard disk. I've not intentionally changed U-boot.

Has the FreeBSD port been updated since you last updated U-Boot?
Do modern armv7 snapshots still use the same U-Boot vintage that
you have in place?

Again, I've not done any testing/tracking in some time.

> Sometimes repeated power cycles induce the Pi to boot successfully
> and I'm starting to wonder if there's a hardware problem.
> 
> The serial console reports
> 
> *** FINAL System shutdown message from bob@www.zefox.com ***                 
> 
> System going down IMMEDIATELY                                                  
> 
> 
> Dec  6 07:29:31 www shutdown[61398]: reboot by bob: 
> Stopping apache24.
> Waiting for PIDS: 1093.
> Stopping cron.
> Waiting for PIDS: 1078, 1078.
> Stopping sshd.
> Waiting for PIDS: 1075.
> Stopping devd.
> Waiting for PIDS: 774.
> Writing entropy file: .
> Writing early boot entropy file: .
> Terminated
> .
> Dec  6 07:29:36 www syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop... done
> 
> Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 3 2 0 0 done
> All buffers synced.
> Swap device da0s2b removed.
> Uptime: 14h16m14s
> Resetting system ... 
> 
> U-Boot 2023.07.02 (Aug 25 2023 - 05:50:16 +0000)

That provides the U-Boot vintage but not the RPI* firmware
vintage.

> DRAM:  948 MiB
> RPI 2 Model B (0xa21041)
> Core:  75 devices, 12 uclasses, devicetree: board
> MMC:   mmc@7e300000: 1
> Loading Environment from FAT... ** Bad device specification mmc 0 **
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... cannot reset port 1!?

Does the above message appear when it manages to boot? Only
when it later fails to find the disk?

That message may be the earliest visible evidence of whatever
the actual problem is.

> 1 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found

I have boot devices for which I end up using the combination:

usb_pgood_delay being 2000
usb_ready_retry being 5

in order to avoid such usually or always happening.
(It is possible that usb_pgood_delay alone would be
sufficient in my context with such.)

> Hit any key to stop autoboot:  0 
> U-Boot> usb tree
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>      U-Boot Root Hub 
> 
> U-Boot> 
> 
> The failure to enumerate more USB devices seems odd.

The prior message:

scanning bus usb@7e980000 for devices... cannot reset port 1!?

may imply that such is not odd at this point.

> Issuing a reset command, or usb reset, results in a hang.

Again, possibly related to the message.

> The red LED remains on. It does seem possible to explore with
> u-boot commands that don't involve resetting. For example, the 
> usb tree command.
> 
> Are there any u-boot commands that might shed light on what's wrong? 
> 
> Depowring the Pi and external hub (along with the disk) and letting
> it sit for ten minutes allows the machine to reboot hands-off when
> power is applied to hub and Pi.
> 
> During the successful power-up u-boot reports 
> ...
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... unable to get device descriptor (error=-22)

So, no:

scanning bus usb@7e980000 for devices... cannot reset port 1!?

message in this example. Any USB issues after that message (unless
power has been cycled) may just be later consequences that do not
contribute much more information.

I've no clue how to figure out what leads to the message being
generated.

> 5 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> ....
> 
> No USB connections were changed between the start attempts.
> 
> Once up the machine seems quite stable, building world slowly
> but reliably.



===
Mark Millard
marklmi at yahoo.com