Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot

On 2022-Jan-1, at 18:58, bob prohaska <fbsd@www.zefox.net> wrote:

> Coming back to the saving of u-boot environment variables,
> backing down to a much older set of FAT files seems to help.
> 
> The machine now has a DOS-only microSD with an old set of
> files:
> 
> root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_"
> VC_BUILD_ID_USER: dc4
> VC_BUILD_ID_TIME: 15:31:38
> VC_BUILD_ID_BRANCH: master
> VC_BUILD_ID_TIME: Jun  7 2018

I've no clue what the status is for this vintage of RPi* firmware.
But it is not obvious that the RPi* firmware is what enabled
saving u-boot environment variables: the U-Boot vintage may be
what made the difference. (It would not be the FreeeBSD loader
that makes the difference: not involved until too late to
contribute to the issue.)

> With this suite of bootfiles it's possible to save a value for
> usb_pgood_delay of 19000, which in most cases results in a hands-
> off detection of the usb hard disk (via a powered hub):

I do not see anything here identifying the U-Boot vintage used.
But the vintage may be tied to the save working.

> MMC:   mmc@7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Intervention with run bootcmd_usb0 gives a successful boot from USB. 
> If nothing is touched, the console displays: 
> 
> MMC Device 0 not found
> no mmc device at slot 0
> switch to partitions #0, OK
> mmc1 is current device
> Scanning mmc 1:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> BootOrder not defined
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC

I do not see anything here identifying the FreeBSD loader.efi
vintage used. Likely it need not be old?

> Consoles: EFI console
>    Reading loader env vars from /efi/freebsd/loader.env

It might be possible to tell the FreeBSD loader to use the
USB drive via the content of the /efi/freebsd/loader.env
file on the microsd card's msdos file system. Likely this
file would need to be created.

For all I know setting rootdev ( or currdev ?) to the
appropriate disk?p?: text might do such. (That notation
presumes UFS, ZFS. ZFS uses zfs:DATASETNOTATION: I've
never tried using /efi/freebsd/loader.env and I've never
found documentation in the system. But there are notes
in:

https://reviews.freebsd.org/rS346879

Given that wording, I'm not sure just where
/efi/freebsd/loader.env ends up being relative to in the
msdos file system. I've not done much analysis of the
code that is also listed.

There also is a loaddev that seems to be involved.

I expect that in some respects part of what is described
in:

# man loader_simp

applies to the contents of /efi/freebsd/loader.env . But
Other things may not, such as rootdev being used to
initialize currdev .

> Setting currdev to disk0p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> 
>   Command line arguments: loader.efi
>   Image base: 0x39e91000
>   EFI version: 2.80
>   EFI Firmware: Das U-Boot (rev 8217.4096)
>   Console: comconsole (0)
>   Load Path: /efi\boot\bootaa64.efi
>   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x
> 01,0,0x81f,0x18fa8)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0
> ,0x81f,0x18fa8)
> Setting currdev to disk0p1:

/efi/freebsd/loader.env content might be able to control the above?

> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1
> 97c7,0x7726839)
> Setting currdev to disk0p2:

/efi/freebsd/loader.env content might be able to control the above?

> Startup error in /boot/lua/loader.lua:
> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> 
> Type '?' for a list of commands, 'help' for more detailed help.
> 
> It looks like the root device is still the microSD card,

/efi/freebsd/loader.env content might be able to control the
kernel load device (via indirectly or directly controlling
the currdev value), possibly via assigning the rootdev value
so that it will be copied to currdev ?

> even though
> the USB disk has been found. Any suggestions appreciated. There's a
> complete and recent ports tree if it's helpful, attempts to use it 
> on my own have caused more trouble than they've solved, in particular
> that's what lead to the "saving to FAT....FAILED" messages. .  




===
Mark Millard
marklmi at yahoo.com