[External] Re: ipmitool FRU write question
Vijay Khemka
vijaykhemka at fb.com
Tue Aug 20 08:26:39 AEST 2019
On 8/19/19, 3:19 PM, "Patrick Venture" <venture at google.com> wrote:
On Mon, Aug 19, 2019 at 2:55 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of venture at google.com> wrote:
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_ipmi-2Dfru-2Dparser_-2B_22022&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=S9tC9Xf2NSLTyHJCFTl6oIO42LpdhrtnwXbH0VssCkI&s=P80VTof0T9asp-kQ4qr9mcEY1Y3mKTfVj-bztx5-3_o&e=
>
> 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.
> Patrick, I am not using intel-dbus-interfaces, only using dbus-sensors. What is the use of intel-dbus-interfaces?
I don't use both. I only use phosphor-dbus-interfaces. I was just
indicating they weren't going to interfere with each other because the
intel-dbus-interfaces isn't used in the same way as
phosphor-dbus-interfaces.
Okay, thanks
>
> >
> > Thanks,
> > Harry
>
>
More information about the openbmc
mailing list