* RE: Read FRU of host through ipmi in Entity manager.
2020-09-21 16:44 ` Kumar Thangavel
@ 2020-09-21 16:44 ` Kumar Thangavel
2020-09-22 19:57 ` Vijay Khemka
2020-09-22 20:04 ` Ed Tanous
2 siblings, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-21 16:44 UTC (permalink / raw)
To: Vijay Khemka, Ed Tanous
Cc: openbmc, Jae Hyun Yoo, Vernon Mauery, James Feist,
Velumani T-ERS,HCLTech, Patrick Williams
Classification: HCL Internal
Hi All,
Thanks for your comments and suggestions.
As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
Following are the advantages, if host FRU handling in entity manager repo.
1. All the FRU information is handling in the same repo.
2. Entity manager Probe can work.
3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
4. Adding Fru object to dbus handling are done.
5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
Please share your comments if any.
Thanks,
Kumar.
-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com>
Sent: Wednesday, September 16, 2020 12:51 AM
To: Ed Tanous <ed@tanous.net>; Kumar Thangavel <thangavel.k@hcl.com>
Cc: openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:
On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
>
>
> We are working on the Platform which has multi host and the host are FRUs. The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
>
> Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
> We understand that entity manager does not support ipmb based host fru.
Minor adjustment. FruDevice has this capability, not Entity Manager.
>
>
>
> So, we are proposing the design to support ipmb based FRU in entity manager.
> From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
>
> Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.
Minor amendment again. I'd much rather the IPMBSensor daemon simply
create the same interface that fru device does, rather than adding
IPMB logic to FruDevice. In this way, platforms that don't have IPMB
don't need to include the feature at all. Also, all the IO can be
managed in one place.
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fdbus-sensors%2Fblob%2Fmaster%2Fsrc%2FIpmbSensor.cpp&data=02%7C01%7Cthangavel.k%40hcl.com%7C2d76e1fe99cd49a9274c08d859ac7afb%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637357944630468057&sdata=i2ymwqY4AN0YeMSMbJRegBy9%2Brw1agiBXxibFZYMP9c%3D&reserved=0
Ideally, your IPMB device would also have an SDR that details what
FRUs and sensors exist, so that the inventory can be read and posted
to DBus at startup. If they don't then we might need a static mapping
from an EM config once the device on the other end is detected via get
device ID.
I agree with Ed here, all ipmb related interfaces should be implemented here.
>
>
>
> Please let us know your comments on this.
>
>
>
> Thanks,
>
> Kumar.
>
>
>
>
>
>
>
> ::DISCLAIMER::
> ________________________________
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
> ________________________________
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Read FRU of host through ipmi in Entity manager.
2020-09-21 16:44 ` Kumar Thangavel
2020-09-21 16:44 ` Kumar Thangavel
@ 2020-09-22 19:57 ` Vijay Khemka
2020-09-22 20:20 ` Ed Tanous
2020-09-22 20:04 ` Ed Tanous
2 siblings, 1 reply; 17+ messages in thread
From: Vijay Khemka @ 2020-09-22 19:57 UTC (permalink / raw)
To: Kumar Thangavel, Ed Tanous
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, James Feist,
Velumani T-ERS, HCLTech, Patrick Williams
On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
Classification: HCL Internal
Hi All,
Thanks for your comments and suggestions.
As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
Following are the advantages, if host FRU handling in entity manager repo.
1. All the FRU information is handling in the same repo.
2. Entity manager Probe can work.
3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
4. Adding Fru object to dbus handling are done.
5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
Please share your comments if any.
Thanks,
Kumar.
-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com>
Sent: Wednesday, September 16, 2020 12:51 AM
To: Ed Tanous <ed@tanous.net>; Kumar Thangavel <thangavel.k@hcl.com>
Cc: openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:
On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
>
>
> We are working on the Platform which has multi host and the host are FRUs. The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
>
> Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
> We understand that entity manager does not support ipmb based host fru.
Minor adjustment. FruDevice has this capability, not Entity Manager.
>
>
>
> So, we are proposing the design to support ipmb based FRU in entity manager.
> From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
>
> Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.
Minor amendment again. I'd much rather the IPMBSensor daemon simply
create the same interface that fru device does, rather than adding
IPMB logic to FruDevice. In this way, platforms that don't have IPMB
don't need to include the feature at all. Also, all the IO can be
managed in one place.
https://urldefense.proofpoint.com/v2/url?u=https-3A__apc01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fopenbmc-252Fdbus-2Dsensors-252Fblob-252Fmaster-252Fsrc-252FIpmbSensor.cpp-26amp-3Bdata-3D02-257C01-257Cthangavel.k-2540hcl.com-257C2d76e1fe99cd49a9274c08d859ac7afb-257C189de737c93a4f5a8b686f4ca9941912-257C0-257C0-257C637357944630468057-26amp-3Bsdata-3Di2ymwqY4AN0YeMSMbJRegBy9-252Brw1agiBXxibFZYMP9c-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=QVSWlu-mEtG6Sld0NeYhXvAUcpOxV6bVkSNsllKLkqA&s=CXdKjUg6ATp5JXX8Ou-blnmgJDzUPOP3ai9na2yT7T0&e=
Ideally, your IPMB device would also have an SDR that details what
FRUs and sensors exist, so that the inventory can be read and posted
to DBus at startup. If they don't then we might need a static mapping
from an EM config once the device on the other end is detected via get
device ID.
I agree with Ed here, all ipmb related interfaces should be implemented here.
>
>
>
> Please let us know your comments on this.
>
>
>
> Thanks,
>
> Kumar.
>
>
>
>
>
>
>
> ::DISCLAIMER::
> ________________________________
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
> ________________________________
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Read FRU of host through ipmi in Entity manager.
2020-09-22 19:57 ` Vijay Khemka
@ 2020-09-22 20:20 ` Ed Tanous
2020-09-22 20:26 ` Vijay Khemka
0 siblings, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:20 UTC (permalink / raw)
To: Vijay Khemka
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
James Feist, Velumani T-ERS, HCLTech, Patrick Williams
On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
> Thanks for your comments and suggestions.
>
> As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
> Following are the advantages, if host FRU handling in entity manager repo.
>
> 1. All the FRU information is handling in the same repo.
> 2. Entity manager Probe can work.
> 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
> 4. Adding Fru object to dbus handling are done.
> 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
>
> What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
phosphor-ipmi-fru is not compatible with IPMB Frus, as the
specification requires them to be dynamically scanned based on the
SDR. I guess you could hardcode them, but you'd still have to have
some auxiliary "does my device exist" scanning that starts to look a
lot like entity manager/fru device. Is the use case you present a
real one, or hypothetical?
>
> For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
Please don't. Entity-manager is dynamic, and the config should be
based on a detected entity. Mixing the dynamic and static use cases
in this way would mean that we get to rewrite all of this when we have
to support IPMB add-in-cards, which are 99% the same, but need to be
detected instead of hardcoded.
If you want this to be relatively static, attach an exposes record to
your baseboard config that has the information you need (if your IPMB
devices are on the baseboard).
>
> Please share your comments if any.
>
> Thanks,
> Kumar.
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Read FRU of host through ipmi in Entity manager.
2020-09-22 20:20 ` Ed Tanous
@ 2020-09-22 20:26 ` Vijay Khemka
2020-09-22 20:56 ` Ed Tanous
2020-09-24 15:12 ` Kumar Thangavel
0 siblings, 2 replies; 17+ messages in thread
From: Vijay Khemka @ 2020-09-22 20:26 UTC (permalink / raw)
To: Ed Tanous
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
James Feist, Velumani T-ERS, HCLTech, Patrick Williams
On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
> Thanks for your comments and suggestions.
>
> As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
> Following are the advantages, if host FRU handling in entity manager repo.
>
> 1. All the FRU information is handling in the same repo.
> 2. Entity manager Probe can work.
> 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
> 4. Adding Fru object to dbus handling are done.
> 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
>
> What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
phosphor-ipmi-fru is not compatible with IPMB Frus, as the
specification requires them to be dynamically scanned based on the
SDR. I guess you could hardcode them, but you'd still have to have
some auxiliary "does my device exist" scanning that starts to look a
lot like entity manager/fru device. Is the use case you present a
real one, or hypothetical?
>
> For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
Please don't. Entity-manager is dynamic, and the config should be
based on a detected entity. Mixing the dynamic and static use cases
in this way would mean that we get to rewrite all of this when we have
to support IPMB add-in-cards, which are 99% the same, but need to be
detected instead of hardcoded.
If you want this to be relatively static, attach an exposes record to
your baseboard config that has the information you need (if your IPMB
devices are on the baseboard).
Rather than having hardcoded config, can we can scan all available ipmb
devices under /dev/ipmb-* and send proper ipmb command to get fru
data.
>
> Please share your comments if any.
>
> Thanks,
> Kumar.
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Read FRU of host through ipmi in Entity manager.
2020-09-22 20:26 ` Vijay Khemka
@ 2020-09-22 20:56 ` Ed Tanous
2020-09-23 5:42 ` Vijay Khemka
2020-09-24 15:12 ` Kumar Thangavel
1 sibling, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:56 UTC (permalink / raw)
To: Vijay Khemka
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
James Feist, Velumani T-ERS, HCLTech, Patrick Williams
On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
>
> On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> >
> >
> > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
> >
> > Classification: HCL Internal
> >
> > Hi All,
> >
> > Thanks for your comments and suggestions.
> >
> > As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
> >
> > Following are the advantages, if host FRU handling in entity manager repo.
> >
> > 1. All the FRU information is handling in the same repo.
> > 2. Entity manager Probe can work.
> > 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
> > 4. Adding Fru object to dbus handling are done.
> > 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
> >
> > What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
>
> phosphor-ipmi-fru is not compatible with IPMB Frus, as the
> specification requires them to be dynamically scanned based on the
> SDR. I guess you could hardcode them, but you'd still have to have
> some auxiliary "does my device exist" scanning that starts to look a
> lot like entity manager/fru device. Is the use case you present a
> real one, or hypothetical?
>
> >
> > For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
>
> Please don't. Entity-manager is dynamic, and the config should be
> based on a detected entity. Mixing the dynamic and static use cases
> in this way would mean that we get to rewrite all of this when we have
> to support IPMB add-in-cards, which are 99% the same, but need to be
> detected instead of hardcoded.
> If you want this to be relatively static, attach an exposes record to
> your baseboard config that has the information you need (if your IPMB
> devices are on the baseboard).
>
> Rather than having hardcoded config, can we can scan all available ipmb
> devices under /dev/ipmb-* and send proper ipmb command to get fru
> data.
When an IPMB card is installed, who is in charge of creating the
/dev/ipmb-* node?
>
> >
> > Please share your comments if any.
> >
> > Thanks,
> > Kumar.
> >
> >
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Read FRU of host through ipmi in Entity manager.
2020-09-22 20:56 ` Ed Tanous
@ 2020-09-23 5:42 ` Vijay Khemka
0 siblings, 0 replies; 17+ messages in thread
From: Vijay Khemka @ 2020-09-23 5:42 UTC (permalink / raw)
To: Ed Tanous
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
James Feist, Velumani T-ERS, HCLTech, Patrick Williams
On 9/22/20, 1:58 PM, "Ed Tanous" <ed@tanous.net> wrote:
On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
>
> On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> >
> >
> > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
> >
> > Classification: HCL Internal
> >
> > Hi All,
> >
> > Thanks for your comments and suggestions.
> >
> > As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
> >
> > Following are the advantages, if host FRU handling in entity manager repo.
> >
> > 1. All the FRU information is handling in the same repo.
> > 2. Entity manager Probe can work.
> > 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
> > 4. Adding Fru object to dbus handling are done.
> > 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
> >
> > What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
>
> phosphor-ipmi-fru is not compatible with IPMB Frus, as the
> specification requires them to be dynamically scanned based on the
> SDR. I guess you could hardcode them, but you'd still have to have
> some auxiliary "does my device exist" scanning that starts to look a
> lot like entity manager/fru device. Is the use case you present a
> real one, or hypothetical?
>
> >
> > For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
>
> Please don't. Entity-manager is dynamic, and the config should be
> based on a detected entity. Mixing the dynamic and static use cases
> in this way would mean that we get to rewrite all of this when we have
> to support IPMB add-in-cards, which are 99% the same, but need to be
> detected instead of hardcoded.
> If you want this to be relatively static, attach an exposes record to
> your baseboard config that has the information you need (if your IPMB
> devices are on the baseboard).
>
> Rather than having hardcoded config, can we can scan all available ipmb
> devices under /dev/ipmb-* and send proper ipmb command to get fru
> data.
When an IPMB card is installed, who is in charge of creating the
/dev/ipmb-* node?
It should be kernel driver.
>
> >
> > Please share your comments if any.
> >
> > Thanks,
> > Kumar.
> >
> >
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Read FRU of host through ipmi in Entity manager.
2020-09-22 20:26 ` Vijay Khemka
2020-09-22 20:56 ` Ed Tanous
@ 2020-09-24 15:12 ` Kumar Thangavel
1 sibling, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-24 15:12 UTC (permalink / raw)
To: Vijay Khemka, Ed Tanous
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, James Feist,
Velumani T-ERS, HCLTech, Patrick Williams
Classification: HCL Internal
Hi Ed/Vijay.
Thanks for your comments. Please find my response below.
-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com>
Sent: Wednesday, September 23, 2020 1:57 AM
To: Ed Tanous <ed@tanous.net>
Cc: Kumar Thangavel <thangavel.k@hcl.com>; openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
> Thanks for your comments and suggestions.
>
> As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
> Following are the advantages, if host FRU handling in entity manager repo.
>
> 1. All the FRU information is handling in the same repo.
> 2. Entity manager Probe can work.
> 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
> 4. Adding Fru object to dbus handling are done.
> 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
>
> What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.
Will explore more on phosphor-ipmi-fru.
phosphor-ipmi-fru is not compatible with IPMB Frus, as the
specification requires them to be dynamically scanned based on the
SDR. I guess you could hardcode them, but you'd still have to have
some auxiliary "does my device exist" scanning that starts to look a
lot like entity manager/fru device. Is the use case you present a
real one, or hypothetical?
>
> For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
Please don't. Entity-manager is dynamic, and the config should be
based on a detected entity. Mixing the dynamic and static use cases
in this way would mean that we get to rewrite all of this when we have
to support IPMB add-in-cards, which are 99% the same, but need to be
detected instead of hardcoded.
If you want this to be relatively static, attach an exposes record to
your baseboard config that has the information you need (if your IPMB
devices are on the baseboard).
Rather than having hardcoded config, can we can scan all available ipmb devices under /dev/ipmb-* and send proper ipmb command to get fru data.
Yes. Planning to have dynamic config. All the ipmb transactions are handled in Ipmbbridge. So we are getting the ipmb bus details from json file(ipmb-channels.json) and then we will do a scan in all the buses defined in json . We will use ipmb command (ReadFruInfo) to get whether this bus/device has valid fru.
>
> Please share your comments if any.
>
> Thanks,
> Kumar.
>
>
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Read FRU of host through ipmi in Entity manager.
2020-09-21 16:44 ` Kumar Thangavel
2020-09-21 16:44 ` Kumar Thangavel
2020-09-22 19:57 ` Vijay Khemka
@ 2020-09-22 20:04 ` Ed Tanous
2020-09-24 15:12 ` Kumar Thangavel
2 siblings, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:04 UTC (permalink / raw)
To: Kumar Thangavel
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Patrick Williams,
James Feist, Velumani T-ERS, HCLTech, Vijay Khemka
On Mon, Sep 21, 2020 at 9:44 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
> Thanks for your comments and suggestions.
>
> As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
> Following are the advantages, if host FRU handling in entity manager repo.
>
> 1. All the FRU information is handling in the same repo.
But IPMB information is bifurcated in your plan. Ideally, Fru-Device
wouldn't even be in the entity-manager repo, it's there now just as an
artifact of the history of how it was built.
> 2. Entity manager Probe can work.
I'm not understanding this; Entity manager probes can work regardless
of where the code is checked in.
> 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
This is a valid point. Maybe some of the functions need abstracted
out into their own libraries?
> 4. Adding Fru object to dbus handling are done.
I'm not following this point. Are you saying that code wouldn't need
duplicated?
> 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
See previous point about "maybe we need a library".
>
> For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
It should be noted, there's going to need to be significantly more
code added to be able to scan and parse the SDR. I'm assuming that
code alone will be larger than FruDevice is today.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Read FRU of host through ipmi in Entity manager.
2020-09-22 20:04 ` Ed Tanous
@ 2020-09-24 15:12 ` Kumar Thangavel
0 siblings, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-24 15:12 UTC (permalink / raw)
To: Ed Tanous
Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Patrick Williams,
James Feist, Velumani T-ERS, HCLTech, Vijay Khemka
Classification: HCL Internal
Hi Ed,
Thanks for your comments on this.
Thanks,
Kumar.
-----Original Message-----
From: Ed Tanous <ed@tanous.net>
Sent: Wednesday, September 23, 2020 1:34 AM
To: Kumar Thangavel <thangavel.k@hcl.com>
Cc: Vijay Khemka <vijaykhemka@fb.com>; openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
On Mon, Sep 21, 2020 at 9:44 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
> Thanks for your comments and suggestions.
>
> As suggested, we are planning to implement a new process/service like xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
> Following are the advantages, if host FRU handling in entity manager repo.
>
> 1. All the FRU information is handling in the same repo.
But IPMB information is bifurcated in your plan. Ideally, Fru-Device wouldn't even be in the entity-manager repo, it's there now just as an artifact of the history of how it was built.
Ok.
> 2. Entity manager Probe can work.
I'm not understanding this; Entity manager probes can work regardless of where the code is checked in.
Ok.
> 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
This is a valid point. Maybe some of the functions need abstracted out into their own libraries?
Ok.
> 4. Adding Fru object to dbus handling are done.
I'm not following this point. Are you saying that code wouldn't need duplicated?
Yes. Planning to reuse the functions for adding fru object to dbus handling.
> 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
See previous point about "maybe we need a library".
>
> For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.
It should be noted, there's going to need to be significantly more code added to be able to scan and parse the SDR. I'm assuming that code alone will be larger than FruDevice is today.
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
^ permalink raw reply [flat|nested] 17+ messages in thread