| /openbmc/phosphor-power/phosphor-power-sequencer/docs/ |
| H A D | powering_on.md | 1 # Powering On
3 ## Initiating a power on
5 The system can be powered on by several methods, such as the `obmcutil` tool, a
6 Redfish command, or a power button on the system enclosure.
8 Whichever method is used, it sets the `state` property to 1 on the
9 `org.openbmc.control.Power` D-Bus interface. The D-Bus object path is
13 The `phosphor-power-sequencer` application only supports powering on the entire
14 system. In a multiple chassis system, `phosphor-power-sequencer` does not
15 support powering on individual chassis independent of the rest of the system.
17 ## Determining which chassis to power on
[all …]
|
| H A D | chassis_status.md | 5 There are multiple D-Bus interfaces and properties that describe the chassis
6 status. The `phosphor-power-sequencer` application publishes one of those
8 used as input by `phosphor-power-sequencer.`
12 The `state` and `pgood` properties exist on the `org.openbmc.control.Power`
13 D-Bus interface.
15 `state` has a value of 0 or 1. `state` represents the desired power state for
16 the chassis. 0 means off, and 1 means on. This property is set when the system
17 is being powered [on](powering_on.md) or [off](powering_off.md).
19 `pgood` has a value of 0 or 1. `pgood` represents the power good (pgood) state
20 of the chassis. 0 means off, and 1 means on. This is the actual, current power
[all …]
|
| H A D | pgood_faults.md | 1 # Power Good Faults
5 The power sequencer device provides a chassis power good (pgood) signal. This
6 indicates that all of the main (non-standby) voltage rails are powered on.
8 If the chassis pgood state is false when it should be true, a chassis power good
11 ## Pgood fault while powering on the system
13 When the power sequencer device is powering on the main voltage rails in order,
14 one of the rails may fail to power on. This is often due to a hardware problem.
16 When a voltage rail fails to power on, the power sequencer device may
18 for the rail to power on. In both cases the chassis pgood signal never changes
21 ## Pgood fault after the system was powered on
[all …]
|
| H A D | monitoring_chassis_pgood.md | 1 # Monitoring Chassis Power Good
5 The power sequencer device provides a chassis power good (pgood) signal. This
6 indicates that all of the main (non-standby) voltage rails are powered on.
8 The `phosphor-power-sequencer` application periodically reads (polls) the
13 chassis. See [Chassis Status](chassis_status.md) for more information on this
16 If the chassis pgood state is false when it should be true, a chassis power good
17 (pgood) fault has occurred. See [Power Good Faults](pgood_faults.md) for more
20 ## Unable to read chassis power good signal
22 `phosphor-power-sequencer` may become unable to read the chassis power good
25 - Hardware communication problems
[all …]
|
| H A D | README.md | 1 # phosphor-power-sequencer
5 The `phosphor-power-sequencer` application powers all the chassis in the system
6 on and off. It also monitors the power good (pgood) state in each chassis.
10 application. The support is also dependent on changes to the existing
11 `phosphor-chassis-state-manager` application and the planned new
12 `phosphor-chassis-power` application. This disclaimer will be removed when this
17 `phosphor-power-sequencer` is a single-threaded C++ executable. It is a daemon
19 the Ready state and before the system is powered on.
21 `phosphor-power-sequencer` is driven by an optional, system-specific JSON
24 chassis, power sequencer devices, voltage rails, GPIOs, and fault checks to
[all …]
|
| H A D | power_loss.md | 1 # Power Loss
5 Power distribution in a computer system is complex. It typically flows from a
6 wall outlet to power supplies to voltage regulators to system components. Other
7 devices may exist between the wall outlet and the power supplies, such as an
8 Uninterruptible Power Supply (UPS) or an Enclosure Power Distribution Unit
11 A **brownout** is a partial reduction in voltage to the power supplies. In some
12 situations, the standby voltage rails are still powered on but the main voltage
14 processor and other system components have lost power.
16 A **blackout** is a complete loss of power to the power supplies.
24 `phosphor-power-sequencer` application will take no action.
[all …]
|
| H A D | multiple_chassis.md | 5 A BMC-based system can contain one or more chassis. A chassis is typically a
6 physical enclosure that contains system components such as CPUs, fans, power
9 A chassis can be stand-alone, such as a tower or desktop. A chassis can also be
12 For the `phosphor-power-sequencer` application, the term "single chassis system"
19 ### System and chassis power state
21 In a single chassis system, the system and chassis power state are identical.
22 Both are either on or off.
24 In a multiple chassis system, each chassis has its own power state. Even if the
25 system is on, an individual chassis may be off. This can occur if that chassis
26 does not have input power or has a critical hardware problem.
[all …]
|
| H A D | powering_off.md | 3 ## Initiating a power off
6 Redfish command, or a power button on the system enclosure.
8 Whichever method is used, it sets the `state` property to 0 on the
9 `org.openbmc.control.Power` D-Bus interface. The D-Bus object path is
13 The `phosphor-power-sequencer` application only supports powering off the entire
14 system. In a multiple chassis system, `phosphor-power-sequencer` does not
17 ## Determining which chassis to power off
19 In a single chassis system, `phosphor-power-sequencer` will always attempt to
20 power off the chassis.
22 In a multiple chassis system, `phosphor-power-sequencer` will only attempt to
[all …]
|
| /openbmc/docs/designs/ |
| H A D | power-recovery.md | 1 # OpenBMC Server Power Recovery
11 Modern computer systems have a feature, automated power-on recovery, which in
13 power to the system. If the system had a black out (i.e. power was completely
14 cut to the system), should it automatically power the system on? Should it leave
16 at before the power loss.
18 There are also instances where the user may not want automatic power recovery to
19 occur. For example, some systems have op-panels, and on these op-panels there
22 situations, the user may wish for the system to not automatically power on the
26 run once the power is restored. For example, IBM requires all LED's be toggled
30 A brownout is another scenario that commonly utilizes automated power-on
[all …]
|
| /openbmc/openbmc-test-automation/redfish/extended/ |
| H A D | test_power_capping.robot | 2 Documentation Energy scale power capping tests.
6 # PL Power Limit
7 # OCC On Chip Controller
34 Escale System On And PL Enabled
35 [Documentation] Change active power limit with system power on and
36 ... Power limit active.
39 Set DCMI Power Limit And Verify ${max_power}
41 Redfish Power On stack_mode=skip
43 Tool Exist opal-prd
47 ${cmd}= Set Variable /tmp/occtoolp9 -p | grep -e State: -e Sensor:
[all …]
|
| /openbmc/u-boot/drivers/power/domain/ |
| H A D | Kconfig | 1 menu "Power Domain Support"
4 bool "Enable power domain support using Driver Model"
5 depends on DM && OF_CONTROL
7 Enable support for the power domain driver class. Many SoCs allow
8 power to be applied to or removed from portions of the SoC (power
9 domains). This may be used to save power. This API provides the
10 means to control such power management hardware.
13 bool "Enable the BCM6328 power domain driver"
14 depends on POWER_DOMAIN && ARCH_BMIPS
16 Enable support for manipulating BCM6345 power domains via MMIO
[all …]
|
| /openbmc/linux/drivers/powercap/ |
| D | Kconfig | |
| /openbmc/openbmc-test-automation/ipmi/ |
| H A D | test_ipmi_chassis.robot | 27 IPMI Chassis Status On
28 [Documentation] This test case verifies system power on status
32 Redfish Power On stack_mode=skip quiet=1
34 ${power_status}= Get Lines Containing String ${resp} System Power
35 Should Contain ${power_status} on
38 [Documentation] This test case verifies system power off status
42 Redfish Power Off stack_mode=skip quiet=1
44 ${power_status}= Get Lines Containing String ${resp} System Power
48 [Documentation] Verify host power off operation using external IPMI command.
51 IPMI Power Off
[all …]
|
| /openbmc/openbmc-test-automation/gui/gui_test/operations_menu/ |
| H A D | test_server_power_operations_sub_menu.robot | 3 Documentation Test OpenBMC GUI "Server power operations" sub-menu of "Operations".
10 Test Setup Navigate to Server Power Operation Page
16 ${xpath_server_power_heading} //h1[text()="Server power operations"]
17 ${xpath_enable_onetime_boot_checkbox} //*[contains(@class,'custom-checkbox')]
18 ${xpath_boot_option_select} //*[@id='boot-option']
19 ${xpath_shutdown_button} //*[@data-test-id='serverPowerOperations-button-shutDown…
20 ${xpath_reboot_button} //*[@data-test-id='serverPowerOperations-button-reboot']
21 ${xpath_poweron_button} //*[@data-test-id='serverPowerOperations-button-powerOn']
23 ${xpath_shutdown_orderly_radio} //*[@data-test-id='serverPowerOperations-radio-shutdownO…
24 ${xpath_shutdown_immediate_radio} //*[@data-test-id='serverPowerOperations-radio-shutdownI…
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/State/ |
| H A D | Chassis.interface.yaml | 1 description: Implement to provide the chassis power management
4 - name: RequestedPowerTransition
8 The desired power transition to start on this chassis. This will be
9 preserved across AC power cycles of the BMC.
11 - xyz.openbmc_project.State.Chassis.Error.BMCNotReady
12 - xyz.openbmc_project.Common.Error.Unavailable
14 - name: CurrentPowerState
17 A read-only property describing the current chassis power state. A
21 - name: CurrentPowerStatus
24 A read-only property describing the current chassis power status. This
[all …]
|
| /openbmc/openbmc/meta-facebook/meta-yosemite4/recipes-phosphor/state/phosphor-state-manager/ |
| H A D | chassis-poweron | 6 # shellcheck source=meta-facebook/meta-yosemite4/recipes-phosphor/state/phosphor-state-manager/powe…
7 source /usr/libexec/phosphor-state-manager/power-cmd
8 # shellcheck source=meta-facebook/meta-yosemite4/recipes-yosemite4/plat-tool/files/yosemite4-common…
9 source /usr/libexec/yosemite4-common-functions
11 #IO 0:7 input port for showing slot 1:8 power status
12 #IO 8:16 output port for controlling slot 1:8 power status
15 IO_EXP_SLOT_PWR_STATUS=$((CHASSIS_ID - 1))
19 GPIOCHIP_IO_EXP_SLOT_PWR_CTRL=$(basename "/sys/bus/i2c/devices/$SPIDER_BOARD_IO_EXP_BUS_NUM-00$IO_E…
20 …TATUS_CTRL=$(basename "/sys/bus/i2c/devices/$MANAGEMENT_BOARD_IO_EXP_BUS_NUM-00$IO_EXP_SLED_PWR_CT…
24 # Server 12v power on
[all …]
|
| H A D | host-poweron | 4 # shellcheck source=meta-facebook/meta-yosemite4/recipes-phosphor/state/phosphor-state-manager/powe…
5 source /usr/libexec/phosphor-state-manager/power-cmd
8 CHASSIS_BUS=$(($1 - 1))
10 GPIOCHIP_IO_EXP_HOST_POWER_STATUS=$(basename "/sys/bus/i2c/devices/$CHASSIS_BUS-0023/"*gpiochip*)
21 msg="Execute host$1 DC power on"
26 if ! flock -n 300 ; then
27 msg="Wait power control flock release for host$CHASSIS_ID DC on"
31 flock -x 300
32 trap 'flock -u 300' EXIT
38 echo "Already host$1 DC power on."
[all …]
|
| H A D | host-powercycle | 6 # shellcheck source=meta-facebook/meta-yosemite4/recipes-phosphor/state/phosphor-state-manager/powe…
7 source /usr/libexec/phosphor-state-manager/power-cmd
10 CHASSIS_BUS=$((CHASSIS_ID - 1))
12 GPIOCHIP_IO_EXP_HOST_POWER_STATUS=$(basename "/sys/bus/i2c/devices/$CHASSIS_BUS-0023/"*gpiochip*)
25 msg="Execute host$CHASSIS_ID DC power cycle"
30 if ! flock -n 300 ; then
31 msg="Wait power control flock release for host$CHASSIS_ID DC cycle"
35 flock -x 300
36 trap 'flock -u 300' EXIT
41 # Current power is ON, cycle do OFF to ON. If current power is OFF then do ON
[all …]
|
| /openbmc/linux/arch/arm64/boot/dts/apple/ |
| D | t600x-pmgr.dtsi | |
| D | t8112-pmgr.dtsi | |
| /openbmc/openbmc-test-automation/openpower/ |
| H A D | test_timed_power_on.robot | 2 Documentation This suite tests Timed Power On(TPO) feature via busctl command
3 ... and verify the power status of the system.
5 ... System can be scheduled to Power ON at a specified time by using this feature.
22 ${CMD_ENABLE_TPO} busctl set-property xyz.openbmc_project.State.ScheduledHostTransition
24 ... ScheduledTransition s "xyz.openbmc_project.State.Host.Transition.On"
26 ${CMD_SET_TPO_TIME} busctl set-property xyz.openbmc_project.State.ScheduledHostTransition
29 ${CMD_GET_TPO_TIME} busctl get-property xyz.openbmc_project.State.ScheduledHostTransition
36 # - Red Hat Enterprise Linux
37 # - SUSE Linux Enterprise Server
38 # Tested on RHEL 8.4.
[all …]
|
| /openbmc/openbmc-test-automation/gui/test/server_control/ |
| H A D | test_obmc_gui_server_power_operations.robot | 3 Documentation Test OpenBMC GUI "Server power operation" sub-menu of
13 ${xpath_power_indicator_bar} //*[@id='power-indicator-bar']
16 ${xpath_power_on_button} //button[contains(text(), "Power on")]
17 ${xpath_tpm_toggle_switch} //label[@for="toggle__switch-round"]
18 ${xpath_select_boot_override} //select[@id="boot-selected"]
19 ${xpath_select_one_time_boot} //label[@id="one-time-label"]
23 Verify System State At Power Off
24 [Documentation] Verify system state at power off.
31 Verify BMC IP In Server Power Operation Page
32 [Documentation] Verify BMC IP in server power operation page.
[all …]
|
| /openbmc/docs/architecture/ |
| H A D | openbmc-systemd.md | 5 which processes are started. There is a lot of documentation on systemd and to
9 [Unit](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#) -
11 [Service](https://www.freedesktop.org/software/systemd/man/systemd.service.html) -
13 [Target](https://www.freedesktop.org/software/systemd/man/systemd.target.html) -
19 On an OpenBMC system, you can go to /lib/systemd/system/ and see all of the
20 systemd units on the system. You can easily cat these files to start looking at
27 ---
29 ## Initial Power
31 When an OpenBMC system first has power applied, it starts the "default.target"
32 unless an alternate target is specified on the kernel command line. In Phosphor
[all …]
|
| /openbmc/linux/Documentation/driver-api/thermal/ |
| D | power_allocator.rst | |
| /openbmc/openbmc-test-automation/xcat/ |
| H A D | test_power_operation.robot | 15 Verify Power On Via XCAT
16 [Documentation] Power on system via XCAT and verify using REST.
19 Execute Command On XCAT rpower on
22 Verify Power Off Via XCAT
23 [Documentation] Power off system via XCAT and verify using REST.
26 Execute Command On XCAT rpower off
33 ${xcat_resp}= Execute Command On XCAT rpower bmcstate
37 Verify Soft Power Off Followed With Power On
38 [Documentation] Verify soft power off system followed with power on.
42 Execute Command On XCAT rpower softoff
[all …]
|