Exposing POST codes
Brad Bishop
bradleyb at fuzziesquirrel.com
Mon Mar 5 16:19:12 AEDT 2018
Hi Patrick
Thanks for bringing this up again.
> On Feb 28, 2018, at 1:56 PM, Patrick Venture <venture at google.com> wrote:
>
> I talked to Nancy and I think it's time to revisit previous conversations
> about POST codes. We have a simple daemon that exposes the information
> over Dbus associated with https://gerrit.openbmc-project.xyz/#/c/5006
So we already have this xyz.openbmc_project.State.Boot.Progress DBus
interface (and others). This is what we implemented on POWER. Can
we talk about how that API falls short for your use case(s)? Can I fix
it to enable your use case(s)?
My concern is I have to at some point implement this API on POWER
so that POWER can take advantage of applications targeting your new API.
If doing that would be non-sensical then this probably shouldn’t be an
API, or at least not in the common xyz namespace.
On POWER, this kind of information comes down through the IPMI boot
progress indicator. Could someone briefly educate me on what the
difference between the IPMI boot progress indicator and POST codes
are on x86? Is there overlap or are they used for different things?
If we went this route I’d be inclined to scrap the existing
xyz.openbmc_project.State.Boot.Progress API and implement
your proposed API on POWER, again, so that POWER can make use of the
applications targeting this API, if the community is unable to write
applications targeting the existing one. That would mean changing
code that today takes actions on meaningful enumerations to instead
take actions on platform specific numbers. Does that seem like
the right thing for me to do? Or does it make sense for the project to
have both of these APIs? If that is the case can you speculate on what
situations an application would target one API over the other?
It just seems like the first thing anyone is going to do with these
numbers is look them up and map them to something. Wouldn’t it make
sense to have done that mapping already at the API level so that
every user and piece of code using this API doesn’t have to do it
themselves?
Mohit - do ARM chips have POST code-like functionality? Can you
conceive of a way to write an application that could implement
the proposed API on an ARM server?
>
> If there's interest, I can stage it against skeleton for review and comment.
I think what I’m hinting at here is that you could add a per-platform config
file to your app that maps the codes to some enumerations in the DBus
interface, and apply that mapping before you emit the signal. If you
wanted to go back to numbers later you could just reverse the mapping
using the same config file. Please poke holes.
-brad
>
> We have a patch to the kernel character device for the aspeed-lpc-snoop
> that is required and enables reading the post codes.
>
> Patrick
More information about the openbmc
mailing list