Booting from USB on RPI3

[Mark Millard]

On 2020-Apr-25, at 15:26, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, Apr 24, 2020 at 09:32:13PM -0700, Mark Millard wrote:
> [much snippage] 
>> 
>> 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 .
>> 
> 
> 
> I looked at that page but didn't read far enough 8-(  It's 
> possible my Pi3 requires a microSD card, but the "no rainbow 
> screen" doesn't prove anything.  
> 
>> 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. 
>> 
> This Pi3 blinks once, very briefly. Hard to catch in the act.

The just-below indicates that the vintage of bootcode.bin
could well matter for "blinks just once".

>> 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.
>>>> 
> 
> Sticking the existing microSD in a USB adapter and trying to
> boot it is easy and worth a try, if only to debunk my claim
> that this particular Pi3 _requires_ a microSD card to start. 

See the later note about /etc/fstab .

>>> 
>>> 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).
>> 
> 
> Don't think I mentioned it. The experiment was flawed and done
> without sufficient care, the results too confusing to recount.
> I was looking at the serial console and screen, not the LEDs.
> When it didn't respond I just accepted the Pi needed a card.
> 
> The larger question is now raised 8-)
> 
> The machine is still chewing away at buildworld. No "indefinite
> wait" warnings, but it's panic'd twice with
> panic: non-current pmap [long hex number]
> So far buildworld has picked up where it left off, but there's
> still plenty of time for things to go wrong. 

There recently has been updates to the dts's and then to the
u-boot ports (some just via u-boot-master --but rpi3 and
rpi4 have updates as well). If you are to report details
from the non-current pmap panics at some point, you probably
should indicate the stage(s) of materials involved as part
of that.

(I've not noticed any updates to the rpi-firmware port.)

> At the next convenient pause I'll stick the microSD card in 
> a USB adapter and watch the LEDs, then look at the serial
> console. 

/etc/fstab on the microsdcard likely will need to be
adjusted if you still have a /dev/mmcsd0* or
/dev/da0* style of notation in use there.

One of the advantages of getting labeling set up
correctly/uniquely is that the label based notation
stays the same no matter which way/place the media
is plugged in.

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