Hi3093开发板升级HPM包后报错问题分析与解决

问题描述

在通过网页端对 Hi3093开发板 升级 HPM 固件包后，虽然可以通过串口登录系统，但持续出现如下报错，并触发自动重启：

1970-01-01 00:03:18.753888 maca ERROR: init.lua(185): [qemu_mockup]StartupCheck failed, 
error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.qemu_mockup was not provided by any .service files, check count: 1
...
1970-01-01 00:04:33.947329 maca ERROR: init.lua(185): [qemu_mockup]StartupCheck failed, 
error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.qemu_mockup was not provided by any .service files, check count: 6

环境信息

• 硬件平台：Hi3093 开发板（如 Milr Hi3093 或 Mirr Hi3093）
• 软件版本：OpenUBMC 2512
• 操作方式：通过 Web UI 执行带外通道的 HPM 包升级
• 现象特征：
  • 系统时间显示为 1970-01-01（Unix 时间起点），表明 RTC 时间未正确初始化或系统未能完成完整启动流程
  • 报错中涉及 D-Bus 服务找不到模块 bmc.kepler.qemu_mockup
  • 错误重复6次后触发自动重启（符合系统健康检查机制）

根本原因分析

根据上下文信息和报错日志内容，可确定以下几点：

1. 报错服务 qemu_mockup 的来源

• qemu_mockup 是一个用于 QEMU 虚拟仿真环境的模拟驱动服务，属于 openUBMC 的仿真测试组件。
• 在真实硬件（如 Hi3093 开发板）上运行时，该服务 不应被启用或依赖。
• 此错误表明：系统尝试加载仅适用于 QEMU 仿真的组件，但在物理设备上无法找到对应服务文件。

2. 可能原因剖析

解决方案

方案一：确认是否误用了 QEMU 仿真固件包

核心判断点：您当前刷写的 rootfs_openUBMC.hpm 是否是为 真实硬件（Hi3093）构建的产物？

检查方法：

1. 检查构建命令中是否启用了 QEMU 相关配置：

   bingo build -b openUBMC -qt              # ❌ 启用了 QEMU Target，不适用于真实开发板
   bingo build -b openUBMC                  # ✅ 正确，针对真实硬件构建
   

2. 检查输出包路径：
   • QEMU 专属包路径通常为：manifest/output/packet/inner/*.cpio.gz
   • 真实硬件 HPM 包路径应为：manifest/output/rootfs_openUBMC.hpm

解决步骤：

• 重新构建标准 HPM 包：

  cd manifest
  bingo build -b openUBMC -r openubmc_dev   # 构建适用于真实硬件的 HPM 包
  

• 使用生成的 rootfs_openUBMC.hpm 文件进行升级。

方案二：清理并重新烧录系统

由于当前系统已处于异常状态（时间错误 + 服务缺失），建议执行彻底恢复流程。

步骤如下：

1. 通过 SD 卡或 TFTP 方式重新烧写完整镜像

   • 参考：《[Community Hi3093 Development Board Onboarding Guide]》
   • 支持方式包括：
     • 使用 TFTP 加载 rootfs_BMC.img（KG 中提及 TFTP 是有效上传方式）
     • 使用 SD 卡备份恢复（KG 提到推荐使用 SD Card Backup 恢复）
     • 使用脚本 Hi3093_upgrade.sh 执行 emmc 更新

2. 确保进入 U-Boot 阶段进行正确引导配置

   • 在启动时按任意键进入 U-Boot 菜单
   • 确认启动参数指向正确的内核和根文件系统：

     bootcmd=run mmc_boot
     mmc_boot= mmc read ${loadaddr} 0x800 0x3000; bootm ${loadaddr}
     

3. 烧录完成后，执行一次 HPM 固化操作

   • 将系统完全写入 eMMC，防止下次重启丢失状态：
     • 登录网页 → 系统管理 > 固件更新
     • 上传 HPM 包 → 执行升级
     • 见文档：“升级一次 hpm 包，会把内核文件等烧录到 emmc 中”（搜索结果1）

方案三：排查构建环境与配置一致性

根据 KG 和文档内容，需确保构建环境符合要求：

检查项清单：

示例正确构建流程：

# 启动容器（使用标准生产环境镜像）
docker run -it --privileged --network host \
  -v $(pwd):/home/workspace \
  swr.cn-north-4.myhuaweicloud.com/openubmc/ubuntu:24.04.2_25.09 /bin/bash

# 初始化项目
python3 init.py -path ./bmc_sdk.zip -user USER -psw PASSWORD

# 执行构建（禁止启用 QEMU 相关参数）
bingo build -b openUBMC -r openubmc_dev

预防措施与建议

总结

本次问题的根本原因是：将含有 QEMU 仿真依赖组件（qemu_mockup）的固件包误刷到了真实的 Hi3093 开发板上，导致系统试图加载不存在的服务，从而不断报错并重启。

最终解决方案：

1. 停止使用带有 qemu_mockup 的仿真 HPM 包
2. 重新使用标准构建命令生成适用于 Hi3093 的 HPM 包
3. 通过 TFTP 或 SD 卡方式彻底重刷系统
4. 完成升级后执行 HPM 包固化以确保持久化

如此即可恢复正常运行，避免再次出现 D-Bus 服务缺失问题，并支持重复升级 HPM 包。

延伸阅读推荐：

• 《Hi3093开发板上手教学》——掌握标准烧录流程
• Firmware Upgrade Process 安全机制说明 ——保障升级可靠性
• Shenwei(百信) 提供的构建实践建议 ——社区权威指导

相关链接：

1. 真实板卡升级phm固件包，提示无效的升级包
2. Hi3093开发烧写后无法启动，报CRC错误
3. bingo build报错，任务 work.build.conan 执行失败
4. 2509版本hpm包导致403 (Forbidden)
5. openUBMC