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

On 2022-Jan-4, at 01:03, Mark Millard via freebsd-arm <[email protected]> wrote:

> On 2022-Jan-1, at 18:58, bob prohaska <[email protected]> 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.

I may have implicitly presumed that the U-Boot vintage supports
presenting a UEFI interface. I've no clue what vintage such was
first good in.

Thus, I may be implicitly indicating requirements on the U-Boot
vintage used when I suggest FreeBSD loader related material.

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


I'll note that the code from https://reviews.freebsd.org/rS346879
that added reading /efi/freebsd/loader.env if it exists was
not committed until 2019-Apr-28, well after "Jun  7 2018" (the only
date I have for your context). The FreeBSD loader in the msdos file
system would need to be from after the 2019-Apr-28 commit involved.
My guess is that a modern one would be fine, but it is just a guess.

Setting rootdev via U-Boot may be another alternative that might not
have such a vintage-tie involved.

===
Mark Millard
marklmi at yahoo.com