Upgrade Component
更新时间： 2026/08/06
在Gitcode上查看源码Upgrade Component
Change History
| openUBMC Version | Revision Date | Description |
|---|---|---|
| 25.06 | 2025/06/26 | Initial draft: add command details |
Basic Information
Function Description
This command is used to upgrade a component.
Privilege
BasicSetting
Command Information
Request Information
| Byte | Data Field |
|---|---|
| NetFn | 30h |
| CMD | 91h |
| 1:3 | Manufacturer ID, LS Byte first. The length is fixed to three bytes. For example, if the vendor ID is 2011 and the corresponding hexadecimal value is 0x0007DB, the first byte is DBh, the second byte is 07h, and the third byte is 00h. |
| 4 | Sub command, sub command=06h |
| 5 | Operation type: 55h finish upgrade AA initiate upgrade CCh SMM initiate upgrade Set the BMC restart flag after the upgrade is complete on the CDh. (Before the upgrade, set the BMC to be manually restarted. After the upgrade progress reaches 100%, set the BMC to be automatically restarted. This solves the problem that the NMS cannot obtain the 100% progress.) The implementation difference between V2 and V3 is as follows: In V2, the return value contains only Completion Code. In V3, the return value contains IANA and Upgrade progress. The CEh command forcibly upgrades the BIOS. The service system is powered off and the BIOS firmware is upgraded in full space. Set the DDh power-off and then upgrade flag. (Deliver the DDh operation type and then the upgrade command. If the power-off is required before the upgrade, power off the device and then perform the upgrade. This solves the problem that the BIOS cannot be upgraded in in-band mode.) 00h get upgrade status DANGER: If Operation type is set to CEh, the customized BIOS configuration will be erased. As a result, the customized BIOS function becomes invalid. Exercise caution when performing this operation. |
| 6* | FRU ID If the value of byte5 is DDh, safe power-off needs to be performed before the upgrade. However, the safe power-off timeout period may be permanent. As a result, the power-off and upgrade may fail. Therefore, if the value of byte5 is DDh and the command does not contain byte6 and byte7 (for compatibility), by default, the server is forcibly powered off after 5 minutes. When byte5 is DDh, this byte indicates the lower byte of the power-off timeout period before the upgrade, in seconds. |
| 7* | Reserved. The value is fixed to 0. When byte5 is DDh, this byte indicates the high-order byte of the power-off timeout period before the upgrade, in seconds. NOTE: Currently, the BMC does not process the component ID and this field will not be used in the future. Currently, the definition of this field is different from that in the implementation, and the implementation of iBMCBMC v1 and iBMCBMC v2 is different. Therefore, this field is reserved. |
| 8* | Flag [7]: Concatenation flag 0: last data 1: middle data [6:0]: offset of the file name, starting from 0. Do not mix the sequence when transmitting a file name multiple times. |
| 9* | Length [7]: effective mode 0: The upgrade takes effect manually. After the firmware (such as BMC and CSR) is upgraded, you need to manually restart the system for the upgrade to take effect. 1: The firmware (such as BMC and CSR) upgrade takes effect after the system is automatically restarted. [6:0]: Length, data length of the current frame. The length of a single frame cannot exceed 16 bytes. |
| 10:N* | Filename: absolute path name. The length of a single frame request cannot exceed 16 bytes. |
| Note: The asterisk (*) needs to be filled only when 80 historical data is obtained. |
Response Information
| Byte | Data Field |
|---|---|
| 1 | Completion Code 0x80: The upgrade is in progress. 0x81: reserved 0x82: The file does not exist. 0x83: file error 0x84: The memory is insufficient. 0x85 File transfer failure (SM) 0x86: The upgrade space is insufficient (SM). 0x87 File name conflict 0x88: The upgrade is not supported when the system is not powered off. 0x89: The firmware version does not match. 0x8B: A physical partition in the same SCE is powered on, and the upgrade cannot be performed. 0x8C: The upgrade file does not match (board ID mismatch). 0x8D: The ME status is incorrect and the BIOS cannot be upgraded. 0x8E: unknown error 0xA8: The BMC coprocessor upgrade fails. |
| 2:4 | Manufacturer ID, LS Byte first. The length is fixed to three bytes. For example, if the vendor ID is 2011 and the corresponding hexadecimal value is 0x0007DB, the first byte is DBh, the second byte is 07h, and the third byte is 00h. |
| 5 | Upgrade progress. [7]-status 0h=Upgrade in progress. 1h=Upgrade completed: indicates that the upgrade is complete or no upgrade task is available. [6:0]-Upgrade progress percentage |
| (6) | Upgrade mode. 1h=prepare 2h=process 3h=complete other: reserve |
| (7) | upgrade compnent(1) if operation type=00h, which is extended to 4 bytes. This is the least significant byte. |
| (8:9) | sub error code LSB if operation type=00h |
| (10) | upgrade compnent(2) if operation type=00h, which is extended to 4 bytes |
| (11) | upgrade compnent(3) if operation type=00h, which is extended to 4 bytes |
| (12) | upgrade compnent(4) if operation type=00h, which is extended to 4 bytes. This is the most significant byte. |
Command Example
Obtain the upgrade status.
Request:
bash
ipmicmd -k "0f 00 30 91 db 07 00 06 00" smi 0Response:
text
0f 31 00 91 00 db 07 00 e4 03 11 00 00 00 00 00