scripts: tt_boot_fs: support multiple descriptor table definitions

[danieldegrasse]

Overview

Add support for multiple descriptor table definitions within tt_boot_fs. This enables us to define an additional "mutable" descriptor table, chosen to reside at 0x17000. This table will change with each firmware revision, but the ROM table at 0x0 should no longer change. This will allow us to preserve a bootable change of rom -> mcuboot -> recovery image across all firmware updates, providing more reliable boot fallback.

Note

the commits in this PR are not bisect-able. To keep everything bisectable, all the code changes would need to be > moved into one commit, as they are not backwards compatible. I can do this if before we merge. For now, I kept commits smaller to aid inreview.

Technical details

This PR adds a "header table" at 0x120000 (offset was chosen because no firmware data lives at this address in current binaries or in pre 19.0 binary layouts)

The header table includes a magic number, version, and bootfs descriptor table count. Most boot images will have 3 descriptor tables:

• ROM table at 0x0 (fixed across updates)
• Failover table at 0x4000 (fixed across updates)
• Mutable table at 0x170000 (variable with updates)

Table offsets in flash are stored following the bootfs header itself as an array of 32 bit unsigned integers.

[danieldegrasse]

Moving this to a draft. We're going to require updates to luwen to understand the multi-bootfs format

[danieldegrasse]

tenstorrent/luwen#142 is needed for the bootfs format updates

[danieldegrasse]

tenstorrent/luwen#142 will be required in order to flash an update after loading firmware built from this PR

[danieldegrasse]

Considering this more, there might be a way to achieve the same update reliability without modifying the bootfs format. If we lock the copy of MCUBoot in use to a specific build (IE from v19.4.0), and do the same for the recovery image then the "safe" boot path could be via the failover descriptor.

Essentially if power was lost while writing to the flash, it could impact boot in the following ways:

a) power is lost while writing descriptor table at 0x0 -> Bootrom uses failover table, which still points to valid MCUBoot
b) power is lost while writing new CMFW -> Bootrom uses main table, runs MCUBoot, which selects recovery image as mission mode CMFW isn't valid

I'm not sure if this would work, but it should function in theory.

@afongTT or @alewycky-tenstorrent, do you have thoughts about this approach? It is less flexible, but would require significantly fewer changes and if we don't plan to reuse the bootfs code in the future it might be the easiest way to accomplish reliable boot

[danieldegrasse]

Considering this more, there might be a way to achieve the same update reliability without modifying the bootfs format. If we lock the copy of MCUBoot in use to a specific build (IE from v19.4.0), and do the same for the recovery image then the "safe" boot path could be via the failover descriptor.

Essentially if power was lost while writing to the flash, it could impact boot in the following ways:

a) power is lost while writing descriptor table at 0x0 -> Bootrom uses failover table, which still points to valid MCUBoot b) power is lost while writing new CMFW -> Bootrom uses main table, runs MCUBoot, which selects recovery image as mission mode CMFW isn't valid

I'm not sure if this would work, but it should function in theory.

@afongTT or @alewycky-tenstorrent, do you have thoughts about this approach? It is less flexible, but would require significantly fewer changes and if we don't plan to reuse the bootfs code in the future it might be the easiest way to accomplish reliable boot

#961 validates that we can boot via the failover descriptor. However, I still think we should move forwards with this PR- it isn't high priority, but there is at least one failure case we can't recovery from: part of the tt_boot_fs header is erased, so the ROM tries to load images like the ethfw or ethfwcfg into CSM. These images aren't loadable by the bootrom and would cause a crash if it tried to copy them

[alewycky-tenstorrent]

Do we use the mutable table during boot? If so, what point in the boot process? Will all the non-recovery images be in the mutable table?

[danieldegrasse]

Do we use the mutable table during boot? If so, what point in the boot process? Will all the non-recovery images be in the mutable table?

We use the mutable table during the boot of mission mode firmware- so once MCUBoot launches the mission mode CMFW, we start reading from the mutable table. The DMFW never uses the mutable table definition.

All non-recovery images will be in the mutable table, yeah. The idea is that no mutable data is stored in the failover descriptor at 0x4000 or the ROM descriptor at 0x0, so these will not change between updates