Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot
Date: Sat, 22 Jan 2022 16:07:22 UTC
On 2022-Jan-4, at 01:31, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Jan-4, at 01:03, Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> wrote:
>
>> 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.
>
> 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.
In testing if I could reproduce your system-clang++ buildworld failure,
I got ahold of the old RPi3B and tested on it. (FYI: No failure.)
But, to get there, I ended up facing the usb_pgood_delay issue for
booting the type of USB3 NVMe now in use.
Based on my ports tree having sysutils/u-boot-rpi-arm64/ that is
based on 2021.07 , the following patch causes the u-boot.bin built
to use 2000 for usb_pgood_delay by default:
# more 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,7 @@
ENV_DEVICE_SETTINGS \
ENV_DFU_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
+ "usb_pgood_delay=2000\0" \
BOOTENV
(Some whitespace details might not be preserved via email.)
I did not manage to get having just bootcode.bin and config.txt to deal
with the USB3 NVMe drive directly. (This might be because of a GPT
style of partitioning on the USB3 NVMe drive.) So a full set of RPi*
firmware and u-boot was required on the microsd card. Basically U-Boot
was the first stage able to deal with the USB3 device (GPT partitioned)
--but the FreeBSD loader needed to run on/from the USB3 NVMe drive.
I also faced the "automatically find and use the UFS-root-on-USB-drive"
issue overall. To make it boot as desired:
A) The microsd card msdosfs does not have any of part of the path:
EFI/BOOT/bootaa64.efi
B) The microsd card msdosfs does have the RPi* firmware files required
C) The microsd card msdosfs does have a copy of the u-boot.bin file
from share/u-boot/u-boot-rpi-arm64/u-boot.bin (as updated via use
of the patch)
D) The USB3 NVMe drive msdosfs does have the EFI/BOOT/bootaa64.efi
path and content
E) The USB3 NVMe drive msdosfs does not need the RPi* firmware
F) The USB3 NVMe drive msdosfs does not need the u-boot.bin
G) The USB3 NVMe drive UFS has normal content
H) Note: The USB3 NVMe drive is GPT partitioned but the
microsd card is MBR based:
# gpart show -p
=> 63 62333889 mmcsd0 MBR (30G)
63 8129 - free - (4.0M)
8192 62325760 mmcsd0s1 fat32lba (30G)
=> 40 1953525088 da0 GPT (932G)
40 532480 da0p1 efi (260M)
532520 2008 - free - (1.0M)
534528 7340032 da0p2 freebsd-swap (3.5G)
7874560 1048576 - free - (512M)
8923136 23068672 da0p3 freebsd-swap (11G)
31991808 2097152 - free - (1.0G)
34088960 33554432 da0p4 freebsd-swap (16G)
67643392 1740636160 da0p5 freebsd-ufs (830G)
1808279552 145245576 - free - (69G)
(The odd freebsd-swap's are tied to sometimes booting
various machines from the same USB3 NVMe drive and the
amount of RAM varying widely.)
This results in U-Boot looking in partitions with msdosfs file systems
until it finds a EFI/BOOT/bootaa64.efi (if it does). By only having
that on the USB3 NVMe drive, that drive is where the FreeBSD loader is
run from and then it finds the FreeBSD kernel on that same drive
(different partition). In turn, the kernel finds the FreeBSD world on
that same drive (and the same partition as it found the FreeBSD
kernel).
Note: This works without involving a powered hub. The USB3 NVMe
drive is bus powered, no separate power source. So far, there
has been no evidence of power problems.
Note: The same files/patch-include_configs_rpi.h content would work
in/for sysutils/u-boot-rpi4/ and sysutils/u-boot-rpi3/ (as long as
the are all based on 2021.07).
===
Mark Millard
marklmi at yahoo.com