Date: Tue, 4 Jan 2022 01:03:45 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> In-Reply-To: <20220102025818.GA42622@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=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 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 >=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 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 >=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: /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. >=20 > Type '?' for a list of commands, 'help' for more detailed help. >=20 > 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=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 =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?073F48C5-4F96-496C-B23F-607752312072>