NVMEM Layouts for Variable-Length Factory Data: Discover Cells Instead of Hard-Coding Offsets
Use a layout parser when factory data has a defined structure but cell offsets vary with preceding records. The parser locates the fields and creates named NVMEM cells; consumers request those names rather than copying a byte offset from one sample EEPROM image.
This article uses the Linux 6.12 NVMEM interface and the stable v6.12.100 ONIE-TLV implementation as a concrete layout example. The illustrative calibration format below is original and is not ONIE. Locating a cell is separate from decoding its payload, proving its authenticity, or authorizing changes to manufacturing data.
1. Decide whether the offset is truly fixed
A fixed-cell description works when the storage contract guarantees the same offset and length across all supported units and format revisions. It becomes fragile when a variable-length product name, optional field or vendor record can move every later value.
The NVMEM layout documentation explicitly describes parsing structured content such as tag-length-value records and creating cells dynamically. It also allows layouts to associate post-processing hooks. These mechanisms do not mean the framework automatically understands an arbitrary factory format.
| Storage contract | Approach | Qualification question |
|---|---|---|
| Stable offset and fixed length. | Fixed cell definition. | Do all supported format revisions preserve that location? |
| Variable offset with defined tags and lengths. | Compatible layout parser and named cells. | Does the parser discover the same logical field in every valid arrangement? |
| Unknown or undocumented format. | Hold interpretation until its owner supplies a contract. | Can the field be identified without guessing from plausible bytes? |
Do not build a dynamic parser merely because one board contains a short string. First obtain the authoritative encoding, version rules, total bounds, integrity mechanism, tag namespace and duplicate-field policy.
2. Keep provider, layout and consumer responsibilities visible
The provider exposes access to the underlying nonvolatile region. The layout interprets the container and registers cell locations. The consumer obtains its assigned cell and validates the returned representation for its own use. Failure at any stage should remain distinguishable in diagnostics.
The v6.12.100 ONIE-TLV layout maps recognized tags to cell names, computes their offsets from the parsed table, and calls nvmem_add_one_cell(). It checks a format header and table checksum before adding cells. This is an example for its own format, not a calibration schema or a universal parser template.
Pin the exact deployed implementation. An older branch can differ in unknown-tag handling and parser progress, so “Linux 6.12” alone is insufficient evidence of identical behavior. Review the actual source and applicable fixes before production qualification.
3. Validate the container before trusting field locations
For the product’s parser, define an ordered acceptance procedure. Validate the header, supported format version and total region length first. Confirm every read returned the required bytes. Then validate the container’s documented integrity protection before publishing values that depend on it.
For each record, require enough bytes for its header, a payload length that fits in the remaining declared container, and a cursor advance that cannot overflow or remain unchanged. A zero-length payload may be legal or illegal according to the format, but the parser must still terminate predictably.
Unknown tags need a declared rule. If the format permits skipping them, skip by their validated length and continue. If they are critical or unsupported, reject the container. Never assume that “unknown” means harmless, and never continue a loop without advancing or returning an error.
Duplicate tags need equally explicit handling: reject duplicates, use a format-defined instance index, or apply another documented rule. Silently taking whichever duplicate happens to be encountered first makes cell identity depend on storage order rather than the format contract.
4. Use a shifted-offset fixture
Consider an invented format with a six-byte container header followed by records containing a one-byte tag, a one-byte length and that many value bytes. Tag 0x10 holds a label; tag 0x20 holds four opaque calibration bytes. This is a test design, not a shipped format or kernel API encoding.
| Fixture | Records after the six-byte header | Expected calibration value offset |
|---|---|---|
| A. | Label length 3, then calibration length 4. | 13. |
| B. | Label length 7, then identical calibration. | 17. |
| C. | Label length 7, optional unknown tag with length 2, then identical calibration. | 21, if this format permits that unknown tag. |
The consumer should receive the same named calibration payload from all accepted fixtures. A hard-coded offset of 13 would instead read the wrong bytes in B and C. The oracle compares discovered cell offset, length and exact payload, not merely whether probe returned success.
Keep the required cell name stable across these arrangements. Do not make consumers parse the entire provider region as a fallback; that duplicates layout knowledge and undermines the intended separation.
5. Test rejection and missing-cell outcomes
- Truncate the container header and each record header.
- Declare a length larger than the remaining region or the supported total bound.
- Provide an unsupported version and a failed container integrity check.
- Insert unknown tags before, between and after recognized tags.
- Duplicate the required tag and exercise the documented policy.
- Omit the calibration tag while keeping the rest of the container valid.
- Place a valid-looking required field before a malformed later record and verify the intended publication policy.
That last case matters when a parser registers cells incrementally. A failure later in parsing must not accidentally expose a partially accepted table as a fully validated configuration. Confirm the selected layout’s actual registration and cleanup behavior; do not assume transactional publication for every implementation.
A missing required cell should produce the approved unavailable or degraded state. It must not trigger a guessed offset or silently borrow another unit’s calibration. Optional data can have a separate default policy, but the consumer’s safety requirements determine that choice.
6. Qualify without touching factory contents
Run parser fixtures against synthetic byte arrays or copied, appropriately sanitized images. No kernel layout probe, EEPROM access or target test was executed for this article. Do not write test records to OTP, efuses or a production factory-data region.
Retain the parser revision, format definition, fixture bytes, expected cell inventory and consumer results. Verify supported board variants and probe ordering in a recoverable development environment after the host-level contract is clear.
Hypothetical factory-format extension
A manufacturing release lengthens a product label while preserving the calibration record’s tag and payload. Fixed-offset firmware now reads label bytes as calibration. A qualified layout discovers the new offset and presents the same logical cell, while its bounds and missing-field tests prevent plausible garbage from becoming a device setting.
The useful deliverable is a stable named-cell contract backed by variable-layout fixtures. It avoids hard-coded location assumptions without pretending that locating bytes also proves their meaning or trustworthiness.
