Booting from USB on RPI3

[bob prohaska]

On Fri, Apr 24, 2020 at 05:47:33PM -0700, Mark Millard wrote:
> On 2020-Apr-24, at 17:17, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> > On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote:
> > [huge snip, hope nothing vital was lost]
> >> 
> >> Now that using both the microsd card and USB drive
> >> as a pair to boot has been shown to work, have you
> >> made the USB drive match what is used on from
> >> the microsd card (such as the msdos file system)
> >> and checked what the USB drive does without
> >> involving the microsd card?
> >> 
> >> (Although, I wonder if the "10 sec" issue ends up
> >> involved, possibly blocking this way of working.)
> > 
> > No. If there's no microSD at all the Pi3B is simply inert
> > on power-up. No rainbow screen, no serial console, nothing. 
> > The OTP boot-from-usb bit is set according to Raspbian,
> > so mine is one of the Pi3's that requires a microSD card.
> 
> Is the RPi3 attached to a powered USB hub? 
Yes.

> Directly to the USB drive? 
Tried that long ago, the power supply on the Pi couldn't cope.
No obvious reason to think it'd be different now.

> A different, probably better, experiment is suggested
> later, one that avoids this USB drive.
> 
> > If there's no microSD filesystem to fall back to, maybe
> > u-boot would keep trying until the USB hard drive woke up.
> 
> u-boot would have to load from someplace and be started
> first in order to be involved at all. The initial code
> is not u-boot code but code internal to the SoC (internal
> firmware).
The Pi3 is able to load bootcode.bin (alone)  from the 
microSD promptly.  Then u-boot can rattle the USB drive. 
If there's nothing else to boot on the microSD it might 
keep trying, how long I don't know. 

> 
> > Somebody also mentioned recompiling u-boot with a longer 
> > timeout, not an unreasonable step.  For now I'll declare 
> > victory and retreat 8-)
> 
> Such would not change the internal firmware code involved
> in looking for msdos file system(s) on mass storage devices
> with a bootcode.bin in the proper place. 
Thus the need for a microSD with a customizable bootcode.bin.

> If that code
> does not find the device in its time frame, bootcode.bin
> is not found and, so, not used.
> 
> Failing to find such a bootcode.bin means using the older,
> buggier code that is the reset of the internal firmware.
> This code is more likely to have problems with drives.
> 
Indeed, on mine it does not appear to even start. AIUI,
a Pi set up to boot without a microSD card should at least
flash the rainbow screen. Mine does nothing.

> > I gather the Raspberry Pi Foundation didn't more widely 
> > publicise the boot-from-usb feature because it didn't work 
> > with a too-large fraction of USB storage devices.
> 
> Which leads to an alternate experiment: a different USB
> "drive", one without the long wait.
> 
> Technically this could be a USB microsd card reader
> with the media you can boot from the microsd card
> slot: That might well prove that you can boot without
> use of the microsd card slot so long as the USB drive
> is compatibile. If yes: Then it becomes a case of
> selecting an appropriate USB drive and getting it set
> up.
>

Is there some larger question that I'm not recognizing?
I've tried a usb flash drive with FreeBSD on it a couple
of times with no microSD. Nothing happened, not even an
output on the serial console. No powered hub in the loop.
 
> > Having 
> > now seen the exercise in person, I understand their motives. 
> > There was absolutely no chance of success without the vast
> > amount of help I got on this list.  
> 
> Given the above possible experiment, are you sure that
> you want to give up now? 

What is the question to be answered? 

I wanted to see if buildworld works any better on a 
mechanical disk than a well-used microSD card. So far, 
the answer appears to be yes: Not a single "indefinite 
wait...." warning even when ~900 megs of swap is in 
use and the machine is crawling at around 70% idle.  

Thanks for reading!

bob prohaska