OTP whitelabel options for RP2350 boards

Development
74
The static assertion was valid.

For the whitelabel, I had only reserved four OTP rows, or eight total characters. Of those, the first character was a space, leaving seven characters for the actual per-board string.

// BP5XL was configured to use:
#define BP_OTP_PRODUCT_VERSION_STRING "5XL REV0"
// which gets a space inserted at front:
static const char  _product_string[] = " " BP_OTP_PRODUCT_VERSION_STRING;
// which really means:
_product_string[] = " BP5XL REV0";
//                   ....-....1.
// which as you can see is eleven characters

To make visibility and feedback easier, I’ve created draft PR 217 on github … Note that it’s to your otp_whitelabel branch.

Here's my current gameplan

  • Cleanup enough to build all platforms again
  • Byte-count instead of row count in BP_OTPDIR entries!
  • Reserve top 8 bits of BP_OTPDIR to identify classes of entries.
    • E.g., 0x8000'0000 → entry can be present multiple times
    • E.g., 0x4000'0000 → entry type is critical to further parsing (e.g., versioning increase for later records)
    • E.g., 0x2000'0000 → Embedded entry (no data, or trivial data <=16 bits stored directly within the directory entry).
  • Get helper functions, includingBP_OTPDIR related, working
    • Iterator functions based on FindFirst() / FindNext() mechanic, as agreed.
    • Helper function: Find single/first BP_OTPDIR entry of given type
    • helper function: Write string + BP_OTPDIR entry.
      • For a defined string type identifiers
      • Writes the string to requested start OTP row, ensuring null-terminated string as agreed
      • If successfully written, also creates the BP_OTPDIR entry.
    • Helper function: Find writable area, including variable criteria:
      • OTP page aligned start
      • OTP page aligned end
      • Allow soft-locked pages (for debugging purposes)
      • Disallow pages with single-bits already flipped … those are normally OK for ECC writes, because BRBP will hide that single-bit error.
    • Define entry types for:
      • each USB whitelabel string
      • BP_OTPDIRENTRY version == 1
      • … etc. …
  • Modify the USB WhiteLabel code to do the following:
    • Take as input, a structure with ALL possible input (strings, etc.)
    • If any of those entries already exist in BP_OTPDIR, validate they are identical (or fail with error)
    • Validate ALL strings as meeting unique USB whitelabel requirement BEFORE doing any OTP operations … string length offsets, strings will be in range, etc. … essentially a map of where all the data will end up.
    • Use BP_OTPDIR helper function to find page-start-aligned zone of sufficient size for whitelabel data (note: currently identical to the hardcoded 0xC0, but could be useful if an OTP area is unusable on a board).
      • Test by corrupting OTP rows 0x0C0…0x0FF first
    • Use BP_OTPDIR helper functions to write each of string entries + corresponding BP_OTPDIR entries
    • Continue as previously done…
      • Write the 16-row whitelabel structure
      • Write the whitelabel address
      • Write the whitelabel
  • Migrate the certificate stuff to use the above helper functions to find an area

One thing I currently struggle with is the process of adding new commands, and ensuring there’s at least default help text. As the project grows, this appears to be a likely source of growing pains, so I think it’ll be valuable to spend time to get a maintainable, hierarchical command set defined. Likely will be at least partly custom, due to “mode” entry / exit causing the addition and/or removal of commands as “valid” for the current state.

I’ll reply with a separate thread so discussions on improving / reorganization of the command structure can have the wisdom of all our contributors and watchers…

2 Likes