Progress Codes in BMC

[Patrick Williams]

On Wed, Jan 27, 2021 at 08:05:26PM -0500, Brad Bishop wrote:
> On Fri, Jan 22, 2021 at 08:52:14AM -0600, Patrick Williams 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.  The hosting daemon doesn't really
care where it came from.  We have this in the fb-ipmi-oem to handle IPMB
messages that come from our per-cpu-card uC.

> >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.
> 
> 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>?

> 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.

The `xyz.opnbmc_project.State.Boot.PostCode` interface contains the
history of the `Boot.Raw` values.  I think you could generate some kind
of "log" from that.

-- 
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/20210130/43bb7c7f/attachment.sig>