| commit | 99e8f9dfe6ed99e201f5920c512587fe3af3cdb9 | [log] [tgz] |
|---|---|---|
| author | Andrei Kartashev <a.kartashev@yadro.com> | Sun Jan 09 12:15:05 2022 +0300 |
| committer | Andrei Kartashev <a.kartashev@yadro.com> | Tue Apr 05 17:09:20 2022 +0000 |
| tree | ffde63ee287bcd6537d6b1332cd3568c13965c0e | |
| parent | 809545a62114b8e88750e4ff2ebc153a8bf1e3db [diff] |
refactor power restore controller
Currently PowerRestorePolicy handling code uses two undocumented
interfaces:
* `xyz.openbmc_project.Control.Power.RestoreDelay`
* `xyz.openbmc_project.Common.ACBoot`
Power Restore Delay seems to be logical part of
`xyz.openbmc_project.Control.Power.RestorePolicy` interface and has
been moved there.
ACBoot depends on some custom logic that can be found only in Intel-BMC
fork.
This commit reorganize PowerRestorePolicy-related code to be more clear
and flexible, fixes interface for RestoreDelay. Use of ACBoot feature is
now optional and can be compile-time enabled.
Tested: Model power loss event with Off, On and Restore policy, verify,
that power restored as expected.
Test On policy with Delay set to 300000000 - ensure, power on
delayed by 5 minutes.
Test with ACBoot interface emulated.
Signed-off-by: Andrei Kartashev <a.kartashev@yadro.com>
Change-Id: Id8b42d2085f44418e02a7f52836cc1a6f55f50db
This repository contains an OpenBMC compliant implementation of power control for x86 servers. It relies on a number of features to do its job. It has several intentional design goals.
This daemon has been successfully used on a variety of server platforms; it should be able to support platforms with power control GPIOs similar to those in its config file.
x86-power-control uses default json file (power-config-host0.json) for GPIO configuration. However this can be customized by producing your own power-config-host0.json file.
Definitions can be configured by two type:
For the platform having direct GPIO access can use the type GPIO and define like below.
{
"Name" : "PostComplete",
"LineName" : "POST_COMPLETE",
"Type" : "GPIO"
},
For the platform not having direct GPIO access can use dbus based event monitor by using the type DBUS.
{
"Name" : "PowerButton",
"DbusName" : "xyz.openbmc_project.Chassis.Event",
"Path" : "/xyz/openbmc_project/Chassis/Event",
"Interface" : "xyz.openbmc_project.Chassis.Event",
"Property" : "PowerButton_Host1",
"Type" : "DBUS"
},
x86-power-control will monitor the property change from the given DbusName and take appropriate action. *define Property as a bool variable.
Caveats: This implementation does not currently implement the common targets that other implementations do. There were several attempts to, but all ended in timing issues and boot inconsistencies during stress operations.
Enable chassis system power reset to allow removing power and restoring back.
The POST Complete GPIO is usually held asserted by BIOS after POST complete and de-asserts on reset. This de-assert behavior is currently used to detect warm resets.
Some systems are adding support for a PLT_RST eSPI signal that can be used to more accurately detect warm resets. When this option is enabled, x86-power-control will use PLT_RST to detect warm resets instead of POST Complete.
See https://github.com/Intel-BMC/host-misc-comm-manager for implementation example.