Re: Troubles booting Pi2 from USB using bootcode.bin method

From: Mark Millard via freebsd-arm <>
Date: Thu, 28 Oct 2021 00:02:27 UTC

On 2021-Oct-27, at 15:37, Mark Millard <> wrote:

> On 2021-Oct-27, at 10:39, Mark Millard <> wrote:
>> On 2021-Oct-27, at 09:28, bob prohaska <> wrote:
>>> On Sun, Oct 24, 2021 at 08:43:32PM -0700, bob prohaska wrote:
>>>> I've got an early Pi2B (not plus) that has been booting reliably
>>>> from a USB2 disk connected via a USB3 hub using just bootcode.bin
>>>> and timeout on the DOS partition of the microSD card.
>>> It turns out the USB3 disk boots normally _provided_ the old
>>> USB2 disk remains connected. I didn't try that initially both
>>> because I didn't need both disks and because the boot order 
>>> couldn't be obviously controlled. 
>>> It turns out the new disk is discovered first and boots as 
>>> desired, so the system is busy building an up-to-date world
>>> and kernel. There's room for a ports tree on this disk.
>>> Does the ports version of u-boot include support for the
>>> bootcode.bin-only mode of USB booting?
>> Before U-Boot is involved there are other files involved
>> such as a start* file from the USB device. With appropriate
>> config.txt content, and possibly other settings, the boot
>> is likely rather explicit about its early activity. (But I
>> do not currently have access to a RPi2B v1.1 or earlier to
>> test the details on. In fact, the accessible only RPi*'s
>> are RPi4B 8 GiByte ones.)
>> (I wondered if you meant RPi3B: To my knowledge there is
>> no such thing as a RPi2B+ so the "plus" reference suggests
>> an early RPi3B might have been what was involved.)
>>> Right now I'm using
>>> the version of bootcode.bin offered at 
>>> Without having the USB2 disk connected the serial console hangs
>>> with what looks like "cb" as the only output. It's unclear if
>>> u-boot is starting at all. The red and green LEDs remain lit,
>>> seemingly indefinitely. 
> Your specific path may be different, but what does a command
> analogous to the below show for you for the problematical
> context?
> # strings /boot/efi/start.elf | grep "VC_BUILD_"
> VC_BUILD_ID_TIME: 12:12:09
> VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
> I'll note that there is:
> bootcode.bin UART Enable
> For boards pre-Raspberry Pi 4, Model B.
> For information on enabling the UART on the Pi4 bootloader, please see this page.
> It is possible to enable an early stage UART to debug booting issues (useful with the above bootcode.bin only boot mode). To do this, make sure you’ve got a recent version of the firmware (including bootcode.bin). To check if UART is supported in your current firmware:
> strings bootcode.bin | grep BOOT_UART
> To enable UART from bootcode.bin use:
> sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin
> Next, connect a suitable USB serial cable to your host computer (a Raspberry Pi will work, although I find the easiest path is to use a USB serial cable since it’ll work out the box without any pesky config.txt settings). Use the standard pins 6, 8 and 10 (GND, GPIO14, GPIO15) on a Pi or CM board.
> Then use screen on linux or a Mac or putty on windows to connect to the serial.
> Setup your serial to receive at 115200-8-N-1, and then boot your Pi / Compute module. You should get an immediate serial output from the device as bootcode.bin runs.
> That text is from:

For more debug information on the serial console, but somewhat later
in the sequence than the output for BOOT_UART=1, config.txt can


The debug output is before U-Boot starts but likely does indicate the loading
of u-boot.bin (as the kernel) and when in the sequence it is about to
start code in u-boot.bin . (It may also report more at shutdown.)

Mark Millard
marklmi at
( went
away in early 2018-Mar)