A config.txt file is required on Pi5 to indicate that this is an RPi bootable partition. Previous bootloaders user the presence of a start.elf as a cue but that doesn't exist on Pi5.I've been preparing a tryboot based boot flow for a while now and everything works well on Pi4/5. I'm using a primary tiny FAT32 (1984 sectors/~1MB) containing only the autoboot.txt file and two additional system partitions 2 and 3. And a forth data partition, but that's irrelevant for this post.
When I tried the same on a Pi3, it didn't boot and I had to make these modifications:
- Only autoboot.txt isn't enough. I also had to add an empty `config.txt`. I'm not entirely sure why.
- At least on my Pi3, the minimal partition above doesn't boot. I got a FAT16 partition with 4160 sectors (~2MB) working.
Requiring a config.txt file from Pi5 gives some some flexibility if a future board design needed some sort of explicit configuration hook i.e. we can check for the absence of it in config.txt before attempting to load a potentially incompatible kernel.
In order to avoid bootrom failures the bootrom will scan partitions to find the first 'FAT like' partition containing a bootcode.bin. In an A/B setup on Pi3 or earlier I think the limitation is that bootcode.bin must be present on partition 1 and only on that partition. That does unfortunately mean that there is no redundancy for bootcode.bin but that is almost never updated. It might be possible to have that on a read-only EMMC partition but I think other bits of plumbing would be required and right now the focus on OTA is for Pi4 and newer..I'm slightly confused on why this works though: tryboot (from what I see) has been introduced in 2020, so after the Pi3 was released. So its burned in stage 1 bootloader probably doesn't know anything about `tryboot_a_b` or `[tryboot]` in autoboot.txt. Yet with the above it still seems to work as expected. I don't have a serial debugger attached to look into what happens during the boot process, but I guess `bootcode.bin` is loaded from either the second or third partition? This potentially violates the complete separation of A and B in case it's always loaded from the second partition? Or maybe it relies on stage 1 quirks when parsing the suggested autoboot.txt format, as it only parses the first boot_partition setting?
IIRC FAT12 isn''t supported by the SoC bootrom so it wouldn't be able to load bootcode.bin. The reason support was added in Pi4 / Pi5 flash bootloader was for minimal ramdisk images. This wasn't intended for use as SD/EMMC partitions.The primary partition type requirements also also a bit unclear to me. The documentation says: "Bootable partitions must be formatted as FAT12, FAT16 or FAT32 and contain a start.elf file (or config.txt file on Raspberry Pi 5) in order to be classed as be bootable by the bootloader.", but I didn't get a tiny FAT12 partition to boot. There have been earlier experiments which seems to confirm that FAT12 isn't supported by (at least) the burned in stage 1 boot loader.
Statistics: Posted by timg236 — Fri Nov 28, 2025 11:02 am