Progress Codes in BMC

Supreeth Venkatesh supreeth.venkatesh at amd.com
Fri Jan 29 05:17:44 AEDT 2021



On 1/28/21 12:03 PM, Benjamin Fair wrote:
> [CAUTION: External Email]
> 
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dmtf.org%2Fsites%2Fdefault%2Ffiles%2Fstandards%2Fdocuments%2FDSP0249_1.0.0.pdf&data=04%7C01%7Csupreeth.venkatesh%40amd.com%7C318ef94d2e2449628c8f08d8c3b72a7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637474539330069219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rmQNUK8TbASF2%2Fy6N%2BLjjh2tCN8CHKEumXIedUYaRmQ%3D&reserved=0
>> 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.
Yup. It does.

> 
> 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 Benjamin. I will refer Nuvoton BPC driver.



> 
>>>
>>> Thanks,
>>> Deepak
>>>


More information about the openbmc mailing list