Read FRU of host through ipmi in Entity manager.

[Kumar Thangavel]

Classification: HCL Internal

Hi Ed/Vijay.

Thanks for your comments. Please find my response below.

-----Original Message-----
From: Vijay Khemka <vijaykhemka at fb.com>
Sent: Wednesday, September 23, 2020 1:57 AM
To: Ed Tanous <ed at tanous.net>
Cc: Kumar Thangavel <thangavel.k at hcl.com>; openbmc at lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo at linux.intel.com>; Vernon Mauery <vernon.mauery at linux.intel.com>; James Feist <james.feist at linux.intel.com>; Velumani T-ERS,HCLTech <velumanit at hcl.com>; Patrick Williams <patrickw3 at 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 at tanous.net> wrote:

    On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
    >
    >
    >
    > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k at 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.
________________________________