1# X86 power control 2 3This repository contains an OpenBMC compliant implementation of power control 4for x86 servers. It relies on a number of features to do its job. It has 5several intentional design goals. 61. The BMC should maintain the Host state machine internally, and be able to 7 track state changes. 82. The implementation should either give the requested power control result, or 9 should log an error on the failure it detected. 103. The BMC should support all the common operations, hard power on/off/cycle, 11 soft power on/off/cycle. 12 13At this point in time, this daemon targets Lewisburg based, dual socket x86 14server platforms, such as S2600WFT. It is likely that other platforms will work 15as well. 16 17Because this relies on the hardware passthrough support in the AST2500 to 18function, it requires a few patches to work correctly. 19 20This patch adds support to UBOOT to keep the passthrough enabled 21https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-common/ 22recipes-bsp/u-boot/files/0005-enable-passthrough-in-uboot.patch 23 24The DTS file for your platform will need the following GPIO definitions 25RESET_BUTTON 26RESET_OUT 27POWER_BUTTON 28POWER_OUT 29POST_COMPLETE 30PS_PWROK 31SIO_ONCONTROL 32SIO_POWER_GOOD 33SIO_S5 34 35x86-power-control uses default json file (power-config-host0.json) for GPIO configuration. 36However this can be customized by producing your own power-config-host0.json file. 37 38Definitions can be configured by two type: 39 401. GPIO 41 42 For the platform having direct GPIO access can use the type GPIO and define like below. 43 44 { 45 "Name" : "PostComplete", 46 "LineName" : "POST_COMPLETE", 47 "Type" : "GPIO" 48 }, 49 502. DBUS 51 52 For the platform not having direct GPIO access can use dbus based event monitor by using the type DBUS. 53 54 { 55 "Name" : "PowerButton", 56 "DbusName" : "xyz.openbmc_project.Chassis.Event", 57 "Path" : "/xyz/openbmc_project/Chassis/Event", 58 "Interface" : "xyz.openbmc_project.Chassis.Event", 59 "Property" : "PowerButton_Host1", 60 "Type" : "DBUS" 61 }, 62 63 x86-power-control will monitor the property change from the given DbusName and take appropriate action. 64 *define Property as a bool variable. 65 66On an aspeed, these are generally connected to E0, E1, E2, and E3 respectively. 67An example of this is available in the s2600WF config. 68 69This patch allows the passthrough to be reenabled to the default condition when 70the appropriate pin is released. This allows power control to take control 71when needed by a user power action, but leave the hardware in control a majority 72of the time, reducing the possibility of bricking a system due to a failed BMC. 73 74https://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 75https://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 76https://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 77 78 79Caveats: 80This implementation does not currently implement the common targets that other 81implementations do. There were several attempts to, but all ended in timing 82issues and boot inconsistencies during stress operations. 83 84## Build Options 85 86#### USE_PLT_RST 87The POST Complete GPIO is usually held asserted by BIOS after POST complete 88and de-asserts on reset. This de-assert behavior is currently used to detect 89warm resets. 90 91Some systems are adding support for a PLT_RST eSPI signal that can be used to 92more accurately detect warm resets. When this option is enabled, x86-power-control 93will use PLT_RST to detect warm resets instead of POST Complete.