Progress Codes in BMC

[Supreeth Venkatesh]

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

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

> 
> Thanks,
> Deepak
>