最近在搞IMX6ULL的Linux驱动手头板子不太够用就想着先搭一套QEMU模拟环境。折腾了两天终于把内核、根文件系统跑起来驱动模块也能正常加载卸载。这个过程里踩了不少坑网上资料又比较零散索性把完整的搭建流程、参数选择和排错方法整理成文给同样在磕linux驱动开发的朋友做个参考。这篇内容适合两类人一是手里暂时没有IMX6ULL板子想先用模拟环境熟悉驱动框架、设备树流程的二是已经有真实板子但想先搭一套“自带断点”的开发环境方便快速验证内核配置和模块逻辑的。QEMU模拟器不是万能的它替代不了真板上的寄存器级调试但把“能跑起来的系统基线”准备好之后你会发现后续开发效率会高很多。1. 为什么要在QEMU里搭IMX6ULL环境1.1 QEMU能做什么不能做什么IMX6ULL是NXP基于Cortex-A7内核设计的嵌入式处理器常用于工业控制、物联网网关这类场景。真板子学习成本不低尤其对于刚接触Linux驱动的人来说最怕的是“板子还没点亮人先不想动了”。QEMU能模拟出ARMv7-A架构的CPU、中断控制器、定时器、串口、网卡、GPIO控制器等基础外设跑一个完整的Linux内核完全没问题。但要认清一个边界QEMU不是把整个IMX6ULL芯片上的所有IP都模拟了。它模拟的外部设备数量有限很多寄存器行为也只是“看起来像”并不完全和手册一致。比如GPU、CSI摄像头、部分音频接口在这些QEMU版本里基本用不了。好在驱动开发最基础的内容——字符设备、平台设备驱动、设备树匹配、中断申请、定时器、网络接口这些在模拟器上都能完整体验所以用来搭环境是非常合适的。1.2 方案选型选哪个machine用哪套源码QEMU从较新版本开始内置了MCIMX6UL EVK开发板的模拟支持对应的machine名是mcimx6ul-evk。用-machine mcimx6ul-evk就能拉起一个带IMX6UL/IMX6ULL基本外设的虚拟开发板。源码方面我建议直接用NXP官方Linux内核或者国产板卡厂商比如正点原子、野火提供的SDK源码不要自己去mainline上随便找一份无关配置。原因是NXP对自己的BSP内核对芯片外设和板级配置很熟悉设备树和defconfig都已经调好QEMU环境下稍作改动就能引导起来。工具链和文件系统方面最省事的组合是arm-linux-gnueabihf-gcc做交叉编译busybox做一个最小根文件系统。后续要扩展驱动、装工具再往rootfs里拷就行。2. 基础环境准备工具链、U-Boot与内核源码2.1 交叉编译工具链安装在Ubuntu等Debian系系统上安装命令很简单sudo apt install gcc-arm-linux-gnueabihf装完后确认版本arm-linux-gnueabihf-gcc --version为什么选arm-linux-gnueabihf而不是arm-linux-gnueabiIMX6ULL的Cortex-A7内核自带硬件浮点单元VFPv4hf版本使用硬浮点ABI编译出来的程序性能和兼容性都更好。虽然对于内核本身来说用哪个工具链都能编过但后续编译用户态程序时差别就出来了。所以这一步直接选hf版本省得后面换工具链。如果你的系统里提示没有这个包可以先把源更新一下sudo apt update sudo apt install gcc-arm-linux-gnueabihf2.2 U-Boot、内核源码获取与版本选择U-Boot和内核源码建议直接找NXP SDK或者板卡厂商的release包。很多厂家的BSP包是基于NXP官方代码打上自己板级补丁的里面已经包含了IMX6ULL的defconfig和设备树源文件这样你就不需要自己从头适配新的板级文件。我用的是5.x内核NXP的BSP分支里一般有对应的imx_v7_defconfig或者厂商自己的defconfig。如果你用的是正点原子或野火的源码它们通常会提供一个类似mx6ull_14x14_evk_defconfig的U-Boot配置和一个完整的内核配置。拿回来后先整体读一下arch/arm/configs/目录找到对应的配置名再继续编译。内核编译前需要安装几个依赖包否则会在menuconfig阶段或者编译过程中报错sudo apt install bc bison flex libssl-dev libncurses5-dev这几个缺一不可。尤其是libssl-dev新版内核编译时如果没有它可能在生成证书文件时报错卡在最后一步。2.3 关于U-Boot到底跑不跑搭建QEMU环境时有一个选择要不要先跑U-Boot再由U-Boot引导内核。我的建议是第一轮搭建先跳过U-Boot直接让QEMU把内核和设备树加载起来。原因很简单QEMU对IMX6ULL的启动模拟和真实板卡的启动流程有差异NXP官方U-Boot在QEMU里不一定能顺利跑起来。先把“内核设备树根文件系统”这条主线打通再回来处理U-Boot排查问题会容易得多。毕竟驱动开发的重点在内核层U-Boot只是二次开发的引导器。3. 编译内核、设备树与最小根文件系统3.1 编译zImage和设备树拿到内核源码后先进入源码根目录。我这里的操作以NXP/厂商分支为例export ARCHarm export CROSS_COMPILEarm-linux-gnueabihf- make imx_v7_defconfig make -j$(nproc) zImage dtbs注意两点第一ARCHarm是告诉内核编译系统目标是ARM架构CROSS_COMPILE指定交叉编译工具链前缀这两个环境变量少了任何一个都会编出错误架构的二进制第二设备树目标要不要指定具体文件取决于你的defconfig。如果默认配置下编译不过可以先只编zImage再单独编imx6ull-14x14-evk.dtb。编译成功后重点检查这些产物arch/arm/boot/zImage内核镜像arch/arm/boot/dts/imx6ull-14x14-evk.dtb设备树二进制如果你用的是野火或正点原子源码dtb名字可能是imx6ull-14x14-evk-emmc.dtb这类自己按实际生成的文件来。3.2 用busybox制作最小rootfs有了内核还不行Linux启动后总得有个根文件系统否则会直接panic。我用busybox做最小rootfs。先去busybox官网下载一个稳定版本解压后配置make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig在menuconfig里找到Settings - Build static binary (no shared libs)勾上。静态编译可以让busybox不依赖动态库后续拷到rootfs里少很多麻烦。然后编译安装make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j$(nproc) make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- install CONFIG_PREFIXrootfs这条命令会把busybox的文件装到rootfs/目录下。随后手工创建系统必需目录mkdir -p rootfs/{dev,etc,lib,proc,sys,tmp,var,mnt}在rootfs/etc/inittab文件里写最基本启动脚本目的是让内核起来后能自动挂载虚拟文件系统、执行rcS脚本。rcS脚本里设置主机名、挂载/proc、/sys、/dev以及用mdev做设备节点管理。#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev echo /sbin/mdev /proc/sys/kernel/hotplug mdev -s注意rootfs里的dev/console节点最好提前创好否则串口可能没输出sudo mknod rootfs/dev/console c 5 1最后用dd和mkfs.ext2生成一个根文件系统镜像dd if/dev/zero ofrootfs.ext2 bs1M count128 mkfs.ext2 -d rootfs rootfs.ext2这里的128M对最小系统来说足够了QEMU给虚拟机分配的内存我习惯设512M不会有什么压力。3.3 第一次启动内核编译产物都准备好后就可以用QEMU启动了。这一步先用最简单的方式验证内核和文件系统有没有问题先别管网络和复杂参数qemu-system-arm \ -machine mcimx6ul-evk \ -m 512M \ -kernel zImage \ -dtb imx6ull-14x14-evk.dtb \ -drive filerootfs.ext2,formatraw,ifsd \ -append consolettymxc0,115200 root/dev/mmcblk0 rw rootwait \ -nographic看到内核打印、挂载rootfs、进入shell交互说明主线已经通了。如果卡在“VFS: Cannot open root device”多半是root参数写错或者rootfs.ext2没有正确生成。后面在第6章我会把常见问题集中列出来。4. QEMU启动参数详解与网络文件挂载4.1 启动参数拆解上面那段命令看着长每个参数都有说法。逐个说-machine mcimx6ul-evk指定虚拟开发板型号。-m 512M给虚拟机分配512MB内存。-kernel zImage告诉QEMU直接加载这个内核镜像不走板载ROM引导。-dtb imx6ull-14x14-evk.dtb加载设备树二进制。-drive filerootfs.ext2,formatraw,ifsd把rootfs.ext2映射成一个SD卡设备内核启动后看到的是/dev/mmcblk0。-append consolettymxc0,115200 root/dev/mmcblk0 rw rootwait传给内核的启动参数。IMX6ULL的调试串口就是ttymxc0波特率115200rootwait确保系统等待SD卡设备完全就绪后再挂载根文件系统不加这个参数很容易出现挂载超时。-nographic把QEMU的输出重定向到当前终端同时也把键盘输入转发给虚拟串口。调试环境下最方便。如果你后面要从虚拟机里退出按CtrlA然后按x。4.2 user网络、tap网络与NFS根文件系统模拟环境跑起来只是第一步实际开发中肯定要让“开发板”和宿主机共享文件或者直接通过网络挂载根目录。QEMU的mcimx6ul-evk默认支持网络设备最常见的是e1000或者virtio-net。启动命令里可以加-netdev user,idnet0 \ -device e1000,netdevnet0user模式网络是QEMU自带的用户态网络栈虚拟机里会有10.0.2.x的子网宿主机是10.0.2.2。这种模式下虚拟机可以访问宿主机也能上外网只要宿主机能上但宿主机不能主动连接虚拟机。对于跑NFS客户端挂载来说够用了。在虚拟机里执行mount -t nfs -o nolock 10.0.2.2:/home/user/share /mnt就能把宿主机目录挂到开发板里。为什么要加nolockQEMU的user网络对NFS锁协议支持并不完整如果宿主机NFS配置严格不加并且不加nolock会卡在挂载上。实测下来加上这个选项最稳定。如果你更习惯让虚拟机网络跟宿主机在一个局域网里可以用tap模式-netdev tap,idnet0,ifnametap0,scriptno \ -device e1000,netdevnet0tap模式要求宿主机上提前创建好tap0虚拟网卡并做网桥或路由配置。好处是虚拟机直接有局域网IP可以用SSH连进去文件传输更方便。缺点是配置稍繁琐新手可以先从user模式开始。4.3 开发板挂载Ubuntu目录的两种方式除了启动后手动mount我更推荐直接让内核把根文件系统挂到NFS上这样每次改完驱动、编译完模块宿主机上同步即可不用反复打包rootfs镜像。启动参数改成root/dev/nfs nfsroot10.0.2.2:/home/user/nfsroot,vers3,tcp rw ipdhcp前提是宿主机配置好NFS服务导出好NFS目录并且这个目录里要有一份完整的rootfs即之前做的busybox rootfs拷贝过来。对这个方案虚拟机用user网络基本都能跑通。实际经验里NFS挂载比SD卡启动方式更适合驱动开发你在宿主机上交叉编译出一个.ko文件直接拷到共享目录开发板立刻就能加载这个新模块省掉了每一步都重新生成rootfs和重启的等待时间。5. 在QEMU里做第一个驱动实验5.1 最简单的字符设备驱动现在到了重头戏写一个可以在模拟器里实际加载和测试的驱动。先从一个最小的hello驱动开始。这是验证整套交叉编译、模块加载、dmesg输出链路最直接的方法。新建hello.c#include linux/init.h #include linux/module.h #include linux/kernel.h static int __init hello_init(void) { printk(KERN_INFO hello: module loaded\n); return 0; } static void __exit hello_exit(void) { printk(KERN_INFO hello: module unloaded\n); } module_init(hello_init); module_exit(hello_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(QEMU hello driver);Makefileobj-m : hello.o KDIR : /path/to/your/kernel/source CROSS_COMPILE : arm-linux-gnueabihf- ARCH : arm all: $(MAKE) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) -C $(KDIR) M$(PWD) clean编译得到hello.ko后拷到虚拟机的rootfs或者NFS共享目录里然后执行insmod hello.ko dmesg | tail rmmod hello看到hello: module loaded和hello: module unloaded两行输出就说明从工具链到内核符号解析、模块加载器、日志系统的链路全部正常。很多新手在这一步会卡住比如insmod时报Invalid module format原因通常是对应内核源码版本和运行的内核版本不一致或者没在内核源码根目录执行过make。解决方法是确保板子上运行的内核就是你编译模块时用的那一份源码编出来的不要用两份不同配置的内核环境。5.2 结合设备树的platform驱动思路hello驱动跑通后可以试试稍微复杂一点的platform驱动。开发板上的外设驱动很多是以platform_driver的形式存在的内核根据设备树里的compatible字段找到对应驱动然后执行probe函数。QEMU对IMX6ULL的设备树节点是支持的所以你可以写一个platform驱动在probe里打印设备节点名字以此验证设备树与驱动匹配流程。这对后续移植自己的外设驱动很有帮助。比如驱动里注册一个platform_driver用of_match_table指定一个compatible值然后你在设备树里新增一个测试节点同样写上这个compatible内核启动后就能自动匹配并调用probe。需要注意的是QEMU只模拟了部分外设控制器比如FEC网卡、UART、GPIO、SD控制器、I2C等。如果你要跑的驱动涉及具体寄存器操作比如某种专用ADC芯片QEMU里没有对应的硬件模型probe跑到一半可能就会访问异常或者超时。这种情况下别急着怀疑代码先确认QEMU是否模拟了这个外设。我的建议是模拟环境里重点跑通驱动的框架和逻辑寄存器级验证放到真板上再做。另外如果你关注Linux DSA switch驱动这类网络交换芯片驱动在QEMU里能做的主要是熟悉DSA框架和虚拟网卡链路因为QEMU本身没有模拟具体的DSA交换芯片。真正调试DSA与交换芯片交互的部分还是离不开真实硬件或至少需要更复杂的FPGA仿真环境这里提前有心理预期。6. GDB调试与常见问题排查6.1 让QEMU自带断点GDB远程调试模拟器最大的优势就是可以随时暂停、断点、单步。QEMU支持把虚拟机的CPU状态通过GDB调试协议暴露出来宿主机上用gdb直接连上去就能调试内核和驱动。启动QEMU时额外加两个参数qemu-system-arm \ -machine mcimx6ul-evk \ -m 512M \ -kernel zImage \ -dtb imx6ull-14x14-evk.dtb \ -drive filerootfs.ext2,formatraw,ifsd \ -append consolettymxc0,115200 root/dev/mmcblk0 rw rootwait nokaslr \ -nographic \ -s -S-s表示在宿主机1234端口开放GDB调试接口-S表示CPU在启动前先暂停住等调试器连接后再开始执行。nokaslr可以关掉内核地址随机化避免调试时打不上断点。然后在另一个终端启动gdbgdb-multiarch file vmlinux target remote :1234这里用到的vmlinux是带符号表的内核映像文件就在内核源码根目录下。连接成功后你就可以设置硬件断点hb start_kernel continue如果你想调试一个具体的驱动函数可以先加载模块或者直接把驱动编译进内核用符号名下断点。VSCode配置也不复杂在launch.json里写{ type: cppdbg, request: launch, name: qemu-gdb, program: ${workspaceFolder}/vmlinux, miDebuggerServerAddress: localhost:1234, miDebuggerPath: /usr/bin/gdb-multiarch, cwd: ${workspaceFolder}, stopAtConnect: true }用VSCode的好处是能看到源码、寄存器窗口、变量实时值调试驱动时比单纯用命令行舒服很多。不过要注意调试加载成模块的驱动时gdb里要先lx-symbols之类的脚本加载模块符号这部分需要额外配置新手可以先从调试内核启动代码入手。6.2 常见问题速查表这段时间在搭建环境上踩过的坑不少整理成一张速查表方便你直接对照排查。现象可能原因解决办法QEMU启动后串口没有任何输出启动参数没指定console或者console指定错误确认使用consolettymxc0,115200且设备树串口节点正常内核启动后挂载rootfs失败提示VFS Cannot open root deviceroot参数写错或rootfs.ext2没生成成功检查root/dev/mmcblk0 rw rootwait用lsblk在板子里查看设备名insmod时报Invalid module format模块编译用的内核源码版本和运行内核不一致用同一个内核源码编译模块并保证内核config一致网络不通ping外网失败user网络或驱动没起来e1000设备树没匹配启动参数加netdev user,idnet0确认内核配置包含e1000驱动NFS挂载卡死user模式下NFS v3协议支持不全加-o nolock宿主机NFS导出目录加insecure选项内核启动卡在Starting kernel后无反应设备树和内核不匹配或内存地址冲突确认dtb与kernel源码同源必要时追加mem512M参数敲键盘终端没有反应没有加-nographic或者串口输入没有正确重定向使用-nographic按CtrlA再按C可以切换控制台GDB连上后continue就崩溃内核地址随机化影响断点启动参数加nokaslr编译内核时缺文件报错缺少必要依赖包安装bc bison flex libssl-dev libncurses5-devrootfs挂载成功后没有shellinittab或rcS脚本没配置好确认/etc/inittab存在并且包含了::respawn:-/bin/sh类似条目这张表里有些问题在真板子上也会遇到比如内核与模块版本不匹配、设备树节点缺失、NFS挂载超时。在模拟器里先排过一遍真板子上你会省很多时间。7. 最后的几个建议我这里再补充几个自己调试过程中的体会。串口日志永远是你最忠实的伙伴。QEMU环境不像真板子容易烧录flash改错东西大不了重启一下所以可以大胆加printk不要怕刷屏。等程序稳定了再慢慢删。很多驱动问题都是信息不足导致反复猜测打印多了自然找到规律。QEMU模拟器和真实IMX6ULL板之间的差异主要在实时性和外设细节上。你的驱动在模拟器里跑通不代表真板子上也能每秒处理那么多数据但至少代码逻辑、资源申请顺序、设备树匹配这些是不会变的。所以把模拟环境定位成“逻辑验证平台”最合适不要指望它能替代一切硬件验证。最后再建议一点一旦主线系统能跑起来马上做一个方便回滚的脚本把编译内核、生成rootfs、启动QEMU这几个动作固化成命令行这样以后再写驱动、调bug重来一遍环境也就一两分钟的事。很多人折腾半天环境没搭好就耗在重复手工步骤上了自动化起来后面会轻松很多。
