archive mirror
 help / color / mirror / Atom feed
From: Andrew Geissler <>
To: Thang Nguyen <>
Subject: Re: Implement OEM mechanism to handle xyz.openbmc_project.Condition.HostFirmware interface
Date: Thu, 9 Sep 2021 10:42:46 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On Sep 8, 2021, at 8:54 PM, Thang Nguyen <> wrote:
> Hi,
> Let me explain more detail about our cases:
> - Our system uses a GPIO called FW_BOOT_OK to detect if the Host is currently ON or OFF. The Host firmware set this GPIO when the first core initialized.
> - We have no problem in Host State with power control. But the problem is in the case of BMC rebooted while the Host is ON.
> - Before the commit, phosphor-reset-host-check@.service  is used to check and update Host State in case of BMC rebooted. But after that commit, the service file was removed. This makes no target service to update the Host State and the host check is fail at
> We would like to ask for your idea on how should we implement for the Host check when BMC is rebooted?

Hi Thang. Yeah, the reason for moving the logic directly into phosphor-host-state
is we had a window where the host state would say off (default) even when the
host was actually on. The other service would run and update it to the correct
value but there was a window where external clients would see an incorrect
state. So since we don’t want to report an invalid state, I needed the logic 
within the app itself on startup.

I think you’re on the right path here. The design is to implement the
xyz.openbmc_project.Condition.HostFirmware object and support the read
of the CurrentFirmwareCondition property. Based on your GPIO state, you’d
respond accordingly to the read. That way the state-manager code will just
work as-is.

On where to put this code… So far we’ve put it in the area that is doing the logic,
like PLDM and IPMI. Since this is really just a GPIO read, I’m not sure the best
place. I’d be interested if anyone on the list has some thoughts. Could host it
outside of openbmc and just pull in via a recipe.

I’d entertain a subdirectory in phosphor-state-manager with this small
app (to host the interface you’ll want a c++ app) and service to run it.
We could just enable it via a meson/compile flag. It seems like it could
be fairly generic and something that other system owners could utilize.

Please take a look at
We’d want the GPIO utilized here to have a standard name so others
could potentially make use of this logic.


> Thanks,
> Thang Q. Nguyen
> On 08/09/2021 20:19, Thu Nguyen wrote:
>> Dear Geissonator,
>> After commit
>> when BMC boots up, phosphor-host-state directly checks  the host state thru interface xyz.openbmc_project.Condition.HostFirmware.
>> It does not check the existing of /run/openbmc/host@%d-on as before.
>> I plan to implement "oem mechanism" to handle the interface xyz.openbmc_project.Condition.HostFirmware.
>> Which will use the GPIO interface to update the host state. I researched the code handle this interface in phosphor-host-ipmi and pldm.
>> I wonder which repo should I upstream the code? Currently, we don't have any OEM repo in github to upstream the code.
>> Do you have any idea to handle interface in bash scripts?
>> Regards.
>> Thu Nguyen.

  reply	other threads:[~2021-09-09 15:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 13:19 Implement OEM mechanism to handle xyz.openbmc_project.Condition.HostFirmware interface Thu Nguyen
2021-09-09  1:54 ` Thang Nguyen
2021-09-09 15:42   ` Andrew Geissler [this message]
2021-09-10 11:34     ` Thu Nguyen
2021-09-10 21:57       ` Andrew Geissler
2021-09-11  3:07         ` Thu Nguyen
2021-09-14 21:16           ` Andrew Geissler

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).