Progress Codes in BMC

chunhui.jia chunhui.jia at linux.intel.com
Mon Jan 25 13:24:25 AEDT 2021


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 at stwcx.xyz>
发送时间:2021-01-22 22:52
主题:Re: Progress Codes in BMC
收件人:"Supreeth Venkatesh"<supreeth.venkatesh at amd.com>
抄送:"openbmc"<openbmc at 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 at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210125/6af7870d/attachment.htm>


More information about the openbmc mailing list