From: Patrick Williams <patrick@stwcx.xyz>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@amd.com>,
openbmc@lists.ozlabs.org
Subject: Re: Progress Codes in BMC
Date: Sat, 30 Jan 2021 08:31:26 -0600 [thread overview]
Message-ID: <YBVtvlsJJJ4faFpt@heinlein> (raw)
In-Reply-To: <20210128010526.wice3o5qznh4lglw@thinkpad.fuzziesquirrel.com>
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-01-30 14:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-22 11:53 Progress Codes in BMC manoj kiran
2021-01-22 12:32 ` Deepak Kodihalli
2021-01-22 14:18 ` Supreeth Venkatesh
2021-01-22 14:52 ` Patrick Williams
2021-01-25 2:24 ` chunhui.jia
2021-01-25 5:29 ` Venkatesh, Supreeth
2021-01-26 4:05 ` chunhui.jia
2021-01-28 1:05 ` Brad Bishop
2021-01-30 14:31 ` Patrick Williams [this message]
2021-02-02 0:21 ` Brad Bishop
2021-02-02 0:49 ` Ed Tanous
2021-02-02 1:08 ` Brad Bishop
2021-02-02 1:44 ` Ed Tanous
2021-02-02 2:45 ` Patrick Williams
2021-02-04 8:47 ` manoj kiran
2021-02-04 9:34 ` Deepak Kodihalli
2021-02-04 10:22 ` manoj kiran
2021-02-04 12:17 ` Deepak Kodihalli
2021-01-28 18:03 ` Benjamin Fair
2021-01-28 18:17 ` Supreeth Venkatesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YBVtvlsJJJ4faFpt@heinlein \
--to=patrick@stwcx.xyz \
--cc=bradleyb@fuzziesquirrel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=supreeth.venkatesh@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.