Progress Codes in BMC

Progress Codes in BMC

[manoj kiran]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

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 ?
Thanks,
Manoj

[1] : https://www.ibm.com/support/knowledgecenter/POWER7_REF/p7eai/progress_codes_parent.htm
[2] : https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/38904

[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: Progress Codes in BMC

[Deepak Kodihalli]

Hi Manoj,

On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda@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.
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). 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

Maybe some of the apps I pointed above can be extended for this
purpose, but I'm yet to take a closer look.

Thanks,
Deepak

Re: 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@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
> 

Re: Progress Codes in BMC

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

On Fri, Jan 22, 2021 at 08:18:29AM -0600, Supreeth Venkatesh wrote:
> On 1/22/21 6:32 AM, Deepak Kodihalli wrote:
> > On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda@gmail.com> wrote:
> > 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.

I was also going to point to the postcode daemons as a good starting
point.  On Intel platforms, the postcodes are typically 1 byte.  The
previous postcode daemon got its data from the LPC "port 80" mechanism,
but Facebook/HCL recently extended it to support multi-host and to be
able to consume postcodes from an IPMB end-point (which is how we talk
to our per-host microcontroller).

I think it should be fairly straight-forward to add a new mechanism to
pick up data from PLDM or whatever your path is on Power.  The daemons
in question here already support keeping a history as well.  I think the
only think you'd need to do is extend it to be 32-bit or 64-bit progress
codes instead of just 8-bit, but I see no reason why that shouldn't be
acceptable.  It sounds like Supreeth might even have some code as a
starting point?

(Supreeth maybe you can throw up anything you've done to the postcode
daemons into Gerrit as a starting point?)

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Re: Progress Codes in BMC

[chunhui.jia]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

Patrick, Deepak,

Current post code is stored as 64bits although data from HW is 8bits. It should be enough to host. With said, we don't need to extend as it is already 64bits.

https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Raw.interface.yaml#L6  
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/PostCode.interface.yaml#L45

2021-01-25 

chunhui.jia 



发件人：Patrick Williams <patrick@stwcx.xyz>
发送时间：2021-01-22 22:52
主题：Re: Progress Codes in BMC
收件人："Supreeth Venkatesh"<supreeth.venkatesh@amd.com>
抄送："openbmc"<openbmc@lists.ozlabs.org>

On Fri, Jan 22, 2021 at 08:18:29AM -0600, Supreeth Venkatesh wrote: 
> On 1/22/21 6:32 AM, Deepak Kodihalli wrote: 
> > On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda@gmail.com> wrote: 
> > 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. 

I was also going to point to the postcode daemons as a good starting 
point.  On Intel platforms, the postcodes are typically 1 byte.  The 
previous postcode daemon got its data from the LPC "port 80" mechanism, 
but Facebook/HCL recently extended it to support multi-host and to be 
able to consume postcodes from an IPMB end-point (which is how we talk 
to our per-host microcontroller). 

I think it should be fairly straight-forward to add a new mechanism to 
pick up data from PLDM or whatever your path is on Power.  The daemons 
in question here already support keeping a history as well.  I think the 
only think you'd need to do is extend it to be 32-bit or 64-bit progress 
codes instead of just 8-bit, but I see no reason why that shouldn't be 
acceptable.  It sounds like Supreeth might even have some code as a 
starting point? 

(Supreeth maybe you can throw up anything you've done to the postcode 
daemons into Gerrit as a starting point?) 

--  
Patrick Williams 

[-- Attachment #2: Type: text/html, Size: 6087 bytes --]

RE: Re: Progress Codes in BMC

[Venkatesh, Supreeth]

[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]

[AMD Official Use Only - Internal Distribution Only]

DBus interface and Phosphor-postcode-manager are equipped to handle 64 bit raw data.
However, phosphor-host-postd in its current form reads only 8 bits as you mentioned from LPC snoop port, which needs to be extended to read more than 8 bits.
Also, it is desirable to have capability to not just read the LPC snoop port(s), but also it should also be able to read from PLDM terminus with scope for extension to read from other device paths.(if necessary based on platform design)
May be a wrapper over the  phosphor-host-postd (which will be LPC snoop reading application), some other application(s) to read from various other device paths can be an option.

Further, I think the original idea from Manoj was to display this progress code via the standard interfaces like GUI control panel, AFAIK, this is not present with current UI.
Right now, We(AMD) are extending the GUI by just adding state sensor which displays the last value in Sensors page with future expansion to add a link to /var/lib/<phosphor-postcode-manager>/currrentbootIndex file to
get the entire post codes.

Thanks,
Supreeth
From: chunhui.jia <chunhui.jia@linux.intel.com>
Sent: Sunday, January 24, 2021 8:24 PM
To: Patrick Williams <patrick@stwcx.xyz>; Venkatesh, Supreeth <Supreeth.Venkatesh@amd.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Re: Progress Codes in BMC

[CAUTION: External Email]
Patrick, Deepak,

Current post code is stored as 64bits although data from HW is 8bits. It should be enough to host. With said, we don't need to extend as it is already 64bits.

https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Raw.interface.yaml#L6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Fblob%2Fmaster%2Fxyz%2Fopenbmc_project%2FState%2FBoot%2FRaw.interface.yaml%23L6&data=04%7C01%7Csupreeth.venkatesh%40amd.com%7Ce3e9a73c11f448affeb508d8c0d856e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637471382696079136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oZMT2egLjtk76X6qhck1XFppvcFfcN58nuXnRd%2BnZDc%3D&reserved=0>
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/PostCode.interface.yaml#L45<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Fblob%2Fmaster%2Fxyz%2Fopenbmc_project%2FState%2FBoot%2FPostCode.interface.yaml%23L45&data=04%7C01%7Csupreeth.venkatesh%40amd.com%7Ce3e9a73c11f448affeb508d8c0d856e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637471382696089131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ojTEgHx9oHCC6ro0rNW0o3wjCxuCBPchjjtb41S7Tmg%3D&reserved=0>

2021-01-25
________________________________
chunhui.jia
________________________________
发件人：Patrick Williams <patrick@stwcx.xyz<mailto:patrick@stwcx.xyz>>
发送时间：2021-01-22 22:52
主题：Re: Progress Codes in BMC
收件人："Supreeth Venkatesh"<supreeth.venkatesh@amd.com<mailto:supreeth.venkatesh@amd.com>>
抄送："openbmc"<openbmc@lists.ozlabs.org<mailto:openbmc@lists.ozlabs.org>>

On Fri, Jan 22, 2021 at 08:18:29AM -0600, Supreeth Venkatesh wrote:
> On 1/22/21 6:32 AM, Deepak Kodihalli wrote:
> > On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda@gmail.com<mailto:manojkiran.eda@gmail.com>> wrote:
> > 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.

I was also going to point to the postcode daemons as a good starting
point.  On Intel platforms, the postcodes are typically 1 byte.  The
previous postcode daemon got its data from the LPC "port 80" mechanism,
but Facebook/HCL recently extended it to support multi-host and to be
able to consume postcodes from an IPMB end-point (which is how we talk
to our per-host microcontroller).

I think it should be fairly straight-forward to add a new mechanism to
pick up data from PLDM or whatever your path is on Power.  The daemons
in question here already support keeping a history as well.  I think the
only think you'd need to do is extend it to be 32-bit or 64-bit progress
codes instead of just 8-bit, but I see no reason why that shouldn't be
acceptable.  It sounds like Supreeth might even have some code as a
starting point?

(Supreeth maybe you can throw up anything you've done to the postcode
daemons into Gerrit as a starting point?)

--
Patrick Williams


[-- Attachment #2: Type: text/html, Size: 19033 bytes --]

Re: RE: Re: Progress Codes in BMC

[chunhui.jia]

[-- Attachment #1: Type: text/plain, Size: 4733 bytes --]

#1 if more backends (PLDM for example) are required, we could extend it for sure. 
#2 Instead of accessing local files directly,  I would suggest to use existed redfish schema for POST code. It could extract post code history.
https://github.com/openbmc/bmcweb/blob/88b3dd12851cd7bdd4b5c065ba99f40feafb775e/redfish-core/lib/log_services.hpp#L2986
User could access like following URL:
https://xx.xx.xx.xx/redfish/v1/Systems/system/LogServices/PostCodes/Entries 

WEBUI could also leverage this to implement UI entry for post code/progress code.  



2021-01-26 

chunhui.jia 



发件人："Venkatesh, Supreeth" <Supreeth.Venkatesh@amd.com>
发送时间：2021-01-25 13:29
主题：RE: Re: Progress Codes in BMC
收件人："chunhui.jia"<chunhui.jia@linux.intel.com>,"Patrick Williams"<patrick@stwcx.xyz>
抄送："openbmc"<openbmc@lists.ozlabs.org>

[AMD Official Use Only - Internal Distribution Only]
 
DBus interface and Phosphor-postcode-manager are equipped to handle 64 bit raw data.
However, phosphor-host-postd in its current form reads only 8 bits as you mentioned from LPC snoop port, which needs to be extended to read more than 8 bits.
Also, it is desirable to have capability to not just read the LPC snoop port(s), but also it should also be able to read from PLDM terminus with scope for extension to read from other device paths.(if necessary based on platform design)
May be a wrapper over the  phosphor-host-postd (which will be LPC snoop reading application), some other application(s) to read from various other device paths can be an option.
 
Further, I think the original idea from Manoj was to display this progress code via the standard interfaces like GUI control panel, AFAIK, this is not present with current UI.
Right now, We(AMD) are extending the GUI by just adding state sensor which displays the last value in Sensors page with future expansion to add a link to /var/lib/<phosphor-postcode-manager>/currrentbootIndex file to 
get the entire post codes.
 
Thanks,
Supreeth
From: chunhui.jia <chunhui.jia@linux.intel.com> 
Sent: Sunday, January 24, 2021 8:24 PM
To: Patrick Williams <patrick@stwcx.xyz>; Venkatesh, Supreeth <Supreeth.Venkatesh@amd.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Re: Progress Codes in BMC
 
[CAUTION: External Email] 
Patrick, Deepak,
 
Current post code is stored as 64bits although data from HW is 8bits. It should be enough to host. With said, we don't need to extend as it is already 64bits.
 
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/Raw.interface.yaml#L6  
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/State/Boot/PostCode.interface.yaml#L45
 
2021-01-25 



chunhui.jia 



发件人：Patrick Williams <patrick@stwcx.xyz>
发送时间：2021-01-22 22:52
主题：Re: Progress Codes in BMC
收件人："Supreeth Venkatesh"<supreeth.venkatesh@amd.com>
抄送："openbmc"<openbmc@lists.ozlabs.org>
 
On Fri, Jan 22, 2021 at 08:18:29AM -0600, Supreeth Venkatesh wrote: 
> On 1/22/21 6:32 AM, Deepak Kodihalli wrote: 
> > On Fri, Jan 22, 2021 at 5:25 PM manoj kiran <manojkiran.eda@gmail.com> wrote: 
> > 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. 
 
I was also going to point to the postcode daemons as a good starting 
point.  On Intel platforms, the postcodes are typically 1 byte.  The 
previous postcode daemon got its data from the LPC "port 80" mechanism, 
but Facebook/HCL recently extended it to support multi-host and to be 
able to consume postcodes from an IPMB end-point (which is how we talk 
to our per-host microcontroller). 
 
I think it should be fairly straight-forward to add a new mechanism to 
pick up data from PLDM or whatever your path is on Power.  The daemons 
in question here already support keeping a history as well.  I think the 
only think you'd need to do is extend it to be 32-bit or 64-bit progress 
codes instead of just 8-bit, but I see no reason why that shouldn't be 
acceptable.  It sounds like Supreeth might even have some code as a 
starting point? 
 
(Supreeth maybe you can throw up anything you've done to the postcode 
daemons into Gerrit as a starting point?) 
 
--  
Patrick Williams 
 

[-- Attachment #2: Type: text/html, Size: 21303 bytes --]

Re: Progress Codes in BMC

[Brad Bishop]

On Fri, Jan 22, 2021 at 08:52:14AM -0600, Patrick Williams wrote:

>I was also going to point to the postcode daemons as a good starting
>point.  On Intel platforms, the postcodes are typically 1 byte.  The
>previous postcode daemon got its data from the LPC "port 80" mechanism,
>but Facebook/HCL recently extended it to support multi-host and to be
>able to consume postcodes from an IPMB end-point (which is how we talk
>to our per-host microcontroller).
>
>I think it should be fairly straight-forward to add a new mechanism to
>pick up data from PLDM or whatever your path is on Power.  

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 daemons
>in question here already support keeping a history as well.  I think the
>only think you'd need to do is extend it to be 32-bit or 64-bit progress
>codes instead of just 8-bit, but I see no reason why that shouldn't be
>acceptable.

Our progress codes are much larger than 64 bits.  More like 64 bytes.  
Does that still seem acceptable?

There were lots of great implementation ideas in this thread, thanks to 
everyone that replied.

I'd also like to sort out the external facing interfaces for these codes 
though.  My straw-man proposal would be that these are just another log 
service with yet another additionaldatauri attachment in the log 
entries.  Is this a terrible idea?

- brad

Re: Progress Codes in BMC

[Benjamin Fair]

On Fri, 22 Jan 2021 at 06:19, Supreeth Venkatesh
<supreeth.venkatesh@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@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
> >

Re: Progress Codes in BMC

[Supreeth Venkatesh]

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@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@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&amp;data=04%7C01%7Csupreeth.venkatesh%40amd.com%7C318ef94d2e2449628c8f08d8c3b72a7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637474539330069219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=rmQNUK8TbASF2%2Fy6N%2BLjjh2tCN8CHKEumXIedUYaRmQ%3D&amp;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
>>>

Re: Progress Codes in BMC

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Wed, Jan 27, 2021 at 08:05:26PM -0500, Brad Bishop wrote:
> On Fri, Jan 22, 2021 at 08:52:14AM -0600, Patrick Williams 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.  The hosting daemon doesn't really
care where it came from.  We have this in the fb-ipmi-oem to handle IPMB
messages that come from our per-cpu-card uC.

> >The daemons
> >in question here already support keeping a history as well.  I think the
> >only think you'd need to do is extend it to be 32-bit or 64-bit progress
> >codes instead of just 8-bit, but I see no reason why that shouldn't be
> >acceptable.
> 
> Our progress codes are much larger than 64 bits.  More like 64 bytes.  
> Does that still seem acceptable?

Maybe we could change Value from a uint64 to a vector<uint64>?

> I'd also like to sort out the external facing interfaces for these codes 
> though.  My straw-man proposal would be that these are just another log 
> service with yet another additionaldatauri attachment in the log 
> entries.  Is this a terrible idea?

I think you're asking about Redfish now?  I have no opinion on that.

The `xyz.opnbmc_project.State.Boot.PostCode` interface contains the
history of the `Boot.Raw` values.  I think you could generate some kind
of "log" from that.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Progress Codes in BMC

[Brad Bishop]

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?

>> Our progress codes are much larger than 64 bits.  More like 64 bytes.
>> Does that still seem acceptable?
>
>Maybe we could change Value from a uint64 to a vector<uint64>?

Works for me.  Does anyone have a problem with this?  Hoping the 
existing users of this interface will speak up - I've CCed them...

>> I'd also like to sort out the external facing interfaces for these codes
>> though.  My straw-man proposal would be that these are just another log
>> service with yet another additionaldatauri attachment in the log
>> entries.  Is this a terrible idea?
>
>I think you're asking about Redfish now?  I have no opinion on that.

Yes I'm asking about Redfish.  If any of the bmcweb maintainers could 
speak up on whether or not a LogService is the right path to take here 
_before_ we get too far down the design path that would be fantastic.

thx - brad

Re: Progress Codes in BMC

[Ed Tanous]

On Mon, Feb 1, 2021 at 4:21 PM Brad Bishop <bradleyb@fuzziesquirrel.com> 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?
>
> >> Our progress codes are much larger than 64 bits.  More like 64 bytes.
> >> Does that still seem acceptable?
> >
> >Maybe we could change Value from a uint64 to a vector<uint64>?
>
> Works for me.  Does anyone have a problem with this?  Hoping the
> existing users of this interface will speak up - I've CCed them...
>
> >> I'd also like to sort out the external facing interfaces for these codes
> >> though.  My straw-man proposal would be that these are just another log
> >> service with yet another additionaldatauri attachment in the log
> >> entries.  Is this a terrible idea?
> >
> >I think you're asking about Redfish now?  I have no opinion on that.
>
> Yes I'm asking about Redfish.  If any of the bmcweb maintainers could
> speak up on whether or not a LogService is the right path to take here
> _before_ we get too far down the design path that would be fantastic.

Considering that bmcweb already has an LogService implementation to
access post codes, yeah, log service seems reasonable to represent
post codes.  I don't see how you're going to fit the vector<uint64_t>
thing into a log entry, as that's not really what log entries are, and
the way that Redfish defines them, you're effectively limited to a
uint64_t for a numeric argument anyway, even though json supports
arbitrary precision, so I'd be interested to see what the proposed log
entries look like.  I was hoping to look into exactly how the existing
one worked so I could give a better technical answer, but a pointer to
the code is as good as I can do for the moment.
https://github.com/openbmc/bmcweb/blob/88b3dd12851cd7bdd4b5c065ba99f40feafb775e/redfish-core/lib/log_services.hpp#L2984

if you're hoping to get human readable post codes, and not just raw
values, there's probably a discussion that needs to be had about how
the message registry would work between systems, considering that
every system implements different post codes, we'd have to switch
registries dependent on the processor present, and there are likely
multiple processors in the system, possibly with different post code
definitions, so the needed configurability explodes a little bit.  If
you could avoid that, I would.

>
> thx - brad

Re: Progress Codes in BMC

[Brad Bishop]

On Mon, Feb 01, 2021 at 04:49:31PM -0800, Ed Tanous wrote:
>Considering that bmcweb already has an LogService implementation to
>access post codes, yeah, log service seems reasonable to represent
>post codes

Nice!  I didn't realize this.  I hope the backend is simply the Boot.Raw 
interface and doesn't require any other applications...

>I  don't see how you're going to fit the vector<uint64_t>
>thing into a log entry

My straw-man thinking was as an additionalDataUri attachment.

>the way that Redfish defines them, you're effectively limited to a
>uint64_t for a numeric argument anyway, 

I'm not following this.  Redfish log entries are limited to a uint64?  
Which property in the LogEntry object are you referring to?

>arbitrary precision, so I'd be interested to see what the proposed log
>entries look like. 

What is the best way to go about making a proposal?  Are additional 
details needed other than I want to stuff all the data in an 
additionalDataUri attachment?

>I was hoping to look into exactly how the existing
>one worked so I could give a better technical answer, but a pointer to
>the code is as good as I can do for the moment.
>https://github.com/openbmc/bmcweb/blob/88b3dd12851cd7bdd4b5c065ba99f40feafb775e/redfish-core/lib/log_services.hpp#L2984
>
>if you're hoping to get human readable post codes, and not just raw
>values, there's probably a discussion that needs to be had about how
>the message registry would work between systems, considering that
>every system implements different post codes, we'd have to switch
>registries dependent on the processor present, and there are likely
>multiple processors in the system, possibly with different post code
>definitions, so the needed configurability explodes a little bit.  If
>you could avoid that, I would.

Agreed - I am not looking for human readable post codes.

Re: Progress Codes in BMC

[Ed Tanous]

On Mon, Feb 1, 2021 at 5:08 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> On Mon, Feb 01, 2021 at 04:49:31PM -0800, Ed Tanous wrote:
> >Considering that bmcweb already has an LogService implementation to
> >access post codes, yeah, log service seems reasonable to represent
> >post codes
>
> Nice!  I didn't realize this.  I hope the backend is simply the Boot.Raw
> interface and doesn't require any other applications...

This is what I was hoping to look at before I posted it, so it remains
to be seen how it works.

>
> >I  don't see how you're going to fit the vector<uint64_t>
> >thing into a log entry
>
> My straw-man thinking was as an additionalDataUri attachment.

Overall, I'm not a huge fan of additionalDataUri in Redfish.  In terms
of redfish, it essentially moves from "this is structured data that
fits X schema" to, "This can be anything you want, and the client
needs to divine the schema out of thin air".  In terms of OpenBMC,
using it a lot worries me, as it seems like it's just there to bypass
the message registry requirement in the schema, and provide an
unstructured interface from an interface that's supposed to be
structured.
With that said, if this is in addition to the structured data, maybe it's ok?

>
> >the way that Redfish defines them, you're effectively limited to a
> >uint64_t for a numeric argument anyway,
>
> I'm not following this.  Redfish log entries are limited to a uint64?
> Which property in the LogEntry object are you referring to?

In a log entry, you'd normally have a message something like

Id: MyCustomPostCodeMessageInTheRegistry
Message: "PostCode 4 happened"
Args: [
   4
]

If automation were reading post codes, it would only be looking at the
ID and Args fields, not the human readable message.  The problem comes
in that the arg itself is an int type, which in nlohmann::json c++ is
a uint64_t.  Technically in the json spec, that int could be a
uint512, and you could declare a custom serializer to do it but you'd
probably run into compatibility problems with other serializers that
can't handle beyond a uint64.

As I'm typing this, there's probably cheats around this, like a hex
encoded string, which I think has a built-in redfish type, but would
be parsed by json just fine.  I'd have to look at the redfish spec to
know for sure.

>
> >arbitrary precision, so I'd be interested to see what the proposed log
> >entries look like.
>
> What is the best way to go about making a proposal?  Are additional
> details needed other than I want to stuff all the data in an
> additionalDataUri attachment?

The ideal in my mind would be to mock up a strawman LogEntry example,
and see what it looks like.  Considering redfish did add the
additionaDataUri field, I suspect I'm in the minority on not liking
it, so I'm not going to pee into the wind here, but would like to see
what the more structured options look like, and why they're not a
great fit.

>
> >I was hoping to look into exactly how the existing
> >one worked so I could give a better technical answer, but a pointer to
> >the code is as good as I can do for the moment.
> >https://github.com/openbmc/bmcweb/blob/88b3dd12851cd7bdd4b5c065ba99f40feafb775e/redfish-core/lib/log_services.hpp#L2984
> >
> >if you're hoping to get human readable post codes, and not just raw
> >values, there's probably a discussion that needs to be had about how
> >the message registry would work between systems, considering that
> >every system implements different post codes, we'd have to switch
> >registries dependent on the processor present, and there are likely
> >multiple processors in the system, possibly with different post code
> >definitions, so the needed configurability explodes a little bit.  If
> >you could avoid that, I would.
>
> Agreed - I am not looking for human readable post codes.

One thing I would like to make sure is that if people _want_ to design
human readable post codes in the future, we haven't backed ourselves
into a corner design-wise.  With that said, I think just having a
unique message id gets us what we need there, but it'd be good to just
keep it in the back of your mind.

Re: Progress Codes in BMC

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Progress Codes in BMC

[manoj kiran]

[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 4264 bytes --]

Re: Progress Codes in BMC

[Deepak Kodihalli]

Hi Manoj,

On Thu, Feb 4, 2021 at 2:17 PM manoj kiran <manojkiran.eda@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@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

Re: Progress Codes in BMC

[manoj kiran]

Hi Deepak,

On Feb 4 2021, at 3:04 pm, Deepak Kodihalli
<deepak.kodihalli.83@gmail.com> wrote:

> Hi Manoj,
> 
> On Thu, Feb 4, 2021 at 2:17 PM manoj kiran <manojkiran.eda@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.

Agree, as far as i understood there is no added benefit as such in using
the host-postd. We are just using it for hosting the dbus object.

But in IBM systems, its not just the host firmware but we also have
couple of applications in BMC that would want to send these progress
codes during the early boot sequence. In that case, would pldm be a
right place to host this interface ?

And also, post-code-manager logic can become complex if it had to watch
out for both the interfaces instead of a single interface right ?


Thanks,
Manoj

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

Re: Progress Codes in BMC

[Deepak Kodihalli]

Hi Manoj,

On Thu, Feb 4, 2021 at 3:53 PM manoj kiran <manojkiran.eda@gmail.com> wrote:
>
> Hi Deepak,
>
> On Feb 4 2021, at 3:04 pm, Deepak Kodihalli
> <deepak.kodihalli.83@gmail.com> wrote:
>
> > Hi Manoj,
> >
> > On Thu, Feb 4, 2021 at 2:17 PM manoj kiran <manojkiran.eda@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.
>
> Agree, as far as i understood there is no added benefit as such in using
> the host-postd. We are just using it for hosting the dbus object.
>
> But in IBM systems, its not just the host firmware but we also have
> couple of applications in BMC that would want to send these progress
> codes during the early boot sequence. In that case, would pldm be a
> right place to host this interface ?

I wasn't aware of this based on your previous email, but in this case
it makes sense to have a single owner of the progress code object,
which could be host-postd.

Thanks,
Deepak