Re: RPi4 - Booting from mSD with USB storage
- In reply to: Mark Millard via freebsd-arm : "Re: RPi4 - Booting from mSD with USB storage"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 08 Jul 2021 21:25:49 UTC
> On 3 Jul 2021, at 17:14, Mark Millard <marklmi@yahoo.com> wrote: > > You do not report what, if any, error messages U-Boot is > reporting. > > Just in case it is relevant, I', going to quote a list > message from back in April: > > QUOTE > I will note that one thing that was discovered was > that u-boot does not well support having a USB device > with more than one storage LUN in the device. It > produces messages like: > > Scanning disk usb_mass_storage.lun1... > ** Unrecognized filesystem type ** > ** Unrecognized filesystem type ** > Scanning disk usb_mass_storage.lun3... > ERROR: failure to add disk device usb_mass_storage.lun3, r = 20 > Error: Cannot initialize UEFI sub-system, r = 20 > 2676208 bytes read in 41 ms (62.2 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Error: Cannot initialize UEFI sub-system, r = 20 > EFI LOAD FAILED: continuing... > BOOTP broadcast 1 > DHCP client bound to address 192.168.1.171 (121 ms) > *** ERROR: `serverip' not set > > (Text is actually from a test that Fedora's configuration > at the time was getting the same sort of problem from its > u-boot build. The text just happened to be handy to grab.) > > It seemed that such a device needed to be plugged in after > u-boot was no longer involved (and to be unplugged before > u-boot would again be involved). > > I mention this because having multiple SATA drives possible > might be an example of multiple storage LUNs for a single > USB device. There is: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983 > > that starts before the u-boot tie was known and progresses > through it being discovered --and that mistakenly indicates > "Closed FIXED" to indicate that it was not a FreeBSD > problem. (No problem was "fixed": just isolated to not > be FreeBSD's problem.) > END QUOTE > > To my knowledge, you would have to adjust U-Boot's > configuration to complete ignore USB in order to > work around U-Boot's problem for such contexts. > Looks like Robert Crowston provided some notes > that go in this driection. > > There might be multi-storage-device (each single > LUN) that also have problems, for all I know. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) I think you’ve hit the nail on the head. It’s a 2 SATA drive USB enclosure and I see errors just like this. > On 3 Jul 2021, at 14:41, Robert Crowston <crowston@protonmail.com> wrote: > > You could create a boot script ("u-boot.scr") and place it in the root of your sd card alongside u-boot. U-boot will interpret it at start up. You can use that to modify the "boot_targets" variable such that it doesn’t scan for usb drives, or so that it tries to load from mmc first. > > As I recall part of the problem is there are several mmc-like devices on the pi4 and the one we want is the third one (mmc2). That’s quite low in the boot priority order. > > First you should become a little familiar with what u-boot is doing when it probes your devices. I’d suggest plugging in a keyboard (or a serial console) and interrupting the automatic boot. Once you know how to make it boot from mmc, you can encode that in a script. > > u-boot.scr is a compiled file, so you need the “mkimage” tool from u-boot. > > I’m not sure if this is the best way, perhaps I am overcomplicating it. Good luck. > > — RHC. Thank you for the pointer, I’ll look into this, it sounds promising.