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

On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
> 
> 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
>  
>  
> 

You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3.
Does that matter? The description seems to imply not.

> #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.
> 

A few experiments with either (but not both)
initial_turbo=60 [spelling per rpi docs, hope that's right] or
force_turbo=1 
didn't have obvious effect. Sometimes found disk, sometimes didn't.

For what it's worth, I've been using a timeout file, essentially out
of habit. Renaming it to no.timeout seems to have no obvious effect. 
It's unclear to me if timeout affects both firmware and u-boot, or
just firmware. 




> 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.
>

It might be possible to boot without the powered hub, seems to
me it has worked in the past. I'll give that a try again.

 
> 
> 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.
> 

Ahh, I thought u-boot inherited at least some environmental
details from the firmware. Thanks for the clarification!

> 
> 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.

Thanks for writing,

bob prohaska