The power supply management component is responsible for obtaining basic power supply information such as the voltage, current, temperature, and power, setting the power supply working mode and sleep mode, upgrading the power supply firmware, and monitoring the power supply status and locating faults through exception events, alarms, and black box logs.

Power Supply Identification and Loading Process ​

1. The hwdiscovery app automatically identifies and loads CSR.
2. The hwdiscovery app mounts the ObjectGroup object to the tree.
3. The component framework sends an InterfaceAdd signal to each component.
4. Each component requests MDS objects from the hwdiscovery app.
5. The component framework creates a resource tree object.
6. The component framework assigns attributes parsed by the hwdiscovery app to the object.
7. The component framework restores data from the persistent storage to the object.
8. The component framework registers the object to the tree.
9. Invoke the addobject callback function of each component.
10. Perform differentiated adaptation of the component device tree.
11. Execute the orm initialization callback and complete object initialization.

Power Supply Adaptation Process ​

The following example shows adaptation of a pmbus power supply, beginning with CSR adaptation.

1. Power Supply CSR Adaptation ​

Confirm the board the power supply module is inserted to. If it is inserted to an extension unit (EXU), adapt the corresponding CSR.

Configuring the Presence Information Scanner (Usually on the EXU) ​

The following example configures the presence information scanner of Power Supply 1. The configured CSR file is 14100513_00000001010123456789.sr.

"Scanner_PS1Pres": {
  "Chip": "#/Smc_ExpBoardSMC,"    // Associated chip
  Offset: 603981056,              // Offset
  "Size": 2,                      // Length of the data to be read
  "Mask": 1,                      // Valid during bit read. After data is read from the hardware, the bitwise AND operation is performed on the data and the mask.
  "Type": 0,                      // Read type. 0: bit read; 1: block read
  Value: 255,                     // Value
  "Period": 2000                  // Scanning period, in milliseconds
}

Configuring the Power Supply Connector (Usually on the EXU) ​

This step configures the CSR for power supply loading. The following example sets the CSR (14191046_PSU_0.sr) for Power Supply 1 loading and uses the presence status configured in the previous step.

"Connector_PowerSupply_1": {
  "Bom": "14191046",                         // BOM ID of the downstream component
  "Slot": 1,                                 // (Mandatory) Current connector slot, which is used to confirm the slot information of the downstream component
  "Position": 9,                             // (Mandatory) Current connector position, which is used to calculate the position of the downstream component
  "Presence": "<=/Scanner_PS1Pres.Value",    // (Mandatory) Presence information of the downstream component
  "Id": "PSU",                               // ID of the downstream component
  "AuxId": "0",                              // AuxId of the downstream component
  "Buses": [                                 // (Mandatory) Bus information of the connector, which is transferred to the downstream 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
}

Configuring the Power Supply Slot and Chip (Usually on the EXU) ​

This step configures the power supply slot and chip. The CSR is set as 14100513_00000001010123456789.sr.

"PsuSlot_1": {
  SlotNumber: 1,                           // Slot number
  "Presence": "<=/Scanner_PS1Pres.Value",  // The referenced presence information
  "SlotI2cAddr": 184,                      // The I2C address of a slot
  "PsuChip": "#/Eeprom_PsuChip1"           // I2C component association
},
"Eeprom_PsuChip1": {                                      
  "Address": 184,                          // Address information      
  "AddrWidth": 1,                          // Bit width
  "OffsetWidth": 1,                        // Offset width
  "ReadTmout": 30,                         // Read timeout, in milliseconds
  "WriteTmout": 30,                        // Write timeout, in milliseconds
  "RwBlockSize": 1024                      // Size of the data read or written in pages, in bytes
}

Configuring the Power Supply CSR ​

This step configures the power supply object, which is loaded and unloaded according to changes in the power supply presence information. 14191046_PSU_0.sr is used for configuration.

"FruData_Ps": {
    "FruId": 1,                         // FRU ID. The value range is 1–63. The FRU ID is automatically allocated. The default value is 1.
    "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. For details, see the appended iBMC IPMI interface description.
    "FruDataId": "#/FruData_Ps"         // Name of the associated FruData object
},
"OnePower_0": {
    "SlotNumber": "${Slot}",            // (Mandatory) Slot number
    "Presence": 1,                      // (Mandatory) Presence information
    "Protocol": "pmbus",                // Power supply protocol
    "PhysicalInterface": "pmbus_test",  // (Mandatory) Physical interface
    "DeviceLocator": "PSU${Slot}",      // (Mandatory) Physical location
    "Position": "EXU",                  // (Mandatory) Container information
    "EnvTemperatureCelsius": 0,         // Ambient temperature of a single power supply
    "SerialNumber": "",                 // Serial number
    "OutputState": 1,                   // Power supply voltage output status
    "DeepSleepEnabled": 0,              // Whether to enable power supply 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,                       // Power supply fault
    "OverTemperature": 0,               // Overtemperature fault
    "LossOfInput": 255,                 // Input power loss
    "RefFrudata": "#/FruData_Ps",       // Associated FruData object
    "PartNumber": ""                    // Component number
}

2. Adapting the Power Supply Device Tree ​

The power supply device tree involves the following objects: OnePower, PsuSlot, Monitor, and Protocol. The definition and function of each object are as follows:

OnePower ​

The device tree loads a general model. If there are inconsistencies with the general logic, an adapter must be added under the corresponding CSR directory. In the init phase, the general OnePower associates with the co-slotted PsuSlot object at the upstream position and updates the Fru information.

PsuSlot ​

Configure an independent adapter for each board where the PsuSlot is located. After obtaining the PsuSlot object, the framework starts different adapter modules based on the CSR to which the object belongs.

Main function logic of the PsuSlot (required for adapting the new adapter):

• fetch_power_supply_info registers the corresponding protocol (such as PMBus and CANbus) and updates the FRU data.
• power_monitor_start starts the attribute polling task.
• psm_monitor_stop stops the power supply polling task.

Monitor ​

Power supplies using different protocols differ in their implementations for attribute querying, polling intervals, and other aspects. Therefore, it is necessary to abstract the implementation functions of fetch_power_supply_info and power_monitor_start, and extract the distinct task scheduling mechanisms into the monitor.

Main function logic of Monitor (required for adapting the new adapter):

• fetch_power_supply_info obtains and updates the FRU data.
• power_monitor_start starts the power supply information monitoring.
• stop_monitor_tasks stops the power supply information monitoring.

Protocol ​

The power supply protocol implements different underlying logic based on the power supply type to abstract away command and functional differences from upper layers, thereby ensuring that interface functions and names remain consistent.

The following functions are included:

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

3. Power Supply Protocol Adaptation and Loading ​

Define the protocol file to be loaded in the init.lua(include/device_tree/adapters/power_mgmt/protocol/init.lua) file of the device tree based on the physical_interface transferred from the upper layer (that is, the PhysicalInterface attribute configured in the OnePower object), and encapsulate the monitor. (Optional)

The following two formats are supported:

physical_interface = {the Protocol field that OnePower externally displays, require xxx file, the file path of monitor}`

Vendor = { [Model] = {the Protocol field that OnePower externally displays, require xxx file, the file path of monitor} }

Taking the pre-configured OnePower object as an example, the PhysicalInterface is set to pmbus_test, therefore the corresponding protocol and monitor must be configured in init.lua. Here, both the power supply protocol and monitor require a new file (existing ones can be reused directly if identical).

Device Tree Adaptation via adapter ​

Device tree adaptation via adapter primarily targets PsuSlot and OnePower objects. The component repository contains a general model of PsuSlot and OnePower for device tree loading. However, if different requirements exist that deviate from the general logic, an adapter must be added to the corresponding CSR directory.

Taking PsuSlot as an example, to implement differentiated code, a new folder with the same name as the configured CSR must be created. Under this folder, add the corresponding PsuSlot file. During loading, the framework prioritizes objects from the folder matching the CSR name, then falls back to general files.

Debugging ​

After completing the above configuration, use the busctl --user tree bmc.kepler.power_mgmt command to view the configured OnePower in the resource tree. Check whether attributes under each power supply object display correctly. If abnormal information appears, first manually send commands to read power supply data. If data can be read successfully, the device tree code adaptation has issues; otherwise, the CSR adaptation is problematic.

The method for manually querying power supply information is as follows. The example below shows using pmbus to read the input power of Power Supply 1:

busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Eeprom/Eeprom_PsuChip1_0101 bmc.kepler.Chip.BlockIo Read a{ss}uu 0 151 3

Description:

• /bmc/kepler/Chip/Eeprom/Eeprom_PsuChip1_0101: resource tree path of the corresponding chip (adjusted based on the path in the environment)
• bmc.kepler.Chip.BlockIo: interface for reading and writing resource tree blocks
• Read: method name
• a{ss}uu: request parameter signature. a{ss} is the context and can be set to 0. The first u indicates the offset. 151 indicates the command word for pmbus to obtain input power. The second u indicates the number of bytes to be read, which are 3, including 2 bytes and a CRC code.

Power Supply Firmware Upgrade ​

1. Obtain data of the power supply with the matching protocol and upgrade package.
2. Verify whether the number of power supplies is 0.
3. Switch the power supply mode to prevent the entire system from being powered off.
4. Sort the upgrade sequence according to the power supply health.
5. Traverse each power supply according to the sorted sequence.
6. Check whether the environment supports the upgrade.
7. Stop the power supply data monitoring.
8. Upgrade a single power supply.
9. Restore the data monitoring and upgrade the power supply firmware information.
10. Return the power supply upgrade result.

Main Function Logic ​

power_upgrade ​

is_support_upgrade(psu_obj) ​

Verifies whether the power supply supports upgrade (including verification of power supply status, mode, and quantity).

PsuSlot ​

power_upgrade(upgrade_path, upgrade_process) ​

Invokes pre- and post-upgrade processing (including stopping and starting power supply monitoring tasks and updating power supply status) and protocol upgrade processing.

Protocol ​

upgrade(upgrade_path, upgrade_process) ​

Power supply upgrade processing

Precautions ​

• Class variables used in the device tree must be defined in the ctor, otherwise retrieval in the code will result in nil.