rpiboot asks for presence of bootcode files even when they are not used

[UtkarshVerma]

Describe the bug

I'm flashing a boot ramdisk to my Raspberry Pi 4 over USB. I just noticed that rpiboot always sends the embedded bootcode4.bin to my device, which means that I don't need a bootcode file anyway.

But if I don't have the bootcode in my directory, rpiboot complains about it not being there.

One other question I have is regarding the config.txt. To get USB boot to work, I had to have two copies of config.txt. One in boot.img and one in my directory. Is this normal or did I do it incorrectly?

Steps to reproduce the behaviour

1. Prepare a directory with config.txt (boot_ramdisk=1), boot.img.
2. rpiboot -d . -l
3. See error:

RPIBOOT: build-date Jul 13 2023 version 20221215~105525 c4b12f85
No 'bootcode' files found in '.'
Usage: rpiboot
   or: rpiboot -d [directory]
Boot a Raspberry Pi in device mode either directly into a mass storage device
or provide a set of boot files in a directory from which to boot.  This can
then contain a initramfs to boot through to linux kernel

To flash the default bootloader EEPROM image on Compute Module 4 run
rpiboot -d recovery

For more information about the bootloader EEPROM please see:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md

rpiboot                  : Boot the device into mass storage device
rpiboot -d [directory]   : Boot the device using the boot files in 'directory'
Further options:
        -l               : Loop forever
        -o               : Use files from overlay subdirectory if they exist (when using a custom directory)
                           USB Path (1-1.3.2 for example) is shown in verbose mode.
                           (bootcode.bin is always preloaded from the base directory)
        -m delay         : Microseconds delay between checking for new devices (default 500)
        -v               : Verbose
        -s               : Signed using bootsig.bin
        -0/1/2/3/4/5/6   : Only look for CMs attached to USB port number 0-6
        -p [pathname]    : Only look for CM with USB pathname
        -h               : This help

Device(s)

Other

Compute Module IO board.

No response

RPIBOOT logs

No response

Kernel logs

No response

Device UART logs

No response

[pelwell]

And what happens if you don't specify -d . ?

[pelwell]

To answer my own question, I think it only sends the embedded boot files, including the MSD version of start.elf.

rpiboot is intended to support booting of arbitrary Pis. Believing that it is better to fail early rather than wait until a device has been detected, it checks upfront for the presence of both bootcode.bin and bootcode4.bin. If you know that you don't need one or both of them then they can (I think, without testing) just be empty files.

One other question I have is regarding the config.txt. To get USB boot to work, I had to have two copies of config.txt. One in boot.img and one in my directory. Is this normal or did I do it incorrectly?

I can't give you a definitive answer on this, but I can see why you might need both. config.txt is used at multiple stages of booting - from bootcode when choosing a start.elf file, from start.elf when choosing a kernel, and for all the Device Tree processing, Under normal circumstances these multiple uses will all be from the same source (e.g. the SD card), but USB booting a boot.img is different.

First, the downloaded bootcode reads config.txt from somewhere so it knows what to do. It can't be boot.img because it doesn't know that it is needed, so it has to be your directory. There it finds boot_ramdisk=1, and requests boot.img. The start file in boot.img then requests config.txt, and because it has a ramdisk loaded it gets it from there.

It makes sense if you think about - the different stages of booting get different information from config.txt, and there's no reason why it should all come from the same file, even though it normally does. The initial config.txt needs to do little more than set boot_ramdisk=1, so you could cut it right down to help you understand how it works.

[UtkarshVerma]

Thanks for the explanation. Creating empty bootcode.bin works for me, and since this is the intended behaviour, I'll close the issue.