Date: Fri, 24 Apr 2020 21:32:13 -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: <592BD226-145D-4A89-81E4-257FB20624FE@yahoo.com> In-Reply-To: <20200425030008.GB7044@www.zefox.net> References: <20200423212614.GA3996@www.zefox.net> <328B7083-1119-43F1-A6E4-61F1FB9E922E@yahoo.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> On Fri, Apr 24, 2020 at 03:09:35PM -0700, Mark Millard wrote: >>> [huge snip, hope nothing vital was lost] >>>>=20 >>>> 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? >>>>=20 >>>> (Although, I wonder if the "10 sec" issue ends up >>>> involved, possibly blocking this way of working.) >>>=20 >>> No. If there's no microSD at all the Pi3B is simply inert >>> on power-up. No rainbow screen, no serial console, nothing.=20 >>> The OTP boot-from-usb bit is set according to Raspbian, >>> so mine is one of the Pi3's that requires a microSD card. >>=20 >> Is the RPi3 attached to a powered USB hub?=20 > Yes. >=20 >> Directly to the USB drive?=20 > 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. >>=20 >>> If there's no microSD filesystem to fall back to, maybe >>> u-boot would keep trying until the USB hard drive woke up. >>=20 >> 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=20 > microSD promptly. Then u-boot can rattle the USB drive.=20 > If there's nothing else to boot on the microSD it might=20 > keep trying, how long I don't know.=20 Ahh. I see now what you were referring to. >>=20 >>> Somebody also mentioned recompiling u-boot with a longer=20 >>> timeout, not an unreasonable step. For now I'll declare=20 >>> victory and retreat 8-) >>=20 >> 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.=20 > 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. >>=20 >> 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. >>=20 > 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=3D28&t=3D58151 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 . 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.=20 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=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 > 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=20 >>> now seen the exercise in person, I understand their motives.=20 >>> There was absolutely no chance of success without the vast >>> amount of help I got on this list. =20 >>=20 >> Given the above possible experiment, are you sure that >> you want to give up now?=20 >=20 > What is the question to be answered?=20 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=20 > mechanical disk than a well-used microSD card. So far,=20 > the answer appears to be yes: Not a single "indefinite=20 > wait...." warning even when ~900 megs of swap is in=20 > use and the machine is crawling at around 70% idle. =20 Cool. =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?592BD226-145D-4A89-81E4-257FB20624FE>