Progress Codes in BMC

[Ed Tanous]

On Mon, Feb 1, 2021 at 4:21 PM Brad Bishop <bradleyb at 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