Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / x86-power-control / 7c8d19cbcd2f444f112c4a78ac4ea7c64d000ee6
commit7c8d19cbcd2f444f112c4a78ac4ea7c64d000ee6[log] [tgz]
authorJason M. Bills <jason.m.bills@linux.intel.com>Thu Jan 21 12:46:21 2021 -0800
committerJason M. Bills <jason.m.bills@linux.intel.com>Fri Jan 29 15:37:09 2021 -0800
tree6483996f6bb36eef64b9b4ff37ebddab0d048332
parent047bcb569b9c8baaa6184350a1628ec6e4008252 [diff]
Don't check for warm reset on reset button press

When the reset button is pressed, it checks for warm reset by
waiting 500ms for other signals to indicate a power off.  If
power stays on, then the BMC returns to the 'on' state.

However, if the POST complete GPIO, which is also triggered by
the reset button, takes longer than 500ms to be detected, it will
trigger another check for warm reset.  In addition, it is treated
as a second warm reset and the reset reason from the reset button
gets overwritten.

This changes the reset button to not trigger a warm reset check.
This makes the warm reset check depend on the POST complete GPIO
already being asserted which leaves open a window where if the
reset button is pressed during boot before POST complete, then
the warm reset will not be handled.

Tested: Confirmed that when POST complete de-asserts after the
warm reset check from the reset button press that the reset
reason is correctly set to the reset button.

Change-Id: I837a8b245c25e2a974301f1a58c28c41d63c4be2
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
1 file changed
tree: 6483996f6bb36eef64b9b4ff37ebddab0d048332
  1. cmake/
  2. i2c/
  3. power-control-x86/
  4. .clang-format
  5. CMakeLists.txt
  6. LICENSE
  7. MAINTAINERS
  8. 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.

At this point in time, this daemon targets Lewisburg based, dual socket x86 server platforms, such as S2600WFT. It is likely that other platforms will work as well.

Because this relies on the hardware passthrough support in the AST2500 to function, it requires a few patches to work correctly.

This patch adds support to UBOOT to keep the passthrough enabled https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-common/ recipes-bsp/u-boot/files/0005-enable-passthrough-in-uboot.patch

The DTS file for your platform will need the following GPIO definitions RESET_BUTTON RESET_OUT POWER_BUTTON POWER_OUT

On an aspeed, these are generally connected to E0, E1, E2, and E3 respecitvely. An example of this is available in the s2600WF config.

This patch allows the passthrough to be reenabled to the default condition when the appropriate pin is released. This allows power control to take control when needed by a user power action, but leave the hardware in control a majority of the time, reducing the possibilty of bricking a system due to a failed BMC.

https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-ast2500/recipes-kernel/linux/linux-aspeed/0002-Enable-pass-through-on-GPIOE1-and-GPIOE3-free.patch https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-ast2500/recipes-kernel/linux/linux-aspeed/0003-Enable-GPIOE0-and-GPIOE2-pass-through-by-default.patch https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-ast2500/recipes-kernel/linux/linux-aspeed/0006-Allow-monitoring-of-power-control-input-GPIOs.patch

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.