OpenBMC - FRU inventory with Entity Manager

[Andrei Kartashev]

> > 
> > At least it'll be there for the next person.
> 
> Line 72 of the doc says the 3rd component to entity-manager is the
> reactor.
> It mentions one example is dbus-sensors, which contains a suite of
> application 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.
> 
> Could someone point a sample code that a platform is doing the flow
> described above?
> 
> For example after enable entity-manager and put in the device tree
> for temp sensors
> and FRU EEPROM devices, and the Exposes, probe config blocks in the
> json file, still
> struggling to get ipmitool sensor list and ipmitool fru to
> work.  "ipmitool fru" issue is
> clear based on the feedback in this thread.  But really want to have
> a tutorial or code
> example to walk through to understand the reactor side of things.
> 

This reactors are just a services that are expected to read their
configuration from dbus. EM expose something to dbus and then these
services are read what they need.

> > > Another thing I would like to have is even more high- level
> > > document 
> > > describing the common architecture of EM-based inventory.
> > > I can start with some drafts of what I dig, to make it more
> > > clear.
> 
> Really appreciate for this type of document if they are
> available.  We are adopting
> entity-manager in our proof-of-concept project but really struggling
> to find detailed
> documentation and end up just copying and pasting existing entity
> manager json
> config files and tweaking them.
> The two links we follow kind of as bibles for entity manager doesn't
> provide a detail guide
> for example in the json config file, what each field means and how
> that field is being
> consumed, causes what to be created on the d-bus side, and being
> consumed by what reactor.
> 
> https://github.com/openbmc/entity-manager/blob/master/docs/my_first_sensors.md
> https://github.com/openbmc/entity-manager/blob/master/README.md
> 
> For example for sensors with entity manager do we still need the IPMI
> YAML
> configuration file described here?
> https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#defining-sensors-in-an-ipmi-yaml-configuration-file
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml
> 
> For FRUs, for example do we still need 
> https://github.com/ibm-openbmc/openbmc/blob/OP940/meta-ibm/meta-romulus/recipes-phosphor/configuration/romulus-yaml-config/romulus-ipmi-fru.yaml
>  
> Because I found out when doing "ipmitool fru" it always goes off of
> the default Builtin FRU Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3,
> and cpu1 ID 4.  
> $ ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
> FRU Device Description : Builtin FRU Device (ID 0)
>  Device not present (Unspecified error)
> 
> FRU Device Description : dimm0 (ID 1)
>  Device not present (Unspecified error)
> 
> FRU Device Description : dimm1 (ID 2)
>  Device not present (Unspecified error)
> 
> FRU Device Description : cpu0 (ID 3)
>  Device not present (Unspecified error)
> 
> FRU Device Description : cpu1 (ID 4)
>  Device not present (Unspecified error)
> 
> And that's because 
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru_gen.py
> always
> taking 
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru-read-example.yaml
> from the as the default fru inventory yaml config.
> unless custom fru yaml like the above is specified.
> 
> Even after porting over intel-ipmi-oem or fb-ipmi-oem's oem command
> fru handler for entity manager,
> still has the above behavior when doing "ipmitool fru".  Just really
> trying to look for a high level flow
> of the reactor side under entity manager, sensor and fru to begin
> with.
> 
> In porting intel-ipmi-oem's fru command handler for entity-manager,
> first phosphor-ipmid-host.service
> would coredump.  Debugged it to be the startMatch() in
> registerStorageFunctions() where it's calling
> boost::asio::spawn with replaceCacheFru()
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L1311
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L361
> 
> So switched to fb-ipmi-oem's implementation which doesn't do the
> replaceCacheFru with
> the async handler.
> https://github.com/openbmc/fb-ipmi-oem/blob/master/src/storagecommands.cpp#L185
> But still "ipmi fru" would still display the default Builtin FRU
> Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3, and cpu1 ID 4. 
> 
> So I guess need to go back and really understand the reactor side
> under entity-manager
> and how the d-bus objects are created by the entity-manager and how
> they are consumed
> by the reactors for each components (sensors, fru, etc.)  Any
> documentation on that will be so
> helpful as a new adopter of entity-manager trying to dig in on what
> different pieces need to line
> up when switching to entity-manager.


You don't need any YAML files when you use EM. However to get ipmitool
fru list to work you need to replace ipmi command handlers by that from
intel-ipmi-oem. If you have output like you show, then you probably
make something wrong and you still have default handlers from phosphor-
ipmid-host.
Reactors are not related to what you see in fru list. They will
construct sensors list, setup some parts of the system and so on, but
fru list in the new model is only defined by FruDevice service: you
will get there only devices that actually have I2C EEPROMs with FRU
data written.