OpenBMC - FRU inventory with Entity Manager

[Jiandi An]

> On Wed, Sep 2, 2020 at 3:27 PM Andrei Kartashev <a.kartashev at yadro.com> wrote:
> >
> > On Mon, 2020-08-31 at 10:14 -0700, Ed Tanous wrote:
> > >
> > > On Wed, Aug 26, 2020 at 11:11 PM Andrei Kartashev < 
> > > a.kartashev at yadro.com> wrote:
> > > > Since there is a plan to move to EM for inventory, I believe it is 
> > > > really good idea to also have support for FruDevice in phosphor-
> > > > host-
> > > > ipmid. Then we can have a common way on how to handle it.
> > > > Same for SDR BTW.
> > >
> > > +1.  This was attempted a long time ago, but nobody was able to come
> > > up with a design that kept the "old" way working for those that 
> > > needed it, and at the time there were some missing features.  Given 
> > > where entity manager has gotten, it's probably time to start that 
> > > discussion up again.  Do you think you could put together a patch 
> > > that does what you describe?
> > >
> > Well, I currently have number of more critical tasks for platform 
> > bring-up, but I can take a look.
>
> If you get the time, I'd appreciate it.  If not, I still appreciate your input sofar.
> 
> >
> > > > But there is other thing: there is catastrophically not enough 
> > > > documentation for EntityManager/dbus-sensors. Looks like common 
> > > > way just to adjust existing config and hope that it still will work.
> > > > <sorry, was all the day trying to get adcsensors work yesterday>
> > >
> > > That being the case, would you mind taking a look at the docs 
> > > changes I just put up.  It's trying to improve the EM documentation 
> > > a bit, although I realize it doesn't get all the way to where it 
> > > needs to be.
> > > https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/36110
> >
> > Great doc! I wish I had it month ago )
>
> 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.

>
> >
> > > Also, it'd be great if you can come up with some concrete examples 
> > > of what else we can improve in this regard.  Unfortunately the "copy 
> > > an existing config and modify" approach was the best way we found to 
> > > make platform ports easy.  A lot of systems tend to look pretty 
> > > similar, based on similar reference platforms, so usually there's 
> > > something to use as a starting point.  Building a config from 
> > > scratch using first principals and documentation is kind of 
> > > daunting, and became a non-starter for most people, given that the 
> > > config files tend to be large.
> >
> > Yes, everyone likes "copy-paste" and this is working approach. Unless 
> > you understand what exactly you pasting. E.g. Fan/PID configuration 
> > looks like a hell and it doesn't match one that described in phosphor- 
> > pid-manager ).
> 
> That's definitely a low effort/high reward place where we should do a better job documenting each parameter and their constraints.
> 
> > So, now we have brilliant top-level overview, next step is to describe 
> > how to use and extend it. That is mostly on reactor side, of course, 
> > but on EM side we should clearly describe how config is translated to 
> > dbus objects.
> 
> This has evolved quite a bit over the life of Entity Manager, but again, this is great feedback, and something that it's probably time to document better including documenting the places that are "wrong", but hacked around a problem.
>
> > 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.


>
> Great!
>
>
> > > What were the biggest roadblocks you hit trying to get ADCSensor 
> > > working?
> > >
> >
> > ADC is king of easiest sensor you can have, I thought ).
>
> I think LM75 beats it :)
>
> > But still I
> > face stones. For example, if you remove "PowerState": "On" from all 
> > channels, you will get crash with "Power Match Not Created". Or this 
> > configuration entry in Wolfpass config:
>
> That's a bug for sure.  What host power state management system are you using?
>
> >             "BridgeGpio": [
> >                 {
> >                     "Name": "P3VBAT_BRIDGE_EN",
> >                     "Polarity": "High"
> >                 }
> >             ],
> > which seems to be copy-pasted from somewhere else, since it present in 
> > all other configs, but not in board schematics ) That is, of cause, 
> > not a problem of EM or dbus-sensor, but this is example for 
> > copy-pasting issues.
> >
>
> I just looked, and there's 2 platforms that have a bridgeGpio definition, and Wolf Pass for sure has it on the schematic, not sure about FBTP.  Which platform were you looking at that didn't have it?
> ADCs have a very high parasitic drain on the cmos battery, to the point where it affects their longevity.  This is an implementation of a FET that explicitly enables the circuit when the battery is being read.  Most modern Aspeed platforms should have this circuit.
>
> Point made, copy-paste is not a substitute for documenting what things do so when you copy paste, you can know what needs modified.