别一提到嵌入式就想起点灯、按键、中断那只是单片机的地盘。真正能把你从“单片机玩家”推向“嵌入式Linux开发工程师”的往往是一块硬骨头——u-boot。如果你刷过招聘网站会发现嵌入式Linux岗位的技能树里几乎都写着u-boot、内核、根文件系统、驱动。u-boot作为板子上电后第一段可交互的程序是理解整个嵌入式Linux启动链路的钥匙也是区分初学单片机和入门嵌入式Linux的重要分水岭。这篇文章不会跟你扯太多晦涩的书本概念而是结合我实际移植、调试u-boot的经验把u-boot的本质、启动流程、移植方法、调试技巧和常见的坑一次讲透。1. 为什么学了单片机还不够u-boot才是分水岭1.1 单片机思维与嵌入式Linux思维的本质差异玩51单片机或者STM32的时候我们通常在做什么初始化时钟、配置GPIO、操作寄存器、跑一个RTOS或者一个裸机状态机。数据手册里写着寄存器地址我们用*(volatile unsigned int*)0x40021000 | (13);去操作或者干脆用HAL库封装好的函数。整个开发过程是“直接控制硬件”。但嵌入式Linux的开发方式完全不同。你面对的不再是一个裸的硬件而是一个运行着Linux内核的“小电脑”。系统上电后首先要由bootloader完成硬件初始化、内存布局、内核镜像加载然后跳转执行内核内核再挂载根文件系统最后运行init进程。也就是说你写的应用程序跑在Linux之上你写的驱动挂接在内核的模型框架之内你不再直接操作寄存器而是通过ioremap、platform总线、设备树这套机制来间接控制硬件。这种从“直接操作寄存器”到“面向框架写代码”的思维跃迁仅靠单片机经验是跨不过去的。而u-boot恰好是两者中间的桥梁。u-boot里很多代码看起来非常“单片机风格”比如为了点亮一个LED、初始化一块DDR内存它就是直接去写寄存器这在u-boot早期汇编阶段尤为明显。但u-boot又不是单片机程序它有自己的链接脚本、命令系统、驱动模型dm模型、设备树支持这些东西在内核里也能看到类似影子。1.2 u-boot在嵌入式Linux中的真实定位u-boot的全称是Universal Boot Loader几乎是当前嵌入式Linux领域事实标准的引导程序。它干的事情其实挺“杂”的它是一个bootloader同时又是一个调试工具集。从功能上看u-boot要做这么几件事第一初始化片级硬件比如关闭看门狗、设置系统时钟、初始化串口、初始化DDR控制器第二把Linux内核镜像从存储介质SD卡、eMMC、Nor Flash、网络读取到内存中第三准备好内核启动所需要的参数通过设备树或ATAG方式传递给内核第四跳转到内核入口点执行。但u-boot的价值远不止“引导内核”这一下。大多数开发板会把u-boot做成一个交互式命令行环境你在串口终端里敲命令它就能帮你操作内存、烧写Flash、通过tftp下载镜像、设置环境变量。我在调试一块新板子的DDR初始化参数时几乎全程是在u-boot命令行里进行的因为这个阶段内核起不来唯一能用的交互工具就是u-boot的console。1.3 嵌入式Linux学习路线里u-boot应该排在哪个位置我经常在技术社区看到不少人问嵌入式Linux该怎么学要不要先学驱动要不要直接啃内核源码。根据我自己走过的路比较稳妥的顺序大概是先掌握Linux基础操作和C语言/数据结构编程能力然后买一块常见开发板比如正点原子、野火、瑞芯微的板子跟着教程把u-boot编译烧录跑起来再尝试修改设备树、配置内核、制作根文件系统。等整个启动链路的每个环节都在你手里亲手操作过一遍之后再去钻研具体的驱动模型和内核机制才有根基。现在网上的教程普遍存在一种倾向把u-boot当成“照脚本编译一下就行”的步骤大家只会敲make xxx_defconfig和make -j8出了问题完全不知道从哪里排查。这其实丢失了最宝贵的部分。u-boot是嵌入式Linux入门阶段最适合“扒源码”找答案的模块它的代码量比内核小一个数量级上下文清晰又能直接跟硬件交互。2. u-boot启动流程拆解从汇编第一行到命令行提示符2.1 u-boot编译产物的分段结构在深入流程之前先讲清楚u-boot的编译产物。编译完u-boot源码之后你会得到多个不同格式的镜像文件u-boot.bin是原始二进制镜像u-boot是ELF格式的文件带符号表可用于gdb调试u-boot.img是带u-boot自定义头的镜像前面加了一个头部信息包含镜像大小、校验和、加载地址等u-boot.srec是Motorola S-record格式还有个MLO或SPL这部分在较新的u-boot里通常通过u-boot-spl.bin生成。理解SPL很关键。这里要提一个背景现代SoC片内SRAM通常很小比如全志的很多芯片内部SRAM只有几十KB到几百KB而u-boot完整镜像经过配置后动辄几百KB甚至上MB。SoC无法在启动时把这么大的镜像直接加载到片内SRAM里运行。所以u-boot采用了两阶段启动方案第一阶段是SPLSecondary Program Loader它是一段精简的代码负责最基础的初始化和把主u-boot从存储介质加载到外部DDR内存第二阶段就是主u-boot完整的命令集、驱动模型都在这一阶段。这个两阶段的思路你可以理解为拆解大型任务先加载一小段代码AA初始化好关键硬件之后再去加载代码BB才是真正干活的。早期单片机开发中从BootROM启动时也有类似的分段设计只是u-boot把这种两阶段理念工程化得更加完整。2.2 启动入口与CPU初始化的那些寄存器操作u-boot的入口点一般是arch/arm/cpu/armv7/start.S或对应架构的start.S文件。这一段的职责比较固定设置CPU为SVC模式管理模式防止中断干扰初始化、关掉MMU和Cache为了让后续汇编和内存布局操作时地址简单直接不用考虑缓存一致性问题、设置栈指针、清BSS段、跳到_main。其中“关MMU和Cache”这一点值得一提。很多从单片机转过来的朋友第一次接触u-boot源码时会对这段代码感到困惑为什么要关掉Cache多浪费性能原因在于启动阶段DDR控制器可能还没初始化好物理内存不可用。如果开着MMU你配置的内存映射表可能是无效的指令预取和数据读写都会出问题。Cache同理如果DDR还没就绪任何Cache回写操作都可能落到虚空里。所以先关掉等DDR初始化好了后续再开启MMU和Cache。真正的硬件初始化通常在board_init_f和board_init_r这两个函数里展开。_f阶段在片内SRAM里运行只能用极简的堆栈_r阶段在DDR就绪后重新relocate到DDR里的最终地址运行。u-boot会把自己从SRAM或者Flash里复制到DDR中的目的地址用relocate_code完成地址搬运。这个过程涉及gdglobal data结构体的保存、重定位偏移计算如果你在移植过程中打印地址发现u-boot运行的链接地址和实际加载地址不一致多半就是relocate这步出了问题。2.3 U-Boot命令系统的实现机制u-boot的命令系统值得单独拿出来讲。因为这是u-boot与内核、通用嵌入式开发最直观交互的接口想真正用好u-boot必须理解命令在源码层怎么注册和命中回调。每个u-boot命令在源码中对应一个U_BOOT_CMD宏定义的结构体里面包含命令名、最大参数个数、可重复执行标志、帮助信息、以及命令处理函数指针。比如cmd/bootm.c里定义了bootm命令用于启动内存中的内核镜像cmd/nand.c、cmd/mmc.c定义存储介质操作命令cmd/net.c包含tftp等网络命令。执行命令时u-boot通过run_command解析用户输入串在命令表里查找匹配项然后调用回调函数。命令系统看似是“给人在终端里敲命令用的”但在实际开发中脚本化和自动化的价值更大。通过u-boot的bootcmd环境变量你可以让板子上电后自动执行一串命令比如从tftp下载内核、设置启动参数、然后bootm启动。我把生产用的板子通常都会配置好bootcmd开机无需人工干预。同时bootargs环境变量设置内核启动参数最典型的是指定console串口和波特率、root根文件系统位置等。2.4 设备树在u-boot里的应用方式u-boot自2014年左右开始全面引入设备树Device Tree这是它现代版本与老版本的重要区别。设备树文件描述了板级硬件信息有哪些内存、哪些外设、中断控制器在哪、GPIO控制器在哪以及它们的地址和配置。u-boot启动时会解析一个fdtFlattened Device Tree二进制块。这个块可能编译进u-boot内部通过CONFIG_OF_CONTROL配置也可能从外部存储介质读取。u-boot的大部分驱动都基于设备树进行匹配这种机制和Linux内核的设备树模型一致。你在u-boot里改设备树相当于告诉它“这块板上有什么硬件、它的配置是什么”。我在给一块新板子移植u-boot时第一件事往往就是检查设备树里的内存节点和串口节点配置。串口节点搞错了u-boot就静默无声你连个调试信息都看不到。内存节点搞错了后续内核dts里也可能跟着错启动到一半kernel panic。3. 移植u-boot到一块新板子的完整实操思路3.1 找一个合适的参考板而不是从零硬啃很多朋友拿到一块新的开发板或自制板卡第一反应是去找官方源码包。能找到对应SoC厂商提供的BSP源码自然是好事但如果你想用主线u-boot就需要自己去适配。这里有一个非常实用的策略以SoC同系列、板级配置相近的现有板卡为起点复制一份board目录下的配置然后逐渐修改而不是自己从空白写起。比如你用的是全志V3s这颗芯片主线u-boot里已经支持了licheepi-zero、荔枝派等多个板卡它们的核心SoC相同差异主要在DDR容量、外部引脚、网络芯片等外围。以其中差距最小的板卡为参考复制其defconfig和board目录文件再有针对性地改DDR配置和外围驱动会比你从头写一个board支持文件省下大量时间。具体的参考板目录结构大概如下board/厂商/板名/下包含Kconfig、Makefile、板名.c、main.c等文件configs/板名_defconfig是核心配置文件arch/arm/dts/下是设备树源文件。把这些都复制一份在此基础上按需修改。3.2 核心配置项与defconfig的关系u-boot的配置体系和内核使用的是同一套Kconfig机制。xxx_defconfig文件里设置的基本都是顶层开关比如CONFIG_ARMy、CONFIG_ARCH_SUNXIy、CONFIG_MACH_SUN8I_V3Sy、CONFIG_DEFAULT_DEVICE_TREEsun8i-v3s-licheepi-zero等等。其余成千上万的配置项则通过Kconfig依赖关系自动生成默认值。执行make xxx_defconfig后源码目录下会生成.config文件。然后执行make顶层Makefile会根据.config递归进入各个子目录编译。这里有个重要的点如果你改了某一项配置单独执行make有时不会触发生效因为Kconfig的自动依赖关系不会自动更新你应该重新执行make xxx_defconfig或者用make menuconfig手动修改后保存。否则你明明改了defconfig文件编译产物却没变这种低级错误我犯过不止一次。3.3 串口、DDR、存储介质这几个大头怎么改移植过程中最先要搞定的是串口console和DDR。串口是调试的生命线没有串口输出你就像在黑暗里开车。串口初始化涉及到几个层面SoC内部UART控制器的基地址、引脚复用配置、时钟配置。在u-boot的早期阶段串口通常是直接寄存器操作硬初始化的比如board_init_f阶段调用的debug_uart_init它对应CONFIG_DEBUG_UART配置。如果串口输出乱码可能是时钟频率配置错误导致波特率不对如果完全没输出多半是引脚复用没配好或者UART外设时钟没开。DDR初始化是移植中最容易卡住的环节。DDR控制器的寄存器配置需要根据DDR芯片的时序参数来设定比如CAS延迟、tRCD、tRP各个参数。u-boot对同一SoC的不同DDR型号一般有对应的DDR3/DDR4配置模板。我常用的办法是先在厂商BSP里找到对应DDR型号的初始化序列确认频率和时序参数然后比对主线u-boot里已有的同类配置。这块没法完全靠猜没有资料就真得拿DDR示波器去量或者跟芯片原厂FAE要初始化代码。存储介质SD/eMMC/NAND这一块则取决于你的板子用哪种介质启动。SD/eMMC走的是SD/MMC控制器驱动NAND走的是NAND控制器驱动。大部分主控SoC的u-boot已经内置了相应支持你只需要在defconfig里打开对应的配置选项并确认GPIO分配和分区表即可。3.4 编译、烧录与首次启动的检查清单完成上述修改后编译烧录通常会走这样一套流程执行make distclean清理之前的构建产物避免旧配置残留影响新板卡的构建。执行make 板名_defconfig生成配置。执行make -j$(nproc)并行编译如果中途报错按依赖顺序往上层看常见问题的原因通常是头文件缺失、链接脚本路径不对。编译完成后确认产物。SPL和u-boot本体分别处理有些SoC需要把SPL单独烧到启动介质起始地址u-boot本体放在后面的固定偏移处。用SD卡、eMMC烧录工具比如dd命令或sunxi-fel等厂商工具把镜像写入。用串口线连接开发板的调试串口打开minicom或putty设置波特率一般是115200 8N1上电观察输出。首次启动时你期望看到一串log如果卡在某个位置比如停在Starting kernel ...之后没反应那通常是内核镜像的参数不对或者设备树地址传递出了问题。4. 用好u-boot命令行解决开发过程的高频痛点4.1 从BootROM到u-boot prompt的串口日志怎么看第一次在串口终端里看到U-Boot 2018.07-rc2-00002-gb0ec5f0 (May 29 2024 - 16:22:33 0800)这种字样时很多人只把它当成一个“欢迎信息”。实际上这条日志里藏着大量信息编译时间判断源码版本、编译主机gcc版本交叉编译工具链版本、DRAM大小DDR初始化是否成功、MMC编号等。我会习惯性看这几项第一是DRAM的初始化报告比如DRAM: 256 MiB如果这个值比你板子实际的内存容量小说明DDR配置有问题第二是MMC: mmc4021000: 0这类输出确认存储控制器是否枚举成功第三是In: serial、Out: serial、Err: serial这三行确认标准输入输出和错误输出都落到了串口上。如果串口是正常的但看不到这些行那就说明u-boot在更早期的初始化阶段就已经跑飞了。这类问题的排查难度会直线上升因为没有任何输出可以看。这时候要么用JTAG调试器要么在源码里手动加putc之类的打印函数从第一条开始定位死在哪个函数里。4.2 常用命令分组记忆与典型玩法u-boot命令行里命令很多按下Tab键可以自动补全输入help或?可以查看全部命令。按功能分组会更容易记住存储与内存类md读内存、mw写内存、mm修改内存、cp拷贝内存区域。调试DDR时我常用md 80000000来查看内存区域的内容确认读出来的数据和写入的数据一致排除数据线虚焊等硬件问题。引导启动类bootm启动内存中的镜像、bootz启动zImage格式内核、go跳转执行指定地址的代码、boot执行bootcmd环境变量定义的启动命令。在调试过程中用tftp 80800000 zImage把内核下载到指定地址然后bootz 80800000 - 83000000手动启动非常方便。存储介质类mmc dev切换当前MMC设备、mmc read/write、fatload从FAT分区读取文件。烧写系统时我经常先把镜像文件放到SD卡的FAT分区然后在u-boot里用fatload mmc 0:1 80800000 uImage加载到内存再烧写到eMMC。网络类tftp、ping、dhcp。网络下载是调试阶段效率最高的手段没有之一。配合NFS挂载根文件系统基本可以实现“修改代码-交叉编译-拷贝到NFS目录-重启板子”的快速迭代循环。环境变量类printenv打印全部环境变量、setenv设置环境变量、saveenv保存环境变量到存储介质。环境变量是u-boot配置闪存般的功臣bootcmd和bootargs几乎每个板子都必须仔细设置。4.3 通过tftp和NFS快速迭代调试我强烈建议每个u-boot玩家都把tftp和NFS这两个服务搭好。tftp解决“把镜像传到板子上”的问题NFS解决“根文件系统在开发机里而不是烧写到板载存储”的问题。具体操作开发机上安装并启动tftp-hpa服务把编译好的uImage或者dtb文件放在/srv/tftp目录下。板子u-boot里设置好IP环境变量setenv ipaddr 192.168.1.100setenv serverip 192.168.1.10tftp 80800000 zImage内核起来后通过bootargs里的NFS参数把根文件系统挂载到开发机的导出目录setenv bootargs consolettyS0,115200 root/dev/nfs nfsroot192.168.1.10:/srv/nfs/rootfs rw ipdhcp这个玩法几乎是嵌入式Linux开发的默认工作方式。之前我在做某个项目时每天都靠这套流程反复测试内核和驱动改完代码十几秒就能在板子上看到效果根本不用反复烧写存储介质节省了大量时间。这个技巧也是网络热词里“嵌入式linux 根文件系统挂载 使用nfs v3”的真实应用场景官方文档和各种社区帖子也都在反复强调NFS调试法。4.4 环境变量的作用域与保存细节u-boot的环境变量存储在哪个位置不同板卡配置不一样。有些存在eMMC的特定分区CONFIG_ENV_IS_IN_MMC有些存在SPI FlashCONFIG_ENV_IS_IN_SPI_FLASH有些存在FAT文件系统的文件里。环境变量的保存机制是把当前环境变量表整体序列化成二进制块写入到指定存储介质位置。这里有一个常见的踩坑点如果启动时修改了环境变量但忘记saveenv重启之后所有修改都会丢失。另一个坑是环境变量大小是有限制的默认CONFIG_ENV_SIZE一般是16KB或32KB几个大字符串比如很长的bootargs塞多了会报错需要适当调整配置编译。5. 移植u-boot时常见的坑与我的排错经验5.1 串口完全无输出的排查链路这是最让人崩溃的问题编译烧录都没报错但上电后串口一个字符都不打印。遇到这种情况我建议按下面的顺序排查确认串口连接本身没问题用USB转串口模块短路TX/RX自发自收确认硬件链路通。确认串口电平匹配。很多开发板是3.3V TTL电平如果你的USB转串口模块是5V电平的轻则读不到信号重则烧坏串口芯片。确认端子接线正确板子的TX要接模块的RXRX接TXGND一定要共地。确认波特率设置正确检查是115200还是某个厂商惯用的1500000。如果以上都没问题开始怀疑u-boot本身。最常见的原因是UART控制器时钟配置错误。需要回去检查板级初始化里时钟树配置。还不行就用JTAG连接调试器在start.S开头打硬件断点单步执行看到底死在哪个位置。5.2 DDR初始化导致启动反复重启另一个高频故障是DDR没初始化好表现形态多样要么u-boot在早期反复重启要么跑起来之后随机死机重启时间完全不确定。之前我调一块板子DDR3芯片用的是某国产品牌按参考板的配置直接拉起来结果memtest跑几分钟就报错。这种问题最阴险因为它不是稳定复现的。我的处理思路是把DDR频率降一档还能不能过stress test。如果不能说明不只是时序问题很可能是布线或者供电问题如果能那就是时序参数需要细调。u-boot的DDR驱动里一般在board/厂商/板名/下有专门的初始化文件里面的寄存器序列可以逐项与芯片数据手册对照。要是没有示波器就只能靠二分法去试参数组合。5.3 烧录方式各异注意启动介质偏移u-boot编译产物如何烧录取决于SoC的BootROM行为。以全志V3s为例它的BootROM会从SD卡的某个偏移地址读取SPL不同的偏移量设置都在源码的CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR或SPL相关配置里。如果你直接把u-boot.bin烧到SD卡开头大概率启动不了。一般NXP i.MX系列是从偏移1K处烧SPLCONFIG_SYS_U_BOOT_BASETI的AM335x有MLO烧到SD卡第一个分区之前的区域。你把uboot.bin raw烧进去之后最好用官方文档或已可用板卡的烧录脚本来对照偏移量。自己没事不要用dd去乱写写错了不清除的话后面重烧可能遇到“怎么烧也启动不了”的假象。5.4 设备树地址与u-boot装载地址的冲突内核镜像加载地址一般约定在内存起始地址往后偏移一段比如32位ARM常见的是0x80800000或0x20008000。每次tftp下载内核之前先确认这个地址在内存范围内并且没有被u-boot本身占用。如果下载地址和u-boot的relocate区域重叠写坏了u-boot自身代码在内存里的映像整个系统会奇奇怪怪地死掉。我在调试时喜欢用bdinfo命令打印u-boot认为的内存布局信息DRAM起始地址、大小、relocate地址然后再决定tftp要下载到哪个地址。这套“先摸底再操作”的习惯可以帮你躲过非常多的灵异问题。6. 学u-boot的进阶路线和未来能通到哪6.1 从u-boot切入Linux内核启动参数的传递机制u-boot学扎实之后你会自然过渡到第二个大主题Linux内核是怎么启动的。u-boot最终通过bootm或bootz把控制权交给内核。这个交接过程在ARM平台上通常会传递一个struct tag或者一个设备树指针。如果你的内核文档熟悉你会发现CONFIG_CMDLINE_TAG、CONFIG_SETUP_MEMORY_TAGS这些配置都是为了让u-boot在跳转前把内存信息、命令行参数、序列号等打包成tag列表。理解了这套参数传递机制将来你在调试“内核起来了但设备不工作”时会习惯性地回头看一眼bootargs是否设置正确。我见过不少驱动开发同事排查几天的疑难问题最后定位在bootargs里少了某个关键的device tree参数或者在bootcmd里把dtb地址传错了。6.2 从u-boot驱动过渡到内核驱动的学习路径u-boot的dm驱动模型driver model和Linux内核的设备模型异曲同工。u-boot把所有设备抽象成一个udevice结构通过U_BOOT_DRIVER宏定义驱动用compatible字符串与设备树节点匹配。如果你在u-boot里手写过一个小驱动再去看Linux内核的platform_driver、i2c_driver、spi_driver框架会发现思路完全一致注册driver、匹配device、probe、bind、release。这也是为什么我一直建议大家不要跳着学u-boot。有人觉得u-boot就是“启动的一小段代码能跑就行”这种心态会让你错失一个完美的入门级Linux驱动参考实现。u-boot的驱动代码精简、没有内核那么多复杂的并发和休眠机制就像一个精心剪裁的教学版特别适合初学者搭骨架。6.3 面试中u-boot相关的高频考点现在不少嵌入式Linux岗位面试会把u-boot作为考点尤其是从单片机转行过来的候选人。常见的问题包括u-boot的启动流程是什么SPL和主u-boot的区别设备树怎么管理硬件描述bootcmd和bootargs的作用如何从NAND/SD卡/eMMC启动如何添加一个新的u-boot命令甚至让你现场分析一段start.S汇编。这些考点其实对应着通用嵌入式开发的底层认知。如果你能把u-boot说清楚不仅仅停留在“会编译”层面面试官通常会更愿意放你进入下一轮。因为u-boot是嵌入式Linux开发的一个缩影你需要理解代码如何链接、如何重定位、如何与硬件打交道、如何与外部工具tftp、NFS、串口协作。这套技能几乎是嵌入式开发者的通用语言。6.4 围绕u-boot延伸出的实用工具链学u-boot的过程中你还会顺带掌握一堆周边工具这些工具在你后续的整个嵌入式开发生涯中都极其有用。交叉编译工具链熟悉aarch64-linux-gnu-gcc以及arm-linux-gnueabihf-gcc等工具以及它们的地址转换工具objcopy、objdump等。 串口调试工具minicom、putty、screen或者pyserial脚本。 网络服务配置tftp服务器、NFS服务器、DHCP服务器。 镜像处理工具mkimage给内核打u-boot头、dtc编译设备树。 烧录工具各厂商提供的烧录器驱动以及通用工具如ethtool、mmc-utils。这些工具链如果单独去学会觉得很枯燥但在“让一块板子从u-boot跑到Linux命令行”这个目标的牵引下你会不知不觉全学会。这也是我认为u-boot学习曲线虽陡峭但回报极高的原因。7. 我的个人体会与给刚入门者的建议说实话u-boot这个东西刚开始接触时挫折感很强。你会遇到无数个莫名其妙的失败编译报错链看不懂、上电没输出、DDR不稳定、网络下载超时。但恰恰是这些“莫名其妙”逼着你去翻源码、看芯片手册、查社区帖子最终建立起自己的嵌入式知识体系。如果说玩单片机教会了我们“硬件是怎么工作的”那学u-boot教会我们的就是“一个复杂软件系统是怎么在硬件上一步步建立起来的”。从u-boot到内核再到根文件系统整条链路跑通之后你会发现自己已经拥有了独立的嵌入式Linux开发能力不再依赖厂商BSP傻瓜包也知道系统一旦出问题该从哪里下手。最后分享一个我用着很顺手的学习方法不要光看博客和文档一定要亲手给u-boot加一个新命令然后把一个自写的驱动挂进去编译烧录跑起来。哪怕只是添加一个打印hello world的命令这个过程就会让你理解U_BOOT_CMD宏、config配置、命令参量解析、Makefile编译依赖和最终的烧录验证。有了这个经验打底后面任何所谓高深话题其实都是同一套思路在不同场景下的延伸。