| /openbmc/openbmc-test-automation/docs/ |
| H A D | boot_test.md | 3 The boot plugins are used in the test and as well can be use a stand-alone
9 robot -v OPENBMC_HOST:xx.xx.xx.xx -v OPENBMC_PASSWORD:xxx -v 'boot_stack:<boot1>:<boot2>:<bootn>:' …
13 [data/boot_lists/All](https://github.com/openbmc/openbmc-test-automation/blob/master/data/boot_list…
18 robot -v OPENBMC_HOST:xx.xx.xx.xx -v OPENBMC_PASSWORD:xxx -v 'boot_stack:Redfish Power On:Redfish …
21 and it will give the following on the console the boot test report:
25 ---------------------------------------- ----- ---- ----
26 Redfish Power On 1 1 0
27 Redfish Power On (mfg) 0 0 0
28 IPMI Power On 0 0 0
29 IPMI Power On (mfg) 0 0 0
[all …]
|
| /openbmc/openbmc/meta-phosphor/recipes-phosphor/state/ |
| H A D | phosphor-state-manager_git.bb | 3 management daemons. It is suitable for use on a wide variety of OpenBMC \
5 HOMEPAGE = "https://github.com/openbmc/phosphor-state-manager"
8 LICENSE = "Apache-2.0"
11 include phosphor-state-manager-systemd-links.inc
14 ${PN}-host \
15 ${PN}-chassi
[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
20 can be a pin hole reset. This is a manual mechanism for the user to force a hard
21 reset to the BMC in situations where it is hung or not responding. In these
22 situations, the user may wish for the system to not automatically power on the
[all …]
|
| H A D | multihost-phosphor-buttons.md | 1 # Multi-host front panel phosphor buttons interface
12 Phosphor buttons module has currently option to monitor gpio events of power and
13 reset buttons and trigger power event handlers.
15 phosphor-buttons currently only support push type buttons.support for different
20 Currently handler events are only based on monitoring gpio events as input
21 (power and reset).There may be cases where we need to create button interface
23 based on dbus property changes.
29 available in the front panel apart from existing power and reset button
34 The front panel of bmc has buttons like power button, reset button in general
38 +----------------------------------------------+
[all …]
|
| H A D | device-tree-gpio-naming.md | 12 subsystem. The replacement is a "descriptor-based" character device interface.
25 specific field used to name the GPIOs in the DTS is `gpio-line-names`. This
29 scheme in the face of a universe of potential use-cases.
37 - Ensure common function GPIOs within OpenBMC use the same naming convention
43 (when available on an OpenBMC system). This naming convention must be followed
52 Pattern: `*-button`
55 BMC-less machines use a button to trigger system behavior and in a BMC-managed
59 #### power-button
64 depends on the index of Host and the active state is high or low.
68 - `host*-ready`: Host ready, active high
[all …]
|
| H A D | state-management-and-external-interfaces.md | 16 Please note that the focus of this document is on the following `ResetType`
17 instance: `redfish/v1/Systems/system/Actions/ComputerSystem.Reset`
23 [phoshor-state-manager][2] implements the xyz.openbmc_project.State.\*
28 the appropriate xyz.openbmc_project.State.\* D-Bus interface.
32 looking to support the capability to reboot an operating system on a system
33 without cycling power to the chassis.
35 Currently phosphor-state-manager supports the following:
37 - Chassis: On/Off
38 - Host: On/Off/Reboot
40 The `Reboot` to the host currently causes a power cycle to the chassis.
[all …]
|
| H A D | bmc-reset-with-host-up.md | 1 # BMC Reset with Host Booted
18 A good portion of this is explained in the phosphor-state-manager [README][1].
20 This design doc is written to formalize the design and add some more details on
25 it then checks the host to see if it is up and alive. If the power is on and the
28 - /run/openbmc/chassis@0-on
29 - /run/openbmc/host@0-on
31 It should be noted that although full support is not in place for multi-chassis
32 and multi-host systems, the framework is there to build on.
33 `op-reset-chassis-running@.service` is a templated service, checking pgood in
34 its instances power domain. It creates a file in the filesystem,
[all …]
|
| /openbmc/openbmc-test-automation/data/ |
| H A D | boot_table_x86.json | 2 "Redfish Power On": {
10 "chassis": "^On$",
18 "method": "Redfish Power Operation On",
21 "IPMI Power On": {
29 "chassis": "^On$",
37 "method": "Run External IPMI Standard Command power on -N 10 -R 1",
41 "Redfish Power Off": {
44 "chassis": "^On$"
56 "method": "Redfish Power Operation GracefulShutdown",
59 "Redfish Hard Power Off": {
[all …]
|
| H A D | boot_table_redfish.json | 2 "Redfish Power On": {
11 "chassis": "^On$",
20 "method": "Redfish Power Operation On",
23 "IPMI Power On": {
32 "chassis": "^On$",
41 "method": "Run External IPMI Standard Command power on -N 10 -R 1",
44 "Istep Power On": {
53 "chassis": "^On$",
64 "Redfish Power Off": {
67 "chassis": "^On$"
[all …]
|
| H A D | boot_table_osrunning_redfish.json | 2 "Redfish Power On": {
11 "chassis": "^On$",
20 "method": "Redfish Power Operation On",
23 "IPMI Power On": {
32 "chassis": "^On$",
41 "method": "Run External IPMI Standard Command power on -N 10 -R 1",
44 "Istep Power On": {
53 "chassis": "^On$",
64 "Redfish Power Off": {
67 "chassis": "^On$"
[all …]
|
| H A D | boot_table.json | 2 "REST Power On": {
12 "chassis": "^On$",
25 "Redfish Power On": {
35 "chassis": "^On$",
45 "method": "Redfish Power Operation On",
48 "IPMI Power On": {
58 "chassis": "^On$",
68 "method": "Run External IPMI Standard Command power on -N 10 -R 1",
72 "REST Power Off": {
75 "chassis": "^On$"
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Control/Power/ |
| H A D | RestorePolicy.interface.yaml | 2 Implement to specify power transition behavior on a BMC reset. The
3 implementation may choose to only enforce the policy on a power loss or on
4 both a power loss and BMC reboot.
7 - name: PowerRestorePolicy
11 The policy to adopt after the BMC reset.
12 - name: PowerRestoreDelay
16 The delay in microseconds before invoke power restore policy after
17 power applied. 0 - disable delay.
20 - name: Policy
22 Possible power restoration policies.
[all …]
|
| /openbmc/openpower-host-ipmi-oem/ |
| H A D | README.md | 1 # openpower-host-ipmi-oem
5 <https://github.com/open-power/op-build>
13 ninja -C build
16 To clean the repository again run `rm -rf build`.
20 - Partial Add
21 - Prepare for host update
22 - BMC Factory Reset
26 ### BMC Factory Reset
30 This command will call to reset the BMC to its factory default. See the
31 [`FactoryReset`][0] interface for the factory reset implementation details.
[all …]
|
| /openbmc/phosphor-state-manager/service_files/ |
| H A D | phosphor-reset-chassis-running@.service | 3 Wants=mapper-wait@-org-openbmc-control-power%i.service
4 After=mapper-wait@-org-openbmc-control-power%i.service
5 Wants=obmc-power-reset-on@%i.target
6 Before=obmc-power-reset-on@%i.target
7 Conflicts=obmc-chassis-poweroff@%i.target
12 …-c "if [ $(busctl get-property `mapper get-service /org/openbmc/control/power%i` /org/openbmc/cont…
13 SyslogIdentifier=phosphor-reset-chassis-running
16 WantedBy=obmc-chassis-powerreset@%i.target
|
| H A D | phosphor-reset-chassis-on@.service | 2 Description=Start chassis%i on after BMC reset
3 Requires=phosphor-reset-chassis-running@%i.service
4 After=phosphor-reset-chassis-running@%i.service
5 After=obmc-power-reset-on@%i.target
6 Requires=obmc-power-reset-on@%i.target
7 ConditionPathExists=/run/openbmc/chassis@%i-on
11 ExecStart=/bin/systemctl start obmc-chassis-poweron@%i.target
12 SyslogIdentifier=phosphor-reset-chassis-on
15 WantedBy=obmc-chassis-powerreset@%i.target
|
| H A D | meson.build | 2 'phosphor-systemd-target-monitor.service',
3 'phosphor-discover-system-state@.service',
4 'obmc-power-start@.service',
5 'obmc-power-stop@.service',
6 'obmc-powered-off@.service',
7 'phosphor-reboot-host@.service',
8 'phosphor-reset-chassis-on@.service',
9 'phosphor-reset-chassis-running@.service',
10 'phosphor-reset-host-reboot-attempts@.service',
11 'phosphor-reset-host-recovery@.service',
[all …]
|
| /openbmc/openbmc-test-automation/pldm/ |
| H A D | test_firmware_boot_side.robot | 6 # 1. Power off the host or post firmware is updated.
9 # pldmtool bios GetBIOSAttributeCurrentValueByHandle -a fw_boot_side
14 # pldmtool bios SetBIOSAttributeCurrentValue -a fw_boot_side -d Temp
16 # 4. Power on
17 # 5. BMC take reset during power on ( expected )
27 Test Teardown FFDC On Test Case Fail
36 # This dictionary is for Temp -> Perm or vice versa in the test code.
42 [Documentation] Power off the host , set the firmware boot side via pldmtool,
43 ... power on the host and confirm the fw_boot_side attribute is
46 [Template] Firmware Side Switch Power On Loop
[all …]
|
| /openbmc/openbmc/meta-facebook/meta-harma/recipes-phosphor/state/phosphor-state-manager/ |
| H A D | power-cmd | 3 # shellcheck source=meta-facebook/recipes-fb/obmc_functions/files/fb-common-functions
4 source /usr/libexec/fb-common-functions
5 renice -10 $$
8 sgpio_vaild0=$(get_gpio "power-card-enable")
9 sgpio_vaild1=$(get_gpio "power-12v-memory-good")
10 sgpio_vaild2=$(get_gpio "power-pvdd33-s5")
19 # Power Good Status
24 if [ "$(get_gpio "host0-ready")" -eq 1 ] && [ "$valid_sgpio" -eq 0 ] ; then
25 echo "on"
33 if [ "$(power_status)" == "on" ]; then
[all …]
|
| /openbmc/x86-power-control/ |
| H A D | README.md | 1 # X86 power control
3 This repository contains an OpenBMC compliant implementation of power control
4 for x86 servers. It relies on a number of features to do its job. It has several
9 2. The implementation should either give the requested power control result, or
10 should log an error on the failure it detected.
11 3. The BMC should support all the common operations, hard power on/off/cycle,
12 soft power on/off/cycle.
14 This daemon has been successfully used on a variety of server platforms; it
15 should be able to support platforms with power control GPIOs similar to those in
18 x86-power-control uses default json file (power-config-host0.json) for GPIO
[all …]
|
| /openbmc/openbmc/meta-ampere/meta-common/recipes-ampere/host/ |
| H A D | ampere-hostctrl.bb | 4 LICENSE = "Apache-2.0"
5 LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Apache-2.0;md5=89aea4e17d99a7cacdbeed46a0096b10"
8 inherit obmc-phosphor-systemd
15 file://ampere-host-force-reset@.service \
16 file://ampere-host-on-host-check@.service \
18 file://obmc-power-already-on@.target \
19 file://obmc-host-already-on@.target \
20 file://ampere-bmc-reboot-host-check@.service \
25 ampere-host-force-reset@.service \
26 obmc-power-already-on@.target \
[all …]
|
| /openbmc/u-boot/arch/arm/mach-keystone/ |
| H A D | psc.c | 1 // SPDX-License-Identifier: GPL-2.0+
5 * (C) Copyright 2012-2014
16 * psc_delay() - delay for psc
27 * psc_wait() - Wait for end of transitional state
34 * Return: 0 when the domain is free. Returns -1 if a timeout occurred waiting
43 * Do nothing if the power domain is in transition. This should never in psc_wait()
59 return -1; in psc_wait()
65 * psc_get_domain_num() - Get the domain number
72 /* Get the power domain associated with the module number */ in psc_get_domain_num()
80 * psc_set_state() - powers up/down a module
[all …]
|
| /openbmc/docs/ |
| H A D | IPMITOOL-cheatsheet.md | 1 # IPMITOOL-cheatsheet.md
6 ## Power section in IPMITOOL-cheatsheet.md
11 ipmitool -C 17 -H "$BMC_IP" -I lanplus -U "$BMC_USER" -P "$BMC_PASSWD" power status
14 ### 2. Server power on
17 ipmitool -C 17 -H "$BMC_IP" -I lanplus -U "$BMC_USER" -P "$BMC_PASSWD" power on
20 ### 3. Server power off
23 ipmitool -C 17 -H "$BMC_IP" -I lanplus -U "$BMC_USER" -P "$BMC_PASSWD" power off
26 ### 4. Server power reset
29 ipmitool -C 17 -H "$BMC_IP" -I lanplus -U "$BMC_USER" -P "$BMC_PASSWD" power reset
32 ### 5. Server power cycle
[all …]
|
| /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 …]
|
| H A D | test_ipmi_watchdog.robot | 60 Test IPMI Watchdog Timer Pre-Timeout Interrupt Bits
61 [Documentation] Execute out of band set/get pre-timeout interrupt bits for watchdog timer.
62 [Tags] Test_IPMI_Watchdog_Timer_Pre-Timeout_Interrupt_Bits
109 # set action command power state SEL event
110 ${IPMI_RAW_CMD['Watchdog']['Set'][60]} ['off'] Power down
111 ${IPMI_RAW_CMD['Watchdog']['Set'][63]} ['on'] Hard reset
112 ${IPMI_RAW_CMD['Watchdog']['Set'][66]} ['on'] Power cycle
113 ${IPMI_RAW_CMD['Watchdog']['Set'][69]} ['on'] Timer expired
116 Verify Reset Timer
117 [Documentation] Set Watchdog via IPMI raw command and verify Reset Timer functions as expected.
[all …]
|
| /openbmc/openbmc-test-automation/redfish/extended/ |
| H A D | test_fan_operation.robot | 25 Check Number Of Fans With Power On
37 Check Number Of Fan Monitors With Power On
38 [Documentation] Verify monitors are present when power on.
41 Verify Fan Monitors With State On
81 # A non-functional fan should cause an error log and
92 Redfish Power On stack_mode=skip
99 Reset Fans And Error Logs
100 [Documentation] Reset Fans, Error Logs, and LEDs
102 Reset Fans ${fan_names}
111 [Documentation] Do the pre-suite setup.
[all …]
|