前言

• 最近使用 VS Code GDB 调试 qemu，有了一点收获，u-boot 编译后生成了一个 elf 文件：u-boot，是否也可以调试一下？

• 为何需要 VS Code GDB 调试，直接 gdb 调试不就可以了吗？答案就是：VS Code 可以界面调试，命令行调试会枯燥很多

环境

• 使用 qemu，就是不需要板子

• win10 64位 VMware Workstation Pro 16

• ubuntu 20.04

• qemu （虚拟ARM开发板），qemu arm64 平台

• u-boot : u-boot-2023.04

• gcc 交叉编译工具链：gcc version 12.2.1 20230401

目标

• 基于 qemu，VS Code GDB，界面调试 u-boot，了解 u-boot 的启动流程

• qemu：不需要硬件电路板支持，当前一些启动初始化流程可能与实际电路板存在差异，所以目标就是摸清楚 u-boot 的启动流程，重在搞清楚 u-boot 启动与初始化流程。

• VS Code，这里重在界面调试，类似于 eclipse 那样的，可以源码调试

• GDB：是一个强大的调试工具

编译 u-boot

• 配置文件：configs/qemu_arm64_defconfig

• 生成配置：make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- qemu_arm64_defconfig

• 【备注】：当前 u-boot-2023.04 ARM 与 ARM64 没有分开，所以 ARCH=arm，而不是 ARCH=arm64

• 开始编译： make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-

• 生成的产物： u-boot.bin：二进制文件， u-boot： elf 可执行文件，默认包含 debug 信息

配置 VS Code gdb

• 当前 是 Win10 下 VS Code 通过 SSH 连接 VM虚拟机中的 ubuntu，如果本地是 ubuntu 系统，应该就不需要 SSH 远程连接

• VS Code 安装 gdb 调试插件

• 【备注】gdb 这个插件，好像不需要，确认下左边栏 是否有个 DEBUG 调试按钮吧，好像是 VS Code 自带的。

• 配置 VS Code 调试：点击 【设置】的按钮，会提示选择某个调试器，这里随便选择一个，然后就会出现一个 .vscode/launch.json 文件

• 修改 launch.json 文件内容如下

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "uboot-debug",
            "type": "cppdbg",
            "request": "launch",
            "miDebuggerServerAddress": "127.0.0.1:1234",
            "miDebuggerPath": "/home/zhangsz/linux/tools/gcc-linaro-12.2.1-2023.04-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb",
            "program": "${workspaceFolder}/u-boot",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "logging": {
                "engineLogging": false
            },
            "MIMode": "gdb",
        }
    ]
}

• 注意点一："miDebuggerPath": "/home/zhangsz/linux/tools/gcc-linaro-12.2.1-2023.04-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb",，这里设置 gcc gdb 的执行路径，全路径即可，这里的 gdb，来自 gcc version 12.2.1 20230401 交叉编译工具链

• 注意点二："program": "${workspaceFolder}/u-boot",，这里选择 u-boot，也就是 ELF 文件，而不是 u-boot.bin 二进制文件

• 注意点三："stopAtEntry": true,，这里选择 所有 的 执行 入口函数，都有断点停下来，否则可能 u-boot 无法调试

qemu 启动与调试脚本

• qemu 启动脚本：qemu.sh，可以确认 u-boot 是否可以正常启动

#!/bin/bash
qemu-system-aarch64 -machine virt \
        -nographic \
        -m 512M \
        -cpu cortex-a57 \
        -kernel u-boot \

• qemu 调试调试脚本，qemu-debug.sh，执行此脚本，可以进入 qemu 调试

#!/bin/bash
qemu-system-aarch64 -machine virt \
        -nographic \
        -m 512M \
        -cpu cortex-a57 \
        -kernel u-boot \
        -s -S

调试方法

• 执行 qemu-debug.sh，此时会卡住，也就是 qemu 处于【冻结】状态

• 点击 调试图标的 【运行】按钮：

• 进入调试界面：

• 此时可以加断点进行调试，可以单步【F11】或者 【F10】进行调试

• 如此， VS Code gdb 源码调试 u-boot 的环境搭建成功了

备注

• 好像 u-boot 有一段 重定位的操作，经过重定位后， VS Code gdb 就无法正常加人断点了，也就是没有了调试符号与信息，这部分后续再梳理一下。

• 当前的 VS Code gdb 界面源码调试 u-boot，可以从 reset 开始，单步【F11】配合【F10】与 手动断点，了解 u-boot 的第一阶段的启动流程，感觉对熟悉 u-boot 启动流程 还是有点用处。

小结

• VS Code GDB 调试功能，感觉有点像专业的 Visual Studio 的感觉了，嵌入式软件可以调试，这本身就是一件好事，利于熟悉代码执行流程、问题定位等。

• 调试过程中，有寄存器、局部变量、断点、【监视】watch 等窗口，可以观察程序执行的当前状态，很有用，至少比 gdb【命令行】调试起来舒服与高效