| commit | 33eb55003f19ec95a95bfdf2473a1457535c1ee1 | [log] [tgz] |
|---|---|---|
| author | Colin Huang <colin.huang2@amd.com> | Thu Nov 13 01:56:03 2025 +0800 |
| committer | Liora Guo <liora.guo.wiwynn@gmail.com> | Thu Dec 18 03:35:38 2025 +0000 |
| tree | db492fd221607bd98a7f0198a55d340917938705 | |
| parent | fbd3bd5d584e83f9f5febf5a457c39d76882ed2b [diff] |
fix reset button not working
meson: fix reset-button-do-warm-reboot not work
button_handler: fix hostNumStr is empty when reset button pressed.
tested: A reset button press works to reset the system.
A power button press work to power system without process restart.
Test Log:
Confirmed multi-instance power button DBus object paths use PowerN
format, and the multi-action mapping correctly triggers chassis1
power-cycle for the tested press duration.
1) Verify DBus object paths are normalized (no zero-padding)
```
root@bmc:~# busctl tree xyz.openbmc_project.Chassis.Buttons
└─ /xyz
└─ /xyz/openbmc_project
└─ /xyz/openbmc_project/Chassis
└─ /xyz/openbmc_project/Chassis/Buttons
├─ /xyz/openbmc_project/Chassis/Buttons/HostSelector
├─ /xyz/openbmc_project/Chassis/Buttons/Power1
├─ /xyz/openbmc_project/Chassis/Buttons/Power2
├─ /xyz/openbmc_project/Chassis/Buttons/Power3
├─ /xyz/openbmc_project/Chassis/Buttons/Power4
├─ /xyz/openbmc_project/Chassis/Buttons/Power5
├─ /xyz/openbmc_project/Chassis/Buttons/Power6
├─ /xyz/openbmc_project/Chassis/Buttons/Power7
└─ /xyz/openbmc_project/Chassis/Buttons/Power8
```
2) POWER_BUTTON multi-action policy configuration (reference)
```
root@bmc:~# cat /etc/default/obmc/gpio/gpio_defs.json
{
"gpio_definitions": [
{
"name": "POWER_BUTTON1",
"pin": "Q0",
"direction": "both",
"multi-action": [
{
"duration": 0,
"action": "chassis-on"
},
{
"duration": 4000,
"action": "chassis-cycle"
},
{
"duration": 8000,
"action": "chassis-off"
}
]
},
...
```
3) Trigger a synthetic Released signal and confirm the expected
chassis transition
```
root@bmc:~# date && busctl emit \
> /xyz/openbmc_project/Chassis/Buttons/Power01 \
> xyz.openbmc_project.Chassis.Buttons.Power \
> Released \
> t 5089675
Wed Dec 17 18:56:22 PST 2025
```
Observed in journalctl:
```
Dec 17 18:56:22 bmc phosphor-chassis-state-manager[709]:
Change to Chassis1 Requested Power State:
xyz.openbmc_project.State.Chassis.Transition.PowerCycle
Dec 17 18:56:22 bmc systemd[1]: Starting Chassis Power Cycle: 1...
Dec 17 18:56:22 bmc chassis-powercycle[4739]:
Execute chassis1 AC power cycle
Dec 17 18:56:22 bmc chassis-powercycle[4752]:
o "/xyz/openbmc_project/logging/entry/10762"
Dec 17 18:56:22 bmc chassis-powercycle[4739]:
Starting chassis1 AC power cycle
Dec 17 18:56:22 bmc chassis-powercycle[4739]:
Do 12V cycle disable i3c hub
Dec 17 18:56:22 bmc chassis-powercycle[4739]: Slot1 on i3c hub 0.
Dec 17 18:56:22 bmc chassis-powercycle[4739]: Unlock i3c hub register.
Dec 17 18:56:22 bmc chassis-powercycle[4739]: Disable slot1 i3c port.
Dec 17 18:56:22 bmc chassis-powercycle[4762]: 0xE
Dec 17 18:56:22 bmc chassis-powercycle[4739]: Lock i3c hub register.
...
```
Change-Id: Ifea143860e4173d10c2386fa13509a0f935a1b21
Signed-off-by: Colin Huang <colin.huang2@amd.com>
Signed-off-by: Liora Guo <liora.guo.wiwynn@gmail.com>
Phosphor-buttons has a collection of IO event handler interfaces for physical inputs which are typically part of some sort of panel.
It defines an individual dbus interface object for each physical button/switch inputs such as power button, reset button etc. Each button interface monitors its associated IO for event changes and emits signals that the button-handler application listens for.
All events occur when the button is released.
If the power is off, power on the host.
If the power is on, it depends on how long the press was and which options are enabled:
The 'power-button-profile' meson option can be used to select custom power button profiles that have different behaviors.
Available profiles are:
See this section below.
When released:
When released, toggles the 'enclosure_identify' LED group provided by the phosphor-led-manager repository. The group name can be changed using the 'id-led-group' meson option.
In order to monitor a button/input interface the respective gpio config details should be mentioned in the gpio defs json file - /etc/default/obmc/gpio/gpio_defs.json
A gpio can be mapped using the "pin" or "num" keyword. The "pin" key uses alphanumerical references while the "num" key supports the integer pin number.
{ "gpio_definitions": [ { "name": "POWER_BUTTON", "pin": "D0", "direction": "both" }, { "name": "RESET_BUTTON", "pin": "AB0", "direction": "both" }, { "name": "HOST_SELECTOR", "group_gpio_config": [ { "pin": "AA4", "direction": "both" }, { "pin": "AA5", "direction": "both" }, { "pin": "AA6", "direction": "both" }, { "pin": "AA7", "direction": "both" } ] } ] }
This config is original config which can be used for configs with only single gpio such as power button,reset button, OCP debug card host select button.
{ "name": "POWER_BUTTON", "pin": "D0", "direction": "both" }
Note: this config is used by most of the other platforms so this format is kept as it is so that existing gpio configs do not get affected.
The following configs are related to multi-host bmc systems more info explained in the design: https://github.com/openbmc/docs/blob/master/designs/multihost-phosphor-buttons.md
The host selector has four gpios associated. So the related gpios are mentioned in a json array named group_gpio_config.
Optional: Polling Configuration Some platforms expose the host selector via a CPLD as GPIO inputs without edge-triggered interrupt support (e.g., no edge detection on GPIOs). In such situations, software-based polling mode can be enabled using the following optional fields in the JSON configuration:
true to enable polling mode.1000 ms if not specified.Optional: Virtual Button Configuration Some platforms implement HostSelector objects without actual power button control functionality. To prevent interference with multi-power button mode detection:
true when not used as power button, e.g., OCP debug card. Defaults to false if not specified.Example : The value of "7" derived from the 4 host select gpio lines are mapped to host position 1.
{ "name": "HOST_SELECTOR", "group_gpio_config": [ { "name": "host_select_0", "pin": "AA4", "direction": "both", "polarity": "active_high" }, { "name": "host_select_1", "pin": "AA5", "direction": "both", "polarity": "active_high" }, { "name": "host_select_2", "pin": "AA6", "direction": "both", "polarity": "active_high" }, { "name": "host_select_3", "pin": "AA7", "direction": "both", "polarity": "active_high" } ], "max_position": 4, "host_selector_map": { "6": 0, "7": 1, "8": 2, "9": 3, "10": 4, "11": 0, "12": 1, "13": 2, "14": 3, "15": 4 } }
{ "name": "HOST_SELECTOR", "polling_mode": true, "polling_interval_ms": 3000, "group_gpio_config": [ { "name": "host_select_sel_0", "num": 2340, "direction": "in", "polarity": "active_low" }, { "name": "host_select_sel_1", "num": 2341, "direction": "in", "polarity": "active_low" }, { "name": "host_select_sel_2", "num": 2342, "direction": "in", "polarity": "active_low" }, { "name": "host_select_sel_3", "num": 2343, "direction": "in", "polarity": "active_low" } ], "max_position": 8, "host_selector_map": { "0": 0, "1": 1, "2": 2, "3": 3, "4": 4, "5": 5, "6": 6, "7": 7, "8": 8 } }
There are also some systems that get the host selector selection from the CPLD, the configuration is provided below.
{ "cpld_definitions": [ { "name": "HOST_SELECTOR", "i2c_bus": 12, "i2c_address": 15, "register_name": "uart-selection-debug-card", "max_position": 4 } ] }
Similar to host selector there are multiple gpios associated with the serial uart mux. These gpio configs are specified as part of json array "group_gpio_config".
Here the serial uart mux output is accessed via OCP debug card. SO the OCP debug card present gpio is mentioned part of the group_gpio_config. The debug card present gpio is identified by its name "debug_card_present".
The other gpios part of the group gpio config is serial uart MUX gpio select lines and serial_uart_rx line.
{ "name": "SERIAL_UART_MUX", "group_gpio_config": [ { "name": "serial_uart_sel_0", "pin": "E0", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_1", "pin": "E1", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_2", "pin": "E2", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_3", "pin": "E3", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_rx", "pin": "E4", "direction": "out", "polarity": "active_high" }, { "name": "debug_card_present", "pin": "R3", "direction": "both", "polarity": "active_high" } ], "serial_uart_mux_map": { "0": 4, "1": 0, "2": 1, "3": 2, "4": 3 } }
This config is used for configs with multiple power buttons on each slots and whole sled, or for which needs multi-level chassis power control behavior.
name - this is name of the specific gpio line, "POWER_BUTTON" + the index of chassis instance
{ "gpio_definitions": [ { "name": "POWER_BUTTON0", "pin": "I6", "direction": "both", "multi-action": [ { "duration": 4000, "action": "chassis cycle" } ] }, { "name": "POWER_BUTTON1", "pin": "V0", "direction": "both", "multi-action": [ { "duration": 0, "action": "chassis on" }, { "duration": 4000, "action": "chassis cycle" }, { "duration": 8000, "action": "chassis off" } ] } ] }