U-Boot 移植（2）

3.2 在 uboot 中自定义开发板

在U-Boot 移植（1）中我们知道 LCD屏幕 和 网络驱动存在问题，需要对 uboot源码进行修改，但在此之前，我们先在 uboot 中添加自己用的开发板。

3.2.1 添加开发板默认配置文件

先在configs/目录下创建默认配置文件，复制 mx6ull_14x14_evk_emmc_defconfig，然后重
命名为 mx6ull_kd_defconfig，命令如下：

cdconfigscpmx6ull_14x14_evk_emmc_defconfig mx6ull_kd_defconfig

修改默认配置文件：

其中 imximage.cfg 主要包含以下三个核心内容：
1. 核心镜像头部信息
它规定了 U-Boot 镜像最终在物理内存（DDR）里运行的绝对起始地址（通常是 0x87800000），以及镜像的大小。芯片的 Boot ROM 读到这些数据后，才知道后续要把 U-Boot 代码搬运到内存的什么地方去执行。
2. DRAM（内存）的物理时序参数（关键）
这是它最重要的职责。在 U-Boot 运行之前，512MB 的 DDR3 内存芯片是无法使用的。imximage.cfg 里面密密麻麻写满了对 i.MX6ULL 内部 MMDC（内存控制器）寄存器的配置值。包括：
内存的时钟频率。
内存的各种延迟时序（t R C D t_{RCD}tRCD​、t R P t_{RP}tRP​、t C L t_{CL}tCL​等）。
内存的容量和位宽设置。
💡 技术背景：芯片的 Boot ROM 在启动时，会先一行行执行这个文件里的寄存器配置，强行把 DDR3 内存给初始化好，然后才能把 U-Boot 的核心代码从 SD 卡里拷贝进内存运行。
3. 基础时钟和引脚配置
配置 CPU 核心的最基础工作频率，以及少数几个与启动相关的 critical（关键）引脚状态。

修改1
现在默认配置文件中的路径为
“IMX_CONFIG=board/freescale/mx6ullevk/imximage.cfg”
我们要把路径改成我们自己的
“IMX_CONFIG=board/freescale/mx6ull_kd/imximage.cfg”

修改2
现在目标是默认的MX6ULL_14X14_EVK
CONFIG_TARGET_MX6ULL_14X14_EVK=y
改成我们自己的
CONFIG_TARGET_MX6ULL_KD=y

3.2.2 添加开发板对应头文件

在 includ/configs/ 目录下复制 mx6ullevk.h 并重命名为：mx6ull_kd.h

修改宏定义:

#ifndef__MX6ULLEVK_CONFIG_H#define__MX6ULLEVK_CONFIG_H

改为

#ifndef__MX6ULL_kd_CONFIG_H#define__MX6ULL_kd_CONFIG_H

3.2.3 添加开发板对应板级文件夹

在 3.2.1 中我们把默认配置文件中的路径改成了我们自己的
“IMX_CONFIG=board/freescale/mx6ull_kd/imximage.cfg”
因此，我们需要添加这个 mx6ull_kd 板级文件夹
将 board/freescale/mx6ullevk复制并且重命名为mx6ull_kd

1. 修改内部文件：
将 mx6ullevk.c 重命名为 mx6ull_kd.c

2. 修改makefile

obj-y:=mx6ullevk.o

改成

obj-y:=mx6ull_kd.o

3.修改 imximage.cfg 文件
PLUGIN board/freescale/mx6ullevk/plugin.bin 0x00907000
改为
PLUGIN board/freescale/mx6ull_kd/plugin.bin 0x00907000

plugin.bin(插件程序)在 i.MX6ULL 启动流程中的核心作用就是：
专门在上电最早期，帮 CPU 初始化外部的 512MB DDR3 内存。
它是为了解决一个嵌入式启动中“镜像太大，但内存还没准备好”的矛盾而生的。
为什么要用它？

1. i.MX6ULL 芯片刚上电时，外部的大内存（DDR3）是处于瘫痪状态的，此时 CPU 只能使用自己内部自带的、极其微小的缓存空间（OCRAM），容量只有 128KB。
2. 现代的 U-Boot 加上设备树（DTB）文件，体积通常有 400KB ~ 500KB 甚至更大，根本没办法直接塞进这 128KB 的内部缓存里。
3. 芯片内部固化的启动程序（Boot ROM）非常死板，它没办法处理复杂的、需要动态判断的 DDR3 内存初始化 C 语言逻辑。

🛠️ plugin.bin 是如何处理的？
为了打破这个死局，NXP 设计了 plugin.bin。
它是一个体积只有几 KB 的微型裸机小程序。它的工作流程就像一场完美的接力赛：

1. 上电后，Boot ROM 发现整个 U-Boot 太大装不下，于是它只把这几 KB 大小的 plugin.bin 拷贝到内部 128KB 缓存里。
2. Boot ROM 跳转到 plugin.bin 里执行。
3. plugin.bin 内部运行着真正的 C 语言代码，它用最完美的逻辑把板子上那块 512MB 的 DDR3 内存彻底初始化并激活。
4. 内存开通后，plugin.bin 把控制权还给 Boot ROM。
5. Boot ROM 这时就可以把几百 KB 大小的完整 U-Boot 镜像，拷贝到已经就绪的 512MB DDR3 内存里去运行。

4.修改 Kconfig 文件

ifTARGET_MX6ULL_14X14_EVK||TARGET_MX6ULL_9X9_EVK

需要改成和默认配置文件中相同的 TARGET：CONFIG_TARGET_MX6ULL_KD=y

ifTARGET_MX6ULL_KD

同样的

config SYS_BOARDdefault"mx6ullevk"config SYS_CONFIG_NAMEdefault"mx6ullevk"

也改成对应的

config SYS_BOARDdefault"mx6ull_kd"config SYS_CONFIG_NAMEdefault"mx6ull_kd"

5. 修改 MAINTAINERS 文件

MX6ULLEVK BOARD M:Peng Fan<peng.fan@nxp.com>S:Maintained F:board/freescale/mx6ullevk/F:include/configs/mx6ullevk.h F:configs/mx6ull_14x14_evk_defconfig F:configs/mx6ull_14x14_evk_plugin_defconfig

改成如下对应的文件

MX6ULLEVK BOARD M:Peng Fan<peng.fan@nxp.com>S:Maintained F:board/freescale/mx6ull_kd/F:include/configs/mx6ull_kd.h F:configs/mx6ull_kd_defconfig

3.2.4 修改图形界面配置文件

仅完成上述修改后进行编译，编译系统会报错，或者你的配置无法生效。必须修改图形界面配置文件（即顶层 Kconfig 文件）。
原因在于 U-Boot 采用了基于 Kconfig 的配置机制。以下是纯技术层面的逻辑与底层编译机制分析：

1.顶层 Kconfig 掌握全局宏符号的“定义权”
在 configs/mx6ull_kd_defconfig 中，写入了：

CONFIG_TARGET_MX6ULL_KD=y

这属于一个赋值语句。然而，在 Linux 驱动或 U-Boot 体系中，任何宏（CONFIG_XXX）要能够被赋值，必须先在某个 Kconfig 文件中被 config 关键字定义（注册）。
如果在顶层总名录中没有定义 TARGET_MX6ULL_KD 这个配置项，编译系统在解析 defconfig 时，会判定其为一个非法/不存在的符号，并直接将其从当前的 .config 文件中抹去。

2.局部 Kconfig 的依赖链无法闭合
在 board/freescale/mx6ull_kd/Kconfig 内部写了：

ifTARGET_MX6ULL_KD...endif

这是一个条件块。只有当外部传入的 TARGET_MX6ULL_KD 变量为真（等于 y）时，这个 if 块内部的声明（如 SYS_BOARD 默认为 “mx6ull_kd”）才会执行。
如果顶层 Kconfig 没有定义 TARGET_MX6ULL_KD，那么：
defconfig 中的赋值失效。
TARGET_MX6ULL_KD 的值恒为假（未定义）。
整个 board/freescale/mx6ull_kd/Kconfig 内部的所有默认值（default）全部无法加载。
编译系统最终获取到的 SYS_BOARD 和 SYS_CONFIG_NAME 为空，引发诸如 configs/.h 找不到的编译错误。

3. 目录检索路径（Source 机制）未打通
U-Boot 顶层 Makefile 在编译时，会读取配置阶段生成的符号表。
如果没有在顶层的 arch/arm/cpu/armv7/mx6/Kconfig 中显式包含新生成的局部 Kconfig：

source"board/freescale/mx6ull_kd/Kconfig"

那么 Kconfig 解析器在扫描整个源码树时，根本不会进入 board/freescale/mx6ull_kd/ 目录去读取任何配置文件。你的新板级配置在逻辑上处于死胡同状态，无法并入编译主线。

因此，必须在配置文件修改完毕后，打开 arch/arm/cpu/armv7/mx6/Kconfig 执行以下两处修改：

1. 注册目标宏搜索 config TARGET_MX6ULL_14X14_EVK，在其下方并列加入你的单板宏声明（后面几行要在前面输入 Tab 严格对启）：

config TARGET_MX6ULL_KD bool"Support mx6ull_kd"select MX6ULL select DM select DM_THERMAL

2. 引入路径拉到该文件的最底端，在大量的 source 语句末尾，加入你新目录的路径：

source"board/freescale/mx6ull_kd/Kconfig"

只有打通了这一条 “顶层注册→ \rightarrow→关联局部 Kconfig→ \rightarrow→激活 defconfig 赋值→ \rightarrow→释出具体 Makefile 变量” 的技术完整链路，U-Boot 编译系统才能正常工作。

3.2.5 建立编译脚本：

在根目录下新建： mx6ull_kd.sh

#!/bin/bash# 1. 彻底清理工程（清除之前由于用错编译器留下的错误缓存，这步非常关键）makeARCH=armCROSS_COMPILE=arm-buildroot-linux-gnueabihf- distclean# 2. 配置基线：载入刚刚新建的默认配置文件 mx6ull_kd_defconfigmakeARCH=armCROSS_COMPILE=arm-buildroot-linux-gnueabihf- mx6ull_kd_defconfig# 3. 全速编译：调用虚拟机 12 个线程全速编译 U-Boot 源码makeARCH=armCROSS_COMPILE=arm-buildroot-linux-gnueabihf--j12

在根目录下执行：

chmod+x mx6ull_kd_emmc.sh ./mx6ull_kd_emmc.sh

即可完成 uboot 的一键编译

用U-Boot 移植（1）的方法进行烧录

可以发现单板识别依然是官方 EVK

Model: Freescale i.MX6 ULL 14x14 EVK Board Board: MX6ULL 14x14 EVK

底层机制：
U-Boot 在启动时，Model 的名字是从设备树（.dtb）文件的根节点 compatible 属性中读取的；而 Board 的名字是由 board/freescale/mx6ull_kd/mx6ull_kd.c 中的 checkboard() 函数硬编码输出的。
技术现状：
这说明你的默认配置文件（defconfig）中，设备树编译目标（CONFIG_DEFAULT_DEVICE_TREE）依然指向的是原厂的 imx6ull-14x14-evk，且 mx6ull_kd.c 内部的文本字符串尚未修改。
我们先不对设备树进行修改，先处理 Board 的内容：

1. 打开 board/freescale/mx6ull_kd/mx6ull_kd.c。
2. 找到 checkboard() 函数，将 puts(“Board: MX6ULL 14x14 EVK\n”); 修改为专属单板名称（例如 puts(“Board: MX6ULL KD \n”);）。

烧录运行结果如下:

3.2.6 流程图总结