uboot启动过程
- 完美的底层基建
DRAM: 16 GiBRelocation Offset: ebb0c000mmc@fe2c0000: 1, mmc@fe2e0000: 0MMC0: HS400 Enhanced Strobe, 200Mhz
系统代码成功完成了大搬家（Relocation）。 eMMC 闪存跑在了 HS400 高速模式（200MHz）！这意味着底层驱动彻底打通，硬件性能已经拉满。
- 核心致命伤：缺失的"硬件接线图
RESC: 'resource', blk@0x0000e000RESC: invalidFailed to load DTB, ret=-2No valid DTB, ret=-22
parameter.txt 里面规定了 0x0000e000 是 resource（资源）分区的地盘。U-Boot 极其聪明地去那个地址找东西，结果发现里面是空的（invalid）。 它要找什么？它要找 DTB (Device Tree Blob，设备树)。没有这份"硬件接线图"，U-Boot 根本不敢瞎猜主板上接了什么屏幕、什么网卡，更无法把这些信息传递给 Linux 内核。
- 病急乱投医的"搜索大军"
Android image load failedFailed to mount ext2 filesystem...starting USB... No working controllers foundRetrieving file: pxelinux.cfg... No ethernet found.
当 U-Boot 在 eMMC 里找不到合法的内核和设备树后，它内部的启动循环（distro_bootcmd）就会触发**"无差别地毯式搜索"**。 它先试着按 Android 系统来启动；失败后，它去搜外接的 USB 接口；USB 没插，它最后竟然去试图启动网卡，企图从局域网的 PXE 服务器上下载系统代码！
补齐 resource.img 拼图
在瑞芯微的生态里，内核的设备树（DTB）和开机的 Logo 图片，会被打包成一个单独的 resource.img 文件
前配置好 ARCH=arm64 和 CROSS_COMPILE 环境变量，就像之前编译内核那样
./scripts/resource_tool arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dtb logo.bmp //设备树文件为rk3588-evb1-v10.dtb
接下来就会uboot启动就会出现如下日志：
🎖️ 架构师的胜利阅兵（硬件苏醒日志分析）
设备树成功注入（瞎子复明）
RESC: 'resource', blk@0x0000e000DTB: rk-kernel.dtb解读：U-Boot 成功从 eMMC 提取到了设备树！它不再是无头苍蝇了。核心电源管理上线（心脏起搏）
spi2: RK806: 2vdd_cpu_big0_s0 800000 uV解读 ：这是极其硬核的一步！系统成功通过 SPI 总线联系上了主板上的大管家------RK806 电源管理芯片（PMIC），并精准地给 CPU 大核供上了 0.8V 的电压。主板绝对安全，没有烧毁风险！显示引擎点亮（眼睛睁开）
VOP update mode to: 1080x1920p60, type: MIPI0 for VP3final DSI-Link bandwidth: 880000 Kbps x 4解读：设备树里的屏幕参数生效了！RK3588 内部强大的 VOP（视频输出处理器）已经被唤醒，甚至已经向 MIPI 接口发送了 1080P/60帧的信号。（如果你板子上接了 MIPI 屏幕，此时大概率已经亮起背光或者显示出原厂 Logo 了！）🚨 最后的卡点：为什么没进内核？
硬件全通了，为什么还是倒计时并报错找不到系统？ 目光锁定这几行致命日志：
Not AVB images, AVB skipNo valid android hdrAndroid boot failed, error -1.
真相大白：U-Boot 在找一个"带包装盒"的内核，而你之前给它的是"裸奔"的内核。
在瑞芯微的生态里，虽然我们跑的是纯正的 Linux，但它的 U-Boot 依然沿用了 Android Boot Image 的打包标准。 U-Boot 不认识直接放在 Kernel 分区里的原始 Image 文件。它要求你必须把 Image 塞进一个带有 ANDROID! 头部魔数（Magic Header）的盒子里，并且这个盒子要放在 Boot 分区 里。
并没有找到boot.img 只看到了boot.its
你之所以只看到了
.its而没看到.img，是因为你的 Ubuntu 编译环境里少了一个装箱工具。我带你解开这个"集装箱"的最后秘密。📦 揭秘：
boot.its到底是什么？还记得上一条日志里，U-Boot 绝望地喊出的那句话吗？
## Booting FIT Image FIT: No fit blob在现代的 ARM 嵌入式系统里，内核不再使用老旧的 Android 包装盒，而是升级成了一种叫 FIT (Flattened Image Tree) 的高级集装箱格式。
而你发现的
boot.its(Image Tree Source) ，就是这个集装箱的**"装箱清单（Blueprint）"**！ 它里面用文本写着："把Image放在第一层，把dtb放在第二层，用 gzip 压缩，签名加密......"真相大白： 你执行
make xxx.img时，瑞芯微的脚本成功编译了内核，也成功帮你写好了这份装箱清单（boot.its）。但是，在最后执行"按清单装箱"的那一瞬间，它发现你的 Ubuntu 系统里没有mkimage（打包机）这个工具！ 于是它悄无声息地罢工了，只留下了这份.its图纸。
第一步：安装"打包机" (U-Boot Tools)
你的系统里缺少这个业界标准的制图和打包工具。执行命令安装它：
sudo apt-get update
sudo apt-get install u-boot-tools -y
有了工具后，直接把 boot.its 喂给它，让它吐出我们苦苦追寻的 boot.img：
bash
mkimage -f boot.its boot.img使用mkimage命令报错了：
FATAL ERROR: Couldn't open "fdt": No such file or directory
mkimage: Can't open boot.img.tmp: No such file or directory
之前你执行make rk3588-evb1-v10.img时，因为系统里没有mkimage工具，整个打包脚本在最后一步崩溃中断 了。 这就导致了一个极其尴尬的局面：内核源码里的自动化脚本，还没来得及把编译好的Image和rk3588-evb1-v10.dtb复制到mkimage期望的指定临时目录（或者没来得及重命名），脚本就死掉了。所以，你现在强行拿着遗留下来的
.its清单去打包，它当然会因为缺文件而报错。
安装缺少的 LZ4 压缩机
sudo apt-get update
sudo apt-get install lz4 -y
又报错了：
CALL scripts/checksyscalls.sh
fatal: not a git repository (or any of the parent directories): .git
LZ4C arch/arm64/boot/Image.lz4
/usr/bin/env: 'python': No such file or directory
make[1]: *** [arch/arm64/Makefile:226: rk3588-evb10-v10.img] Error 127
make: *** [Makefile:234: __sub-make] Error 2
/usr/bin/env: 'python': No such file or directory这个报错在芯片驱动圈子里，堪称"新人第一杀手"。 破案了： 瑞芯微的那个打包脚本（make_fit_atf.py）开头写着去找python运行。但是在你使用的 Ubuntu 20.04 或 22.04 系统中，Python2 已经被彻底淘汰，系统默认把 Python 叫作python3，根本没有叫python的命令！脚本找不到执行环境，当场"猝死"。
第一步：安装伪装包
sudo apt-get install python-is-python3 -y
编译：
make rk3588-evb10-v10.img
烧录流程：
第一步：提取神器 去你的 Linux 内核源码根目录下，找到刚刚用 Python 脚本和 mkimage 成功合成的
boot.img。把它拷贝到 Windows 上。第二步：部署 RKDevTool（极其关键的换阵） 回到烧录工具，进行以下终极勾选：
勾选 1 (Loader)
勾选 2 (Parameter)
勾选 3 (Uboot)
勾选 6 (Resource) （刷入你之前生成的
resource.img，也就是设备树图纸）极其重要：取消勾选 7 (Kernel)！ （系统不需要裸奔的 Image 了）
极其重要：勾选 8 (Boot)！ （把路径指向你刚拿到的
boot.img集装箱）第三步：一击致命 点击【执行】刷入开发板。