Re: Troubles booting Pi2 from USB using bootcode.bin method
Date: Thu, 28 Oct 2021 00:02:27 UTC
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 > > 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)