Date: Tue, 4 Jan 2022 01:31:14 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <8551EF27-BF69-44E5-BC32-FB7E1752FDD6@yahoo.com> In-Reply-To: <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <E62FFB2B-9424-434D-9358-280FD8EC1B91@yahoo.com> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> <20220102025818.GA42622@www.zefox.net> <073F48C5-4F96-496C-B23F-607752312072@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> Coming back to the saving of u-boot environment variables, >> backing down to a much older set of FAT files seems to help. >>=20 >> The machine now has a DOS-only microSD with an old set of >> files: >>=20 >> 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 >=20 > 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.) >=20 >> 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): >=20 > 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 >>=20 >> Intervention with run bootcmd_usb0 gives a successful boot from USB.=20= >> If nothing is touched, the console displays:=20 >>=20 >> 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 >=20 > I do not see anything here identifying the FreeBSD loader.efi > vintage used. Likely it need not be old? >=20 >> Consoles: EFI console >> Reading loader env vars from /efi/freebsd/loader.env >=20 > 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. >=20 > 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: >=20 > https://reviews.freebsd.org/rS346879 >=20 > 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. >=20 > There also is a loaddev that seems to be involved. >=20 > I expect that in some respects part of what is described > in: >=20 > # man loader_simp >=20 > applies to the contents of /efi/freebsd/loader.env . But > Other things may not, such as rootdev being used to > initialize currdev . >=20 >> Setting currdev to disk0p1: >> FreeBSD/arm64 EFI loader, Revision 1.1 >>=20 >> 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: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 >> 97c7,0x7726839) >> Setting currdev to disk0p2: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or = directory. >>=20 >> Type '?' for a list of commands, 'help' for more detailed help. >>=20 >> It looks like the root device is still the microSD card, >=20 > /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 ? >=20 >> 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=20 >> on my own have caused more trouble than they've solved, in particular >> that's what lead to the "saving to FAT....FAILED" messages. . =20 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8551EF27-BF69-44E5-BC32-FB7E1752FDD6>