Progress Codes in BMC

[Deepak Kodihalli]

Hi Manoj,

On Thu, Feb 4, 2021 at 3:53 PM manoj kiran <manojkiran.eda at gmail.com> wrote:
>
> 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 ?

I wasn't aware of this based on your previous email, but in this case
it makes sense to have a single owner of the progress code object,
which could be host-postd.

Thanks,
Deepak