Update README file
Remove outdated information about passthrough: x86-power-control do
nothing with this and works fine without any passthrough-related
patches.
Update compile options.
Cleanup document formatting.
Signed-off-by: Andrei Kartashev <a.kartashev@yadro.com>
Change-Id: I370ce124770719365b14146aeb3bfcf998a8ec3a
diff --git a/README.md b/README.md
index 9f5bef1..b5df2fb 100644
--- a/README.md
+++ b/README.md
@@ -10,36 +10,20 @@
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.
+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.
-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
-POST_COMPLETE
-PS_PWROK
-SIO_ONCONTROL
-SIO_POWER_GOOD
-SIO_S5
-
-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.
+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:
1. GPIO
- For the platform having direct GPIO access can use the type GPIO and define like below.
+For the platform having direct GPIO access can use the type GPIO and define
+like below.
{
"Name" : "PostComplete",
@@ -49,7 +33,8 @@
2. DBUS
- For the platform not having direct GPIO access can use dbus based event monitor by using the type DBUS.
+For the platform not having direct GPIO access can use dbus based event monitor
+by using the type DBUS.
{
"Name" : "PowerButton",
@@ -60,21 +45,8 @@
"Type" : "DBUS"
},
- x86-power-control will monitor the property change from the given DbusName and take appropriate action.
- *define Property as a bool variable.
-
-On an aspeed, these are generally connected to E0, E1, E2, and E3 respectively.
-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 possibility 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
-
+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
@@ -83,11 +55,18 @@
## Build Options
-#### 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.
+#### 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.
\ No newline at end of file
+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.