[External] Re: ipmitool FRU write question

Patrick Venture venture at google.com
Sat Aug 17 03:55:47 AEST 2019


On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1 at lenovo.com> wrote:
>
>
> > On 8/15/19 6:49 AM, Harry Sung1 wrote:
> > > Hi Team,
> > >
> > >
> > >
> > > Current phosphor-host-ipmid does not support fru write command, but
> > > ipmi-fru-parser supports it.
> > >
> > > We found this fru write command only update the data to dbus
> > > inventory, but doesn't sync the data back to the EEPROM.
> > >
> > > Does ipmi-fru-parser has any plans to implement it? I think it is more
> > > make sense to sync the data to EEPROM when we do fru write.
> >
> > The alternative FRU daemon from entity manager, FruDevice, supports writing
> > the FRU directly.
> > https://github.com/openbmc/entity-manager/blob/master/src/FruDevice.cpp
> >
> > Happy to see this capability added to ipmi-fru-parser, but you might be able to
> > model it off FruDevice.  If you want to use FruDevice as-is, you will need the
> > alternative FruWrite command sets from here.
> >
> > https://github.com/openbmc/intel-ipmi-oem/blob/159547cdfbf1992737dcecb
> > cb3888af7795f930b/src/storagecommands.cpp#L316
> >
> > As written, those commands change the behavior a bit, and double buffers the
> > FRU write commands.  When the last Fru write is sent, the data is flushed
> > through the FRU parser to ensure that it's valid, and the user isn't doing
> > anything nefarious (like changing a product name or serial
> > number) before it writes the EEPROM in one chunk, as quickly as it can to
> > reduce the possibility of a half written EEPROM.
>
> Hi Ed,
>
> Thanks for your kindly reply! I have surveyed the entity-manager before.
> But I encountered an issue when I using phosphor-inventory-manager and entity-manager at the same time.
> Both of them have same method "Notify" under same interface " xyz.openbmc_project.Inventory.Manager ", but different signature.

https://gerrit.openbmc-project.xyz/c/openbmc/ipmi-fru-parser/+/22022

This patch addresses part of it.

>
> phosphor-inventory-manager:
> NAME                                  TYPE    SIGNATURE   RESULT/VALUE   FLAGS
> xyz.openbmc_project.Inventory.Manager interface -             -             -
> .Notify                               method    a{oa{sa{sv}}} -             -
>
> entity-manager
> NAME                                  TYPE    SIGNATURE   RESULT/VALUE   FLAGS
> xyz.openbmc_project.Inventory.Manager interface -         -            -
> .Notify                               method    a{sa{sv}} -            -
>
> So when some services call the 'Notify' method failed because of getting wrong service.
> Ex: https://github.com/openbmc/ipmi-fru-parser/blob/master/writefrudata.cpp#L206
> Have you ever seen this issue before?

I've addressed part of this issue in phosphor-host-ipmid, now it no
longer assumes the FRU's owner.
See patches related to:

https://github.com/openbmc/phosphor-host-ipmid/commit/45e93cbae0aa0d0f5385d40f5685b23e18f95351
https://github.com/openbmc/phosphor-host-ipmid/commit/c26cc717a4eef18fffc1ca891bb6a6015740bf9f

>
> Should I use intel-dbus-interfaces if I want to use Frudevice (entity-manager) and write FRU command(intel-ipmi-oem)?
> Or it is compatible with original dbus-interface?

You use both.

>
> Thanks,
> Harry


More information about the openbmc mailing list