Progress Codes in BMC

[Benjamin Fair]

On Fri, 22 Jan 2021 at 06:19, Supreeth Venkatesh
<supreeth.venkatesh at amd.com> wrote:
>
>
>
> On 1/22/21 6:32 AM, Deepak Kodihalli wrote:
> > [CAUTION: External Email]
> >
> > Hi Manoj,
> >
> > On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda at gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> IBM Servers has a feature called Progress codes[1]. These are generated by applications on the BMC & host to show their progress via the standard interfaces like GUI & control panel [2]. These progress codes are used during boot hangs e.t.c to provide additional detail as to how far we made it with respect to boot.
> >>
> >> Does the community has shared interests on this & would like to collaborate ?
> >
> > I am interested in this problem as well and would like to collaborate.
> I am interested as well.
>
> > OpenBMC already seems to have solutions for POST codes -
> > phosphor-host-postd, phosphor-post-code-manager and there's a
> > Boot.Raw.Value D-Bus API. However it would be nice to have a more
> > generic solution. I think it's hard to converge on the format of such
> > codes (since they can originate from different layers of firmware
> > stacks/bootloaders and some of these layers might not accommodate
> > PLDM/IPMI etc).
> In this process, We may have to extend
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf
> which has a 16 bit state sensor for Boot Progress. As well, We may have to make sure that it gets mapped to
> Redfish.
>
> What I mean by generic above is:
> > - A generic D-Bus API for progress codes
> > - A generic app for managing the policies around such codes
> > - Platform specific "Producers" of progress codes, conforming to the
> > generic D-Bus API
> > - Redfish mechanisms (LogService/other) to extract codes

Yes, this would definitely be useful. I believe we've had discussions
in the past but were unable to come up with a satisfactory interface
that supports all of the different types of progress codes.

>
> +1
>
> >
> > Maybe some of the apps I pointed above can be extended for this
> > purpose, but I'm yet to take a closer look.
> One of the deviations on AMD platforms is that POST code is usually 32 bit code.
> I did extend phosphor-host-postd to read 32 bit codes and added experimental associated driver in Linux, as LPC ports supported is only two.
> However, it is far from production quality code at this point. We can definitely collaborate on this to arrive at a generic solution.
>

phosphor-host-postd supports the "-b" option to specify POST code
length in bytes, with up to 8 supported.

The Nuvoton BPC driver has support for 32 bit POST codes as well, so
you may find it helpful to refer to that when working on the Aspeed
driver.

> >
> > Thanks,
> > Deepak
> >