固件升级整体描述
固件升级动作主要包含启动固件升级和升级进度查询，其中启动固件升级分为两个场景，即本地升级和远程升级，实际的升级动作由实际的固件子模块完成，固件管理模块驱动完成整个固件升级流程，因此固件管理模块需要与固件子模块机型交互：
固件升级具体实现
固件升级阶段分为Initialize，prepare，process，和finish四个阶段，在两个阶段间插入公共处理动作，每个固件子模块包含prepare，process，和finish三个特有动作。
prepare
在接收到固件管理组件发送的prepare消息后，确认收到的消息是当前子模块的升级消息，判断是否允许升级，回复prepare结果。
process
- 升级包数据预处理。通过AES,CBC,128算法加密，解密并将升级数据写入bin文件；
- 写升级数据到flash。将bin文件打包写入flash，并最终输出到对应的分区；
- 设置M3标志位。设置BMC升级标志位。
finish
- 判断若first boot脚本存在，则执行该脚本；
- 给固件管理组件注册生效模式，生效动作由固件管理组件统一管理。 固件升级时序流程如下： 三个阶段都通过之后则升级成功，中间任意一个阶段收到固件子系统”升级失败“的结果，则认为此次升级失败，或者在规定时间段内固件子系统未回复固件管理阶段性结果，则认为超时失败。
固件生效
固件子模块感知到生效条件满足后，找固件管理模块进行裁决，由固件管理模块决定其是否能执行生效动作。基础的处理流程如下：
并行升级
并行升级流程
iBMC除了常用的升级方式单独升级固件以外，还配置了并行升级方式，具体的升级流程如下：
互斥处理
并行升级与串行升级互斥
升级流程（如固件生效）需串行执行，避免并发冲突。生效接口调用时，若已经在生效流程中，直接报错。
固件互斥规则
- 相同ComponentID和ComponentIDEx的固件不支持并行升级；
- 不同ComponentIDEx的固件可能支持并行，但需要业务组件在prepare阶段返回错误码；
- 硬件对象间（如管理板与接口卡）禁止并行升级；BMC必须优先升级且独立。
互斥处理
互斥场景（如加锁失败或者下游组件判断不支持并行升级）时，任务移动至队尾等待，不记录重试次数，相同ComponentID和ComponentIDEx的固件在升级时，新任务排队等待重试。
资源限制
- 并行任务上限：同时升级的固件数量通过CSR配置，默认上限为5；等待队列任务数默认任务上限为10，超限后新掉用报错。
- 存储队列管理：本地升级需要先缓存固件包，优先处理本地任务以释放资源。
并行升级固件升级常用接口及方式
固件升级接口由多个，其中包括web页面升级，cli命令升级，redfish接口升级，snmp接口升级及ipmi命令升级等，但是常用的有web页面升级及cli升级，其他升级方式见社区资料,文档中心。
web页面升级
操作位置：iBMC管理>>固件升级>>固件更新
cli命令升级
xshell登录后，下发如下命令即可升级：
白牌包升级
产品管理组件实现对接固件管理组件，完成白牌包升级和生效；具体步骤及升级流程图如下：
- 升级前准备：解析update.cfg文件，判断升级包类型是否为白牌包；
- 升级动作执行：解析filelist.cfg,完成定制文件导入到系统指定目录；
- 升级后处理：解析web_custom.xml文件，完成xml文件中属性定制。
升级常见问题
升级报错：无效升级包/FirmwareType is nil
日志报错如下： 固件类型的定位被外置，遇到这种报错就是因为没有在VPD仓定义需要升级的固件类型，自发现没分发此固件的对象给固件管理组件，导致固件管理组件无法识别此固件。新增固件对象的方法：VPD仓中对应的机型的platform.sr中新增对象，如下如所示，且ComponentID与ComponentIDEx数据需与update.cfg内数据保持一致。
密钥解密失败导致升级失败
如上图日志打印说明是升级需要的密钥解密失败，可能原因是key_mgmt更新密钥后，ksf密钥与升级密钥不匹配，导致升级密钥无法解密，当前固件版本大于等于1.0.30，已经从firmware角度增强健壮性，解决了整个问题。如果遇到该问题规避措施如下：
- 删除环境密钥
- 重启bmc_core服务；
- 组件服务起来之后，重新升级。
升级白牌包时报"p12 parse fail"
白牌包在制作的过程中涉及到ssl证书，证书分为加密和不加密两种，该日志对应的是加密证书，加密证书的制作分为四个步骤，分别为原始加密.pxf证书制作，确认加密密码，去密码，设置加密密码，而该报错是因为在制作证书的时候未按照要求去密码设置，导致在解密的时候系统解密密钥与加密密钥不匹配。
保留配置升级和不保留配置升级BIOS均失败
日志上显示get snaphot failed,尝试下发如下图命令，确实是否有返回： 返回报错，此时根本原因是上图中的BIOS资源树未成功加载，从而生成快照失败。沟通后发现，环境为天池模组环境，无bcu，导致bcu中涉及bios升级的资源树全部未加载，解决方案是将bcu中涉及bios的资源树部分功能进行迁移，最好跟着产品走。
V2无法升级V3
ipmcget -d v 获取V2版本信息 收集日志或重启触发升级，分析升级相关日志： 从日志可以看到此版本BMC缺乏或本根证书，导致签名校验失败，当前版本的BMC不但无法从V2升级到V3，也无法升级V2，需要先解决证书问题。解决办法：使用镜像倒换功能切换到另一个分区的BMC版本，然后在尝试升级。
烧片包的V2无法升级V3
环境上的BMC是一个较老的V2烧片BMC，V2升级V3日志报错如下： 原因是V2较老把呢不能的签名只支持PKCS，不支持PSS,需要升级到中间版本作预埋，然后B版本就可以同时校验PKCS和PSS，此时在升级V3的BMC就可以成功。
上电升级CPLD，下电后未生效
现象：上电情况下升级了CPLD，下电后CPLD未触发生效，环境没AC,CPLD版本未变化。 定位步骤：
- 查看操作日志，确定操作时间：
- 搜索app.log日志对应时间点，查看详细升级日志：
- 在相关事件点附近查看日志，管擦和CPLD生效流程日志是否按照正常预期执行：
- CPLD上电升级，向固件管理组件注册生效item；
- 环境下电；
- 固件管理组件监听到下电，触发生效 在步骤（1）中，看到CPLD注册的生效条件是PowerCycle，说明跑了CPLD生效定制化，此定制项定制之后，下电和强制下电将不会生效CPLD，此时只需要消除此定制化即可。
升级超时失败
升级的三个现象代表三个阶段的超时失败：
- prepare阶段超时失败： 现象：升级进度在5%持续一分钟，然后升级失败，app.log存在如下打印： 说明子固件在prepare阶段没有在一分钟之内响应固件管理组件，导致超时失败。
- process阶段超时失败 现象：升级进度在大于等于15%持续一小时，然后升级失败，app.log存在超时相关日志打印
- finish阶段超时失败 现象：升级进度在99%持续一分钟，然后升级失败，app.log存在超时相关日志打印