文档中心
Power-on and Power-off Configuration Guide
更新时间： 2025/11/21
在Gitcode上查看源码

Power-on and Power-off Configuration Guide ​

Primary Modules Involved in Power-on and Power-off Configuration: fructl and vpd ​

The fructl code can be found at fructl.

Introduction ​

As the out-of-band management system for servers, the BMC can control operations such as power-on, power-off, and restart for the OS. This document describes how to configure the power-on and power-off functions.

Overall Design and Implementation ​

The fructl module is responsible for logic processing and requires data configured within the vpd module to complete the final operations. Typically, only the vpd module needs to be configured to adapt the power-on and power-off functions. For ease of understanding and learning, both modules are described.

Introduction to Startup Using the fructrl_obj_mgnt Module ​

The entry function for fructrl is cpayload:init() in src\lualib\payload_app.lua.

In fructrl_obj_mgnt:object_manage_callback(), the add_objects_callback function is called to complete the loading of the primary objects.

Internal module management uses a hierarchical design: chassis > multihost > system (host).

Chassis-level FRU control (ChassisFruCtrl) manages power operations for the entire chassis, which affect all host systems. Currently, devices are not configured with a chassis-level system and are single-host systems. Each host system has its own FRU control (FruCtrl) object to manage power operations for that host system.

Using the normal startup flow of the 920X model as an example, objects in ObjectGroup/00 (four objects) need to be loaded. The corresponding configurations are in vpd\vendor\Huawei\Server\Kunpeng\S920X20\platform\platform.sr.

text
FruCtrlCapabilities_00: FRU control capability object
SystemLockDown_1_00: system lockdown object
Multihost_00: multihost object (actually a single host)
FruCtrl_1_0_00: FRU control object for host 1

Add objects from ObjectGroup/0101 (six objects). The corresponding configuration is in vendor\Huawei\TianChi\EXU\14100513_00000001010302044492.sr.

text
DftPowerButton_1_0101: equipment power button
PowerAction_1_0101: power action object
PGSignal_1_0101: power good signal
ButtonEvt_1_0101: button event
ACCycle_1_0101: AC cycle control
PowerButton_1_0101: power button

Add objects from ObjectGroup/010101 (five objects). The corresponding configuration is in vendor\openUBMC\14060876_00000001020302031825_soft.sr.

text
Nmi_1_010101: NMI control
SysReset_1_010101: system reset
ThermTrip_1_010101: thermal protection
RecordFault_1_010101: fault recording
ForceReset_1_010101: forced reset

Essential fructl Module Configurations ​

fructrl_obj is the primary object. Once created, it matches in add_object_callback to complete the creation of the following five objects. Under normal circumstances, these five configurations are mandatory and must not be defined repeatedly. The original code is as follows:

text
['FruCtrl'] = 'NA',
['PGSignal'] = 'NA',
['PowerButton'] = 'NA',
['ThermTrip'] = 'NA',
['RecordFault'] = 'NA',

Once these objects are matched, their corresponding values are set to Added instead of NA. The add_fruobj_complete_callback function checks if all objects are retrieved. If any are missing, power-on and power-off operations cannot be implemented, and the following log is printed:

text
objs_bef_init distribute failed.

Command-driven Power-on Process ​

First, the system receives and processes power control commands, which can come from IPMI, the web, or other sources.

Starting from onehost_system_power_ctrl, the system calls cpower_api:system_reset to start a separate task. This task executes set_CurrentRestartType and, using a table-driven approach in powerctrl_api, calls the execute_poweron function associated with powerctrl_api[power on].

The execute_poweron function sends a power-on event to the control state machine. In ctrl_state, the system evaluates its current state and the desired next state to perform the subsequent operation. If the current state is NoAction, it enters the Oning state and executes fructrl:poweron().

Finally, it calls power_button:push_button_short() to interact with the hardware and perform the power-on operation. This involves power_button and its Accessor information configured in the vpd component, as well as Scanner information used by pg_signal. The vpd must be configured correctly; otherwise, the system will fail to power on.

Button-driven Power-on Process ​

When the power button is pressed, GetPowerBtnEvt defined in ButtonEvt_1 is triggered, calling dealwith_pwr_button_evt. The log records power button event change to [1], and sys_reset_flag is set to true. This flag is also set to true when the BMC actively issues a command leading to a system reset.

After the power-on state changes, dealwith_power_gd_status is triggered, printing PowerGDStatus changed to power on. Subsequently, the power-on state enters transitions such as M1 to M4. Throughout this process, the fructl module is only responsible for recording and modifying certain states and does not perform other actions.

vpd Module Configuration Examples ​

As the preceding description, the FruCtrl object is central to the power-on and power-off functions and requires specific attributes configured in the vpd module. Scanner and Accessor objects must be modified based on actual conditions. The following objects are all required:

json
"FruCtrl_1_0": {
    "CurrentRestartCauseId": 0
},

PGSignal object, representing the power signal:

json
"PGSignal_1": {
    "PowerGDState": "<=/Scanner_PowerGood.Value",
    "@Default": {
        "PowerGDState": 255
    }
},

PowerButton object, distinguishing between a long press and a short press:

json
"PowerButton_1": {
    "ShortPushButton": "#/Accessor_ShortPushButton.Value",
    "LongPushButton": "#/Accessor_LongPushButton.Value"
},

Implementing system restarts and persistence actions before and after restarts:

json
"ACCycle_1": {
    "AC": "#/Accessor_AC.Value"
},

Power button sensing and the function to mask power button operations:

json
"ButtonEvt_1": {
    "PowerBtnLock": "#/Accessor_PowerBtnLock.Value",
    "GetPowerBtnEvt": "<=/Scanner_PowerBtnEvt.Value",
    "SetPowerBtnEvt": "#/Accessor_PowerBtnEvt.Value",
    "PowerBtnShield": "#/Accessor_PowerBtnShield.Value"
},

Power-on timeout flag and power-on lock:

json
"PowerAction_1": {
    "PowerOnTimeoutFlag": "#/Accessor_PowerOnLock.Value"
},

ForceReset object. When this object is distributed normally, the forced reset command is supported:

json
"ForceReset_1": {
    "FruID": 0,
    "ForceRst": "#/Accessor_ForceRst.Value",
    "IsValid": true
},

SysReset object. This reset signal object is required when OS restart events are reported:

json
"SysReset_1": {
    "GetSysRstDetected": "<=/Scanner_SysRstDetected.Value",
    "SetSysRstDetected": "#/Accessor_SysRstDetected.Value"
},

Clearing alarm latch signals, historical fault records, and current fault status:

json
"RecordFault_1": {
    "IssueRecoredAcc": "#/Accessor_IssueRecoredAcc.Value",
    "LatchRecoredAcc": "#/Accessor_LatchRecoredAcc.Value"
},

NMI interrupt (pre-interrupt):

json
"Nmi_1": {
    "NmiInt": "#/Accessor_NmiInt.Value"
},

High-temperature power-off detection:

json
"ThermTrip_1": {
    "GetThermTrip": "<=/Scanner_Cpu1ThermalTripAccessor.Value",
    "SetThermTrip": "#/Accessor_Cpu1ClearThermalTripAccessor.Value"
},

Common Issues ​

  1. A module fails to be loaded. This is usually because FruCtrl, PGSignal, PowerButton, ThermTrip, or RecordFault are not configured correctly. They might be missing or repeatedly configured.

  2. A power-on command is issued, but power-on fails. Search the logs for Notify cpld to send short button signal through hwproxy Accessor.. This entry indicates that a short-press interrupt has been sent to the hardware. If the system still fails to power on, contact the hardware engineers to locate the fault. Run the ipmcget -t main -d poweronlock command to check for a power-on timeout event. If the output is locked, a power-on timeout event has occurred.

  3. A power-off command is issued, but power-off fails. Power-off can be achieved by a normal shutdown through a short-press signal or a forced shutdown through a long-press signal. Search the logs for Notify cpld to send short button signal through hwproxy Accessor. or Notify cpld to send long button signal through hwproxy Accessor.. If the system still fails to power off, contact the hardware engineers to locate the fault.

  4. Power-off can fail in several scenarios.

    1. If a safe power-off timeout is configured, the system will perform a forced power-off if it fails to shut down within the configured time.
    2. If no safe power-off timeout is configured, the default power-off timeout is 10 minutes. If this time is exceeded, the system powers on again. Look for the Power off timeout keyword in the power-off failure logs.

5: How to determine if a power-on or power-off command originates from the BMC or OS Check the logs at the corresponding timestamp to see if the command passed through powerapi functions. Any power-on or power-off command originating from the BMC must pass through the BMC.

Reference ​