Talk:Embedded Open Modular Architecture/EOMA68/EEPROM Data Format
< Talk:Embedded Open Modular Architecture | EOMA68
Revision as of 00:52, 6 November 2013 by Lkcl (Created page with "<pre> 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 ...")
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 32768 are defined in the DIDS specification. Values above 32768 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.