Read FRU of host through ipmi in Entity manager.

Ed Tanous ed at tanous.net
Wed Sep 23 06:56:24 AEST 2020


On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> 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.
>
>     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.
>     >
>     >
>


More information about the openbmc mailing list