Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / x86-power-control / cfc4d25edfdc12f02ea082fc4bb9ebe8f9c40dfb
commitcfc4d25edfdc12f02ea082fc4bb9ebe8f9c40dfb[log] [tgz]
authorKonstantin Aladyshev <aladyshev22@gmail.com>Thu Nov 18 11:08:38 2021 +0300
committerJayanth Othayoth <ojayanth@gmail.com>Mon Mar 04 15:34:54 2024 +0000
treef78895f3373aba10869b39099102469fdd2e08d1
parent88dd68b5c6132db521be11b1bd45e87312675e66 [diff]
Add HpmStbyEn signal

HpmStbyEn signal is a special signal that can be found on AMD boards.
It indicates that all DC-SCM STBY power rails are enabled and good.
The signal enables STBY power rails on the HPM.
It is a level GPIO, and if it is not activated, onboard CPLD wouldn't
relinquish control of power control GPIOs to BMC making it impossible
to power on the host.
Therefore if this GPIO is present in the JSON configuration activate it
in the main function.

Tested on the AMD EthanolX/Onyx CRB
   Onyx verification: power on/off, application restart at power on/off
                      and bmc reboot.

Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Signed-off-by: Jayanth Othayoth <ojayanth@gmail.com>
Change-Id: I3a21c2e5214dfcf05cdae8efc2ebbb21c4b4e080
1 file changed
tree: f78895f3373aba10869b39099102469fdd2e08d1
  1. config/
  2. service_files/
  3. src/
  4. subprojects/
  5. .clang-format
  6. .gitignore
  7. LICENSE
  8. meson.build
  9. meson.options
  10. OWNERS
  11. README.md
README.md

X86 power control

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.

  1. The BMC should maintain the Host state machine internally, and be able to track state changes.
  2. The implementation should either give the requested power control result, or should log an error on the failure it detected.
  3. The BMC should support all the common operations, hard power on/off/cycle, soft power on/off/cycle.

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.

Signal Definitions

Definitions can be configured by two type: GPIO and DBUS

GPIO

For the platform having direct GPIO access can use the type GPIO and define like below.

{
  "Name": "PostComplete",
  "LineName": "POST_COMPLETE",
  "Type": "GPIO"
}

DBUS

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.

Build Options

chassis-system-reset

Enable chassis system power reset to allow removing power and restoring back.

use-plt-rst

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.