openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kumar Thangavel <thangavel.k@hcl.com>
To: Vijay Khemka <vijaykhemka@fb.com>, Ed Tanous <ed@tanous.net>
Cc: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
	Vernon Mauery <vernon.mauery@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	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.
Date: Mon, 21 Sep 2020 16:44:40 +0000	[thread overview]
Message-ID: <HK0PR04MB29649824A0F904C61F35152AFD3A0@HK0PR04MB2964.apcprd04.prod.outlook.com> (raw)
In-Reply-To: <3D149923-0A95-4CE6-82EF-8338677EF831@fb.com>

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&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7C2d76e1fe99cd49a9274c08d859ac7afb%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637357944630468057&amp;sdata=i2ymwqY4AN0YeMSMbJRegBy9%2Brw1agiBXxibFZYMP9c%3D&amp;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.
    > ________________________________


WARNING: multiple messages have this Message-ID (diff)
From: Kumar Thangavel <thangavel.k@hcl.com>
To: Vijay Khemka <vijaykhemka@fb.com>, Ed Tanous <ed@tanous.net>
Cc: "openbmc@lists.ozlabs.org" <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.
Date: Mon, 21 Sep 2020 16:44:40 +0000	[thread overview]
Message-ID: <HK0PR04MB29649824A0F904C61F35152AFD3A0@HK0PR04MB2964.apcprd04.prod.outlook.com> (raw)
Message-ID: <20200921164440.aj_BZWMd7WITj-gEvkwoFpL4V95RoO3KcD1CaPPxNHA@z> (raw)
In-Reply-To: <3D149923-0A95-4CE6-82EF-8338677EF831@fb.com>

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&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7C2d76e1fe99cd49a9274c08d859ac7afb%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637357944630468057&amp;sdata=i2ymwqY4AN0YeMSMbJRegBy9%2Brw1agiBXxibFZYMP9c%3D&amp;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.
    > ________________________________


  reply	other threads:[~2020-09-21 17:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 16:55 Read FRU of host through ipmi in Entity manager Kumar Thangavel
2020-09-14 17:25 ` Thomaiyar, Richard Marian
2020-09-14 17:28 ` James Feist
2020-09-14 17:28 ` Ed Tanous
2020-09-15 19:20   ` Vijay Khemka
2020-09-21 16:44     ` Kumar Thangavel [this message]
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:26           ` Vijay Khemka
2020-09-22 20:56             ` Ed Tanous
2020-09-23  5:42               ` Vijay Khemka
2020-09-24 15:12             ` Kumar Thangavel
2020-09-22 20:04       ` Ed Tanous
2020-09-24 15:12         ` Kumar Thangavel
2020-09-22  7:51     ` Andrei Kartashev
2020-09-22 20:13       ` Ed Tanous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK0PR04MB29649824A0F904C61F35152AFD3A0@HK0PR04MB2964.apcprd04.prod.outlook.com \
    --to=thangavel.k@hcl.com \
    --cc=ed@tanous.net \
    --cc=jae.hyun.yoo@linux.intel.com \
    --cc=james.feist@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrickw3@fb.com \
    --cc=velumanit@hcl.com \
    --cc=vernon.mauery@linux.intel.com \
    --cc=vijaykhemka@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).