Kria SOM EEPROM Design Guide¶
Kria SOM EEPROM Overview¶
This document covers Kria SOMs platform’s EEPROM content format, which are based on the IPMI specification. It is meant to provide a guideline for you to create your own EEPROM contents for your custom carrier card. The information in EEPROM defines platform information that allows the system to be identified by software. The Intelligent Platform Management Interface (IPMI) is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system’s CPU, firmware (BIOS or UEFI) and operating system. AMD EEPROM configuration is based on the IPMI Platform Management FRU Information Storage Definition v1.0 specification.
For specific EEPROM content format of Kria SOM and its starter kit carrier cards (CC), refer to EEPROM mapping for Kria Product page.
EEPROM Information¶
SOM and SOM CC EEPROM device details:
Size: 64K bits (8K bytes)
I2C address:
SOM-7’b101_0000(0x50)
Carrier Card –7’b101-0001(0x51)
Note: the physical EEPROM device used on Kria SOM and Carrier Cards (ST M24C64) has two I2C addresses - the first address is the main EEPROM memory interface (e.g. 0x50, 0x51) and the second address (0x58, 0x59) is associated with the “identification page”. When probing the I2C bus, there will be two addresses associated with the EEPROM.
To readout EEPROM in Linux:
sudo hexdump -C /sys/devices/platform/axi/ff030000.i2c/i2c-1/1-0050/eeprom # Reads out SOM EEPROM
sudo hexdump -C /sys/devices/platform/axi/ff030000.i2c/i2c-1/1-0051/eeprom # Reads out CC EEPROM
To readout EEPROM, in u-boot:
i2c dev 1;
i2c md 0x50 0.2 0x100 # Reads out SOM EEPROM
i2c md 0x51 0.2 0x100 # Reads out CC EEPROM
Tools and Scripts¶
Kria-EEPROM-gen repo contains scripts to:
generate EEPROM bins for different Starter kit SOMs and Carrier cards by processing user data
generate user data from EEPROM bins which is useful for comparing the deltas
Refer to readme in the repo for instructions.
Record Type Summary for Kria SOM and AMD Carrier Cards¶
There are two record types in Kria SOM EEPROM - standard record type that follows IPMI specification, and OEM (original equipment manufacturer) record type that is specified by Xilinx. Developer of SOM carrier cards (OEM) are expected to fill in their carrier card specific information aligning to standard or OEM record types. The following tables list the record areas for SOM and CC to show the order which they are presented in. For an example, this is the record areas for K26:
Kria SOM (K26) and EEPROM Record Area Summary:
Record Area | Record Type |
---|---|
Common Header | IPMI Standard, refer to table 8-1 in IPMI Spec |
Board Info Area | IPMI Standard, refer to table 11-1 in IPMI Spec |
DC Load MultiRecord | IPMI Standard, refer to table 16-1 and 18-4 in IPMI Spec |
SOM MAC Addr MultiRecord | IPMI OEM Record, refer to table in MAC Addr MultiRecords |
SOM Memory Config MultiRecord | IPMI OEM Record, refer to table in Memory Config MultiRecord |
For information on Kria product EEPROM record area, review EEPROM mapping for Kria products.
IPMI-defined Record Fields¶
For IPMI standard record type, refer to IPMI specification to determine field meaning and determine how to fill in those fields. They must be IPMI-compliant.
IPMI OEM Xilinx-defined Record Fields¶
For IPMI OEM Record, they are free-form in IPMI Specification. The SOM and CC from AMD uses AMD-Xilinx-defined format for those record, which custom CC vendor can choose to reference and/or use their own definition.
Board Info Area Record Custom Mfg Info¶
In the Board Info Area Record for Kria SOM and its carrier card, there are additional custom Mfg. Info fields. They are defined by AMD as following, but a carrier card manufactured can use the field anyway they like.
Length (in Bytes) | Description | Stored Format | Notes |
---|---|---|---|
1 | Revision Type-Length | Binary | Bits 7:6 - format 11 indicates ASCII Bits 5:0 - length |
8 | Revision Number | ASCII | Indicates the board PWA revision capturing PCB + BOM + rework level. Unused Bytes are 0x0 filled. Value assigned at time of board manufacturing. |
1 | PCIe Info Type/length byte | Binary | Bits 7:6 - format 00 indicates Binary Bits 5:0 - length |
8 | PCIe Info | Binary | Vendor ID – 2 bytes Device ID – 2 bytes SubVendor ID – 2 bytes SubDevice ID – 2 bytes |
1 | UUID Type/length byte | Binary | Bits 7:6 - format 00 indicates Binary Bits 5:0 - length |
16 | UUID | Binary | UUID. Universal Unique Identifier. SOM use this field with random UUID to support customer implemented device enrollment functionalities. |
MAC Addr MultiRecords¶
The SOM MAC Addr MultiRecord is a OEM Record of type 0xD2 (“Xilinx MAC Addr Multi Record” defined by AMD-Xilinx), manufacturer of Carrier card can choose to follow the same format to define their MAC address, but its not required.
This is the AMD-Xilinx definition for its MAC Addr MultiRecord.
Length (in Bytes) | Data Description | Stored Format | Notes |
---|---|---|---|
1 | Record Type (OEM) | Binary | OEM Record - set to 0xD2 (free form format) |
1 | Type | Binary | set to 0x02 or 0x82 (Bit 7 on means last record) |
1 | Length | Binary | Data length starting after Header Check Sum to end of record - this indicates how many MAC ID fields are present |
1 | Record Check Sum | Binary | Sum over bytes after Header Checksum plus this checksum should equal 00. |
1 | Header Check Sum | Binary | Sum over last 4 bytes plus this checksum = 00. |
3 | IANA ID | Binary | Internet Assigned Numbers Authority |
1 | Version Number | Binary | Version number - 0x31 for Device Under Test for characterization/ evaluation MAC ID’s |
6 | MAC ID 0 | Binary | MAC ID |
6 | MAC ID 1 | Binary | MAC ID - if Length field is 16 or greater |
6 | MAC ID 2 | Binary | MAC ID - if length field is 22 or greater |
6 | MAC ID 3 | Binary | MAC ID - if length field is 28 or greater |
While the SOM itself support only 1 MAC ID for PS primary Ethernet, each CC card have different numbers of MAC IDs dependent on how many Ethernet PHYs are put on the CC. Refer to EEPROM mapping for Kria products for examples.
EtherCat Addr MultiRecords¶
The SOM EtherCat Addr MultiRecord is a OEM Record of type 0xD2 (“Xilinx EtherCat Addr Multi Record” defined by Xilinx), manufacturer of Carrier card can choose to follow the same format to define their EtherCat address, but its not required.
This is the AMD-Xilinx definition for its EtherCat Addr MultiRecord. It is similar to MAC Address MultiRecords except the EtherCat ID is 4 bytes long.
Length (in Bytes) | Data Description | Stored Format | Notes |
---|---|---|---|
1 | Record Type (OEM) | Binary | OEM Record - set to 0xD2 (free form format) |
1 | Type | Binary | set to 0x02 or 0x82 (Bit 7 on means last record) |
1 | Length | Binary | Data length starting after Header Check Sum to end of record - this indicates how many MAC ID fields are present |
1 | Record Check Sum | Binary | Sum over bytes after Header Checksum plus this checksum should equal 00. |
1 | Header Check Sum | Binary | Sum over last 4 bytes plus this checksum = 00. |
3 | IANA ID | Binary | Internet Assigned Numbers Authority |
1 | Version Number | Binary | Version number - 0x31 for Device Under Test for characterization/ evaluation MAC ID’s |
4 | EtherCat ID 0 | Binary | EtherCat ID |
Memory Config MultiRecord¶
The AMD-Xilinx Free Form Record with OEM record type 0xD3 is for “Xilinx Memory Config MultiRecord” and free form. manufacturer of Carrier card can choose to have a record following the same format but it is not required.
Length(in Bytes) | Data Description | Stored Format | Notes |
---|---|---|---|
1 | Record Type (OEM) | Binary | Set to 0xD3 |
1 | Record Format | Binary | set to 0x02 or 0x82 (Bit 7 on means last record) |
1 | Length | Binary | length of data after Header Checksum - 0x57 (87) for K26 SOM |
1 | Record Check Sum | Binary | Sum over bytes after Header Checksum plus this checksum should equal 00. |
1 | Header Check Sum | Binary | Sum over last 4 bytes plus this checksum should equal 00. |
3 | IANA ID | Binary | (Internet Assigned Numbers Authority) |
8 | Memory Type Field Name identifier. e.g. “Memory: ” | ASCII | Memory Type Field Name identifier. |
12 | Primary boot device memory definition e.g. “QSPI:512Mb” |
ASCII | Describes primary NV memory device. If no primary device note “None”. Unused characters are spaces: 0x20 “b” means bit, “B” means byte |
1 | Memory Type Field end | Binary | Set to 0x00 |
8 | Memory Type Field Name identifier. e.g. “Memory: ” | ASCII | Memory Type Field Name identifier. |
12 | SOM secondary boot device memory e.g. “eMMC:16GB” e.g. “eMMC:32GB” |
ASCII | Describes secondary NV memory device. If no secondary boot device note “None”. Unused characters are spaces: 0x20 “b” means bit, “B” means byte |
1 | Memory Type Field end | Binary | Set to 0x00 |
8 | Memory Type Field Name identifier. e.g. “Memory: ” | ASCII | Memory Type Field Name identifier. |
12 | SOM PS DDR memory e.g. “PSDDR4:4GB” e.g. “PSDDR4:2GB” |
ASCII | Describes PS MIO based DDR configuration. If no PS DDR note “None”. Unused characters are spaces: 0x20 “b” means bit, “B” means byte |
1 | Memory Type Field end | Binary | Set to 0x00 |
8 | Memory Type Field Name identifier. e.g. “Memory: ” | ASCII | Memory Type Field Name identifier. |
12 | SOM PL DDR memory e.g. “PLDDR4:None” |
ASCII | Describes PL based DDR configuration. If no PL DDR note “None”. Unused characters are spaces: 0x20 “b” means bit, “B” means byte |
1 | Memory Type Field end | Binary | Set to 0x00 |
License¶
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright© 2023 Advanced Micro Devices, Inc