Re: RE: Re: Progress Codes in BMC

["chunhui.jia" <chunhui.jia@linux.intel.com>]

[-- 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 --]