Progress Codes in BMC
Patrick Williams
patrick at stwcx.xyz
Sat Jan 23 01:52:14 AEDT 2021
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210122/a0b5512a/attachment.sig>
More information about the openbmc
mailing list