Progress Codes in BMC

Deepak Kodihalli deepak.kodihalli.83 at gmail.com
Thu Feb 4 20:34:58 AEDT 2021


Hi Manoj,

On Thu, Feb 4, 2021 at 2:17 PM manoj kiran <manojkiran.eda at gmail.com> wrote:
>
> Hi All,
>
> Thanks to everyone for all the implementation ideas on this thread.
>
> After understanding all the inputs from the community , we were planning to proceed forward with using the existing infrastructure provided by phosphor-host-postd, phosphor-post-code-manager repo's & leverage the BIOS POSTCode Log service to do the job.
>
> The plan is to start with minimal working pieces. On the first go we are planning to come up with patchsets that will do the following:
>
> 1.Come up with a compilation flag & make sure phosphor-host-postd still hosts the dbus interface even if it does not see the snoop port.

Is there a benefit of using phosphor-host-postd as opposed to pldmd
implementing the Boot.Raw interface (i.e if you take out the snoop
part, does it do anything else than just hosting a D-Bus object)?
Post-code-manager should still work as-is. If you use host-postd for
this and if pldmd makes a D-Bus call to write Boot.Raw as a client,
that seems like one additional D-Bus call to get a code out via
Redfish.

Thanks,
Deepak

> 2.PLDM will receive the 72bytes of progress code from the hypervisor via File I/O, and then just send the first 8 bytes(discard everything else) to the existing Raw Property & use the existing redfish BIOS Post Code log service to check if things are working.
>
> In the next iteration :
> 1. We will try to modify the existing dbus property (Boot.Raw) to array[byte] & the piece of code that uses this property in other repos including the post-code-manager.
> 2. There might be a need to Modify/Add new interfaces used by post-code-manager to parse the buffer & host the dbus objects to such an extent that an AdditionalDataURI can be given to clients(base64 encoded buffer) apart from filling the existing redfish message registry.
>
> Does the community foresee any issues/problems if we stick to the above-mentioned plan?
>
> Thanks,
> Manoj
>
> On Feb 2 2021, at 8:15 am, Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Mon, Feb 01, 2021 at 07:21:39PM -0500, Brad Bishop wrote:
> > On Sat, Jan 30, 2021 at 08:31:26AM -0600, Patrick Williams wrote:
> > >On Wed, Jan 27, 2021 at 08:05:26PM -0500, Brad Bishop wrote:
> > >>
> > >> There are multiple sources of the codes - on Power the power sequencing
> > >> is done on the BMC and that is considered part of the server boot so we
> > >> have both those applications indicating their progress along with the
> > >> more traditional progress flowing down from system firmware.
> > >
> > >The `xyz.openbmc_project.State.Boot.Raw` is the interface to use here.
> > >You just write the `Value` property.
> >
> > Ok. Do I have it right - on any application that wants to post a
> > "progress code" you would just implement this interface on a single
> > (arbitrary?) path and continually write to the Value property?
>
> I think it is even simpler than that. You just need to make a dbus
> client call to write to the Boot.Raw value. This might happen from your
> boot sequence on the BMC-side or from PLDM for the Host-side.
>
> You will want the phosphor-post-code-manager application running, which will
> listen to the PropertyChanged signals from Boot.Raw and keep the running
> history for you.
>
> There is also phosphor-host-postd. Currently it has an implementation
> that looks at LPC to get the post codes. There was a proposed
> implementation [1] that added multi-host support and I think support to
> get the value directly from dbus client writes to Boot.Raw instead of
> the lpc-snoop method. Then there is code in fb-ipmi-oem that writes the
> results of some IPMB messages into the Boot.Raw value[2]. Looking at
> this I'm not positive that all the pieces are all there, but I think it
> is mostly there. Maybe check with the author on 1 to see where it is
> at.
>
> This design doc might be useful too [3].
>
> 1. https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-postd/+/36509
> 2. https://github.com/openbmc/fb-ipmi-oem/blob/master/src/biccommands.cpp#L76
> 3. https://github.com/openbmc/docs/blob/master/designs/multi-host-postcode.md
>
> --
> Patrick Williams


More information about the openbmc mailing list