Some DIMM SPD fields must be parsed before issuing IPMI Write FRU command

[AlexanderAmelkin]

Currently the Manufacturer Name and Product Name fields of DIMM FRUs fed to the BMC contain raw binary data from Manufacturer ID Code (bytes 320-321) and DRAM Device Type (byte 2) fields of SPD.

This yields incorrect data presentation in BMC (see openbmc/openbmc#1169).

I believe that parsing should be done on the OpenPOWER Firmware side so that the data written to FRU via IPMI is human-readable (e.g. "Samsung" instead of binary 0xCE80, and something like "DDR4 UDIMM, 32GB, 2400MHz, 64-bit, ECC" instead of binary 0x0C) because on the BMC side, strictly speaking, parsing those fields is not covered by any specification and parsing them according to JEDEC SPD spec would require building in some superfluous knowledge regarding hostboot operation into BMC firmware.

Please also note that for Product Name it is desirable to parse not just byte 2 of SPD, but also bytes 3 (for module type), 4,6,12,13 (for total capacity, bus width and ECC presence), and 18 (for speed).

[Analysis]

FRU Board Info Area is filled in hostboot using addVpdData() function that takes a pointer to the FRU area byte array tail, and a single JEDEC field specifier as arguments. The function derives the size and type of the field being written from the field description array ddr4Data[]. Only the fields that are longer that word (4 bytes) are treated as string type. The manufacturer ID field in JEDEC is byte 0x141 and has the size of 2 bytes. For the Product Name, as said in the description, the code only takes the SPD::BASIC_MEMORY_TYPE field which is byte 0x01 and has size 1.

JEDEC Manufacturer IDs are specified in JEP106AW specification and are split into banks, each bank containing up to 127 IDs (0x00..0x7E). JEDEC DDR4 SPD specification JESD21C prescribes the manufacturer ID field to be constructed of the bank number and the Manufacturer ID per JEP106AW, each represented by a single byte with bit 7 used for parity. Thus bank 0 becomes 0x80, and ID 2 becomes 0x82, while bank 1 remains 0x01 and ID 3 remains 0x03. So, for instance, the ID for Samsung Electronics (bank 0, ID 78/0x4E) is encoded as 0x80CE in big-endian encoding and becomes 0xCE80 that is currently observed in FRUs on BMC side.

As there are 11 banks giving in total about 1400 manufacturer IDs, with only a small subset of them belonging to companies actually manufacturing DDR4 DIMM modules, it is proposed to introduce a mapping of supported IDs to their string representations, and report Unknown for any ID not found in the mapping.

The FRU field Product Name as proposed in the description should be built using multiple SPD fields. Each field is essentialy also an integer-to-string map.

Such approaches to building both fields mean that the existing addVpdData() function can not be used for this purpose. It's proposed to introduce a new function that will use appropriate maps to convert the required SPD field to a string, and use that function instead of addVpdData() to construct the Manufacturer Name and Product Name fields.

[Design]

Structure type jedecMap will be added, and the following maps will be introduced:

• jedecManufacturer
• jedecBasicType
• jedecModuleType
• jedecBusWidthPri
• jedecBusWidthExt
• jedecTckMin

Function jedecDecode() will be added to return a pointer to the string contained in the appropriate map for the requested SPD field, or will return NULL if wrong field is requested or no mapping is found.

There will be also two wrapper functions added to be used instead of addVpdData() for SPD::MODULE_MANUFACTURER_ID and SPD::BASIC_MEMORY_TYPE fields respectively:

• addSpdManufacturer() - will obtain the manufacturer ID string using jedecDecode() and will add it to the FRU area at the given position, prepending it with the correct type/length field. The function will add string Unknown (XXXX) when there was no mapping for manufacturer ID XXXX;
• addSpdDetails() - will obtain string representations for all fields mentioned in the description that constitute the module type, and will concatenate them into a single string using space as a separator. The function will also calculate the module speed using the formula provided in JESD21C and will concatenate the result to the string. The string will be prepended with the correct type/length field and put into the FRU area at the given position.

Only the following manufacturers will be supported:

• AMD
• Apacer Technology
• Baikal Electronics
• Corsair
• Crucial Technology
• Fujitsu
• Hewlett-Packard (also Hewlett Packard Enterprise)
• IBM
• Intel
• Kingston
• LG Semi
• Micron Technology
• Samsung Electronics
• Siemens AG
• SK Hynix
• Toshiba Corporation
• Transcend Information

The result when parsed by ipmitool will look like this:

FRU Device Description : dimm0 (ID 30)
 Product Manufacturer  : Samsung Electronics
 Product Name          : DDR4-2400 16GiB 64-bit ECC RDIMM
 Product Part Number   : M393A2G40EB1-CRC
 Product Serial        : 198752b5

[End user impact]

FRU records for DIMM modules as reported by BMC firmware now have module manufacturer and type fully decoded and represented as strings

[dcrowell77]

parsing them according to JEDEC SPD spec would require building in some superfluous knowledge regarding hostboot operation into BMC firmware.

I'm not sure I agree with this. The JEDEC spec is universal so there is nothing Hostboot-specific about using it to parse things. The only platform-specific piece in here is the format of the data in the FRU Inventory records itself. There is no real standard there so it is all just legacy from the initial POWER8 OpenPOWER implementation. The IPMI standard allows for binary or ascii data to be included in these fields.

However, I am not discounting the potential usefulness of such a change. We're happy to take a look at a Hostboot commit/patch to support your request. :-)

[AlexanderAmelkin]

@dcrowell77, we most probably will provide such a patch some day. I've created this issues just to keep track of it. However, if anyone creates a patch before we do, that will be nice. :)

As for SPD and FRU standards, what I meant when I wrote "superfluous knowledge" is that when you read an SPD (in hostboot) you definitely know you're dealing with JEDEC-compliant data. When on the other hand you're parsing FRU on the BMC side, you generally have no idea what data is contained in the the custom data fields of this particular FRU record. The standardized FRU fields in any of the standardized areas do not allow for storing binary JEDEC SPD data, nor does the FRU specification refer to JEDEC anywhere at all. The BMC generally has no knowledge that binary 0xCE80 in the Manufacturer Name field of a Board Area must be treated according to some JEDEC spec, and 0x0C in the Product Name field is simply insufficient to decode the actual product type.

[AlexanderAmelkin]

FYI: This is resolved for P8 in YADRO-KNS/op-build#2
Would you like us to prepare a pull request to master-p8? I'm not sure if it cleanly applies to master.

[dcrowell77]

Yes, that would be great!