Booting from USB on RPI3

Sat Apr 25 04:32:22 UTC 2020

On 2020-Apr-24, at 20:00, bob prohaska <fbsd at www.zefox.net> wrote:

> 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.

Okay.

>> 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. 

Ahh. I see now what you were referring to.

>> 
>>> 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.

Understood.

>> 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.

That is not what:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=58151

reports relative to what causes the rainbow screen 
on the RPi3*'s (and when). Code from start.elf is what draws
the rainbow screen (as part of testing the GPU). start.elf
comes after bootcode.bin .

Here is the sequencing documented that leads to the rainbow
screen:

QUOTE
. . . uses its MMC hardware to attempt to read a file from a MMC compatible device. On the Pi, this is the SD card; the file should be on a FAT16 or FAT32-compatible filing system, and is called bootcode.bin. At this point, the ARM CPU is still in reset, so the contents of bootcode.bin are executed by the dedicated processor of the GPU: this code has more smarts, and can read the next file called start.elf, which in turn reads and interprets config.txt. It configures things like memory and Video/HDMI modes, console frame buffers, tests the GPU (resulting in the "rainbow screen"), and then handles the loading and configuring of the Linux Kernel (addresses, device tree, uart/console baud rates and suchlike). Only after this is the ARM CPU started, to execute the kernel code.
END QUOTE

(For FreeBSD that "kernel code" above is not the FreeBSD
kernel yet: more stages before reaching that point.)

Early on the LEDs are what needs to be looked at:

QUOTE
Error ACT LED patterns (for RPI up-to but not including RPI4
While booting, the ACT LED should blink in an irregular pattern, indicating that it is reading from the card. If it starts blinking in a regular, Morse code-like pattern, then it is signalling an error. 

If it blinks just once, it could be that you have a Raspberry Pi with SDRAM from Micron. If the processor has a logo showing an M with an orbit around it, then using the latest software should solve your problem. Also make sure you are using a 4GB SD card, as a 2GB won't work in this particular case.

These are the other patterns that the ACT LED might show during a failed boot, together with their meanings (the below blink codes are NOT valid for a RPI4, read the RPI4 section for ACT LED flash messages!):

* 3 flashes: start.elf not found
* 4 flashes: start.elf not launch-able (corrupt) See below: (not valid for RPI4! On an RPI4 four flashes means no boot code found!)
* 7 flashes: kernel.img not found
* 8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf firmware, or your SDRAM is damaged
END QUOTE

(Same URL.)

>>> 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.

I did not remember that you had done so. That would be
approximately what I was suggesting (depending on what
materials were on the USB flash drive).

> Nothing happened, not even an
> output on the serial console. No powered hub in the loop.

Got it.

>>> 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? 

Apparently you had already done analogous experiments.
So my idea provided little or nothing new.

> 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.  

Cool.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)