We need to be able to change board names on update

[cbiffle]

Currently, update-server won't accept an update if the board name in the caboose doesn't match the board name of the current image. This is generally good and right.

However, it's becoming apparent that this might need to change. The Gimlet E/F revs are not different to firmware, so we'd sure like to make a combined gimlet-ef image that covers both -- but the gimlet-e boards currently deployed wouldn't accept such a thing. For now, we're going to make separate E and F images.

One possible approach to this: include multiple BORD chunks in the caboose of the firmware and accept the image if any one names the current board. That isn't future-proof though, where if we make a mostly-identical G rev for design-for-manufacturing reasons, it should be able to run the existing E/F firmware... but its name won't be in the caboose yet.

So, maybe we need something more nuanced.

@Aaron-Hartwig @labbott @mkeeter @jgallagher

[cbiffle]

Another option would be to transition the BORD over to naming revisions that actually rewire stuff or otherwise change firmware compatibility, and list hardware revision somewhere else... where future Gimlet revs will likely not change the firmware-oriented revision but will bump hardware revision.

[mkeeter]

Transitioning BORD / target_board to mean "Hubris Compatibility Version" (RFD 438) seems sensible to me. It looks like the RFD doesn't specify a format, but the hypothetical gimlet-ef makes sense and matches what we do elsewhere in Hubris.

How about releasing a trampoline update that looks for a CMPT ("compatible") array in the new image, and allows an upgrade if BORD is contained in CMPT (even if BORD doesn't match between new and old)?

Here's what that would look like:

BORD	CMPT	Notes
gimlet-e	(not present, not used)	Current state
gimlet-e	(not present, checked if BORD doesn't match)	Upgrade trampoline
gimlet-ef	[gimlet-e, gimlet-f]	New steady state

(we could remove CMPT later, or leave it be)

I think this solves the Rev G problem from the first comment: we could release an image with BORD = gimlet-efg, CMPT = [gimlet-e, gimlet-f, gimlet-ef, gimlet-efg] to allow for upgrades from EF → EFG.

(Alternatively, we could pick a Hubris Compatible Version naming scheme that doesn't need changing if a new compatible board revision is released)

[cbiffle]

I like the CMPT idea, it's sort of similar to the DeviceTree compatibility family notion I alluded to in the huddle. This would give an image a way of stating that it is deliberately trying to replace a set of other images and potentially change the BORD name as a result.

[cbiffle]

(Nitpick: I haven't been saying "Hubris Compatibility" because it's really compatibility with the Oxide Gimlet firmware components; Hubris-proper doesn't rely on any of this.)

[Aaron-Hartwig]

It looks like the RFD doesn't specify a format

@mkeeter it does not, but we certainly could! I'd mostly written that RFD for my own sake since I was having the same conversations with people getting caught up on the nomenclature.

(Nitpick: I haven't been saying "Hubris Compatibility" because it's really compatibility with the Oxide Gimlet firmware components; Hubris-proper doesn't rely on any of this.)

@cbiffle in the discussion for 438 there is a long thread about what to call this. I'd advocated for Hubris Compatibility Version because I felt that was the most explicit. It is something that is trying to indicate some compatibility for a Hubris image. I'm happy to entertain changing the terminology here as it has yet to really proliferate at all. Would you rather have something more general, like "Firmware Compatibility Version"?