Trouble USB booting with firmware in images since 2026-04-14

[jocave]

Describe the bug

I can no longer USB boot my Raspberry Pi Zero 2 W using rpiboot and the firmware included in releases of e.g. Raspberry Pi OS Lite arm64 (trixie) since 2026-04-14. I believe this corresponds to the the raspi-firmware deb package version 1.20260408-1

To reproduce

• On the dev pc, download an official image pre-change image from the archive e.g. 2025-12-04. This will be the source of the expected behaviour output.
• Uncompress, loop mount the img, mount the boot partition
• A directory is now available with the firmware containing bootcode.bin, config.txt, ... etc
• Using any released version of rpiboot run sudo ./rpiboot -d path/to/mounted-firmware-dir
• Connect the rpiz2 using USB to the development host (no SD Card present)

Expected behaviour

The firmware files are read, initramfs and kernel loaded and second stage boot completed

RPIBOOT: build-date 2026/02/11 pkg-version 20260210~145518 

Please fit the EMMC_DISABLE / nRPIBOOT jumper before connecting the power and USB cables to the target device.
If the device fails to connect then please see https://rpltd.co/rpiboot for debugging tips.

Loading: /mnt/boot/bootcode.bin
Waiting for BCM2835/6/7/2711/2712...

Loading: /mnt/boot/bootcode.bin
Sending bootcode.bin
Successful read 4 bytes 
Waiting for BCM2835/6/7/2711/2712...

Loading: /mnt/boot/bootcode.bin
Loading: /mnt/boot/bootcode.bin
Second stage boot server
Cannot open file autoboot.txt
Loading: /mnt/boot/config.txt
File read: config.txt
Cannot open file recovery.elf
Loading: /mnt/boot/start.elf
File read: start.elf
Loading: /mnt/boot/fixup.dat
File read: fixup.dat
Cannot open file recovery.elf
Loading: /mnt/boot/config.txt
File read: config.txt
Cannot open file dt-blob.bin
Cannot open file recovery.elf
Loading: /mnt/boot/config.txt
File read: config.txt
Cannot open file bootcfg.txt
Cannot open file recovery8.img
Loading: /mnt/boot/kernel8.img
Loading: /mnt/boot/initramfs8
Loading: /mnt/boot/initramfs8
File read: initramfs8
Loading: /mnt/boot/bcm2710-rpi-zero-2-w.dtb
File read: bcm2710-rpi-zero-2-w.dtb
Loading: /mnt/boot/overlays/overlay_map.dtb
File read: overlays/overlay_map.dtb
Loading: /mnt/boot/config.txt
File read: config.txt
Loading: /mnt/boot/overlays/vc4-kms-v3d.dtbo
File read: overlays/vc4-kms-v3d.dtbo
Loading: /mnt/boot/cmdline.txt
File read: cmdline.txt
Cannot open file armstub8.bin
Loading: /mnt/boot/kernel8.img
File read: kernel8.img
Second stage boot server done

Actual behaviour

Performing the same steps with either 2026-04-14 or 2026-04-21 results in:

RPIBOOT: build-date 2026/02/11 pkg-version 20260210~145518 

Please fit the EMMC_DISABLE / nRPIBOOT jumper before connecting the power and USB cables to the target device.
If the device fails to connect then please see https://rpltd.co/rpiboot for debugging tips.

Loading: /mnt/boot/bootcode.bin
Waiting for BCM2835/6/7/2711/2712...

Loading: /mnt/boot/bootcode.bin
Sending bootcode.bin
Successful read 4 bytes 
Waiting for BCM2835/6/7/2711/2712...

Loading: /mnt/boot/bootcode.bin
Second stage boot server
Cannot open file autoboot.txt
Loading: /mnt/boot/config.txt
File read: config.txt
Cannot open file recovery.elf
Loading: /mnt/boot/start.elf
File read: start.elf
Loading: /mnt/boot/fixup.dat
File read: fixup.dat
Cannot open file recovery.elf
Loading: /mnt/boot/config.txt
File read: config.txt
Failed to write complete file to USB device

Could you let me know if this is a bug in the newly released firmware or is there something I'm missing about how rpiboot works that means this is actually expected behaviour? Is there some of other step I'm missing that should keep the board booting with newer images? Thanks

[jocave]

@timg236 I wondered if you might be able to comment on whether the issue above is a valid bug with the firmware or not?

[pelwell]

Yours is a very niche use case, and we're not short of things to work on.

Given that it's always possible to recover from a non-booting device, you could really help the investigation if you can narrow it down to a change in only one or two files.

1. You can see from the output of rpiboot which files it is accessing. Start by copying all of those files from a working image into a local directory and confirm that it boots.
2. One at a time, copy those files from the non-working image and see if it still boots. If it fails, rewind that file back to the known-working version and move on to the next file. N.B. Treat start.elf and fixup.dat as a pair that must match - either update them both or neither. Remember the combinations that you test and the outcomes.
3. At the end of that process you may have identified a number of files that cause a problem. If you haven't already done so, try with updated versions of those files one at a time (apart from the start/fixup pair) on top of an otherwise all-old set. Ideally you would try all combinations of old/new versions of each file/pair, but there might be too many of those.
4. Report your findings.

You may find it easier to grab the firmware files from this repo: https://github.com/raspberrypi/rpi-firmware/commits/master
There are also more versions to chooose from - every commit with "firmware" in the title is a candidate, but ignore the "kernel" commits - which will narrow it down further.

[timg236]

In addition to what @pelwell says, I would add that the preferred approach these days is to use a boot.img file to package boot directory plus kernel and initramfs. This the approach used for the mass-storage-gadget because it avoids dangers of timeouts in later stages of boot file-systems.
The make-boot-image script will build a fairly optimised boot.img file for you
https://github.com/raspberrypi/usbboot/blob/master/tools/rpi-make-boot-image