Re: U-boot on RPI3, sees disk but won't boot it

On 2022-Sep-19, at 15:15, bob prohaska <[email protected]> wrote:

> Dealing with a Pi3B running stable-13, current as of today.
> 
> Root device is a USB hard drive on a powered hub, no microSD.
> 
> About half the time it boots hands-off via power cycling or
> shutdown -r, other times it stops in u-boot reporting:
> 
> U-Boot 2022.04 (Sep 05 2022 - 16:28:34 -0700)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> 
> This looks a bit strange, since u-boot was loaded from the USB disk....

I have 2 directions for this . . .

#0:

U-Boot resets the bus, re-enumerates the  devices, etc. This
can time out or otherwise fail despite prior activity by the
RPi* firmware that managed to use the device.

My NVMe USB SSD media have such issues with RPI4B's, also
getting 0 found in U-Boot. This is why I build U-Boot using
the patch:

# more /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h 
--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
	ENV_DEVICE_SETTINGS \
	ENV_DFU_SETTINGS \
	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
	BOOTENV
 
 

It may well be that the Samsung T7 Touch's are outside of the
USB specifications in some way that requires such. I can not
claim that U-Boot is wrong relative to the specifications. It
is just that the adjustment is needed for my media.

#1:

I'm unsure if this applies to more than RPi4B's and the like . . .

Booting an RPi* can have the clock speed(s) vary during booting
and this can mess up timeouts/waits/etc. during booting, timing
too early, for example. I use one of:

init_turbo=60 # or other sufficient number of seconds

or, if I'm always after turbo mode for general operation,

force_turbo=1

in config.txt to avoid the failure.

On the RPi4B's I have to boot based on both #0 and #1 being
in place. Either not being in place can lead to the 0 found
status.

A powered hub being involved adds complications not invovled
in my context.

> Next:
> 
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
> 
> Device 0: unknown device
> missing environment variable: pxeuuid
> Retrieving file: pxelinux.cfg/01-b8-27-eb-ba-68-d5
> Retrieving file: pxelinux.cfg/00000000
> Retrieving file: pxelinux.cfg/0000000
> Retrieving file: pxelinux.cfg/000000
> Retrieving file: pxelinux.cfg/00000
> Retrieving file: pxelinux.cfg/0000
> Retrieving file: pxelinux.cfg/000
> Retrieving file: pxelinux.cfg/00
> Retrieving file: pxelinux.cfg/0
> Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
> Retrieving file: pxelinux.cfg/default-arm-bcm283x
> Retrieving file: pxelinux.cfg/default-arm
> Retrieving file: pxelinux.cfg/default
> Config file not found
> 
> At this point one can enumerate the USB devices:
> 
> U-Boot> usb tree
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub 
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00KE3E
>    |  
>    +-4  Vendor specific (480 Mb/s, 2mA)
>    |  
>    +-5  Hub (480 Mb/s, 100mA)
>      |  GenesysLogic USB2.1 Hub 
>      |
>      +-6  Mass Storage (480 Mb/s, 500mA)
> 
> U-Boot> 
> 
> The obvious oddity is that clearly a mass storage device has
> been found (indeed, u-boot was started from it) but u-boot
> does not recognize it as the device to boot from. 

What the RPi* firmware does to get U-Boot in place is not
used by U-Boot for its activity. The RPi* firmware need
not work the same as U-Boot, allowing for differing results.

> So far it appears that rebooting from multi-user via shutdown -r
> works about half the time. If the disk isn't recognized, an immediate
> reset command usually ends the same way. Simply waiting for 15-30
> minutes before rebooting _usually_ results in successful disk 
> discovery and boot. 
> 
> Can anyone suggest simple experiments that might shed light on
> what's going on? The u-boot employed was compiled from ports
> and system up to date at the time. The same type of disk on a
> Pi4 running -current (no powered hub needed) boots without 
> problems. 

I warn that my notes above are based on RPi4B activity, not
RPi3B use. Also, no power hub use is involved. How much
applies to your context is a valid question.

===
Mark Millard
marklmi at yahoo.com