Talk:Embedded Open Modular Architecture/EOMA68/EEPROM Data Format

Purpose:

Each chassis needs to ship chassis-specific information such as the vendor and
device ID on the identification EEPROM. There must be a defined data structure
for that information such that a bootloader/OS loaded on any given CPU card
can read it out.


Goals:

* Appropriate for storage on an EEPROM (low overhead)
* Appropriate for access via i2c+smbus
* Can be use to store heterogeneous data. Already identified are:
        * Device and vendor ID
        * Device tree
* Reliable, within the first two constraints, it must involve as few hacks as
possible and as many reasonable mechanisms for reliable usage
* Extensible, allowing for future expansion as necessary


Proposal:

To create a specification for the “device information data segment” (DIDS) to
be referenced by the EOMA68 standard in relation to the data stored on the
EOMA68 identification EEPROM.

Keeping it separate from the EOMA68 standard:

* keeps the EOMA68 spec concise
* allows other open hardware implementations to more easily consider adoption


Implementation:

The DIDS will consist of a single contiguous block of binary data. The IDS
will be segmented into variable size pages, and the IDS will be prefaced with
a header.

        Header

The header will be 4 bytes in size with the following layout:

Byte            Size                            Value
======          ===                     ====
0x00               2                            Capabilities bytes
0x02               1                            Checksum byte
0x03               1                            Reserved

The capabilities bytes are a bitfield. All bits are currently reserved for
future usage and may only be assigned in future revisions of the EOMA68
specification. An IDS for this version of the EOMA68 spec must contain the
value 0x00

The checksum byte is the CRC-8 result of the IDS. (The CRC-8 algorithm must be
referenced from the final specification to avoid any ambiguities.)

The final byte is reserved for future use.


        Pages

Other than the header, the remainder of the IDS will be divided into variable
length pages. Each page starts with a header with the following format:

Byte             Size                Value
======      ===                 ====
0x00            2                       Page identifier (defined by EOMA68 spec)
0x02            2                       Size of page data

The page identifier (PID) is used to detect the layout of the data in the page,
and all PIDs up to and including 32767 (0xffff) are defined in the DIDS specification.
Values 32768 (0x10000) and above are reserved.

The page data then follows directly after the header. The maximum size of page
data is limited by the page size value contained in 2 bytes, or 64k. A page
may consist of 0 bytes of data, which may be used in cases where the PID
itself is sufficiently informative on its own.

The only page layout exception allowed is for the last, or terminal, page. The
0x00 value is used to identify the terminal page, and the remaining 2 bytes
are ignored and therefore may contain any values. The terminal page always has
page size of zero, regardless of the value stored in the last 2 bytes.

Navigating between pages becomes an exercise in reading page headers, seeking
to the end of the page (processing the contents along the way if desired) and
repeating for the next page until the terminal page is encountered.

There is no page index. Variable length pages without an accompanying index
means that it is not possible to seek directly to a given page; however given
the relatively small size of the IDS, the small number of pages and that the
headers allow skipping from page to page this is deemed acceptable.