// 此模板仅供参考，如果不适用可以修改
问题描述
参考Hi3093开发板上手教学的博客时，没做SD卡备份镜像操作，现在不能升级flash中的rootfs_BMC.img了，希望能解答一下，在没有sd卡备份原镜像的情况下，该如何能对flash中的rootfs_BMC.img升级呢 
答案内容由AI生成，仅供参考：
Hi3093 开发板如何更新 rootfs_BMC.img 文件系统
针对您在 Hi3093 开发板 上更新 rootfs_BMC.img 文件系统的问题，即使没有提前制作 SD 卡备份镜像，仍然可以通过标准的固件升级流程完成对 Flash 中 rootfs_BMC.img 的升级。以下是详细的指导步骤和原理说明。
问题分析
- 您参考的是《Hi3093开发板上手教学》博客。
- 该教程建议使用 SD 卡备份原始
openEuler镜像以备恢复，但这并非升级rootfs_BMC.img所必需的前提条件。 - 当前目标是：将新的
rootfs_BMC.img成功写入 Flash 存储（即 BMC 主分区）中，完成系统更新。 - 结论：无 SD 卡备份不影响正常升级流程，可直接通过标准升级机制进行操作。
正确升级 rootfs_BMC.img 的方法
根据知识库中的文档和架构设计，Hi3093 平台使用 openUBMC 固件管理体系，支持通过标准 HPM（Hot Plug Management）包或直接文件替换方式进行固件更新。
方法一：通过标准 HPM 升级包升级（推荐）
这是最安全、最标准的方式。
步骤如下：
-
构建新的
rootfs_BMC.img- 确保已基于 openUBMC 源码完成定制化编译。
- 最终输出文件位于：
temp/build_openUBMC_debug_dev/output/rootfs_BMC.img
-
打包为
.hpm固件升级包
使用签名工具链将rootfs_BMC.img打包成 HPM 格式的可升级固件：# manifest.yml 示例配置片段 gpp: files: - file: ${work_out}/rootfs_BMC.img dst: rootfs_BMC.img配置完成后，调用
bingo构建系统自动生成.hpm文件（如rootfs_BMC.hpm）。 -
启用签名服务（若启用安全升级）
若系统启用了安全验证（hpm_encrypt.enable=true），需要：- 替换根证书（
rootca.der）和吊销列表（rootca.crl） - 使用伙伴私钥对 HPM 包签名
- 替换根证书（
-
上传并升级 HPM 包
- 登录 BMC Web 界面或使用 Redfish API
- 选择“固件升级”功能
- 上传
.hpm文件并启动升级流程
-
系统自动处理升级
Firmware_Mgmt服务接收升级请求bmc_upgrade模块负责解压、校验、写入 Flash- 完成后自动重启并激活新固件
方法二：手动替换 rootfs_BMC.img 并刷新（适用于调试）
若仅需快速测试，可手动替换镜像并刷写。
步骤如下：
-
将新镜像上传至
/tmp目录scp rootfs_BMC.img root@<BMC_IP>:/tmp/Hi3093_ext4fs.img注意：按照规范，上传后建议重命名为
Hi3093_ext4fs.img，与文档 [2] 保持一致。 -
登录 BMC 系统执行升级脚本
ssh root@<BMC_IP> cd /tmp ./Hi3093_upgrade.sh该脚本会自动处理镜像写入 Flash 分区（如
/dev/mmcblk0pX）的过程。 -
等待升级完成并重启
- 升级过程中不要断电
- 系统会自动重启并加载新的
rootfs_BMC.img
关键组件与流程说明
| 组件 | 作用 |
|---|---|
Firmware_Mgmt |
核心固件管理服务，控制整个升级生命周期 |
bmc_upgrade Module |
执行 Flash 写入、验证、重启等底层操作 |
General_Hardware |
协调硬件级操作（如 SPI 读写、电源管理） |
Info Mgmt Lua |
管理升级状态、版本信息、阶段转换 |
update_ext4.cfg |
定义升级流程和组件映射关系（见文档 [2]） |
升级流程：
用户上传 → Firmware_Mgmt 接收 → bmc_upgrade 执行 → Flash 写入 → 重启激活
注意事项
| 项目 | 说明 |
|---|---|
| 无需 SD 卡备份 | SD 卡仅用于紧急恢复 openEuler 环境，不影响正常升级流程 |
| 首次升级注意兼容性 | 若从 BMC 3.xx.xx.xx 升级到 openUBMC，需确保签名一致（参考 KG 中 self-signed firmware package） |
| 保留旧版本备份 | 系统通常保留备用分区（A/B分区），支持失败回滚 |
| 避免断电 | 升级过程中断电可能导致 BMC 无法启动 |
| 密码变化 | 升级后可能需要使用新默认密码（原 Admin@aeon1 可能失效） |
参考资料
- 《Hi3093开发板上手教学》：提供基础环境准备与镜像命名规范
- 《新增产品配置》：定义
rootfs_BMC.img构建与打包规则 - 《签名包制作指导》：用于生成合法
.hpm升级包 - 知识图谱实体：
Firmware_Mgmt：管理升级全过程bmc_upgrade Module：执行 Flash 写入与重启Rootfs OpenUBMC 2 iBMC.hpm：标准升级包格式
结论
即使没有做 SD 卡备份，也可以安全地升级
rootfs_BMC.img。
只需遵循以下任一方式即可：
- 推荐：构建
.hpm签名升级包，通过 Web 或 Redfish 接口上传升级 - 调试可用：手动上传
rootfs_BMC.img并运行升级脚本
只要保证镜像正确、签名合规、升级过程不断电，即可顺利完成更新。
如需进一步帮助（如构建 .hpm 包或调试脚本），可提供更多上下文信息继续提问。
相关链接：
先确定几件事情：
1、你的串口中的日志已经出现如下的打印
2、确保你的网络配置和192.168.2.100 在同一个网段，博客里面有写
3、如果上述描述都没有问题，那很可能是电脑的网络配置有问题，建议换一台电脑去连接。之前也有开发者出现过该ip无论如何都无法ping通的情况，但换个电脑就好了。
然后回复一下你所说的没有SD的情况。在Uboot阶段是可以通过tftp的方式上传rootfs_BMC.img的，唯一的缺点是网络传输慢。你可以参考使用tftp上传dtb的方法。
您好！我在Uboot阶段是通过tftp的方式上传rootfs_BMC.img的，具体执行的是
=> setenv tftp_rootfs “tftp ${rootfs_load_addr} Hi3093_ext4fs.img”
=> run tftp_rootfs
但开发板启动后报错：
[ 3.603717] EXT4-fs (mmcblk0p3): unable to read superblock
[ 3.609578] EXT2-fs (mmcblk0p3): error: unable to read superblock
然后进入了开发板自带的系统
qemu-aarch64 login:
请问是指令执行的不对吗 如何正确替换开发板现有的rootfs_BMC.img呢？
确认一下两个事情：
1、run tftp_rootfs 执行这个之后，是否有等待10分钟以上，300多MB的内容通过tftp上传需要很长时间。
2、之后是否有执行run run_linux，这条命令中会有一个从当前烧录的img中启动的配置
您好！是的。执行run tftp_rootfs是有等待加载完成。也确实有执行run run_linux。麻烦您再解答一下呢
1 个赞
好的，谢谢您 我按照博客在flash里也有一个rootfs_BMC.img，现在tftp烧写，是不是之前那个会有影响呢
烧录了就会覆盖的。有一种可能就是你只是烧录了，但是没有用这个地址去启动。就会出现回到euler的那个系统中
您好！ 用您提供的已恢复了环境。我后续开发驱动部件过程中，应该会编译替换，请问后面正确的操作是什么呢
如何替换bmc_sdk 中的驱动 - #2，来自 ubmc_assistant 看一下这一篇帖子是否能够解决你的诉求
您好！ 不是内核驱动，主要是现在做南向驱动，有自己的.so, 需要替换的是Hi3093_ext4fs.img
将这片博客里面的 openUBMC 最后一步完成后。就不需要再管 img的事情了。后续参考 构建你的BMC | 文档中心 | openUBMC 升级你的BMC | 文档中心 | openUBMC 两篇文章构建出你自己的固件升级包，然后升级到开发板环境中就行了。后续我们都是使用.hpm 包了
好的 谢谢指导