[External] Re: ipmitool FRU write question

[Harry Sung1]

> 
> 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-2Dpro
> ject.xyz_c_openbmc_ipmi-2Dfru-2Dparser_-2B_22022&d=DwIBaQ&c=5VD0RT
> tNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g
> &m=S9tC9Xf2NSLTyHJCFTl6oIO42LpdhrtnwXbH0VssCkI&s=P80VTof0T9asp-kQ4
> qr9mcEY1Y3mKTfVj-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#L
> 206
>     >     > 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/45e93cbae0aa0d
> 0f5385d40f5685b23e18f95351
>     >
> https://github.com/openbmc/phosphor-host-ipmid/commit/c26cc717a4eef18
> fffc1ca891bb6a6015740bf9f

Thanks for fix it! Actually, I have the similar patches in my repo to address this issue, now I am able to remove them.

>     >
>     >     >
>     >     > 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
>     >
>     >
> 

I will not using intel-dbus-interfaces for now, thanks for comments.

Harry