Raspberry Pi 4B: Have to run `rpiboot` twice to get it to boot my kernel

UtkarshVerma commented 11 months ago

Describe the bug

I have a dev directory containing these files:

$ ls dev
bcm2711-rpi-4-b.dtb  blink.img  bootcode.bin  config.txt  fixup4.dat  start4.elf

I pass this directory to rpiboot and my blink kernel works, but it takes two tries. I think this is related to https://github.com/raspberrypi/usbboot/issues/8.

$ ./rpidev -d dev
RPIBOOT: build-date Jul 13 2023 version 20221215~105525 c4b12f85
Loading: dev/bootcode.bin
Waiting for BCM2835/6/7/2711...
Loading embedded: bootcode4.bin
Second stage boot server
Loading: dev/config.txt
File read: config.txt
Cannot open file vl805.sig
Cannot open file pieeprom.sig
Cannot open file recover4.elf
Cannot open file fixup4rc.dat
Cannot open file recovery.elf
Cannot open file fixup_rc.dat
Loading: dev/start4.elf
File read: start4.elf
Loading: dev/fixup4.dat
File read: fixup4.dat
Second stage boot server done

$ ./rpidev -d dev
RPIBOOT: build-date Jul 13 2023 version 20221215~105525 c4b12f85
Loading: dev/bootcode.bin
Waiting for BCM2835/6/7/2711...
Loading: dev/bootcode.bin
Second stage boot server
Cannot open file recovery.elf
Loading: dev/config.txt
File read: config.txt
Cannot open file dt-blob.bin
Cannot open file recovery.elf
Loading: dev/config.txt
File read: config.txt
Cannot open file bootcfg.txt
Loading: dev/blink.img
Loading: dev/bcm2711-rpi-4-b.dtb
File read: bcm2711-rpi-4-b.dtb
Cannot open file overlays/overlay_map.dtb
Loading: dev/config.txt
File read: config.txt
Cannot open file cmdline.txt
Cannot open file armstub8-gic.bin
Loading: dev/blink.img
File read: blink.img
Second stage boot server done

I also notice that some files are being transferred again. This entire sequence takes 13s with -l set. Would it be possible to reduce this time somehow?

Steps to reproduce the behaviour

Set BOOT_ORDER=0xf31 in the EEPROM bootloader config.
Remove SD card and power on the board.
Run ./rpidev -d dev
Run it again to load the kernel

Device(s)

Other

Compute Module IO board.

No response

RPIBOOT logs

No response

Kernel logs

No response

Device UART logs

No response

UtkarshVerma commented 11 months ago

My use case is kernel development for the RPi 4B and I'm planning to use USB boot to load the kernel from my laptop. Since I'm fairly new to the RPi ecosystem, any suggestions would be highly appreciated.

On a side note, one doubt I'm having is with the need for bootcode.bin. Isn't it already in the EEPROM for RPi 4B? Why does the CLI tool still enforce that it is needed?

timg236 commented 11 months ago

Run "rpiboot -l" to keep it running.

N.B. Individual file loading is deprecated in favour of the boot.img ramdisk approach. The file-loading is prone to timeouts and is no longer maintained.

UtkarshVerma commented 11 months ago

Thanks for the update. I knew about the -l flag as mentioned in the issue description. #8 also had this issue and got a fix. Do I take it that this issue is only for single file loading and will go away if I use boot.img?

On a side note, one doubt I'm having is with the need for bootcode.bin. Isn't it already in the EEPROM for RPi 4B? Why does the CLI tool still enforce that it is needed?

Could you also please let me know about this? USB boot takes about 13s and I was just curious if removing bootcode would make it faster.

timg236 commented 11 months ago

Loading a boot.img means that bootloader loads a single large blob which avoids problems when there are delays between loading individual files.

rpiboot causes the bootrom to load the second-stage (bootcode.bin) from USB rather than the SPI EEPROM so it's not possible to get rid of bootcode.bin.

13s seems about right, unfortunately the only way to make this after is to make the kernel smaller

UtkarshVerma commented 11 months ago

Thanks a lot for the clarification and for this really handy tool. Regarding the kernel (blink example), it is only 332B, so I don't think it could be reduced. I guess this is just how USB boot performs and that is totally fine.

raspberrypi / usbboot