文档中心
Power Management Mechanism Introduction
更新时间： 2025/12/11
在Gitcode上查看源码

Repository Introduction ​

The power management component (power_mgmt) is the core module for power supply unit (PSU) status monitoring, configuration control, and fault diagnosis.
Repository location: power_mgmt
Repository functions: The power management component is responsible for obtaining basic PSU information such as the voltage, current, temperature, and power, setting the PSU working mode and sleep mode, upgrading the PSU firmware, and monitoring the PSU status and locating faults through exception events, alarms, and black box logs.

Code directory structure:

bash
📦power_mgmt
 ┣ 📂docs                                        # Documentation directory
 ┣ 📂include
 ┃ ┣ 📂device_tree                               # Device tree implementations
 ┃ ┃ ┗ 📂adapters
 ┃ ┃ ┃ ┣ 📂14060876_0000000xxxxxxxxxxxxx         # Adapter implementation for board 14060876_0000000xxxxxxxxxxxxxxxx
 ┃ ┃ ┃ ┣ 📂14100513_0000000xxxxxxxxxxxxx         # Adapter implementation for board 14100513_0000000xxxxxxxxxxxxxxxx
 ┃ ┃ ┃ ┣ 📂14191046_0000000xxxxxxxxxxxxx         # Adapter implementation for board 14191046_0000000xxxxxxxxxxxxx
 ┃ ┃ ┃ ┣ 📂power_mgmt
 ┃ ┃ ┃ ┃ ┣ 📂protocol
 ┃ ┃ ┃ ┃ ┃ ┣ 📂monitor
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus.lua                      # CANbus PSU monitor
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus_pah.lua
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus_tpsu.lua
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus.lua                       # PMBus PSU monitor
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_PDC4000D12_LC.lua
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_qb900.lua
 ┃ ┃ ┃ ┃ ┃ ┃ ┗ 📜powerconverter_pmbus.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📂upgrade
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus_upgrade.lua              # CANbus PSU upgrade handling
 ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜fw_def.lua                      
 ┃ ┃ ┃ ┃ ┃ ┃ ┗ 📜pmbus_upgrade.lua               # PMBus PSU upgrade handling
 ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus.lua                        # CANbus protocol
 ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus_pah.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜canbus_tpsu.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜init.lua                          # Protocol adaptation and loading
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus.lua                         # PMBus protocol
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_FP1420.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_PDC3KD5412_LC.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_PDC4000D12_LC.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_eb1000_1.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜pmbus_qb900.lua
 ┃ ┃ ┃ ┃ ┃ ┣ 📜powerconverter_pmbus.lua
 ┃ ┃ ┃ ┃ ┃ ┗ 📜smc.lua
 ┃ ┃ ┃ ┃ ┗ 📜utils.lua                           # Utility function implementations
 ┃ ┃ ┃ ┣ 📜OnePower.lua                          # OnePower general implementation
 ┃ ┃ ┃ ┗ 📜PsuSlot.lua                           # PsuSlot general implementation
 ┃ ┗ 📂hwproxy                                   # Power plugin implementations
 ┃ ┃ ┗ 📂plugins
 ┃ ┃ ┃ ┗ 📂power_mgmt
 ┃ ┃ ┃ ┃ ┗ 📜init.lua                            # Power plugin code
 ┣ 📂manufacture                                 # Equipment test item code
 ┃ ┣ 📜customize_cfg.lua
 ┃ ┗ 📜manufacture_app.lua                     
 ┣ 📂src
 ┃ ┣ 📂debug
 ┃ ┃ ┗ 📂lualib
 ┃ ┃ ┃ ┗ 📂power_mgmt_mock
 ┃ ┃ ┃ ┃ ┗ 📜init.lua
 ┃ ┣ 📂lualib
 ┃ ┃ ┣ 📂config_mgmt
 ┃ ┃ ┃ ┣ 📜customize_config.lua
 ┃ ┃ ┃ ┗ 📜server.lua
 ┃ ┃ ┣ 📂device                                   # PSU object processing layer
 ┃ ┃ ┃ ┣ 📜circuit.lua
 ┃ ┃ ┃ ┣ 📜power_configuration.lua                # PSU configuration object processing layer
 ┃ ┃ ┃ ┣ 📜power_mgmt.lua
 ┃ ┃ ┃ ┣ 📜power_supplies.lua
 ┃ ┃ ┃ ┣ 📜psu.lua                                # Individual PSU processing layer
 ┃ ┃ ┃ ┗ 📜psu_slot.lua                           # Individual PSU slot object processing layer
 ┃ ┃ ┣ 📂external_interface
 ┃ ┃ ┃ ┗ 📜handler.lua                            # External calling interfaces and global variable interfaces
 ┃ ┃ ┣ 📂macros                                   # Constants
 ┃ ┃ ┃ ┣ 📜fw_def.lua
 ┃ ┃ ┃ ┣ 📜power_mgmt_enums.lua
 ┃ ┃ ┃ ┗ 📜psu_def.lua
 ┃ ┃ ┣ 📜add_event.lua                            # Software alarm generation through interface calling             
 ┃ ┃ ┣ 📜capacitor_mgmt.lua
 ┃ ┃ ┣ 📜circuit_mgmt.lua
 ┃ ┃ ┣ 📜efficiency_curve.lua                     # Power efficiency conversion curves
 ┃ ┃ ┣ 📜export_import_engine.lua                 # Configuration import/export
 ┃ ┃ ┣ 📜gpio_drived.lua                          # Interrupt signal capture
 ┃ ┃ ┣ 📜life_prediction_model.lua                # TPSU turbo capacitor life prediction
 ┃ ┃ ┣ 📜lock_chip.lua
 ┃ ┃ ┣ 📜log_service.lua                          # Log collection and ACLost events
 ┃ ┃ ┣ 📜metric_collect.lua                       # Data collection
 ┃ ┃ ┣ 📜parser_cfg.lua                           # Upgrade package parser
 ┃ ┃ ┣ 📜power_ipmi.lua                           # Power IPMI implementation
 ┃ ┃ ┣ 📜power_mgmt_app.lua                       # Application entry
 ┃ ┃ ┣ 📜power_mgmt_bus.lua                       # Global bus storage
 ┃ ┃ ┣ 📜power_mgmt_metric.lua
 ┃ ┃ ┣ 📜power_mgmt_utils.lua                     # Power utility function implementations
 ┃ ┃ ┣ 📜power_supplies_service.lua
 ┃ ┃ ┣ 📜power_upgrade.lua                        # Power upgrade handling
 ┃ ┃ ┣ 📜psu_service.lua                          # Processing layer for all PSU objects
 ┃ ┃ ┣ 📜signal.lua                               # Power upgrade signal processing
 ┃ ┃ ┣ 📜system_power.lua                         # Custom power FRU information configurations
 ┃ ┃ ┗ 📜task_service.lua                         # General task processing
 ┃ ┗ 📂service
 ┃ ┃ ┗ 📜main.lua
 ┣ ...
 ┗ 📂test                                          # Test directory

Key Features ​

  1. Power information collection

    The power management component obtains basic information such as the manufacturer, model, serial number, and rated parameters by accessing the FRU associated with the PSU and the protocol-specified registers. Vendors can use OEM commands to extend custom data. Users can query the real-time status and historical power data by using Redfish, IPMI commands, or CLI tools.

    Currently, the system supports the following two types of communication protocols:

    • Power management bus (PMBus)

    This open digital power management protocol based on I2C allows multiple devices to be mounted to the same bus to implement bidirectional communication between the host and PSUs. It is suitable for standard voltage regulation and real-time monitoring scenarios.

    • Controller area network bus (CANbus)

    The CANbus is a serial communication protocol with high reliability and strong anti-interference capabilities. It is widely used in scenarios with strict real-time requirements, such as automotive electronics, industrial control, and aerospace. In a specific server architecture (such as an industrial-grade or customized high-availability system), CAN facilitates peer-to-peer communication between PSUs, supporting PSU status synchronization, fault isolation, and collaborative load control.

  2. Black box log mechanism

    The PSU black box continuously records status changes of critical power registers. When a power anomaly occurs (such as a sudden voltage change, overtemperature, or communication interruption), the system automatically saves data from before and after the event to the /dump_info/LogDump/ps_black_box.log file. You can quickly export the record using the one-click log collection function to help developers and O&M personnel analyze the cause of the fault accurately.

  3. Firmware upgrade

    The PSU firmware is upgraded by uploading the signed upgrade package. During the upgrade, the system will:

    • Pause routine monitoring tasks.
    • Force the PSU to be upgraded into active mode to ensure uninterrupted service power supply.
    • Automatically restart monitoring services and verify the new firmware version after the upgrade completes.

  4. PSU mode management

    The following PSU modes are supported:

    • Active mode (Enabled): The PSU operates normally and provides power to loads.
    • Standby mode (StandbySpare): The PSU remains on standby and takes over the load only if the active PSU fails.

    openUBMC supports load balancing (all PSUs are active) and active/standby power supply (only specified PSUs are active, and others are on standby). You can adjust these strategies dynamically based on redundancy requirements.

  5. Alarm and event mechanism

    The hardware triggers an interrupt when an AC power loss occurs. The management controller records the event flag and starts a post-analysis process (such as recording the cause of the last power loss). In addition, threshold alarms (such as overvoltage, overcurrent, and temperature exceeding the threshold) can be configured and reported in real time through Syslog and Redfish events.

Key Adaptation Points ​

For details about the PSU adaptation process, see Power Supply Adaptation Guide. This section summarizes the functions and key adaptation points of the adaptation items.

PSU CSR Adaptation ​

Configuring the Presence Information Scanner (Usually on the Extension Board) ​

The following example configures the presence information scanner of PSU 1. The configured CSR file is 14100513_00000001010302023922.sr.

json
"Scanner_PS1Pres": {
  "Chip": "#/Smc_ExpBoardSMC",  // Associated chip
  "Offset": 603981056,          // Offset
  "Size": 2,                    // Read data length
  "Mask": 1,                   // Valid during bit read. After data is read from the hardware, bitwise AND is performed with the mask.
  "Type": 0,                    // Read type: 0 for bit read and 1 for block read
  "Value": 0,                   // Read value
  "Period": 2000                // Scanning cycle in milliseconds (ms)
}

Functions of Scanner_PS1Pres: Based on the configuration, hwproxy performs periodic scans (every 2 seconds in this example). It updates the resource tree with the scanned and calculated values to determine the presence status of PSU 1.

Configuring the PSU Connector (Usually on the Extension Board) ​

This step configures the CSR for PSU loading. The following example sets the 14191046_PSU_0.sr CSR for PSU 1 loading and uses the presence status configured in the previous step.

json
"Connector_PowerSupply_1": {
  "Bom": "14191046",                            // Sub-component BOM ID
  "Slot": 1,                                    // (Mandatory) Current connector slot, which is used to determine the sub-component slot information
  "Position": 9,                                // (Mandatory) Current connector position, which is used to calculate the sub-component position
  "Presence": "<=/Scanner_PS1Pres.Value",       // (Mandatory) Sub-component presence information
  "Id": "PSU",                                  // Component Id of the sub-component
  "AuxId": "0",                                 // Component AuxId of the sub-component
  "Buses": [                                    // (Mandatory) Connector bus information passed to the sub-component
    "I2c_2"
  ],
  "SystemId": 1,                                // SystemId to be transferred downstream
  "SilkText": "psu1",                           // Silkscreen information of the connector
  "IdentifyMode": 2,                            // (Mandatory) Connector flag mode
  "Type": "Psu"                                 // Connector type
}

Configuration notes:

  • Position uniqueness: The position of each connector in a CSR must be unique.
  • Identification mode matching: The value of IdentifyMode must match the actual component type.
  • Bus validity: Buses in Buses must exist in the system.
  • Presence status: The sub-level SR is loaded only when the value of Presence is 1.
  • ID configuration rule: Select a proper ID obtaining mode based on the value of IdentifyMode.

Configuring the PSU Slot and Chip (Usually on the Extension Board) ​

This step configures the PSU slot and chip. Ths configured CSR file is 14100513_00000001010302023922.sr.

json
"PsuSlot_1": {
  "SlotNumber": 1,                         // Slot number
  "Presence": "<=/Scanner_PS1Pres.Value",  // Referencing the PSU presence register
  "SlotI2cAddr": 184,                      // PSU slot I2C address
  "PsuChip": "#/Eeprom_PsuChip1"           // Associated PSU I2C device
},
"Eeprom_PsuChip1": {                                      
  "Address": 184,                          // Address information      
  "AddrWidth": 1,                          // Address bit width
  "OffsetWidth": 1,                        // Offset width
  "ReadTmout": 30,                         // Read timeout in ms
  "WriteTmout": 30,                        // Write timeout in ms
  "RwBlockSize": 1024                      // Data size for paged read/write in bytes
}

Configuration notes:

  • Slot uniqueness: SlotNumber must uniquely identify the PSU slot.
  • I2C address: SlotI2cAddr is represented in decimal format
  • Presence detection: Presence must associate with a valid Scanner object.
  • Component association: PsuChip must associate with a valid EEPROM device that communicates with the PSU hardware (including offset and address).

Configuring the PSU CSR ​

This step configures the PSU object, which is loaded and unloaded as the PSU presence information changes. The configured CSR is 14191046_PSU_0.sr.

json
"FruData_Ps": {
    "FruId": 1,                         // FRU ID. FruId. IDs 1 to 63 are allocated automatically. You can set it to 1 by default.
    "StorageType": "Power"              // There is no restriction on non-standard electronic labels.
},
"Fru_Ps": {
    "PowerState": 1,                    // Hot swap status of the FRU
    "Health": 0,                        // Health status
    "EepStatus": 1,                     // EEPROM status
    "Type": 3,                          // FRU type. See the device type appendix in the IPMI interface description of the IDP document.
    "FruDataId": "#/FruData_Ps"         // Associated FruData object name
},
"OnePower_0": {
    "SlotNumber": "${Slot}",            // (Mandatory) Slot number
    "Presence": 1,                      // (Mandatory) Presence information
    "Protocol": "pmbus",                // PSU protocol
    "PhysicalInterface": "pmbus",       // (Mandatory) Physical interface
    "DeviceLocator": "PSU${Slot}",      // (Mandatory) Physical location
    "Position": "EXU",                  // (Mandatory) Container information
    "EnvTemperatureCelsius": 0,         // Ambient temperature of the individual PSU
    "SerialNumber": "",                 // Serial number
    "OutputState": 1,                   // PSU output voltage status
    "DeepSleepEnabled": 0,              // Whether to enable PSU deep sleep (used for alarms)
    "OutputPowerWatts": 0,              // Output power
    "InputVoltageFault": 32768,         // Input voltage status
    "OutputVoltageFault": 0,            // Output voltage status
    "OutputCurrentFault": 0,            // Output current status
    "FanFault": 0,                      // Fan status
    "Fan1Fault": 0,                     // Fan 1 fault
    "Fan2Fault": 0,                     // Fan 2 fault
    "Failure": 0,                       // PSU fault
    "OverTemperature": 0,               // Overtemperature fault
    "LossOfInput": 255,                 // Input power loss
    "RefFrudata": "#/FruData_Ps",       // Associated FruData object
    "PartNumber": ""                    // Component number
}

PSU Device Tree Adaptation ​

OnePower ​

The device tree loads the general model. If the logic differs from the general model, add an adapter in the corresponding CSR directory. Core functions of the general OnePower include:

  • Slot association establishment: Establishes associations between OnePower and PsuSlot through position matching. The core function is register_psu_slot.
  • Electronic label information refresh: Obtains FRU data from the bottom layer (retries up to 3 times) and updates the upper-layer framework. The core function is update_fru_data.
  • Automatic property synchronization: The core function is fetch_property().
  • Method registration: Register external invoking methods.
  • Power monitoring startup: The core function is power_monitor_start.

PsuSlot ​

The PsuSlot object is an intermediate layer of hardware abstraction and is responsible for:

  • Managing specific PSU hardware (driven by the protocol).
  • Providing unified interfaces for the upper-layer OnePower object.
  • Monitoring the PSU status in real time.

Monitor ​

The monitor module returns a PsuSlot class with complete monitoring functions. Its core roles include:

  • Protocol abstraction: Hides differences between PMBus and CANbus protocols to provide a unified monitoring interface.
  • Policy customization: Optimizes monitoring frequency and methods based on protocol characteristics.
  • Data standardization: Maps data from different protocols to a unified health event model.
  • Performance adaptation: Implements appropriate monitoring strategies based on protocol capabilities.

Protocol ​

PSU protocols are implemented based on PSU types, hiding command words and logical function implementations while keeping interface functions and names consistent.

The following functions are included:

  • Querying power information, status information, and FRU information
  • Obtaining PSU black box data
  • Setting the PSU mode (active/standby and deep sleep)
  • Setting the fan speed
  • Upgrading the PSU

Debugging Commands ​

Querying the PSU Fan Speed ​

Function

Queries the PSU fan speed.

Syntax

getpsufanspeed <ObjectName>

Example

shell
% attach power_mgmt
Success

% lsobj OnePower   
OnePower_0_010109   
OnePower_0_01010B  

% getpsufanspeed OnePower_0_01010B   
6419   

%

Querying the PSU Register Information ​

Function

Queries the PSU register information of the PMBus protocol.

Syntax

getpsureg <ObjectName> <Cmd> <Length>

Example

shell
% attach power_mgmt  
Success  

% lobj OnePower  
OnePower_0_010109  
OnePower_0_01010B  

% getpsureg OnePower_0_01010B 144 2
[26,25]
shell
busctl --user tree bmc.kepler.power_mgmt
#View OnePower properties of the power object
busctl --user introspect bmc.kepler.power_mgmt /bmc/kepler/Systems/1/PowerMgmt/OnePower_0_010109
busctl --user introspect bmc.kepler.hwproxy /bmc/kepler/Chip/Eeprom/Eeprom_PsuChip1_0101
#Read the input power of PSU 1 via PMBus
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Eeprom/Eeprom_PsuChip1_0101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 151 3