beep code manager for openbmc

beep code manager for openbmc

[Ren, Zhikui]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Hi All,

Beepcode manager is a stand-alone beep code service should be created to manage the beeper hardware, and provide D-Bus methods to expose the beeper function globally, all other services can use the beeper hardware by calling the beep methods.

This package has been included in our distribution. Now we would like  to upstream it and make it available to the community.
https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc-mods/meta-common/recipes-phosphor/beepcode-mgr

Since it is now a very light service that only have one source file and a service file. I am wondering whether this service can go to an existing repository.
If not, we would like to request a new repository for it.

Thanks,
Zhikui


[-- Attachment #2: Type: text/html, Size: 4124 bytes --]

Re: beep code manager for openbmc

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

Hi Zhikui,

A few questions...

On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote:
> Hi All,
> 
> Beepcode manager is a stand-alone beep code service should be created to manage the beeper hardware, and provide D-Bus methods to expose the beeper function globally, all other services can use the beeper hardware by calling the beep methods.
> 
> This package has been included in our distribution. Now we would like  to upstream it and make it available to the community.
> https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc-mods/meta-common/recipes-phosphor/beepcode-mgr
> 
> Since it is now a very light service that only have one source file and a service file. I am wondering whether this service can go to an existing repository.
> If not, we would like to request a new repository for it.
> 
> Thanks,
> Zhikui
> 

I see it creates dbus interfaces but I don't see them defined anywhere.  Can we
get that added to phosphor-dbus-interfaces?

It isn't obvious to me from looking at what interfaces are there who would call
it.  I see various "beep code" patterns:

    {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"},
    {beepCPUMIssing, "1-5-2-1"},        {beepCPUCatError, "1-5-2-2"},
    {beepCPUErr2, "1-5-2-3"},           {beepVoltageMismatch, "1-5-2-4"},
    {beepCPUConfigError, "1-5-2-5"},    {beepPowerFail, "1-5-4-2"},
    {beepPowerGoodTimeOut, "1-5-4-4"},

How do these get triggered?  Do arbitrary programs call into the "BeepCode"
service when they hit their own event?  This doesn't seem very maintainable;
shouldn't the beepcode service react to events through some other method,
similar to what is going on for Redfish events?

How easily configurable would this be for someone who has a different beepcode
policy than Intel's?  Are you planning to update it with some JSON config or
leave that as an exercise for the next user?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: beep code manager for openbmc

[Ren, Zhikui]

>-----Original Message-----
>From: Patrick Williams <patrick@stwcx.xyz>
>Sent: Thursday, September 2, 2021 2:59 PM
>To: Ren, Zhikui <zhikui.ren@intel.com>
>Cc: openbmc@lists.ozlabs.org; Brad Bishop <bradleyb@fuzziesquirrel.com>
>Subject: Re: beep code manager for openbmc
>
>Hi Zhikui,
>
>A few questions...
>
>On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote:
>> Hi All,
>>
>> Beepcode manager is a stand-alone beep code service should be created to
>manage the beeper hardware, and provide D-Bus methods to expose the
>beeper function globally, all other services can use the beeper hardware by
>calling the beep methods.
>>
>> This package has been included in our distribution. Now we would like  to
>upstream it and make it available to the community.
>> https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc-
>mods/meta
>> -common/recipes-phosphor/beepcode-mgr
>>
>> Since it is now a very light service that only have one source file and a service
>file. I am wondering whether this service can go to an existing repository.
>> If not, we would like to request a new repository for it.
>>
>> Thanks,
>> Zhikui
>>
>
>I see it creates dbus interfaces but I don't see them defined anywhere.  Can
>we get that added to phosphor-dbus-interfaces?
>
[Ren, Zhikui] Yes, I will submit a review on that.
>It isn't obvious to me from looking at what interfaces are there who would call
>it.  I see various "beep code" patterns:
>
>    {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"},
>    {beepCPUMIssing, "1-5-2-1"},        {beepCPUCatError, "1-5-2-2"},
>    {beepCPUErr2, "1-5-2-3"},           {beepVoltageMismatch, "1-5-2-4"},
>    {beepCPUConfigError, "1-5-2-5"},    {beepPowerFail, "1-5-4-2"},
>    {beepPowerGoodTimeOut, "1-5-4-4"},
>
>How do these get triggered?  Do arbitrary programs call into the "BeepCode"
>service when they hit their own event?  This doesn't seem very maintainable;
>shouldn't the beepcode service react to events through some other method,
>similar to what is going on for Redfish events?
>
[Ren, Zhikui] Currently, an application can call into the BeepCode by calling the dbus method
One of improvement ideas is to make the beepcode service monitor the events it is interested in.

>How easily configurable would this be for someone who has a different
>beepcode policy than Intel's?  Are you planning to update it with some JSON
>config or leave that as an exercise for the next user?
>
[Ren, Zhikui] Good idea.  However I don't have a definitive plan on that currently and open to suggestions/collaborations.

>--
>Patrick Williams
[Ren, Zhikui] To summarize, I think the following steps can be taken:
1. Find an existing home or create a new one for Beep code manager
2. Upstream existing code as initial check in
3. create phosphor-dbus-interfaces for it 
4. update to use phosphor-dbus-interface
5. further improvements including the two discussed above

Any comments/feedback? 

Thanks,
Zhikui

RE: beep code manager for openbmc

[Milton Miller II]

Ren, Zhikuui wrote:
>Patrick Williams wrote:>>On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote:
>>> Hi All,
>>>
>>> Beepcode manager is a stand-alone beep code service should be
>created to
>>manage the beeper hardware, and provide D-Bus methods to expose the
>>beeper function globally, all other services can use the beeper
>hardware by
>>calling the beep methods.
>>>
>>> This package has been included in our distribution. Now we would
>like  to
>>upstream it and make it available to the community.
>>>
>>>
>>> Since it is now a very light service that only have one source
>file and a service
>>file. I am wondering whether this service can go to an existing
>repository.
>>> If not, we would like to request a new repository for it.
>>>

My thought is perhaps with our progress code logging and 7-segment 
post code display in phosphor-host-postd ?

I could see several of the events mentioned be triggered by writing 
a post code, and there are already a few separate programs in that 
repository, one to record codes and one to display on some 7-segment 
led hardware.  The phosphor-post-code-manager which records the 
history is in its own repository (before the desire to combine them).

I'm certianally open to other suggestions just thought I'd plant a 
seed for discussion.

>>> Thanks,>>> Zhikui
>>>

[various other discussions on interfaces , making the beep codes 
configurable , etc]

>[Ren, Zhikui] To summarize, I think the following steps can be taken:>1. Find an existing home or create a new one for Beep code manager
>2. Upstream existing code as initial check in
>3. create phosphor-dbus-interfaces for it 
>4. update to use phosphor-dbus-interface
>5. further improvements including the two discussed above
>
>Any comments/feedback? 
>
>Thanks,
>Zhikui

milton

Re: beep code manager for openbmc

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

On Wed, Sep 08, 2021 at 03:29:48PM +0000, Ren, Zhikui wrote:
> >I see it creates dbus interfaces but I don't see them defined anywhere.  Can
> >we get that added to phosphor-dbus-interfaces?
> >
> [Ren, Zhikui] Yes, I will submit a review on that.
> >It isn't obvious to me from looking at what interfaces are there who would call
> >it.  I see various "beep code" patterns:
> >
> >    {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"},
> >    {beepCPUMIssing, "1-5-2-1"},        {beepCPUCatError, "1-5-2-2"},
> >    {beepCPUErr2, "1-5-2-3"},           {beepVoltageMismatch, "1-5-2-4"},
> >    {beepCPUConfigError, "1-5-2-5"},    {beepPowerFail, "1-5-4-2"},
> >    {beepPowerGoodTimeOut, "1-5-4-4"},
> >
> >How do these get triggered?  Do arbitrary programs call into the "BeepCode"
> >service when they hit their own event?  This doesn't seem very maintainable;
> >shouldn't the beepcode service react to events through some other method,
> >similar to what is going on for Redfish events?
> >
> [Ren, Zhikui] Currently, an application can call into the BeepCode by calling the dbus method
> One of improvement ideas is to make the beepcode service monitor the events it is interested in.

Fundamentally, I see this as a very poor design.  I don't really like us taking
code written in isolation without any design feedback and then expecting the
project to pick it up as-is.

We already have REDFISH_MESSAGE_ID and IPMI_SEL_* journal strings, a proposal
for audit, and now this beepcode proposal, which are all a type of event.  The
current design proposals for all of them is that every application needs to be
aware of every consumer and make N random function calls to each of those
consumers.  It is sloppy and doesn't scale.  I don't want to add to the mess by
adding beepcodes this way.

I'm slowly working on unraveling this by adding an Event concept to
phosphor-logging (distinct from the current Error concepts).  I'm hopeful that
this can be leveraged for any such event, including boot sequence states that
can be consumed by this beepcode application.  I should have the initial design
within a week or two and would certainly welcome any review (with respect to
beep code) and assistance in implementation.

> >How easily configurable would this be for someone who has a different
> >beepcode policy than Intel's?  Are you planning to update it with some JSON
> >config or leave that as an exercise for the next user?
> >
> [Ren, Zhikui] Good idea.  However I don't have a definitive plan on that currently and open to suggestions/collaborations.

Another reason why we shouldn't just take wholesale code that was written and
designed in isolation but isn't really fit for anyone else's purposes.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: beep code manager for openbmc

[Ren, Zhikui]

>-----Original Message-----
>From: Patrick Williams <patrick@stwcx.xyz>
>Sent: Tuesday, September 14, 2021 2:18 PM
>To: Ren, Zhikui <zhikui.ren@intel.com>
>Cc: openbmc@lists.ozlabs.org; Brad Bishop <bradleyb@fuzziesquirrel.com>
>Subject: Re: beep code manager for openbmc
>
>On Wed, Sep 08, 2021 at 03:29:48PM +0000, Ren, Zhikui wrote:
>> >I see it creates dbus interfaces but I don't see them defined
>> >anywhere.  Can we get that added to phosphor-dbus-interfaces?
>> >
>> [Ren, Zhikui] Yes, I will submit a review on that.
>> >It isn't obvious to me from looking at what interfaces are there who
>> >would call it.  I see various "beep code" patterns:
>> >
>> >    {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"},
>> >    {beepCPUMIssing, "1-5-2-1"},        {beepCPUCatError, "1-5-2-2"},
>> >    {beepCPUErr2, "1-5-2-3"},           {beepVoltageMismatch, "1-5-2-4"},
>> >    {beepCPUConfigError, "1-5-2-5"},    {beepPowerFail, "1-5-4-2"},
>> >    {beepPowerGoodTimeOut, "1-5-4-4"},
>> >
>> >How do these get triggered?  Do arbitrary programs call into the
>"BeepCode"
>> >service when they hit their own event?  This doesn't seem very
>> >maintainable; shouldn't the beepcode service react to events through
>> >some other method, similar to what is going on for Redfish events?
>> >
>> [Ren, Zhikui] Currently, an application can call into the BeepCode by
>> calling the dbus method One of improvement ideas is to make the
>beepcode service monitor the events it is interested in.
>
>Fundamentally, I see this as a very poor design.  I don't really like us taking
>code written in isolation without any design feedback and then expecting the
>project to pick it up as-is.
>
>We already have REDFISH_MESSAGE_ID and IPMI_SEL_* journal strings, a
>proposal for audit, and now this beepcode proposal, which are all a type of
>event.  The current design proposals for all of them is that every application
>needs to be aware of every consumer and make N random function calls to
>each of those consumers.  It is sloppy and doesn't scale.  I don't want to add to
>the mess by adding beepcodes this way.
>
>I'm slowly working on unraveling this by adding an Event concept to phosphor-
>logging (distinct from the current Error concepts).  I'm hopeful that this can be
>leveraged for any such event, including boot sequence states that can be
>consumed by this beepcode application.  I should have the initial design within
>a week or two and would certainly welcome any review (with respect to beep
>code) and assistance in implementation.
>
[Ren, Zhikui] Looking forward to see the review.

>> >How easily configurable would this be for someone who has a different
>> >beepcode policy than Intel's?  Are you planning to update it with
>> >some JSON config or leave that as an exercise for the next user?
>> >
>> [Ren, Zhikui] Good idea.  However I don't have a definitive plan on that
>currently and open to suggestions/collaborations.
>
>Another reason why we shouldn't just take wholesale code that was written
>and designed in isolation but isn't really fit for anyone else's purposes.
>
[Ren, Zhikui] Getting feedbacks from the community was the intention of this email chain.
We have some ideas how to improve the current design and make it more flexible.
I will start working on a design review next. 
>--
>Patrick Williams