上周有个同事跑过来问我AST2600的板子还没到货能不能不买硬件就把OpenBMC环境搭起来我说能而且比你想象的简单。用QEMU模拟AST2600-EVB开发板是OpenBMC开发里性价比最高的起步方式之一——不用等硬件、不怕折腾坏、随时可以重建环境。本文带你走一遍完整的OpenBMC环境搭建全流程确认QEMU支持、获取官方镜像、启动虚拟开发板、进入系统验证再深入到自己编译镜像和调试技巧。过程中我会把每条命令为什么这么写、每个参数到底在干什么讲清楚最后再分享几个实际使用中踩过的坑。1. 为什么我建议先用QEMU跑OpenBMC而不是等真实板子1.1 真实项目里的窘境板子永远不够用做BMC固件开发最怕的就是手边没有硬件。真实项目里AST2600的EVB板通常只有一两块固件开发、内核调试、Redfish/BMC服务开发、系统测试全都要用。你烧了一个镜像进真实板子发现启动卡住了想调得先找个JTAG工具恢复另外一位同事也想用板子你只能排队。这种场景重复几次之后我养成了一个习惯能先在QEMU里跑通的流程绝不动真实板子。QEMU对AST2600-EVB的支持并不是糊弄人的那种。OpenBMC社区自己就大量依赖QEMU做CI测试也就是说模拟环境跑出来的结果和真实板子在90%以上的常规场景下是一致的。对学习OpenBMC、开发BMC应用、验证镜像定制这套模拟环境完全够用。1.2 AST2600-EVB在QEMU里到底模拟了哪些东西AST2600是Aspeed推出的服务器管理专用SoC内部集成双核ARM Cortex-A7处理器主打BMC场景。QEMU的ast2600-evb机器属于aspeed machine family它模拟的硬件包括双核ARM Cortex-A7 CPU和中断控制器DDR内存控制器板载UART串口OpenBMC的console输出就走这里两个百兆/千兆MAC网络控制器SPI Flash控制器OpenBMC镜像烧录的载体I2C控制器、PWM、ADC、GPIO等基础外设换句话说OpenBMC用户态程序依赖的那些硬件基础QEMU基本都覆盖了。所以你能在模拟环境里完整看到U-Boot启动、Kernel启动、systemd拉起服务、DBus服务注册这些全流程。对于环境搭建和基础开发来说这些已经足够。1.3 模拟环境的边界哪些能学、哪些学不到QEMU不是万能的提前知道边界能少走很多弯路。我的建议是下面这些任务放心交给模拟环境适合在QEMU里做的事不适合/做不了的事OpenBMC的编译、镜像定制、烧录流程验证真实传感器硬件温度、电压读数U-Boot和Kernel启动流程分析、早期调试JTAG硬件调试、信号时序分析systemd服务、DBus接口、Redfish接口开发真实外设插拔、电源时序控制WebUI界面截图、Redfish API验证、日志分析高强度压力测试、真实网络吞吐测试多节点同时开发、自动化CI回归验证硬件勘误、特定芯片版本的errata搞清楚这些边界你就明白QEMU不是替代真实板子而是把那些不依赖特定真实外设的开发工作提前做掉。真到板子到手你已经把软件层面的问题全部清完了。2. 开工前先别急着敲命令版本、镜像、依赖一个都不能错2.1 先确认你的QEMU带不带ast2600-evb机器很多新手上来就apt install qemu-system-arm然后告诉我启动报错了。一问版本Ubuntu 20.04自带的QEMU 4.2根本没有ast2600-evb这个machine。AST2600的支持是QEMU在6.2版本左右合入的所以第一步是确认版本qemu-system-arm --version qemu-system-arm -M help | grep -i ast正常情况下你会看到ast2500-evb ast2600-evb如果grep出来只有ast2500-evb说明QEMU版本太老请升级QEMU再继续。这里有个容易犯的认知误区AST2600虽然是ARM Cortex-A732位但要用qemu-system-arm不是qemu-system-aarch64。我见过有人拿着aarch64的QEMU去跑AST2600镜像折腾半天不知道问题在哪。升级QEMU建议直接用官方源或者编译安装具体方式看你的发行版。Ubuntu 22.04自带的QEMU 6.2已经支持如果不想折腾直接换到22.04系统是最省事的。2.2 获取OpenBMC预编译镜像新手首选别一上来就自己编译环境搭建阶段我强烈建议先从OpenBMC官方发布的预编译镜像开始不要一上来就自己跑bitbake。原因很简单OpenBMC首次编译少则两三个小时多则五六个小时以上中间还会遇到各种网络、依赖问题对新手劝退感极强。先把现成镜像跑起来建立整体认知再回头学编译效率高得多。去OpenBMC的GitHub Releases页面找对应版本的发布包下载里面带有ast2600-evb字样的镜像压缩包。解压之后你通常会看到一个或多个raw格式的镜像文件比如flash0、image-bmc或者一个.static.mtd结尾的文件有的版本会附带一个启动脚本比如start-qemu.sh或类似名字不同版本的命名习惯略有差异但核心就一句话这些文件最终会通过QEMU的MTD驱动挂到模拟的SPI Flash上。如果解压包里有启动脚本先看脚本内容它会告诉你官方推荐的启动参数是什么。这里再强调一次不要下载ast2500-evb的镜像塞到ast2600-evb的machine里跑两个SoC内存映射和外设地址不一样大概率启动异常。2.3 宿主机依赖安装不需要KVM但需要这些基础软件QEMU模拟ARM属于跨架构模拟走的是TCGTiny Code Generator动态翻译不依赖KVM虚拟化加速。这一点和跑同架构虚拟机不一样所以在普通PC、虚拟机、甚至部分云主机上都能跑。但这不代表可以裸奔下面这些依赖还是要装# Ubuntu / Debian sudo apt-get update sudo apt-get install -y qemu-system-arm unzip xz-utils tmux # Fedora / RHEL系列 sudo dnf install -y qemu-system-arm unzip xz此外如果你想用GDB调试OpenBMC早期启动建议再装一个gdb-multiarch后面第6章会详细讲。装依赖这部分没什么技术含量但它决定了后面几步是否顺利别跳过去。3. 跑通虚拟开发板一条QEMU命令逐段拆给你看3.1 优先使用官方脚本但也别只会双击运行如果你下载的发布包里带脚本比如start-qemu.sh先直接跑一次。脚本能跑通说明你的镜像和QEMU版本匹配正常。但我建议你务必打开脚本看一眼里面的命令。很多所谓“环境问题”其实就是镜像与QEMU版本不匹配或者参数写错看官方脚本是最快的学习路径。我平时搭建环境的命令大概长这样不同版本可能略有差异qemu-system-arm -M ast2600-evb \ -m 512M \ -nographic \ -drive fileflash0,formatraw,ifmtd \ -drive fileimage-bmc,formatraw,ifmtd \ -net nic \ -net user,hostfwdtcp::2222-:22,hostfwdtcp::8080-:80如果你的发布包只有一个.static.mtd文件可以试试用一条-drive把它挂上去OpenBMC的发布包结构在不同版本之间有差异这条命令不一定是万能钥匙但思路是一致的。3.2 参数逐段解释每个配置为什么必须要有这条命令看起来长其实拆开来很清晰参数作用为什么需要-M ast2600-evb指定模拟的开发板型号告诉QEMU按AST2600 EVB的内存布局和外设创建虚拟机-m 512M指定内存大小EVB板常见内存配置是512MB或1GB具体看你的镜像需求-nographic把串口输出接到当前终端OpenBMC启动日志走串口不设这个看不到登录提示符-drive fileflash0,formatraw,ifmtd挂载第一个SPI Flash镜像flash0一般存放U-Boot引导程序-drive fileimage-bmc,formatraw,ifmtd挂载BMC主镜像OpenBMC的根文件系统就在这里面-net nic创建一张虚拟网卡让BMC侧能看到eth0网络接口-net user,hostfwd...用户态网络栈并做端口转发宿主机通过localhost:2222访问BMC的SSH通过localhost:8080访问BMC的WebUI这里特别说明一下ifmtd。BMC的固件是放在SPI Flash上的QEMU的aspeed machine把ifmtd的drive映射到模拟的SPI Flash控制器上这和普通虚拟机的硬盘驱动路径完全不同。如果你图省事改成ifsd或ifvirtioOpenBMC根本找不到启动介质直接卡死在U-Boot阶段。3.3 观察启动日志看到什么样的输出才算成功执行上面那条命令之后你会看到一串启动日志正常的顺序是U-Boot阶段开头能看到ASPEED相关的版本信息然后U-Boot加载环境变量、初始化DDR、搬运内核到内存。Linux Kernel阶段输出大量内核日志能从Booting Linux on physical CPU 0x0看到内核开始执行。systemd用户态启动阶段OpenBMC的各个服务逐个启动PDI、DBus、网络服务等。最终出现登录提示符ast2600-evb login:看到这个提示符说明你的QEMU模拟环境基本搭建成功了。这时候输入root回车就能登录进去OpenBMC默认root账号没有密码。如果你卡在某一步比如U-Boot输出完就停住不再动了或者Kernel启动过程中报No working init found先别急着怀疑QEMU优先检查镜像文件和machine类型是否匹配。后面第6章会专门讲排查方法。4. 进系统之后干什么登录、网络配置、基础验证三板斧4.1 串口控制台登录root无密码但不是所有版本都这样在ast2600-evb login:提示符下输入root直接回车就能进入OpenBMC的shell没有密码。不过要提醒一句较新的OpenBMC版本在某些镜像里可能会启用密码策略如果root直接登录被拒绝试试用空密码登录或者查一下对应Release的发布说明。登录后的提示符类似rootast2600-evb:~#。这个shell是BusyBox提供的很多命令是精简版和完整Linux发行版略有差异。比如你看到的可能是vi而不是vimps的输出格式也不太一样。但基础的cat、ls、ip、journalctl、systemctl都是可用的。4.2 网络配置一个user模式网络解决90%的联网需求QEMU的-net user网络栈实际上是一个内置的NAT网络。从BMC内部看eth0的IP通常是10.0.2.15网关是10.0.2.2。这个网络有两个特点BMC可以主动访问外网如果你想在BMC里wget下载一个文件只要宿主机有网BMC就能上网。宿主机要主动访问BMC必须走端口转发这就是hostfwd参数的作用。实际操作中我常用的访问方式# 从宿主机SSH登录BMC ssh -p 2222 root127.0.0.1 # 从宿主机浏览器访问BMC WebUI # 打开 http://127.0.0.1:8080这里有个坑hostfwd的写法是hostfwdtcp::2222-:22意思是把宿主机2222端口映射到虚拟机的22端口。冒号后面的冒号前面如果写了IP那是宿主机监听的地址不是BMC的地址。我见过有人写成hostfwdtcp::2222-10.0.2.15:22结果怎么都连不上因为10.0.2.15是虚拟网络内部的地址宿主机根本监听不到。4.3 验证环境是否健康三板斧检查法登录进去之后我建议先跑几个命令确认OpenBMC基本服务正常这一步也是对模拟环境健康度的快速体检# 查看OpenBMC版本信息 cat /etc/os-release # 查看DBus服务树确认关键服务已注册 busctl tree | head -50 # 查看本次启动日志检查有没有服务崩溃 journalctl -b | grep -i error # 查看网络地址 ip a其中busctl tree是最能体现OpenBMC特点的命令。OpenBMC的几乎所有硬件管理功能都是通过DBus服务暴露的比如传感器、电源、风扇、日志等。如果这个命令能输出一长串服务路径说明systemd和DBus总线正常工作环境搭建已经成功了一大半。另外在BMC内部可以通过HTTPS访问Redfish接口验证管理服务curl -k https://127.0.0.1/redfish/v1/Systems返回一段JSON就说明Redfish服务已经运行。到这里你的QEMU模拟环境已经是一个“能干活”的开发环境了。5. 进阶挑战自己用bitbake编译OpenBMC镜像5.1 为什么要折磨自己去编译镜像用官方预编译镜像跑通之后你迟早会发现一个需求我想改OpenBMC的代码、添加自己的应用、定制镜像配置这必须走编译。OpenBMC基于Yocto/OpenEmbedded构建系统核心工具是bitbake。第一次编译确实耗时但掌握之后你就拥有了持续产出自定义镜像的能力这是BMC开发者的分水岭。5.2 搭建bitbake构建环境克隆仓库、执行setup编译OpenBMC的推荐方式是在Linux环境里进行。官方推荐Ubuntu 20.04/22.04这类LTS版本。先克隆代码仓库git clone https://github.com/openbmc/openbmc.git cd openbmc进入仓库根目录后执行环境初始化脚本。OpenBMC仓库根目录有一个setup脚本专门用来创建特定机器的构建目录. setup ast2600-evb执行之后它会创建类似build-ast2600-evb的目录并自动切换进去同时设置好Yocto所需的全部环境变量。这一步和很多嵌入式项目的source environment-setup逻辑类似但更简洁。需要注意的开头有个点source这是必须的否则环境变量不会保留在当前shell里。5.3 启动构建并耐心等待产物在哪里环境初始化好之后执行bitbake obmc-phosphor-image这个obmc-phosphor-image是OpenBMC的完整镜像目标会构建U-Boot、Linux内核、所有OpenBMC用户态服务最后打包成可烧录的镜像文件。构建过程非常耗时建议用tmux或者nohup挂在后台避免终端断连导致中断。构建完成的产物在tmp/deploy/images/ast2600-evb/这个目录下你会看到多个文件。最核心的是.static.mtd结尾的镜像文件比如obmc-phosphor-image-ast2600-evb.static.mtd。这个文件可以直接用第3章的方法挂进QEMU启动。5.4 第一次构建容易踩的几个坑构建OpenBMC是个体力活踩坑高发区集中在三块常见问题原因解决办法构建中途报错提示缺Python模块或系统依赖宿主机缺少Yocto需要的工具链对照OpenBMC官方文档安装所有依赖包不要凭感觉装下载源码超时、校验失败Yocto会从上游拉取大量源码包网络不稳定就失败配置DL_DIR缓存目录断点续传必要时配置镜像源宿主系统太新Yocto老旧版本不兼容OpenBMC不同版本对宿主Linux版本有要求优先用Ubuntu 20.04/22.04或者直接用OpenBMC官方提供的容器镜像构建我的经验是新手第一次编译优先用OpenBMC官方文档推荐的容器方式也就是拉一个官方构建镜像把代码挂载进去编译。这样能规避掉70%的宿主环境问题。等熟悉了构建体系再迁移到本地环境也不迟。6. 启动失败怎么办高发问题排查与提升效率的调试技巧6.1 三个最高发的启动失败问题我帮人排查OpenBMC环境问题无数次下面三个问题占了我遇到情况的八成。整理成表格方便你对照现象可能原因解决办法-M help里看不到ast2600-evbQEMU版本太老升级到QEMU 6.2及以上版本启动后卡在U-Boot内核迟迟不跑flash0镜像与主镜像不匹配或者machine类型选错确认镜像来自ast2600-evb发布包检查-M参数能进登录界面但SSH连不上hostfwd参数写错或者没有配置网络检查命令里的hostfwd格式确认-net nic存在启动后终端完全没有输出忘记-nographic参数加上-nographic重新启动这里特别提醒一个隐蔽问题有人为了调试方便启动命令里加了-S参数然后忘记去掉。-S会让QEMU启动后在第一条指令处暂停等待调试器连接。如果你只是想正常跑系统看到黑屏是必然的。排查启动问题时先确认命令行里没有多余的调试参数。6.2 用GDB追OpenBMC早期启动QEMU的调试能力是真香QEMU模拟环境相比真实板子最大的优势之一就是它能无缝对接GDB调试。想追U-Boot阶段的问题在启动命令里加上-s -Sqemu-system-arm -M ast2600-evb -nographic \ -drive fileflash0,formatraw,ifmtd \ -drive fileimage-bmc,formatraw,ifmtd \ -s -S-s表示在宿主机1234端口开放GDB远程调试服务-S表示CPU启动后立刻暂停等待调试器连接然后另开一个终端gdb-multiarch u-boot (gdb) target remote :1234 (gdb) hbreak _start (gdb) continue这里有一点要注意BMC侧是32位ARM所以调试器要用gdb-multiarch不是默认的x86_64 GDB。用错GDB的报错五花八门最典型的是Architecture of file not recognized。另外U-Boot的符号文件建议从构建产物里找也就是tmp/deploy/images/ast2600-evb/目录里对应的u-boot文件直接网上随便找的U-Boot符号对不上。6.3 提升日常开发效率的几个小技巧最后分享几个我日常开发中沉淀下来的QEMU使用技巧技巧一用-snapshot参数保证环境干净。在-drive参数后面加上-snapshot选项意思是虚拟机的写入不会真正落盘每次启动都是一份“全新的镜像”。开发调试时非常有用改坏了重启一下环境瞬间回到干净状态。需要保留修改时不加这个参数即可。技巧二把启动命令写进脚本。不要每次手动敲那一长串QEMU命令。我习惯在项目目录里放一个run-bmc.sh#!/bin/bash qemu-system-arm -M ast2600-evb \ -m 512M \ -nographic \ -drive fileflash0,formatraw,ifmtd \ -drive fileimage-bmc,formatraw,ifmtd \ -net nic \ -net user,hostfwdtcp::2222-:22,hostfwdtcp::8080-:80chmod x run-bmc.sh之后一条命令启动整个环境省时省力。技巧三用tmux保持后台会话。跑编译或者长时间跑BMC测试时用tmux开个会话就算SSH断了环境也还在跑。这个习惯在真实服务器上开发同样适用。技巧四多个调试场景可以同时开多个QEMU实例。只需注意每次启动时改用不同的端口转发比如第二个实例用2223和8081避免宿主端口冲突。这一点在对比不同镜像、验证不同分支行为时特别方便。我个人现在的工作流已经固定为先在QEMU里完成镜像编译验证、启动流程验证、Redfish接口测试然后再申请真实板子。这样真实板子的使用时间大幅缩短基本一次刷机就能进入功能调试阶段。如果你刚开始接触OpenBMC我建议你也把这套流程走一遍别嫌麻烦——模拟环境前期投入的这点时间会在之后每一次调试里成倍赚回来。