3. 开发环境搭建：交叉编译工具链配置、模拟器（QEMU）环境搭建、调试工具（GDB）准备

好，咱们直接进入正题。做微内核设备驱动开发，第一件事不是写代码，而是把“家伙事儿”备齐。我见过太多新手一上来就撸代码，结果编译不过、跑不起来、调试不了，最后卡在环境问题上好几天。说白了，环境搭不好，后面全是白费功夫。

这一章，我会带你一步步把三样核心工具搞定：交叉编译工具链、QEMU 模拟器、GDB 调试器。这三样配齐了，你就能在笔记本上模拟整个嵌入式环境，不用买开发板也能干活。

3.1 交叉编译工具链配置

先说说为什么需要交叉编译。你的开发机是 x86 架构，但微内核跑在 ARM 或 RISC-V 上。你想想看，x86 编译出来的二进制，ARM 能认识吗？当然不能。所以我们需要一套能在 x86 上生成 ARM 指令的工具链——这就是交叉编译工具链。

我个人习惯用 GNU Arm Embedded Toolchain，稳定、社区活跃、文档齐全。我记得第一次配置时踩了个坑：版本选错了，导致链接时一堆 undefined reference。后来我学乖了，统一用 gcc-arm-none-eabi-9-2020-q2-update 这个版本，后面再没出过问题。

3.1.1 下载与安装

去 ARM 官网下载对应你操作系统的版本。以 Ubuntu 为例，我推荐直接解压到 /opt 目录：

# 下载（以 x86_64 Linux 为例）
wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/9-2020q2/gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2

# 解压到 /opt
sudo tar xjf gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2 -C /opt/

# 添加环境变量
echo 'export PATH=$PATH:/opt/gcc-arm-none-eabi-9-2020-q2-update/bin' >> ~/.bashrc
source ~/.bashrc

验证一下是否装好了：

arm-none-eabi-gcc --version

如果看到版本信息，说明工具链已经就绪。

小提示： 如果你用的是 macOS，可以用 Homebrew 安装：brew install arm-none-eabi-gcc。但注意，brew 的版本可能不是最新的，我个人还是建议手动下载。

3.1.2 验证交叉编译

写一个最简单的 C 文件测试一下：

// test.c
int add(int a, int b) {
    return a + b;
}

然后交叉编译：

arm-none-eabi-gcc -c test.c -o test.o
arm-none-eabi-objdump -d test.o

你会看到 ARM 指令集的反汇编输出，比如 add r0, r0, r1 之类的。嗯，看到这个就对了，说明你的工具链能正确生成 ARM 代码。

注意： 千万不要用本地的 gcc 去编译嵌入式代码！我曾经见过有人用 gcc -c test.c 编译，然后放到 QEMU 里跑，结果当然是段错误。交叉编译器的前缀 arm-none-eabi- 一定要写对。

3.2 QEMU 模拟器环境搭建

QEMU 是个好东西。它能在你的笔记本上模拟出一块完整的开发板，包括 CPU、内存、外设。说白了，你不需要买硬件，就能跑微内核、调试驱动。

我选的是 QEMU 模拟 ARM Versatile Express 开发板（简称 vexpress）。这个板子的外设模型比较全，适合做驱动开发练习。

3.2.1 安装 QEMU

Ubuntu 上直接 apt 安装：

sudo apt update
sudo apt install qemu-system-arm

验证安装：

qemu-system-arm --version

如果看到类似 QEMU emulator version 6.2.0 的输出，就说明装好了。

3.2.2 准备内核镜像与设备树

要让 QEMU 启动微内核，你需要两样东西：内核镜像（zImage）和设备树文件（.dtb）。

以我们课程用的微内核为例，编译后会生成 kernel.elf。但 QEMU 通常需要 zImage 格式。你可以用 objcopy 转换：

arm-none-eabi-objcopy -O binary kernel.elf kernel.bin

设备树文件描述硬件信息，比如内存大小、外设地址等。vexpress 板子的设备树可以从 Linux 内核源码中提取，或者直接用 QEMU 自带的：

# 查看 QEMU 支持的机器列表
qemu-system-arm -M vexpress-a9 -machine help

# 使用默认设备树
qemu-system-arm -M vexpress-a9 -dtb vexpress-v2p-ca9.dtb
小提示： 如果你不想折腾设备树，可以用 -machine vexpress-a9 参数让 QEMU 自动生成。但做驱动开发时，我建议还是显式指定设备树，这样你能控制外设的地址映射。

3.2.3 启动微内核

一切准备就绪后，启动命令如下：

qemu-system-arm \
    -M vexpress-a9 \
    -m 128M \
    -kernel kernel.bin \
    -nographic \
    -append "console=ttyAMA0"

参数说明：

  • -M vexpress-a9：指定模拟的机器类型
  • -m 128M：分配 128MB 内存
  • -kernel kernel.bin：指定内核镜像
  • -nographic：不使用图形界面，用串口输出
  • -append：传递内核启动参数

如果一切正常，你会看到串口输出微内核的启动信息。嗯，看到那个 Hello from Microkernel! 的时候，说明环境已经跑通了。

注意： 如果 QEMU 启动后没有任何输出，先检查串口参数。我曾经因为忘记加 -nographic，结果 QEMU 弹了个黑窗口，我还以为死机了。其实它只是把输出定向到了图形窗口，而你没看到而已。

3.3 GDB 调试工具准备

写驱动离不开调试。微内核驱动跑在 QEMU 里，你不能像调试普通程序那样打断点。这时候就需要 GDB + QEMU 的远程调试 组合。

说白了，QEMU 内置了一个 GDB 服务器，你可以在宿主机上用 GDB 连接它，然后像调试本地程序一样调试内核和驱动。

3.3.1 安装交叉调试器

你需要的是 arm-none-eabi-gdb，而不是本地的 gdb。因为你要调试的是 ARM 代码，所以调试器也必须能理解 ARM 指令集。

如果你已经安装了完整的 ARM 工具链，arm-none-eabi-gdb 应该已经包含在内了。验证一下：

arm-none-eabi-gdb --version

如果没有，可以单独安装：

sudo apt install gdb-multiarch

然后用 gdb-multiarch 代替 arm-none-eabi-gdb，效果是一样的。

3.3.2 启动 QEMU 的 GDB 服务器

在启动 QEMU 时加上 -s 和 -S 参数：

qemu-system-arm \
    -M vexpress-a9 \
    -m 128M \
    -kernel kernel.bin \
    -nographic \
    -s \
    -S

参数说明：

  • -s：在 TCP 1234 端口开启 GDB 服务器（等价于 -gdb tcp::1234）
  • -S：启动时暂停 CPU，等待 GDB 连接

加上 -S 后，QEMU 会停在第一条指令之前，不会执行任何代码。这时候你就可以用 GDB 连接上去，设置断点，然后继续执行。

3.3.3 使用 GDB 远程调试

打开另一个终端，启动 GDB：

arm-none-eabi-gdb kernel.elf

在 GDB 中连接 QEMU：

(gdb) target remote localhost:1234

连接成功后，你可以设置断点：

(gdb) break kernel_main
(gdb) continue

这时候 QEMU 会开始执行，直到遇到 kernel_main 函数时停下来。你可以单步执行、查看变量、反汇编等等。

核心技巧： 调试驱动时，我经常在设备初始化函数里打断点。比如 break uart_init，然后单步跟踪寄存器配置。这样能快速定位是哪个寄存器写错了。

3.3.4 调试驱动时的常用命令

我整理了几个调试驱动时最常用的 GDB 命令：

命令 作用 使用场景
info registers 查看所有寄存器值 检查外设寄存器是否写对
p/x *(uint32_t*)0x10009000 读取指定内存地址的值 查看 MMIO 寄存器的当前值
set *(uint32_t*)0x10009000 = 0x01 写入指定内存地址 手动触发外设操作
layout asm 显示反汇编窗口 查看编译器生成的指令是否正确
monitor system_reset 复位 QEMU 驱动把系统搞崩了，快速重启
小提示： 调试 MMIO 外设时，p/x *(uint32_t*)0x... 这个命令我一天能用上百次。建议把它设成 GDB 的别名，比如 define mmio，能省不少事。

3.4 环境验证：跑一个最小驱动

环境搭好了，咱们跑个最小驱动验证一下。这个驱动只做一件事：往串口输出一个字符。

// mini_uart.c
#define UART_BASE 0x10009000

void uart_putc(char c) {
    volatile uint32_t *uart = (uint32_t*)UART_BASE;
    while (*(uart + 5) & (1 << 5));  // 等待发送缓冲区空
    *uart = c;  // 发送字符
}

void driver_init(void) {
    uart_putc('D');
    uart_putc('R');
    uart_putc('V');
    uart_putc('\n');
}

编译：

arm-none-eabi-gcc -c mini_uart.c -o mini_uart.o -mcpu=cortex-a9

然后链接到内核中，启动 QEMU。如果串口输出 DRV，说明你的交叉编译、QEMU 模拟、驱动代码全部正确。

避坑指南： 我曾经在调试 UART 驱动时，发现字符死活输出不出来。折腾了半天，最后发现是 UART_BASE 地址写错了。vexpress 板子的 UART0 基地址是 0x10009000，不是 0x1000A000。所以一定要对照设备树或芯片手册确认地址。

3.5 总结

这一章我们搞定了三件事：

  • 交叉编译工具链：让 x86 机器能编译出 ARM 代码
  • QEMU 模拟器：在笔记本上模拟开发板环境
  • GDB 调试器：远程调试内核和驱动

这三样配齐了，你就有了一个完整的微内核驱动开发环境。下一章，我们会正式开始写第一个设备驱动——UART 驱动。到时候你会看到，今天搭的环境会派上大用场。

嗯，环境搭建这部分就到这里。如果你在配置过程中遇到问题，别急着放弃。我当年第一次配交叉编译环境，整整折腾了两天。但一旦配好了，后面就一马平川了。

← 上一章 📖 返回目录 下一章 →