1. Introduction to CSRs ​

Before learning to configure CSRs, you need to understand the following.

1.1 What Is CSR? ​

CSR stands for component self-description.

1.2 Purpose of CSR ​

A component attaches an EEPROM with a fixed address of 0xAE under the BMC management root link. The BMC obtains component information by reading the CSR file.

1.3 Contents of CSR ​

A component CSR contains the basic hardware of the board, its physical topology, and the physical objects of the devices on the board that require management. The basic hardware attributes describe the board type, ID, and version number. The physical topology primarily defines the device management topology information, such as the management bus topology. Although the board can define the content of the data file based on actual hardware conditions, the management topology is mandatory. The physical objects mainly define in-board physical entities, including chips, connectors, buses, and I/O slots. The BMC loads corresponding management features by obtaining these physical objects.

1.4 Why Is CSR Needed? ​

Traditional out-of-band management solutions for boards require an independent board ID. After startup, the BMC software collects the board ID to distinguish the board type and then loads the corresponding configuration file by searching a table. The BMC software reads the CPLD register values of the board through the Localbus and obtains the corresponding alarm and presence information by describing the CPLD register list for each board in the configuration file.

Disadvantages: An 8-bit board ID can describe only 256 types of boards and board IDs require specialized management. This limits the total number of boards that the BMC can manage. Each board requires an independent configuration file, increasing the development and adaptation workload for BMC software. Furthermore, board management buses are not unified, so BMC adaptation is required whenever a new type of management device is added.

The Tianchi architecture management solution unifies out-of-band management interfaces into a standardized management bus. Currently, this is an I2C bus (which can smoothly evolve to an I3C bus) or an SPI bus. This management bus serves as the root management link for board management. An EEPROM with a fixed address must be connected to the board management root link as a Field Replaceable Unit Description (FRUD). The FRUD should contain hardware information, devices to be managed, topology information, and alarm information. The BMC software automatically loads the management features of the board by reading the FRUD information.

1.5 How CSR Works ​

Other out-of-band management devices on the board, including but not limited to sensors like temperature sensors and ADCs, as well as external devices like hard drives, are not directly connected to the root management bus from the BMC. Instead, they are managed collectively by a Satellite Manager Centre (SMC) on the board. The SMC can be a CPLD or an MCU. After collecting sensor information on the board, the SMC reports it to the BMC through the root management bus interface using command words. Each type of data corresponds to one command word. Command words are shared across different boards, so the BMC does not need to perform adaptation for each board. An SMC command word has a fixed length of 4 bytes (32 bits).

Opcode consists of four parts: Function describes the board type corresponding to the function definition, command defines the standard command word, MS distinguishes between multiple or single reads, and RW distinguishes between read and write commands. parameter describes which sensor information the command word is obtaining.

2. Understanding the Board Management Solution and Outputting the CSR Hardware and Software Interface Document ​

To configure a complete CSR file for a board, you must be familiar with its management solution. This information is contained in the CSR hardware and software interface document provided by the board owner. The document presents the basic hardware configuration, including the UID, 0302, and PCB ID. It also explains the out-of-band and in-band management topology, cable alarm descriptions for high-speed ports, voltage thresholds, and various alarm events. Most of this content needs to be configured in the CSR, so understanding this document is essential.

Note: Before the component code is submitted to the repository for the first time, the CSR software and hardware interface document of the board must be output. Otherwise, the component code cannot be submitted to the repository.

3. Pulling the Golden Sample SR of the Corresponding Component and Analyzing Differences ​

Tianchi intelligent components are classified into five types: basic board, expansion board, backplane, fan board, riser card, and the PSR of the entire system. Currently, golden sample SR files and corresponding configuration guides are available for these six types of components. The golden sample SR matches its configuration guide. After understanding the board management solution, you can confirm the differences between boards by reviewing the configuration guide and the golden sample SR.

The following lists some common differences.

3.1 Difference 1: Management Topology ​

The management topology of different boards is generally consistent, but details vary. In the ManagementTopology module, this is mainly reflected in the number of external interfaces. You must synchronously increase or decrease connector-related configurations and modify the hisport_IIC enablement configuration in DFX (which must be aligned with the logic). Taking the basic board management topology as an example, the management topology for each board type is archived in its corresponding configuration guide. Assume that you are developing a new board based on openUBMC, and the number of UBCs on the board is half that of openUBMC. In this case, you need to remove half of the Hisport_I2C instances and their corresponding connectors.

3.2 Difference 2: Board Information ​

This mainly includes differences in UID, board name, and component position on the board.

3.3 Difference 3: Board-level Sensor and Alarm Configuration ​

This includes all board-level voltage, temperature, clock, and power sensors, as well as related alarm configurations. Generally, the differences lie in the number of sensors and alarm thresholds. Sensor information is described in the hardware and software interface document. Configuration mainly involves the following four parts:

1. Configure the scanner for the corresponding sensor in the SR file.

1. Configure the corresponding scanner in DFX. Configure data in the Config section of SMCDFX and perform concatenation and shifting operations in Mapping to assign values to the corresponding sensors. Ensure that the DFX Config matches Mapping exactly.s

1. Configure related alarms based on the scanner. Note that Event configurations are typically in the soft file. When adding an alarm, configure related parameters with the BMC.

1. Configure sensor information. Currently, software-related sensor information is in the soft file, while hardware-related information is in the SR file. When adding a sensor, configure related parameters with the BMC.

3.4 Difference 4: DFX Differences ​

This part needs to be aligned with the logic/MCU to ensure that each byte of the SMC corresponds to the logic/MCU. Ensure that Config matches Mapping exactly.

3.5 Difference 5: Upgrade Management for CPLD, CSR, and MCU ​

A corresponding UID must be configured for validation.

CPLD upgrade

CSR upgrade

MCU upgrade

3.6 Difference 6: Energy Efficiency Management ​

This is ultimately used for system-wide cooling. Configure temperature points and abnormal fan speed values, which are provided by the thermal design team.

3.7 Difference 7: Slot and Quantity Differences ​

Differences in riser card slots, backplane slots, and the number of fans on fan boards are reflected in the management topology. Modify relevant configurations when configuring the management topology.

3.8 Difference 8: PSR Cooling Policy Configuration ​

The BMC leads the configuration of PSR cooling policies.

3.9 Difference 9: Cable Detection Allowlist Configuration ​

This involves cable detection allowlist configurations (only for the PSR). This configuration is explained in the PSR configuration guide. For details, see the PSR configuration guide.

Note: The differences listed here are the most significant ones. Specific details must still be configured according to the parameters in the hardware and software interface document.

4. Modifying Differences Using BMC Studio ​

BMC Studio is a one-stop BMC development software for development, configuration, packaging, and debugging. Currently, any CSR modifications or changes for Kunpeng hardware must be performed through BMC Studio. In particular, the first version must be written and modified using the tool to reduce low-level errors.

Note: Only PSRs modified using BMC Studio can be submitted to the repository.

After identifying differences from the golden sample SR, use BMC Studio to modify the configuration of those differences.

For details on the installation and configuration of BMC Studio, see the BMC Studio Installation Guide | openUBMC.

5. Verifying Basic Functions and Outputting a Verification Report Based on Test Cases ​

After modification, generate a package and verify the basic functions. Once they are verified, output a verification report for review and submission.

The basic functions include:

1. Successful upgrade
2. Normal environment power-on after the upgrade
3. No abnormal alarms
4. Correct display of component information on the web WebUI, including the name, position, description, and UID
5. Successful execution of test cases

6. Outputting the CSR Detailed Design Document ​

Output the CSR detailed design document before the first submission to the repository.