Chromium OS VPD Reporting Specification 1.0

Copyright © Google Inc, 2010. See “Copyright Info” section for details.

Last updated: Dec. 5, 2010

Revision Guide

1.0

- First public release. All previous entries in the revision guide are for historical purposes only.

- Add copyright section.

0.96

- Change the word "BIOS" to "Firmware". This is superficial, and is only meant to clarify application of this specification outside the context of x86 BIOS.

- Add non-DMTF disclaimer

0.95

- Corrected some byte offsets and field sizes in the binary blob pointer structure (type 241)
- Corrected some internal issues with the binary blob pointer structure illustration (redrew it, basically)

0.94

- Removed Google Custom (type 240) stuff. We'll reserve type 240 for future use, but currently the information (network IDs) is redundant with various vendor binary blobs and is not needed outside of modules/drivers which can query the information directly.

0.93

- Updated the diagram in section 2.1 to omit reference to unrelated components.

- Updated Google OEM custom table version to 1.1 for clearer representation in the data structure.

0.92

- Removed HW Qual ID from Google OEM structure. Adjusted offsets of other fields accordingly.

- Removed "reserved" bytes from the Google OEM structure.

0.91

- Clarified Google Hardware Qualification ID length in the Google OEM custom structure and updated offsets to reflect size of qualification ID.

- Corrected UUID length in the binary blob pointer structure and updated surrounding offsets.

0.90

- Added MEID to Networking Device ID Types (section 3.3.1.1)

- Corrected length of network device IDs in Networking Device ID Types (section 3.3.1.1)

- Removed manufacturing log code from Google OEM type. This is highly manufacturer specific, and is best left as a binary blob. Manufacturing logs will be treated as generic binary blobs and, if present, should have a corresponding binary blob pointer structure.

- Added a version number to the doc, starting at 0.90. We'll bump this to 1.0 when outstanding issues with vendors are resolved.

0 Disclaimer

This specification is not part of any DMTF (Distributed Management Task Force) standard. It is merely an application of the DMTF SMBIOS specification with small modifications to certain conventions.

1 Summary

This document proposes a means of storing non-enumerable platform-specific data in a manner which is simple, well-understood by the industry, and easily extensible.

Vital product data (VPD) is often stored in a firmware-dependent, platform-dependent, and OEM/ODM-dependent manner. VPD usually takes form of non-standard data structures in binary form. We often rely on software tools written for a specific platform or for the firmware to aggregate dozens or hundreds of values and present them in a standarized fashion.

We can do better. Rather than defining such data in a manner only known to the system firmware we would like to have the data easily recognizable by systems software. This document will describe a means of storing VPD in a non-volatile location in a useful manner.

2 Implementation

2.1 Manufacturing

The VPD will be programmed into a writeable (not write-protected) region of the flash memory where the system firmware resides. VPD may be generated at various stages during manufacturing. Individual data members deemed of critical importance should be copied to a secure location (e.g. TPM) before the computer leaves the factory.

2.2 Data Layout

This information will be stored using the data structures described based upon the DMTF SMBIOS Specification (http://www.dmtf.org/standards/published_documents/DSP0134_2.6.1.pdf). SMBIOS is chosen for its table of structures style which is simple, standardized, and well-supported by firmware, kernel, and operating system tools.

An SMBIOS implementation consists of two parts: An entry point structure and a structure table. The entry point structure and structure table shall be stored at manufacturing time in a writable location the system boot firmware storage.

The SMBIOS entry point structure and structure table will be generated at manufacturing time. They will be stored in a non-volatile location, preferably on the same storage device as the system boot firmware. Because the SMBIOS entry point structure points to the structured tables, they must both reside within the same address space. We will restrict the required tables such to provide only data that is not discoverable at runtime.

2.2.1 Entry Point

The SMBIOS Entry Point structure can be located at runtime by searching for the anchor-string ("_SM_", 5F 53 4D 5F) on paragraph (16-byte) boundaries.  The structure table address at offset 18h shall specify the location of the structure table, relative to offset zero (00h) of the flash memory device containing the firmware.

2.2.2 Data Structures

Each SMBIOS structure has a formatted section and an optional unformed section. The formatted section of each structure begins with a 4-byte common header (type/length/handle). Remaining data in the formatted section is determined by the structure type, as is the overall length of the formatted section. The unformed section is used to contain all STRING data for the given structure, if applicable. Every instance of a structure is terminated by two NULL (00h) bytes (See section 3.1.1 of SMBIOS spec v2.6.1). The following diagram illustrates an example of this organization:

All strings will be stored as per SMBIOS specification (See: Section 3.1.3 of the SMBIOS Specification v2.6.1).

3 Required Structures

The SMBIOS table shall include the following structure types: 

• Type 0: Firmware  information*
• Type 1: System information
• Type 127: End of structure

* Note: "BIOS" is described in this document as "firmware" since BIOS is typically associated with a specific type of firmware (x86 BIOS).

All other defined structure types are optional, as per the discretion of the ODM/OEM partner. See Required Structure Details information about each required structure.

3.1 Firmware Information (Type 0)

Required Fields:

  * Common structure header (Type/Length/Handle)

  * Vendor (STRING 1)

  * Firmware Version (STRING 2)

  * Firmware Starting Address Segment

  * Firmware Release Date (STRING 3, Format: MM/DD/YYYY)

  * Firmware ROM Size

  * Firmware Characteristic (see: Note 1)

  * Firmware Major Release

  * Firmware Minor Release

  * Embedded Controller Firmware Major Release (see: Note 2)

  * Embedded Controller Firmware Minor Release  (see: Note 2)

Note 1: Extended BIOS characteristics field is not used.

Note 2: Embedded controller firmware major and minor numbers are optional. Use values FFh if these values do not apply, for example if the system does not have an EC or if the VPD is being written for the EC itself.

3.2 System Information (Type 1)

Required Fields:

  * Common structure header (Type/Length/Handle)

  * Manufacturer (STRING 1)

  * Product Name (STRING 2)

  * Version (STRING 3)

  * Serial Number (STRING 4)

  * UUID (See DMTF Specification)
  * Wake-Up Type

  * SKU Number (STRING 5)

  * Family (STRING 6)

3.4 End-of-Table (Type 127)

Required Fields:

  * Common structure header (Type/Length/Handle)

Appendix A. Optional Structures

Optional structures must precede the End-of-Table (Type 127) structure.

A.1. Binary Blob Pointer (Type 241)

Proprietary data formats, also known as "binary blobs," are discouraged. This is because they are often non-discoverable and usually do not contain enough information for generic systems software to interpret the data within. If a binary blob is used then a Binary Blob Pointer structure must be present to provide information about where the data is located and version information.

A.1.1 Binary Blob Pointer (Type 241)

*UUID will be assigned by Google if one is not provided by the vendor. 

The following diagram illustrates the relationship between the required structures and the Binary Blob Pointer structure:

Copyright Info

The copyright holder of this document, Google Inc, has chosen to release it under the Creative Commons Attribution License 3.0.

This license allows others to freely distribute the document and create derivative works, both for commercial and non-commercial purposes, so long as attribution is given to Google Inc. in a manner which does not endorse any derivative work. It is akin to BSD license for software.

For more information, refer to the following URLs:

http://creativecommons.org/licenses/by/3.0/

http://creativecommons.org/licenses/by/3.0/legalcode