Progress Codes in BMC

[manoj kiran]

Hi Deepak,

On Feb 4 2021, at 3:04 pm, Deepak Kodihalli
<deepak.kodihalli.83 at gmail.com> wrote:

> Hi Manoj,
> 
> On Thu, Feb 4, 2021 at 2:17 PM manoj kiran <manojkiran.eda at gmail.com> wrote:
>> 
>> Hi All,
>> 
>> Thanks to everyone for all the implementation ideas on this thread.
>> 
>> After understanding all the inputs from the community , we were
>> planning to proceed forward with using the existing infrastructure
>> provided by phosphor-host-postd, phosphor-post-code-manager repo's &
>> leverage the BIOS POSTCode Log service to do the job.
>> 
>> The plan is to start with minimal working pieces. On the first go we
>> are planning to come up with patchsets that will do the following:
>> 
>> 1.Come up with a compilation flag & make sure phosphor-host-postd
>> still hosts the dbus interface even if it does not see the snoop port.
> 
> Is there a benefit of using phosphor-host-postd as opposed to pldmd
> implementing the Boot.Raw interface (i.e if you take out the snoop
> part, does it do anything else than just hosting a D-Bus object)?
> Post-code-manager should still work as-is. If you use host-postd for
> this and if pldmd makes a D-Bus call to write Boot.Raw as a client,
> that seems like one additional D-Bus call to get a code out via
> Redfish.

Agree, as far as i understood there is no added benefit as such in using
the host-postd. We are just using it for hosting the dbus object.

But in IBM systems, its not just the host firmware but we also have
couple of applications in BMC that would want to send these progress
codes during the early boot sequence. In that case, would pldm be a
right place to host this interface ?

And also, post-code-manager logic can become complex if it had to watch
out for both the interfaces instead of a single interface right ?


Thanks,
Manoj

> 
> Thanks,
> Deepak
> 
>> 2.PLDM will receive the 72bytes of progress code from the hypervisor
>> via File I/O, and then just send the first 8 bytes(discard everything
>> else) to the existing Raw Property & use the existing redfish BIOS
>> Post Code log service to check if things are working.
>> 
>> In the next iteration :
>> 1. We will try to modify the existing dbus property (Boot.Raw) to
>> array[byte] & the piece of code that uses this property in other
>> repos including the post-code-manager.
>> 2. There might be a need to Modify/Add new interfaces used by
>> post-code-manager to parse the buffer & host the dbus objects to such
>> an extent that an AdditionalDataURI can be given to clients(base64
>> encoded buffer) apart from filling the existing redfish message registry.
>> 
>> Does the community foresee any issues/problems if we stick to the
>> above-mentioned plan?
>> 
>> Thanks,
>> Manoj
>> 
>> On Feb 2 2021, at 8:15 am, Patrick Williams <patrick at stwcx.xyz> wrote:
>> 
>> On Mon, Feb 01, 2021 at 07:21:39PM -0500, Brad Bishop 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?
>> 
>> I think it is even simpler than that. You just need to make a dbus
>> client call to write to the Boot.Raw value. This might happen from your
>> boot sequence on the BMC-side or from PLDM for the Host-side.
>> 
>> You will want the phosphor-post-code-manager application running,
>> which will
>> listen to the PropertyChanged signals from Boot.Raw and keep the running
>> history for you.
>> 
>> There is also phosphor-host-postd. Currently it has an implementation
>> that looks at LPC to get the post codes. There was a proposed
>> implementation [1] that added multi-host support and I think support to
>> get the value directly from dbus client writes to Boot.Raw instead of
>> the lpc-snoop method. Then there is code in fb-ipmi-oem that writes the
>> results of some IPMB messages into the Boot.Raw value[2]. Looking at
>> this I'm not positive that all the pieces are all there, but I think it
>> is mostly there. Maybe check with the author on 1 to see where it is
>> at.
>> 
>> This design doc might be useful too [3].
>> 
>> 1. https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-postd/+/36509
>> 2. https://github.com/openbmc/fb-ipmi-oem/blob/master/src/biccommands.cpp#L76
>> 3. https://github.com/openbmc/docs/blob/master/designs/multi-host-postcode.md
>> 
>> --
>> Patrick Williams
>