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