Redundancy - modified ramstage in Slot B won't load

[filipleple]

Component

Dasharo firmware

Device

Protectli VP6670, Protectli VP6650

Dasharo version

v0.9.3-rc3

Dasharo Tools Suite version

No response

Test case ID

No response

Brief summary

In a Top Swap Redundancy build, once Slot B (COREBOOT_TS) is modified, booting ends with

CBFS: Found 'fallback/postcar' @0x385840 size 0xf8a8 in mcache @0xfef8c6c8
VB2:vb2_digest_init() 63656 bytes, hash algo 2, HW acceleration unsupported
Loading module at 0x76b35000 with entry 0x76b35031. filesize: 0xe988 memsize: 0x14de8
Processing 952 relocs. Offset value of 0x74b35000
BS: romstage times (exec / console): total (unknown) / 1215 ms


coreboot-protectli_vault_adl_v0.9.3-rc3-40-g68c4a414dcd2-dirty-v0.9.3-rc4 Fri Jan 16 14:04:33 UTC 2026 x86_32 postcar starting (log level: 8)...
Normal boot
Starting cbfs_boot_device
CBFS: Found 'fallback/ramstage' @0x248780 size 0x246c5 in mcache @0x76b4d164
VB2:vb2_digest_init() 149189 bytes, hash algo 2, HW acceleration unsupported
CBFS ERROR: 'fallback/ramstage' file hash mismatch!
Ramstage was not loaded!

How reproducible

100%

How to reproduce

• Build with CONFIG_TOP_SWAP_REDUNDANCY=y,
• Flash onto the board,
• Note how both slots (Top Swap on and off) boot fine
• Modify Slot B, i.e. flash a slightly different binary to --fmap -i TOPSWAP -i COREBOOT_TS
• Try to boot from Slot B

Expected behavior

It should boot the newer version

Actual behavior

The newer version boots up to Ramstage was not loaded!

Screenshots

No response

Additional context

No response

Solutions you've tried

No response

[SergiiDmytruk]

Starting cbfs_boot_device

I wonder how this gets printed reliably but Booting from ... region is often missing. I would expect every stage to print both at least once. Anyway, postcar does in fact end up using COREBOOT even when TS is active as file size was suggesting before:

Normal boot
XXX Starting cbfs_boot_device(!force_ro)
XXX cbfs_boot_device region already initialized to 0x690000 of len 0x3f0000
CBFS: Found 'fallback/postcar' @0x1e0840 size 0x12d2c in mcache @0xfef8ce70
VB2:vb2_digest_init() 77100 bytes, hash algo 2, HW acceleration unsupported
VB2:vb2_digest_init() 77100 bytes, hash algo 1, HW acceleration unsupported
TPM: Digest of `CBFS: fallback/postcar` to PCR 2 logged
Loading module at 0x76b22000 with entry 0x76b22031. filesize: 0x11988 memsize: 0x18028
Processing 1241 relocs. Offset value of 0x74b22000
BS: romstage times (exec / console): total (unknown) / 290 ms


coreboot-protectli_vault_adl_v0.9.3-rc3-34-g4574a15eaf85-dirty-v0.9.3-rc4 Tue Jan 20 17:28:03 UTC 2026 x86_32 postcar starting (log level: 7)...
Normal boot
XXX Starting cbfs_boot_device(!force_ro)
XXX cbfs_boot_device region already initialized to 0xb00000 of len 0x3f0000
CBFS: Found 'fallback/ramstage' @0xa2d00 size 0x2536c in mcache @0x76b4d10c
VB2:vb2_digest_init() 152428 bytes, hash algo 2, HW acceleration unsupported
CBFS ERROR: 'fallback/ramstage' file hash mismatch!
Ramstage was not loaded!

The cause is that rtc code isn't compiled for postcar stage, therefore default weak version of cbfs_fmap_region_hint() gets utilized there. Updating src/soc/intel/common/block/rtc/Makefile.mk and src/soc/intel/common/block/pcr/Makefile.mk to list postcar seems to fix this.

[filipleple]

@SergiiDmytruk yes that was it!

ubuntu@3mdeb:~$ sudo dmidecode | grep Version
        Version: Dasharo (coreboot+UEFI) v0.9.3-rc3
        Version: 1.0
        Version: 1.0
        Version: Not Specified
        Version: 12th Gen Intel(R) Core(TM) i7-1255U
ubuntu@3mdeb:~$ sudo nvramtool -w attempt_slot_b=Enable
ubuntu@3mdeb:~$ sudo reboot
(...)
Last login: Wed Jan 21 10:09:58 2026 from 192.168.4.89
ubuntu@3mdeb:~$ sudo dmidecode | grep Version
[sudo] password for ubuntu:
        Version: Dasharo (coreboot+UEFI) v0.9.3-rc4
        Version: 1.0
        Version: 1.0
        Version: Not Specified
        Version: 12th Gen Intel(R) Core(TM) i7-1255U

Full successful capsule update log:

caps_FINAL.log