[sw,rom_ext] Add dual-redundancy boot_data writing algorithm

[sasdf]

This commit introduces a new dual-redundancy scheme for writing boot data to flash. Instead of the legacy circular writing scheme, which is now renamed to boot_data_write_old, the new boot_data_write function ensures that a valid and consistent entry is written to the first index of both boot data pages.

Key changes:

• Renamed the legacy boot_data_write to boot_data_write_old (for compatibility testing).
• Implemented the new boot_data_write using a dual-redundancy algorithm.
• Added boot_data_redundancy_check to verify consistency between the two pages.
• Updated rom_ext_start to automatically repair boot data using the redundancy check.

Size difference:

rom_ext	size	Δoriginal	Δfeature
Original	52668	+0	+0
New boot_data_write	52604	-64	-64
+ redundancy fix	52756	+88	+152
(Features below could be omitted if size is a concern)
+ hardening	52804	+136	+48
+ two entries per page	52844	+176	+40
+ boot log event	52860	+192	+16

Coverage:

Full coverage of the added code is verified manually with the following command.

./bazelisk.sh coverage --config=ot_coverage \
  //sw/device/silicon_creator/lib:boot_data_functest_fpga_cw340_rom_with_fake_keys

genhtml -o /tmp/$USER/coverage --ignore-errors inconsistent,unsupported \
  bazel-out/_coverage/_coverage_report.dat

[siemen11]

Thank you for the changes to the ROM_EXT! These changes are highly important to secure the rollback mechanic of the boot.
However, if I understand correctly, if all boot_data entries are invalidated (the two indices per page and the two pages of boot_data), then the ROM_EXT will proceed with loading a default boot data (which has security version 0) to all copies in flash. This invalidation could have been done through adversarial means.
Given the attacker has an old BL0 (with a lower security version), this means that it can be correctly loaded giving a rollback.
Please let me know if I misunderstood the logic. Maybe we can discuss the change in a meeting?

[sasdf]

if all boot_data entries are invalidated, ...

The update flow is designed to ensure that the inactive page is written and verified via read-back before the active page is updated. This guarantees that at least one valid entry is available at all times, preventing an unintended fallback to the default boot data.

With the new scheme, entries are categorized as either:

1. Valid (with correct hashes)
2. Invalid (erased, partially programmed, or physically corrupted)

In scenarios where a page becomes corrupted (e.g., due to power loss), we always write the new data to that corrupted page first. This makes it impossible to invalidate all entries simultaneously without a direct physical attack.

[cfrantz]

This change LGTM, but I'd really like to make sure there is a test to validate that the approach of writing two records to each page.

[sasdf]

Thanks. The latest commit introduced tests for various entry validity combinations within the page. The write_empty_test handles cases where all entries are invalid, while subsequent tests cover the remaining scenarios: invalid/valid, valid/invalid, and valid/valid.

Each of these tests reads back all four entries to verify that boot_data_write has updated all of them accordingly.

[sasdf]

In addition to the requested changes, I included two minor follow-up commits:

• boot_data_check() during read-back verification to confirm that new data indeed verifies correctly, preventing a write from potentially invalidating all entries.
• Ignore redundancy fix error codes in ROM_EXT to avoid non-rescuable boot loops.

[siemen11]

Thank you for the offline discussions, change looks good to me!