commit | 7a2cf16cfd752ac686ca71e0b5fd8855b6730394 | [log] [tgz] |
---|---|---|
author | Manojkiran Eda <manojkiran.eda@gmail.com> | Tue Nov 12 11:49:26 2024 +0530 |
committer | Manojkiran Eda <manojkiran.eda@gmail.com> | Tue Nov 12 11:56:50 2024 +0530 |
tree | a6f5e172e47f8cf638aed358ef969dd43d8309b7 | |
parent | 1d73dccc89f0bb9d1dce3543e5af6b3e3087d5f4 [diff] |
Enable support for SMBIOS version 3.0 SMBIOS 3.2 is essentially a superset of SMBIOS 3.0. The changes from SMBIOS 3.0 to 3.2 added new structures and fields to accommodate more recent hardware features and capabilities, but they did not remove or fundamentally alter any pre-existing structures from 3.0. This means that: - SMBIOS 3.2 remains backward-compatible with SMBIOS 3.0. Any software or system expecting information from SMBIOS 3.0 should still be able to interpret the data in SMBIOS 3.2 without issues. Since we already support 3.2, its safe to assume that the code can also parse the smbios table version 3.0 without any issues. Hence adding 3.0 in the list of supported versions. Tested By: Tested this change by sending the SMBIOS 3.0 tables from coreboot to BMC via IPMI, and the smbios app seems to parse the data successfully and host the dbus objects of CPU's and DIMM's. Change-Id: I2af595ed49b7c697abb6d19331470ad17e060836 Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
The main application in this repo is smbiosmdrv2app
, capable of parsing a binary SMBIOS table and publishing the system information on D-Bus, to be consumed by other OpenBMC applications.
The SMBIOS table is usually sent to the BMC by the host firmware (BIOS). The system designer can theoretically choose any transport and mechanism for sending the SMBIOS data, but there are at least two implementation today:
The primary API is a set of Intel OEM IPMI commands called Managed Data Region version 2 (MDRv2), which provides a means for host firmware to send data through the VGA shared memory region. MDRv2 has a concept of multiple agents, each maintaining a "directory" containing directory entries (aka data sets). The host can query for the existence and version of directories to determine when it needs to send an updated SMBIOS table.
intel-ipmi-oem
implements the IPMI command handlers, routing commands and data to the correct agent (e.g. smbios-mdr
). The D-Bus interface between the IPMI handler and smbios-mdr
is largely a mirror of IPMI commands.
phosphor-ipmi-blobs
is an alternative implementation of a generic IPMI blob transfer API. Compared to MDRv2, it is simpler and easier to use, but also transfers the data in-band with the IPMI commands and therefore slower than using a shared memory region (which may or may not be a concern).
phosphor-ipmi-blobs
provides a blob manager shared library for ipmid
which implements the IPMI commands. In turn, it loads blob handler libraries that each implement support for specific blobs. Here in smbios-mdr
we provide such a blob handler for the /smbios
blob. It works by writing the data into /var/lib/smbios/smbios2
(the local persistent cache for the SMBIOS table) and calling the AgentSynchronizeData
D-Bus method to trigger smbios-mdr
to reload and parse the table from that file.
cpuinfoapp
is an Intel-specific application that uses I2C and PECI to gather more details about Xeon CPUs that aren't included in the SMBIOS table for some reason. It also implements discovery and control for Intel Speed Select Technology (SST).