4、Kconfig与配置系统：U-Boot的Kconfig体系、menuconfig图形化配置、如何选择目标板

说到U-Boot的配置系统，我刚开始接触时也觉得挺绕的。说白了，Kconfig就是一套让你能像搭积木一样选择功能模块的机制。你想想看，一块开发板上有几百个可配置项，总不能每次改个参数都去翻源码吧？Kconfig就是来解决这个问题的。

Kconfig最早是从Linux内核那边借鉴过来的。U-Boot的Kconfig体系，本质上是一棵巨大的配置树。每个功能模块都有自己的Kconfig文件，分布在各个子目录下。

举个例子，你想让U-Boot支持网络功能，那就要找到net/Kconfig这个文件。里面会定义类似这样的配置项：

config CMD_NET
    bool "networking commands"
    default y
    help
      Support various networking commands (tftp, ping, etc.)

这里bool表示这是个开关选项，要么选要么不选。default y表示默认开启。我个人习惯是把所有用不到的功能都关掉，这样编译出来的U-Boot体积小，启动也快。

Kconfig的依赖关系也很重要。比如你想用TFTP功能，那必须先开启网络支持。这种依赖关系在Kconfig里是这样表达的：

config CMD_TFTP
    bool "tftp command"
    depends on CMD_NET
    help
      TFTP command support

嗯，这里要注意：depends on的意思是，如果CMD_NET没选，那CMD_TFTP根本不会出现在配置菜单里。我在项目中遇到过有人直接改.config文件强行开启某个功能，结果编译报错，查了半天才发现是依赖没满足。

光看Kconfig文件太抽象了，所以U-Boot提供了menuconfig这个图形化配置工具。你只需要在U-Boot源码根目录下执行：

make menuconfig

就会弹出一个基于ncurses的图形界面。说实话，第一次看到这个界面时，我还以为是回到了90年代的DOS系统。但用习惯了你会发现，它比直接改配置文件高效得多。

在menuconfig里，你可以：

我曾经在一个项目中，需要同时支持三块不同型号的板子。每次切换板子都要重新配置一遍，烦得很。后来我发现menuconfig支持savedefconfig功能，可以把当前配置精简保存为最小配置，这样切换板子时只需要加载对应的defconfig文件就行。

小技巧：如果你不确定某个配置项在哪里，在menuconfig界面按/键，输入关键词搜索。搜索结果会直接告诉你这个配置项在哪个菜单路径下，省得你一层层翻。

U-Boot支持几百种开发板，你不可能每次都从头配置。所以就有了defconfig文件——每个官方支持的板子都有一个默认配置文件。

选择目标板的流程其实很简单：

这里有个坑，我踩过好几次：有些板子的defconfig文件命名并不直观。比如sandbox_defconfig是用于PC上模拟调试的，qemu_arm64_defconfig是用于QEMU虚拟机的。如果你拿这些配置去编译真实硬件，那肯定跑不起来。

怎么确认你选的defconfig对不对？我的经验是：

    核心逻辑：Kconfig体系 + defconfig文件 + menuconfig工具，这三者构成了U-Boot的完整配置系统。defconfig提供基础配置，menuconfig让你按需调整，Kconfig保证配置的合法性。

下面这张图展示了U-Boot配置系统的核心逻辑，我画了好几次才把关系理清楚：

避坑指南：千万不要手动修改.config文件！我曾经为了省事，直接改了.config里的一个宏，结果Kconfig的依赖检查没通过，编译出来的U-Boot在板子上直接死机。正确的做法是：用make menuconfig修改，或者修改对应的defconfig文件后重新生成。

在实际项目中，我一般会这样管理配置：

这样做的好处是，你永远知道当前配置是从哪个基准点改出来的。如果出了问题，回退到defconfig重新配置就行。

嗯，关于Kconfig和配置系统，核心就是这些。记住一点：配置不是一次性的工作，随着硬件迭代和功能增减，你会反复进出menuconfig。把这个流程玩熟了，后面移植U-Boot到新板子时能省不少力气。

    一句话总结：Kconfig定义规则，defconfig提供模板，menuconfig让你可视化操作，三者配合，搞定U-Boot配置。

可可精品资料库