Date: Sat, 25 Apr 2020 17:20:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Booting from USB on RPI3 Message-ID: <B27E50C5-4D9C-4C51-A588-D38B4C07CF44@yahoo.com> In-Reply-To: <20200425222657.GA11076@www.zefox.net> References: <20200423233259.GD3996@www.zefox.net> <74DB7BC9-8F60-404B-BF7B-02B06D5A1011@yahoo.com> <20200424021808.GA4638@www.zefox.net> <F0C464CD-2E1A-487C-97D3-D79C7A197132@yahoo.com> <20200424195953.GA6707@www.zefox.net> <5FA69E16-72DE-4175-A0FB-BEFA1A865633@yahoo.com> <20200425001743.GA7044@www.zefox.net> <5A943B45-FE58-452D-BBC5-534756782276@yahoo.com> <20200425030008.GB7044@www.zefox.net> <592BD226-145D-4A89-81E4-257FB20624FE@yahoo.com> <20200425222657.GA11076@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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]=20 >>=20 >> https://www.raspberrypi.org/forums/viewtopic.php?f=3D28&t=3D58151 >>=20 >> reports relative to what causes the rainbow screen=20 >> 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 . >>=20 >=20 >=20 > I looked at that page but didn't read far enough 8-( It's=20 > possible my Pi3 requires a microSD card, but the "no rainbow=20 > screen" doesn't prove anything. =20 >=20 >> Here is the sequencing documented that leads to the rainbow >> screen: >>=20 >> 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 >>=20 >> (For FreeBSD that "kernel code" above is not the FreeBSD >> kernel yet: more stages before reaching that point.) >>=20 >> Early on the LEDs are what needs to be looked at: >>=20 >> 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.=20 >>=20 > 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. >>=20 >> 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!): >>=20 >> * 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 >>=20 >> (Same URL.) >>=20 >>>>> I gather the Raspberry Pi Foundation didn't more widely=20 >>>>> publicise the boot-from-usb feature because it didn't work=20 >>>>> with a too-large fraction of USB storage devices. >>>>=20 >>>> Which leads to an alternate experiment: a different USB >>>> "drive", one without the long wait. >>>>=20 >>>> 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. >>>>=20 >=20 > 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.=20 See the later note about /etc/fstab . >>>=20 >>> 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. >>=20 >> 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). >>=20 >=20 > 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. >=20 > The larger question is now raised 8-) >=20 > 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.=20 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=20 > a USB adapter and watch the LEDs, then look at the serial > console.=20 /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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B27E50C5-4D9C-4C51-A588-D38B4C07CF44>