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

From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Thu, 28 Oct 2021 01:14:51 UTC

On 2021-Oct-27, at 17:02, Mark Millard <marklmi@yahoo.com> wrote:



On 2021-Oct-27, at 15:37, Mark Millard <marklmi@yahoo.com> wrote:

> On 2021-Oct-27, at 10:39, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2021-Oct-27, at 09:28, bob prohaska <fbsd@www.zefox.net> 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 
>>> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#special-bootcode-bin-only-boot-mode
>>> 
>>> 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_USER: dom
> VC_BUILD_ID_TIME: 12:12:09
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
> 
> I'll note that there is:
> 
> QUOTE
> bootcode.bin UART Enable
> 
> NOTE
> 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

That is a linux sed command for use on  RaspiOS*'s and the
like. In particular, for FreeBSD:

     -i extension
             Edit files in-place similarly to -I, but treat each file
             independently from other files.  In particular, line numbers in
             each file start at 1, the “$” address matches the last line of
             the current file, and address ranges are limited to the current
             file.  (See Sed Addresses.) The net result is as though each file
             were edited by a separate sed instance.

In other words: the "extension" is not optional after -i if I understand
right for FreeBSD.

> 
> 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.
> END QUOTE
> 
> That text is from:
> 
> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
> 

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

enable_uart=1
uart_2ndstage=1
dtdebug=1

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 yahoo.com
( dsl-only.net went
away in early 2018-Mar)


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