Progress Codes in BMC

[manoj kiran]

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.
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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210204/184d17c2/attachment.htm>