I am working particularly on the Compute Module 5. I was wondering if enabling secure boot disabled the PARTITION_WALK feature. I had luck with PARTITION_WALK before I enabled secure boot, which is why I am confused. I cannot seem to find any information online about this, perhaps I messed something up in the process? Some input from an engineer working on the bootcode would be greatly appreciated!
My plan was to do something like thisI would have an A/B bootloader scheme, and I did not put BOOTA on part 1 because ideally, I do not want to mount the current running boot partition as writable so I did not mess it up, in the case of something like editing autoboot.txt.
So the scheme would be kind of like OS running from slot A would write new boot and root to slot B, then edit autoboot.txt (on part 1) to try slot B etc.
However, when I tested this scheme and simulated an autoboot.txt corruption pointing to an unbootable partition, the bootloader failed to find a bootable partition, indicating that it is not walking at all. Infact, it printed a message on the hdmi monitor that it tried to load boot.img from partition 1 (which did not exist), and then failed, and then proceeded to restart the sequence trying again.
I have tested this with both MBR (with only 4 partitions) and GPT, I see the same phenomenon either way.
As a somewhat related side note, I know that PARTITION_WALK was not intended to provide A/B system behavior, but I personally believe that it is the only thing in the autoboot.txt scheme that can be relied on to provide this reliable A/B behavior. If while updating autoboot.txt, the system crashes, and the file is corrupted, without PARTITION_WALK, someone in my situation would have a bricked device in the field, no good. Now one may make the argument that because autoboot.txt is less than 512 bytes, which fits in a typical FAT sector and emmc block, that the chance for corruption is pretty small. However, A more elegant solution is don't have autoboot.txt at all, just have PARTITION_WALK, and always write to slot B for updates, when B decides to stay on the update, copy its contents to slot A, during the copy to slot A, the boot.img and boot.sig would be invalid until the copy is finished, and if a power failure were to happen during this, PARTITION_WALK would just boot back to slot B, so that B could finish its copy to slot A. Another elegant aspect to this design is that there are 2 copies of the OS at any time other than an update, which means the ability to detect and recover from corruption if so desired.
If for some reason, this is intended behavior, it is not the end of the world for me, I will find another way to do what I want, with some combination of boot config settings, recovery partitions etc. But it sure would be nice for PARTITION_WALK to work for me during secure boot, as building an A/B system with it is an extremely elegant and simple design.
If anyone is wondering, here is my bootloader config and information:
My plan was to do something like this
Code:
mkfs.vfat -F 32 -n PART1 "${DEV}p1" >/dev/nullmkfs.vfat -F 32 -n BOOTA "${DEV}p2" >/dev/nullmkfs.ext4 -F -L ROOTA "${DEV}p3" >/dev/nullmkfs.vfat -F 32 -n BOOTB "${DEV}p4" >/dev/nullmkfs.ext4 -F -L ROOTB "${DEV}p5" >/dev/nullmkfs.vfat -F 32 -n AUX1 "${DEV}p6" >/dev/nullmkfs.vfat -F 32 -n AUX2 "${DEV}p7" >/dev/nullmkfs.vfat -F 32 -n AUX3 "${DEV}p8" >/dev/nullSo the scheme would be kind of like OS running from slot A would write new boot and root to slot B, then edit autoboot.txt (on part 1) to try slot B etc.
However, when I tested this scheme and simulated an autoboot.txt corruption pointing to an unbootable partition, the bootloader failed to find a bootable partition, indicating that it is not walking at all. Infact, it printed a message on the hdmi monitor that it tried to load boot.img from partition 1 (which did not exist), and then failed, and then proceeded to restart the sequence trying again.
I have tested this with both MBR (with only 4 partitions) and GPT, I see the same phenomenon either way.
As a somewhat related side note, I know that PARTITION_WALK was not intended to provide A/B system behavior, but I personally believe that it is the only thing in the autoboot.txt scheme that can be relied on to provide this reliable A/B behavior. If while updating autoboot.txt, the system crashes, and the file is corrupted, without PARTITION_WALK, someone in my situation would have a bricked device in the field, no good. Now one may make the argument that because autoboot.txt is less than 512 bytes, which fits in a typical FAT sector and emmc block, that the chance for corruption is pretty small. However, A more elegant solution is don't have autoboot.txt at all, just have PARTITION_WALK, and always write to slot B for updates, when B decides to stay on the update, copy its contents to slot A, during the copy to slot A, the boot.img and boot.sig would be invalid until the copy is finished, and if a power failure were to happen during this, PARTITION_WALK would just boot back to slot B, so that B could finish its copy to slot A. Another elegant aspect to this design is that there are 2 copies of the OS at any time other than an update, which means the ability to detect and recover from corruption if so desired.
If for some reason, this is intended behavior, it is not the end of the world for me, I will find another way to do what I want, with some combination of boot config settings, recovery partitions etc. But it sure would be nice for PARTITION_WALK to work for me during secure boot, as building an A/B system with it is an extremely elegant and simple design.
If anyone is wondering, here is my bootloader config and information:
Code:
$ vcgencmd bootloader_config[all]BOOT_UART=0POWER_OFF_ON_HALT=1# Boot Order Codes, from https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER# Try SD(emmc) first, then repeatBOOT_ORDER=0xf1# Disable self-update mode - to prevent automatic updates of unsigned bootloader imagesENABLE_SELF_UPDATE=0# We rely on this for our a/b update schemePARTITION_WALK=1Code:
$ vcgencmd bootloader_version2025/12/08 19:29:54version 2226a853bb9f5fd80392e3a4a89e457aeca88008 (release)timestamp 1765222194update-time 1770159319capabilities 0x000000ffStatistics: Posted by chack131 — Wed Feb 04, 2026 8:08 pm — Replies 0 — Views 26