docs/designs/vpd-collection.md

5 Created: 2019-06-11
10 Field Replaceable Units (FRUs) today - one example is the BMC FRU. On OpenPower
18 - Some of the VPD information such as FRU part number, serial number need to be
21 - Several use cases on the BMC require that the applications decide on a certain
23   application that controls voltage regulators might need to set different
26 - There are use cases for the BMC to send VPD data to the host
31 of certain parameters of the FRU (atypical - for FRUs that do not have an
39 Essentially, the IPZ VPD structure consists of key-value pairs called keywords.
40 Each keyword can be used to contain specific data about the FRU. For example,
52 - IPZ VPD has different records and keywords.
54 - IPZ VPD is required to implement and validate ECC as defined in the OpenPower
59 - The keyword format VPD is also something that consists of key-value pairs, but
67 - The BMC must collect VPD for all FRUs that it has direct access to by the time
82 - If a FRU does not have a VPD store such as an EEPROM, the BMC should be able
86 - The BMC should be able to recollect VPD for FRUs that can be hotplugged or
89 - The BMC must log errors if any of the VPD cannot be properly parsed or fails
92 - The BMC must create/update FRU inventory objects for all FRUs that it collects
93   VPD for. The inventory D-Bus object must contain (among other details), the
97 - Applications on the BMC need to have the ability to query any given VPD
100 - Applications also need to have the ability to update the VPD contents in a
104 - There needs to be a tool/API that allows viewing and updating VPD for any
118 - [op-vpd-parser] [2] service, which parses the contents of an EEPROM containing
121 - A udev [rule] [3] that is used by systemd to launch the above service as
124 - A set of config [files] [4] that describe the inventory objects and D-Bus
130 - Two new services will be created to handle the new VPD formats. ipz-vpd-parser
131   and a keyword-vpd-parser. These services shall be templated to allow for
134 - Another service will be created to update the inventory with location code
139 - There will be one udev rule per EEPROM on the system from which the BMC has to
141   would have to filter out non-VPD EEPROMs somehow.
143 - Each udev rule will be setup to launch an instance of one of the VPD parser
145   they are system specific)
147 - The service (one instance of ipz-vpd-parser or keyword-vpd-parser), when
151 - The service will update the inventory D-Bus object with the contents of the
158   containing keywords SN, FN and CCIN, the representation in D-Bus would look
169 - In case of keyword format VPD, all keywords shall be placed as properties
172 - The parser services will not format or transform the data in VPD in any way
176   as the openpower-vpd-parser does.
178 - To handle VPD writes, another systemd service will be launched once all the
180   manage parallel writes to EEPROMs. The VPD writer service will expose D-bus
183 - Generation of the udev rules and configs shall be layered such that they can
184   be tweaked on a per-system basis.
190 - Some more thought is needed on how concurrent maintenance (replacing a FRU
200 One option considered was to develop a standalone, do-it-all VPD application on
201 the BMC that collects all of the VPD by BMC standby. The application has to be a
202 daemon that will expose a set of D-bus interfaces to:
204 - Collect/recollect all VPD.
205 - Query a given FRU for its VPD. Example read the serial number of the VRM.
206 - Update the VPD keyword(s) for a given FRU.
207 - Concurrently maintain a FRU, which will in turn perform a remove/add/replace
210 The application would be driven off of a configuration file that lists the FRUs
215 - Design would make the application very specific to a given system or a set of
216   VPD formats. Although the application could be written in a way that allows
218   approach of small applications that target a very specific requirement is
220 - The design does not leverage upon the layered design approach that the chosen
225 Using the entity manager: https://github.com/openbmc/entity-manager. The Entity
226 manager has an application called the FruDevice, which probes /dev/i2c/ for
229 The application could be enhanced to:
231 - Add support for other VPD formats such as the IPZ and keyword format.
232 - Perhaps update a different set of data into a different DBUS object, like the
234 - Change the external DBUS interfaces that read/write FRU data to take an
239 - We do not need the full spectrum of functions offered by the entity manager,
243 - The code did not appear very pluggable to add support for new VPD formats, we
245 - Does not have a way to determine system blueprint for FRU devices, scans the
252 - The services to parse VPD and store it in the inventory will add some time to
255 - Applications that need to read VPD keywords will be impacted in the sense that
264 mode into the application. The file mode will not need real hardware to test the
268 the VPD write application's APIs to write VPD.
271 …https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=1D060729AC96891885257E1B00…
273 …https://github.com/openbmc/meta-openpower/blob/master/recipes-phosphor/vpd/openpower-fru-vpd/op-vp…
275 …https://github.com/openbmc/meta-openpower/blob/master/recipes-phosphor/vpd/openpower-fru-vpd/70-op…
277 …https://github.com/openbmc/meta-openpower/blob/master/recipes-phosphor/vpd/openpower-fru-vpd-layou…