Digital signatures for RP2350 boards

Development
59

I’ve been giving this some thought, and I think it can be skipped under our use cases. Specifically, the below solution is permissible because OTP is not a rewritable medium, only appendable.

Thus, have the following situations:

  1. Rev0 applied to all directory entry items
  2. Rev1 (or higher) applied to all directory entry items
  3. Rev0 applied to first N entries, later entries appended with a higher revision

The use of the iterator allows a simple solution:

  • Today, no special code needed.
  • If non-compatible change needed, then define a record type that increases the version of subsequent records.

Here’s what it would look like:

  1. [Rev0 item] [Rev0 item] [Rev0 item] ...
  2. [Rev1 ID->] [Rev1 item] [Rev1 item] ...
  3. [Rev0 item] [Rev0 item] [Rev1 ID->] [Rev1 item] [Rev1 item] ...

Benefits:

  • YAGNI … don’t write code we don’t need.
  • Callers are insulated from the changes when using the helper functions (which use an iterator).
  • Really simple way to allow OTP directory programmed with earlier revision to support later revision.

So, no specific changes need to be added today for this support. Also, forcing use through the iterator allows many other changes to the OTP directory entry in future (e.g., entry to create gaps in the directory, etc.).

2 Likes