Re: Saving environment variables in u-boot

[This eventually suggests that the vintage of U-Boot used
in the default Fedora 35 is the problem: a later version
of U-Boot does not get the problem (so far).]

On 2021-Dec-18, at 17:33, Mark Millard <marklmi@yahoo.com> wrote:

> [I decided to have this specific message still under
> the old Subject line.]
> 
> Hmm.
> 
> I just tried a Fedora 35 server install on a RPi4B (8 GiByte)
> using a bus-powered USB3 SSD. It did fine until it did a around
> of downloading and installing= updates to the original image
> install. On reboot it got the:
> 
> scanning usb for storage devices... 0 Storage Device(s) found
> 
> But:
> 
> . . .
> U-Boot> editenv usb_pgood_delay
> edit: 2000
> U-Boot> usb reset
> . . . (found this time) . . .
> U-Boot> boot
> 
> got past that. I'll note that, looking around with
> printenv in U-Boot showed a:
> 
> bootdelay=2
> 
> (That I've not adjusted.)
> 
> Repeated testing has usually booted just fine but
> on occasion gets the:
> 
> scanning usb for storage devices... 0 Storage Device(s) found
> 
> The same sequence involving usb_pgood_delay has always
> managed to find the drive and boot so far.
> 

Note: This context is (so far) with no microsd card in
use at all: Pure USB3 based booting.

I ended up with an example of the USB3 SSD being in a state
that none of the parameters helped usb reset or usb stop
then usb start (many tries). What did finally work was:

U-Boot> usb stop
U-Boot> 

Then: leave the RPi4B powered but unplug the USB3 SSD
from it (so it lost power) and then plug it back in.
Finally:

U-Boot> usb start

(at the same prompt), which finally found the drive.
This had:

usb_max_blk=20
usb_pgood_delay=2000
usb_ready_retry=5

in U-Boot at the time, but I can not tell what of that
might have been necessary.

With the drive found,

U-Boot> boot

worked fine.

This is a context in which there is no external
hub and no option for non-bus power to the drive.

Question:
Does your USB drive allow direct/external power
(no hub)?

Fedora uses a different U-Boot than I've been using
with FreeBSD. But I do not know if that is contributing.
The type of USB3 SSD is the same as I've been using
with FreeBSD for some time.

So far my experiments indicate that having

uEnv.txt
or:
uboot.env

does not contribute to the U-Boot environmental
settings.

I'll note that there is another error message sequence
involved in my sequence, "cannot reset port 2!?" and
then "cannot reset port 1!?":

. . .
U-Boot> usb reset
resetting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... cannot reset port 2!?
cannot reset port 1!?
4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
. . .

Sometimes repeating:

U-Boot> usb stop
. . .
U-Boot> usb start

does lead to finding the drive in only a few tries.

I'll note that the rpi4-u-boot.bin that Fedora 35
is using reports their build as:

U-Boot 2021.10 (Oct 14 2021 - 00:00:00 +0000)

Tracking the development/test builds ends up with:

U-Boot 2021.04-rc3 (Mar 13 2021 - 00:00:00 +0000)

instead.

Hmm. I replaced rpi4-u-boot.bin with the newer one
and so far, no problems finding the USB SSD or
booting in general.


===
Mark Millard
marklmi at yahoo.com