All of lore.kernel.org
 help / color / mirror / Atom feed
* ipmitool FRU write question
@ 2019-08-15 13:49 Harry Sung1
  2019-08-15 15:24 ` Ed Tanous
  0 siblings, 1 reply; 10+ messages in thread
From: Harry Sung1 @ 2019-08-15 13:49 UTC (permalink / raw)
  To: openbmc

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

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.

Thanks,
Harry

[-- Attachment #2: Type: text/html, Size: 2840 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: ipmitool FRU write question
  2019-08-15 13:49 ipmitool FRU write question Harry Sung1
@ 2019-08-15 15:24 ` Ed Tanous
  2019-08-16 16:52   ` [External] " Harry Sung1
  0 siblings, 1 reply; 10+ messages in thread
From: Ed Tanous @ 2019-08-15 15:24 UTC (permalink / raw)
  To: Harry Sung1, openbmc

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/159547cdfbf1992737dcecbcb3888af7795f930b/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.

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [External]  Re: ipmitool FRU write question
  2019-08-15 15:24 ` Ed Tanous
@ 2019-08-16 16:52   ` Harry Sung1
  2019-08-16 17:37     ` Ed Tanous
  2019-08-16 17:55     ` Patrick Venture
  0 siblings, 2 replies; 10+ messages in thread
From: Harry Sung1 @ 2019-08-16 16:52 UTC (permalink / raw)
  To: Ed Tanous, openbmc


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

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?

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?

Thanks,
Harry

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [External] Re: ipmitool FRU write question
  2019-08-16 16:52   ` [External] " Harry Sung1
@ 2019-08-16 17:37     ` Ed Tanous
  2019-08-22 13:58       ` Harry Sung1
  2019-08-16 17:55     ` Patrick Venture
  1 sibling, 1 reply; 10+ messages in thread
From: Ed Tanous @ 2019-08-16 17:37 UTC (permalink / raw)
  To: Harry Sung1, openbmc

On 8/16/19 9:52 AM, Harry Sung1 wrote:
> 
> 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.
> 
> 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}} -            -

Looking at the code, there's some irony there.  That function appears to
be implemented for compatibility, as it doesn't actually do anything
except return immediately.
https://github.com/openbmc/entity-manager/blob/b0097d41d206006a6c9a0e464cb87ccbf797921b/src/EntityManager.cpp#L1641

The irony is that (as you've found) it got the interface wrong, so it
doesn't really do anything useful in terms of compatibility.

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

If you are using FruDevice, you should use it in tandem with the command
sets I linked previously.  Given how entity-manager is architected,
there is no concept of a "Notify".  Entity manager relies on the
published ObjectManager interfaces to know when things have been
added/removed.  In the command sets I linked, they interact with
FruDevice directly, so technically entity manager isn't even required
for interacting with the physical fru devices.  Entity manager is used
for reconfiguring the system once the hardware has been detected via
FruDevice.

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

I don't believe anything you've looked at so far requires
intel-dbus-interfaces.  Most of the entity-manager/frudevice bindings
are using sdbusplus directly to create their interfaces.

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [External] Re: ipmitool FRU write question
  2019-08-16 16:52   ` [External] " Harry Sung1
  2019-08-16 17:37     ` Ed Tanous
@ 2019-08-16 17:55     ` Patrick Venture
  2019-08-19 21:55       ` Vijay Khemka
  1 sibling, 1 reply; 10+ messages in thread
From: Patrick Venture @ 2019-08-16 17:55 UTC (permalink / raw)
  To: Harry Sung1; +Cc: Ed Tanous, openbmc

On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1@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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [External] Re: ipmitool FRU write question
  2019-08-16 17:55     ` Patrick Venture
@ 2019-08-19 21:55       ` Vijay Khemka
  2019-08-19 22:18         ` Patrick Venture
  0 siblings, 1 reply; 10+ messages in thread
From: Vijay Khemka @ 2019-08-19 21:55 UTC (permalink / raw)
  To: Patrick Venture, Harry Sung1; +Cc: openbmc, Ed Tanous



On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of venture@google.com> wrote:

    On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1@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?
    
    >
    > Thanks,
    > Harry
    


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [External] Re: ipmitool FRU write question
  2019-08-19 21:55       ` Vijay Khemka
@ 2019-08-19 22:18         ` Patrick Venture
  2019-08-19 22:26           ` Vijay Khemka
  0 siblings, 1 reply; 10+ messages in thread
From: Patrick Venture @ 2019-08-19 22:18 UTC (permalink / raw)
  To: Vijay Khemka; +Cc: Harry Sung1, openbmc, Ed Tanous

On Mon, Aug 19, 2019 at 2:55 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of venture@google.com> wrote:
>
>     On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1@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.

>
>     >
>     > Thanks,
>     > Harry
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [External] Re: ipmitool FRU write question
  2019-08-19 22:18         ` Patrick Venture
@ 2019-08-19 22:26           ` Vijay Khemka
  2019-08-20  2:07             ` Harry Sung1
  0 siblings, 1 reply; 10+ messages in thread
From: Vijay Khemka @ 2019-08-19 22:26 UTC (permalink / raw)
  To: Patrick Venture; +Cc: Harry Sung1, openbmc, Ed Tanous



On 8/19/19, 3:19 PM, "Patrick Venture" <venture@google.com> wrote:

    On Mon, Aug 19, 2019 at 2:55 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of venture@google.com> wrote:
    >
    >     On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1@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
    >
    >
    


^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [External] Re: ipmitool FRU write question
  2019-08-19 22:26           ` Vijay Khemka
@ 2019-08-20  2:07             ` Harry Sung1
  0 siblings, 0 replies; 10+ messages in thread
From: Harry Sung1 @ 2019-08-20  2:07 UTC (permalink / raw)
  To: Vijay Khemka, Patrick Venture; +Cc: openbmc, Ed Tanous

> 
> On 8/19/19, 3:19 PM, "Patrick Venture" <venture@google.com> wrote:
> 
>     On Mon, Aug 19, 2019 at 2:55 PM Vijay Khemka <vijaykhemka@fb.com>
> wrote:
>     >
>     >
>     >
>     > On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture"
> <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of
> venture@google.com> wrote:
>     >
>     >     On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1
> <hsung1@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


^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [External] Re: ipmitool FRU write question
  2019-08-16 17:37     ` Ed Tanous
@ 2019-08-22 13:58       ` Harry Sung1
  0 siblings, 0 replies; 10+ messages in thread
From: Harry Sung1 @ 2019-08-22 13:58 UTC (permalink / raw)
  To: Ed Tanous, openbmc



> On 8/16/19 9:52 AM, Harry Sung1 wrote:
> >
> > 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.
> >
> > 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}} -
> -
> 
> Looking at the code, there's some irony there.  That function appears to be
> implemented for compatibility, as it doesn't actually do anything except return
> immediately.
> https://github.com/openbmc/entity-manager/blob/b0097d41d206006a6c9a0
> e464cb87ccbf797921b/src/EntityManager.cpp#L1641
> 

Thanks for your clear reply. I will look into it. 

> The irony is that (as you've found) it got the interface wrong, so it doesn't
> really do anything useful in terms of compatibility.
> 
> >
> > 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.cp
> > p#L206
> > Have you ever seen this issue before?
> 
> If you are using FruDevice, you should use it in tandem with the command sets
> I linked previously.  Given how entity-manager is architected, there is no
> concept of a "Notify".  Entity manager relies on the published ObjectManager
> interfaces to know when things have been added/removed.  In the command
> sets I linked, they interact with FruDevice directly, so technically entity
> manager isn't even required for interacting with the physical fru devices.
> Entity manager is used for reconfiguring the system once the hardware has
> been detected via FruDevice.

If I only want to use the FRU command sets yon linked previously. 
Is it allow to add Intel IPMI OEM commands into our IPMI OEM library?

> 
> >
> > 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?
> 
> I don't believe anything you've looked at so far requires intel-dbus-interfaces.
> Most of the entity-manager/frudevice bindings are using sdbusplus directly to
> create their interfaces.

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-08-22 13:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-15 13:49 ipmitool FRU write question Harry Sung1
2019-08-15 15:24 ` Ed Tanous
2019-08-16 16:52   ` [External] " Harry Sung1
2019-08-16 17:37     ` Ed Tanous
2019-08-22 13:58       ` Harry Sung1
2019-08-16 17:55     ` Patrick Venture
2019-08-19 21:55       ` Vijay Khemka
2019-08-19 22:18         ` Patrick Venture
2019-08-19 22:26           ` Vijay Khemka
2019-08-20  2:07             ` Harry Sung1

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.