| commit | 89092a9ccd91f315aea7814040521f2107d9594e | [log] [tgz] |
|---|---|---|
| author | Naresh Solanki <naresh.solanki@9elements.com> | Mon Jun 02 15:48:04 2025 +0530 |
| committer | Ed Tanous <ed@tanous.net> | Wed Sep 03 15:19:12 2025 +0000 |
| tree | b33196c5c1b17f90dc67045da66d3e7c744e53a0 | |
| parent | d3ec0661dda2d26f2268cc3aab23c354f261b699 [diff] |
fru-device: Add option to allow updating all FRU fields This patch introduces a new meson option `fru-update-property` to enable updating FRU properties via D-Bus. This is particularly useful during lab testing to modify FRU fields as needed. TESTED=Build for tiagopass with fru-update-property set to true. Verify the following: 1. Run command: `busctl introspect xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/BMC_Storage_Module` 2. Verify the FRU fields are `writable` Example: ... .PRODUCT_ASSET_TAG property s "XXXXXXX" emits-change writable .PRODUCT_FRU_VERSION_ID property s "1.0" emits-change writable .PRODUCT_INFO_AM1 property s "XXXXXXXXX" emits-change writable .PRODUCT_INFO_AM2 property s "Config A" emits-change writable ... 3. Update FRU field: busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/BMC_Storage_Module xyz.openbmc_project.FruDevice PRODUCT_INFO_AM2 s "123" 4. Verify by reading the field: busctl get-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/BMC_Storage_Module xyz.openbmc_project.FruDevice PRODUCT_INFO_AM2 s "123" root@tiogapass:~# hexdump /sys/bus/i2c/drivers/at24/6-0054/eeprom 0000000 0001 0100 000d f100 0c01 3600 d0e6 58c6 0000010 5858 5858 d258 4d42 2043 7453 726f 6761 0000020 2065 6f4d 7564 656c 58cd 5858 5858 5858 0000030 5858 5858 5858 58ce 5858 5858 5858 5858 0000040 5858 5858 c358 2e31 c930 5858 5858 5858 0000050 5858 d258 5858 5858 5858 5858 5858 5858 0000060 5858 5858 5858 39c1 0c01 c600 5858 5858 0000070 5858 54d2 6f69 6167 5020 7361 2073 6953 0000080 676e 656c ce32 5858 5858 5858 5858 5858 0000090 5858 5858 58c4 5858 cd32 5858 5858 5858 00000a0 5858 5858 5858 c758 5858 5858 5858 c358 00000b0 2e31 c930 5858 5858 5858 5858 c858 6f43 00000c0 666e 6769 4120 45c1 0000 0000 0000 0000 00000d0 0000 0000 0000 0000 0000 0000 0000 0000 * 0002000 root@tiogapass:~# busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/BMC_Storage_Module xyz.openbmc_project.FruDevice PRODUCT_INFO_AM1 s "123456" root@tiogapass:~# hexdump /sys/bus/i2c/drivers/at24/6-0054/eeprom 0000000 0001 0100 000d f100 0c01 3600 d0e6 58c6 0000010 5858 5858 d258 4d42 2043 7453 726f 6761 0000020 2065 6f4d 7564 656c 58cd 5858 5858 5858 0000030 5858 5858 5858 58ce 5858 5858 5858 5858 0000040 5858 5858 c358 2e31 c930 5858 5858 5858 0000050 5858 d258 5858 5858 5858 5858 5858 5858 0000060 5858 5858 5858 39c1 0c01 c600 5858 5858 0000070 5858 54d2 6f69 6167 5020 7361 2073 6953 0000080 676e 656c ce32 5858 5858 5858 5858 5858 0000090 5858 5858 58c4 5858 cd32 5858 5858 5858 00000a0 5858 5858 5858 c758 5858 5858 5858 c358 00000b0 2e31 c630 3231 3433 3635 43c8 6e6f 6966 00000c0 2067 c141 0000 4f00 0000 0000 0000 0000 00000d0 0000 0000 0000 0000 0000 0000 0000 0000 * 0002000 Change-Id: Iff11d64a291e6bdb653b6c524ca90e2e16003ec3 Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Entity manager is a design for managing physical system components, and mapping them to software resources within the BMC. Said resources are designed to allow the flexible adjustment of the system at runtime, as well as the reduction in the number of independent system configurations one needs to create.
A server component that is physically separate, detectable through some means, and can be added or removed from a given OpenBMC system. Said component can, and likely does contain multiple sub-components, but the component itself as a whole is referred to as an entity.
Note, this term is needed because most other terms that could've been used (Component, Field Replaceable Unit, or Assembly) are already overloaded in the industry, and have a distinct definition already, which is a subset of what an entity encompasses.
A particular feature of an Entity. An Entity generally will have multiple Exposes records for the various features that component supports. Some examples of features include, LM75 sensors, PID control parameters, or CPU information.
A set of rules for detecting a given entity. Said rules generally take the form of a D-Bus interface definition.
Entity manager has the following goals (unless you can think of better ones):
A full BMC setup using Entity Manager consists of a few parts:
A detection daemon This is something that can be used to detect components at runtime. The most common of these, fru-device, is included in the Entity-Manager repo, and scans all available I2C buses for IPMI FRU EEPROM devices. Other examples of detection daemons include: peci-pcie: A daemon that utilizes the CPU bus to read in a list of PCIe devices from the processor. smbios-mdr: A daemon that utilizes the x86 SMBIOS table specification to detect the available systems dependencies from BIOS.
In many cases, the existing detection daemons are sufficient for a single system, but in cases where there is a superseding inventory control system in place (such as in a large datacenter) they can be replaced with application specific daemons that speak the protocol information of their controller, and expose the inventory information, such that failing devices can be detected more readily, and system configurations can be "verified" rather than detected.
An entity manager configuration file Entity manager configuration files are located in the ./configurations directory in the entity manager repository, and include one file per device supported. Entities are detected based on the "Probe" key in the json file. The intention is that this folder contains all hardware configurations that OpenBMC supports, to allows an easy answer to "Is X device supported". An EM configuration contains a number of Exposes records that specify the specific features that this Entity supports. Once a component is detected, entity manager will publish these Exposes records to D-Bus.
A reactor The reactors are things that take the entity manager configurations, and use them to execute and enable the features that they describe. One example of this is dbus-sensors, which contains a suite of applications that input the Exposes records for sensor devices, then connect to the filesystem to create the sensors and scan loops to scan sensors for those devices. Other examples of reactors could include: CPU management daemons and Hot swap backplane management daemons, or drive daemons.
note: In some cases, a given daemon could be both a detection daemon and a reactor when architectures are multi-tiered. An example of this might include a hot swap backplane daemon, which both reacts to the hot swap being detected, and also creates detection records of what drives are present.
Entity Manager will automatically create associations between its entities in certain cases. For details see the associations doc.
Entity manager shall support the dynamic discovery of hardware at runtime, using inventory interfaces. The types of devices include, but are not limited to hard drives, hot swap backplanes, baseboards, power supplies, CPUs, and PCIe Add-in-cards.
Entity manager shall support the ability to add or remove support for particular devices in a given binary image. By default, entity manager will support all available and known working devices for all platforms.
Entity manager shall provide data to D-Bus about a particular device such that other daemons can create instances of the features being exposed.
Entity manager shall support multiple detection runs, and shall do the minimal number of changes necessary when new components are detected or no longer detected. Some examples of re-detection events might include host power on, drive plug/unplug, PSU plug/unplug.
Entity manager shall have exactly one configuration file per supported device model. In some cases this will cause duplicated information between files, but the ability to list and see all supported device models in a single place, as well as maintenance when devices do differ in the future is determined to be more important than duplication of configuration files.
bmcweb A webserver implementation that uses the inventory information from entity-manager to produce a Redfish compliant REST API. intel-ipmi-oem An implementation of the IPMI SDR, FRU, and Storage commands that utilize Entity Manager as the source of information.