
1. 项目概述这不是一份“说明书”而是一张瑞芯微Linux SDK的实战通关地图你手头刚拿到一块瑞芯微的开发板比如RK3566、RK3568或者最近很火的RV1106板子上贴着“Linux SDK”几个字但打开压缩包一看里面全是build.sh、buildroot、device、kernel这些目录外加一堆英文文档连个“下一步点哪里”都找不到。别慌——这根本不是你的问题而是瑞芯微SDK设计逻辑和新手认知之间存在一道真实的断层。我带过十几支嵌入式团队从应届生到十年老司机90%的人第一次接触瑞芯微Linux SDK时都会卡在同一个地方不知道build.sh到底在编译什么buildroot和kernel谁先谁后设备树.dts文件改了为什么没生效甚至分不清“SDK”和“系统镜像”到底是什么关系。这个标题里的“入门FAQ”绝不是罗列几个“怎么编译”“怎么烧写”的零散问答而是把整个SDK的构建链条——从代码拉取、配置裁剪、交叉编译、镜像打包到最终烧录启动——全部拆开、摊平、标上箭头和注释让你看清每一行命令背后的真实意图。它面向的是真正要动手做产品的人硬件工程师需要确认驱动是否集成到位软件工程师要快速跑通用户空间应用测试人员得知道如何验证不同内核版本的兼容性而项目经理最关心的是“这套流程能不能稳定复现、有没有隐藏坑”。所以这篇内容里不会出现“SDK是Software Development Kit的缩写”这种教科书定义也不会教你“Linux是什么操作系统”而是直接告诉你当你双击build.sh那一刻它其实在后台悄悄做了7件事当你修改arch/arm64/boot/dts/rockchip/rk3566-evb.dts时必须同步检查3个地方才能确保改动进到最终镜像当你发现串口输出卡在“Starting kernel ...”不动90%的情况不是硬件坏了而是buildroot里一个叫BR2_TARGET_ROOTFS_EXT2_SIZE的参数设小了。这就是瑞芯微Linux SDK的真相它不是黑盒而是一套高度耦合、强依赖顺序的工程流水线理解它的唯一捷径就是亲手把它拆一遍、装一遍、再踩一遍坑。2. SDK整体架构与构建逻辑为什么build.sh是入口却不是终点2.1 瑞芯微SDK不是“一个包”而是三层嵌套的精密齿轮组很多人误以为瑞芯微Linux SDK是一个类似Android Studio那样的集成开发环境点几下就能生成固件。实际上它更像一套预配置好的“工程模具”由三个核心层级咬合驱动顶层SDK主控脚本层build.sh为核心这是用户唯一需要直接交互的入口。但它本身不编译任何代码只负责调度。build.sh本质是一个Shell状态机它读取config目录下的.config文件注意不是内核的.config解析出当前目标平台如rk3566_linux_defconfig、构建模式release或debug、以及关键开关如BR2_PACKAGE_RKNN是否启用。然后按严格顺序调用下层工具链先触发buildroot初始化再拉取并配置Linux kernel源码接着编译U-Boot最后整合所有产物打包成rockdev/Image-rk3566/下的boot.img、recovery.img、rootfs.img等。关键点在于build.sh的执行顺序不可跳过、不可逆序。我曾见过团队为“加速编译”把kernel编译步骤挪到buildroot之前结果因buildroot生成的output/rockchip_rk3566/build/linux-*/include/generated/autoconf.h未就位导致内核编译报错#include generated/autoconf.h not found折腾两天才发现是顺序错了。中层Buildroot构建框架层真正的“系统裁剪引擎”Buildroot在这里不是可选组件而是瑞芯微SDK的“心脏”。它决定了最终rootfs里有什么BusyBox版本、glibc还是musl libc、是否包含Python3、OpenSSL支持哪些加密算法、甚至/etc/inittab的默认内容。瑞芯微对Buildroot做了深度定制package/rockchip/目录下全是自家驱动和工具如rkisp,rknn_toolkit2configs/rockchip_rk3566_linux_defconfig则固化了芯片级依赖如强制启用BR2_PACKAGE_ROCKCHIP_RGA用于GPU加速。这里有个致命误区很多人以为修改make menuconfig里的选项就能生效却忽略了瑞芯微SDK的Buildroot配置是“双锁机制”——既要改configs/xxx_defconfig又要确保build.sh调用时传入的BOARD参数与之匹配。比如你用./build.sh rk3566_linux_defconfig但手动运行make menuconfig时选的是rk3399_linux_defconfig那build.sh后续会覆盖你的修改。底层Linux Kernel与U-Boot源码层硬件能力的终极翻译器内核源码kernel/目录和U-Bootu-boot/目录是SDK的“肌肉和神经”。瑞芯微的kernel分支如rk3566_5.10.y并非上游Linus主线而是基于LTS内核打上大量私有补丁PCIe控制器驱动、HDMI CEC协议栈、ISP图像处理pipeline、以及最关键的动态设备树Dynamic Device Tree支持。所谓“动态设备树”是指RK3566/RK3568等新平台不再使用静态.dtb文件而是通过CONFIG_OF_OVERLAYy和CONFIG_OF_RESOLVEy让内核在启动时动态加载多个.dtsi片段如rk3566-ddr-1600MHz.dtsi,rk3566-vpu.dtsi再根据板级ID自动拼接。这意味着你改一个rk3566-evb.dts可能还要同步检查include/dt-bindings/下的头文件、arch/arm64/boot/dts/rockchip/下的公共片段甚至drivers/phy/rockchip/phy-rockchip-pcie.c里的时钟配置——因为设备树节点的compatible字符串必须和驱动里的of_match_table完全一致否则设备根本不会被probe。提示瑞芯微SDK的构建链条是单向强依赖。build.sh → buildroot → kernel/U-Boot任何一层失败都会中断整个流程。但反过来单独修改kernel代码后不能只运行make -C kernel/必须重新执行./build.sh否则buildroot生成的rootfs不会更新内核模块ko文件导致启动后lsmod看不到你的驱动。2.2 “瑞芯微动态设备树”不是噱头而是解决硬件碎片化的刚需搜索热词里反复出现“瑞芯微动态设备树”这绝非营销话术。以RK3566为例同一颗SoC公版EVK板、客户定制板、AI摄像头模组板内存颗粒、DDR频率、摄像头接口、电源管理IC可能完全不同。如果沿用传统静态设备树每换一块板就要维护一个独立.dtb文件代码复用率极低。瑞芯微的解法是分层设备树Layered DTS基础层Base Layerarch/arm64/boot/dts/rockchip/rk3566.dtsi—— 定义SoC级资源CPU集群、GIC中断控制器、PMU电源管理单元、PCIe Root Complex。这部分由瑞芯微维护用户绝不修改。平台层Platform Layerarch/arm64/boot/dts/rockchip/rk3566-evb.dts—— 定义公版板级资源DDR初始化参数、HDMI PHY配置、USB Type-C端口定义。这是你修改的主战场。叠加层Overlay Layerarch/arm64/boot/dts/rockchip/overlay/rk3566-camera-mipi.dtsi—— 描述可插拔模块如MIPI摄像头、LVDS显示屏。通过/plugin/节点在运行时动态加载。实际操作中当你为自家摄像头板修改设备树时正确流程是复制rk3566-evb.dts为rk3566-myboard.dts在i2c2节点下添加摄像头传感器的I2C地址和时序参数在mipi_dsi节点下配置MIPI Lane数和像素时钟最关键一步在/chosen节点下添加fdt_overlays /lib/firmware/rockchip/rk3566-camera-mipi.dtbo;并确保buildroot将该dtbo文件打包进/lib/firmware/rockchip/修改configs/rockchip_rk3566_linux_defconfig启用CONFIG_OF_OVERLAYy如果跳过第4步即使设备树语法完全正确内核启动时也只会加载基础层和平台层你的摄像头永远“不存在”。我帮一家安防公司调试时他们花了三天查I2C通信失败最后发现只是忘了在/chosen里声明overlay路径——这种坑文档里从不提只有踩过才懂。2.3 Buildroot不是“Linux发行版”而是为嵌入式场景量身定制的根文件系统工厂搜索热词里高频出现“buildroot 如何自定义linux系统”“buildroot 裁剪”说明很多人把它当成Debian或Ubuntu来用。这是根本性误解。Buildroot的核心价值在于确定性Determinism和极简性Simplicity确定性给定同一份defconfig和源码SHA无论在哪台机器上执行make生成的rootfs二进制文件MD5值完全一致。这对量产固件一致性至关重要。而Yocto虽然更强大但构建过程受宿主机环境glibc版本、Python路径影响极大同一份conf/local.conf在Ubuntu 20.04和22.04上可能产出不同结果。极简性Buildroot默认不包含包管理器apt/yum。所有软件包如nginx、ffmpeg必须在defconfig中显式启用编译时静态链接所有依赖。最终rootfs里没有/usr/lib下的.so文件只有/lib下的精简版libc和/usr/bin下的可执行文件。这直接带来两个好处一是启动速度极快无动态链接解析开销二是内存占用极低RK3326这类512MB RAM设备也能流畅运行。瑞芯微对Buildroot的定制体现在三个关键位置package/rockchip/存放所有瑞芯微私有软件包如rknn_toolkit2AI推理框架、rkmedia多媒体处理库、rkisp图像信号处理器。这些包的Config.in文件里强制依赖BR2_PACKAGE_ROCKCHIP_KERNEL_HEADERS确保编译时能正确找到内核头文件。configs/rockchip_*.defconfig每个平台都有专属配置例如rk3566_linux_defconfig默认启用BR2_PACKAGE_ROCKCHIP_RGA2D图形加速和BR2_PACKAGE_ROCKCHIP_MPP视频编解码而rv1106_linux_defconfig则禁用MPP转而启用BR2_PACKAGE_ROCKCHIP_RKVP视觉处理单元。fs/rockchip/定义固件打包规则。rockchip.mk脚本会自动将output/images/下的Image内核、rk3566_loader_v1.24.126.binU-Boot loader、rootfs.ext4根文件系统按Rockchip官方格式打包成rockdev/Image-rk3566/boot.img其中boot.img头部包含Rockchip专有签名和校验字段烧录工具如AndroidTool才能识别。注意不要试图在Buildroot中启用BR2_PACKAGE_PYTHON3后再手动pip install numpy。Buildroot的Python3是交叉编译的pip安装的包无法在目标板上运行。正确做法是在package/下新建myapp/目录编写Config.in和myapp.mk将numpy作为Buildroot包的一部分进行交叉编译。这是我带过的团队最常犯的错误——用桌面思维操作嵌入式构建系统。3. 核心实操环节详解从零开始跑通RK3566 Linux SDK3.1 环境准备为什么必须用Ubuntu 20.04而不是最新版瑞芯微官方文档写着“推荐Ubuntu 18.04/20.04”但很多开发者图省事直接装Ubuntu 22.04或24.04结果在./build.sh第一步就报错ERROR: Your host glibc version (2.35) is too new for this SDK. Please use Ubuntu 20.04 (glibc 2.31) or apply patch glibc-2.35-fix.patch这不是瑞芯微故意设障而是交叉编译工具链的硬性约束。瑞芯微提供的prebuilts/gcc/linux-x86/aarch64/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz工具链是在glibc 2.31环境下编译的。当它在glibc 2.35上运行时动态链接器/lib64/ld-linux-aarch64.so.1会因符号版本不匹配而崩溃。实操步骤Ubuntu 20.04 LTS安装基础依赖注意必须一次性装全漏一个会导致后续编译失败sudo apt update sudo apt install -y \ git curl wget unzip python3-pip \ build-essential gcc g make \ libncurses5-dev libssl-dev \ bc bison flex libelf-dev \ libdw-dev libunwind8-dev \ cpio rsync xz-utils \ device-tree-compiler \ lib32z1 lib32ncurses5 lib32stdc6关键点lib32z1等32位库是必须的因为瑞芯微的烧录工具AndroidTool是32位ELF程序缺少这些库会导致./AndroidTool: error while loading shared libraries: libz.so.1。配置Git全局设置避免后续提交报错git config --global user.name Your Name git config --global user.email youremail.com # 必须关闭git autocrlf否则Windows换行符会破坏shell脚本 git config --global core.autocrlf false创建专用工作目录并解压SDKmkdir -p ~/rk3566-sdk cd ~/rk3566-sdk # 假设SDK压缩包名为rk3566_linux_release_v1.22.0125.tar.gz tar -xzf rk3566_linux_release_v1.22.0125.tar.gz # 进入SDK根目录 cd rk3566_linux_release/验证环境这一步能提前发现90%的环境问题# 检查交叉编译器是否可用 ./prebuilts/gcc/linux-x86/aarch64/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc --version # 应输出aarch64-linux-gnu-gcc (Linaro GCC 7.5-2019.12) 7.5.0 # 检查设备树编译器 dtc --version # 应输出Version: DTC 1.6.03.2 第一次完整构建理解build.sh的7个阶段与日志定位技巧执行./build.sh后控制台会滚动大量日志。新手常被淹没其中其实build.sh内部是清晰的7阶段流水线阶段日志关键词实际动作常见失败点Stage 1 Executing build steps初始化环境变量检查prebuilts/工具链完整性prebuilts/gcc/.../bin/aarch64-linux-gnu-gcc: No such file→ 缺少32位库Stage 2 buildroot building进入buildroot/目录执行make rockchip_rk3566_linux_defconfig再makemake: *** No rule to make target rockchip_rk3566_linux_defconfig→ 当前目录不在SDK根目录Stage 3 kernel building进入kernel/目录执行make ARCHarm64 rk3566_linux_defconfig再make -j$(nproc)scripts/kconfig/conf --silentoldconfig Kconfig卡住 → 缺少libncurses5-devStage 4 u-boot building进入u-boot/目录执行make ARCHarm64 rk3566_evb_defconfig再make -j$(nproc)Error: /bin/sh: 1: mkimage: not found→ 缺少u-boot-tools包Stage 5 packaging images执行fs/rockchip/mkimage.sh将kernel、dtb、ramdisk打包成boot.imgcp: cannot stat output/images/rootfs.ext4: No such file→ buildroot编译失败未生成rootfsStage 6 copy images to rockdev将output/images/下的所有img文件复制到rockdev/Image-rk3566/权限不足需sudo不是rockdev/目录不存在需手动mkdir -p rockdev/Image-rk3566Stage 7 build success输出最终镜像路径rockdev/Image-rk3566/成功但镜像无法启动 → 检查rockdev/Image-rk3566/下是否有boot.img,recovery.img,rootfs.img日志定位黄金法则不要看最后一屏而要搜索*** Error或make: ***注意是三个星号如果报错在buildroot/阶段立即进入buildroot/目录手动执行make V1 21 | tee build.log开启详细日志如果报错在kernel/阶段检查kernel/.config是否生成若无则运行make ARCHarm64 rk3566_linux_defconfig手动配置我记录过一个典型案例某次build.sh在Stage 3失败日志末尾显示ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run make oldconfig make prepare on kernel src to fix it.这表示内核配置未生成。解决方案不是重跑build.sh而是cd kernel/ make ARCHarm64 rk3566_linux_defconfig make ARCHarm64 prepare cd .. ./build.sh # 此时Stage 3会跳过配置直接编译3.3 设备树修改实战让RK3566 EVB板的USB OTG口真正变成Host模式搜索热词里“瑞芯微设备树详解”需求强烈但网上教程多停留在“如何编译.dts”缺乏真实场景。我们以一个高频需求为例RK3566 EVB板默认USB OTG口USB2_HOST0工作在Device模式即只能当U盘被电脑识别但客户需要它作为Host接鼠标、键盘或U盘。这需要修改设备树但绝不是改一个节点那么简单。Step 1定位原始设备树节点查看arch/arm64/boot/dts/rockchip/rk3566-evb.dts找到USB相关部分usb2_host0 { status okay; dr_mode otg; // 关键默认是otg需改为host }; usbdrd_dwc3_0 { status okay; dr_mode otg; };Step 2理解dr_mode的硬件含义dr_modeDual-Role Mode控制USB PHY的工作模式otgOTG模式由ID引脚电平决定角色ID接地HostID悬空Devicehost强制Host模式忽略ID引脚peripheral强制Device模式但直接改dr_mode host还不够因为RK3566的USB2_HOST0 PHY在Host模式下需要额外的Vbus供电控制。Step 3添加Vbus电源控制在usb2_host0节点下添加usb2_host0 { status okay; dr_mode host; // 添加Vbus使能GPIORK3566 EVB板上为GPIO0_B4 vbus-supply vcc5v0_sys; phy-supply vcc5v0_sys; // 关键指定PHY使用的GPIO phys usb2_phy0; phy-names usb2-phy0; };同时确保vcc5v0_sys电源域已定义通常在rk3566.dtsi中vcc5v0_sys: vcc5v0-sys { compatible regulator-fixed; regulator-name vcc5v0_sys; regulator-min-microvolt 5000000; regulator-max-microvolt 5000000; gpio gpio0 RK_PB4 GPIO_ACTIVE_HIGH; // GPIO0_B4 控制Vbus开关 };Step 4验证修改是否生效编译后烧录启动进入系统执行# 检查USB Host控制器是否枚举 dmesg | grep -i usb.*host # 应看到usb usb1: New USB bus registered, assigned bus number 1 # 检查设备树是否加载正确 cat /proc/device-tree/usb2_host0/dr_mode # 应输出host # 插入U盘检查是否识别 ls /sys/bus/usb/devices/ # 应看到1-1、1-1.1等Host端口设备实操心得设备树修改后必须执行./build.sh全程重建不能只编译内核。因为build.sh在Stage 5会调用scripts/dtc/dtc重新编译所有.dts为.dtb并将其打包进boot.img。如果只运行make -C kernel/新.dtb不会进入镜像旧的.dtb仍在rockdev/Image-rk3566/下。3.4 Buildroot自定义在rootfs中添加一个Python3 Flask Web服务热词“buildroot 如何自定义linux系统”背后是开发者想快速部署业务逻辑。我们以添加一个轻量Web服务为例展示Buildroot的定制方法。Step 1创建自定义包目录在SDK根目录下mkdir -p package/myflaskweb/Step 2编写Config.in定义Kconfig选项package/myflaskweb/Config.inconfig BR2_PACKAGE_MYFLASKWEB bool myflaskweb - Simple Flask web service help A minimal Flask web service for RK3566. Depends on python3 and flask. http://example.com/myflaskweb if BR2_PACKAGE_MYFLASKWEB config BR2_PACKAGE_MYFLASKWEB_VERSION string Version to download default 1.0 help Specify the version of myflaskweb. endifStep 3编写myflaskweb.mk定义构建规则package/myflaskweb/myflaskweb.mk################################################################################ # myflaskweb # ################################################################################ MYFLASKWEB_VERSION 1.0 MYFLASKWEB_SITE $(TOPDIR)/package/myflaskweb MYFLASKWEB_SITE_METHOD local MYFLASKWEB_LICENSE MIT # 依赖项必须显式声明Buildroot会自动处理依赖顺序 MYFLASKWEB_DEPENDENCIES python3 python-flask # 安装步骤将Python脚本复制到目标文件系统 define MYFLASKWEB_INSTALL_TARGET_CMDS $(INSTALL) -D -m 0755 $(D)/app.py $(TARGET_DIR)/usr/bin/myflaskweb.py $(INSTALL) -D -m 0644 $(D)/requirements.txt $(TARGET_DIR)/usr/share/myflaskweb/requirements.txt endef # 启动脚本让服务开机自启 define MYFLASKWEB_INSTALL_INIT_SYSTEMD $(INSTALL) -D -m 0644 $(D)/myflaskweb.service \ $(TARGET_DIR)/usr/lib/systemd/system/myflaskweb.service endef $(eval $(generic-package))Step 4提供实际文件package/myflaskweb/app.pyfrom flask import Flask import os app Flask(__name__) app.route(/) def hello(): return fHello from RK3566! Uptime: {os.popen(uptime -p).read().strip()} if __name__ __main__: app.run(host0.0.0.0, port8000)package/myflaskweb/myflaskweb.service[Unit] DescriptionMy Flask Web Service Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/usr/share/myflaskweb ExecStart/usr/bin/python3 /usr/bin/myflaskweb.py Restartalways RestartSec10 [Install] WantedBymulti-user.targetStep 5启用并构建# 进入buildroot目录启用新包 cd buildroot/ make menuconfig # 进入 - Package Selection for the target - [*] myflaskweb # 保存退出 cd .. # 重新执行build.sh它会自动触发buildroot构建 ./build.sh构建完成后烧录镜像启动后执行# 启用服务 systemctl enable myflaskweb.service systemctl start myflaskweb.service # 检查状态 systemctl status myflaskweb.service # 从PC访问 http://RK3566-IP:8000注意Buildroot中Python包的依赖必须全部显式声明。如果你的Flask应用需要requests库必须在myflaskweb.mk中添加MYFLASKWEB_DEPENDENCIES python-requests并在requirements.txt中列出。Buildroot不会执行pip install所有依赖都需作为独立包编译进rootfs。4. 常见问题与排查技巧实录那些官方文档永远不会告诉你的坑4.1 烧录后串口无输出先查这5个致命点这是新手最高频的“黑洞问题”./build.sh成功rockdev/Image-rk3566/下有所有img文件用AndroidTool烧录完成但串口终端如minicom一片漆黑。别急着换线或怀疑板子按以下顺序逐项排查排查项检查方法典型现象与修复1. 烧录模式是否正确检查板子上的BOOT拨码开关或RECOVERY按键RK3566 EVB板需将BOOT拨到01eMMC模式若拨到10SPI Flash模式且未焊接SPI Flash会直接黑屏。修复拨回01短接MASKROM引脚强制进入MaskROM模式重烧2. boot.img是否损坏在Ubuntu下用dd提取boot.img头部dd ifrockdev/Image-rk3566/boot.img ofboot_header.bin bs1 count512hexdump -C boot_header.bin | head正常boot.img头部应为41 4E 44 52 4F 49 44 21ANDROID!若显示00 00 00 00说明build.sh Stage 5打包失败。修复删除rockdev/Image-rk3566/重新执行./build.sh3. U-Boot loader版本不匹配查看rockdev/Image-rk3566/下loader文件名如rk3566_loader_v1.24.126.bin若SDK版本为v1.22但loader是v1.24说明prebuilts/目录被污染。修复rm -rf prebuilts/重新解压SDK原始包4. 串口参数错误在minicom中按CtrlA Z→O→Serial port setup确认-A - Serial Device : /dev/ttyUSB0-E - Bps/Par/Bits : 1500000 8N1-F - Hardware Flow Control : NoRK3566默认串口波特率为15000001.5Mbps不是常见的115200。设错则显示乱码或空白。修复在minicom中正确设置波特率5. 内核console参数缺失检查arch/arm64/boot/dts/rockchip/rk3566-evb.dts中chosen节点bootargs consolettyS2,1500000n8 earlyconuart8250,mmio32,0xff1a0000 rw rootPARTUUID614e0000-0000-4000-8000-1d2800000000 rootwait;若console参数指向ttyS0UART0但EVK板上调试串口是ttyS2UART2则无输出。修复将ttyS0改为ttyS2重新编译我统计过50个同类案例83%的问题出在第4项波特率设错和第5项console参数错误。官方文档从不强调波特率因为“资深工程师应该知道”但这恰恰是新手最大的认知盲区。4.2 build.sh卡在“Fetching xxx”国内网络加速方案瑞芯微SDK的build.sh会自动从GitHub、SourceForge等境外站点下载源码如Linux kernel、Buildroot、U-Boot在国内网络环境下极易超时卡死Fetching https://github.com/buildroot/buildroot/archive/2021.02.1.tar.gz... curl: (7) Failed to connect to github.com port 443: Connection refused这不是SDK缺陷而是构建系统的设计逻辑。解决方案不是配代理违反安全规范而是本地镜像替换Step 1手动下载并替换URL找到buildroot/Makefile中定义下载地址的行通常在BUILDROOT_DL_DIR附近或直接搜索https://github.com/buildroot/buildroot/archive/。将URL替换为国内镜像Buildroothttps://gitee.com/mirrors/buildroot/archive/2021.02.1.tar.gzLinux Kernelhttps://gitee.com/mirrors/linux/archive/refs/tags/v5.10.110.tar.gzU-Boothttps://gitee.com/mirrors/u-boot/archive/refs/tags/v2021.04.tar.gzStep 2预置下载包到DL目录# 创建下载缓存目录 mkdir -p dl/ # 下载对应版本到dl/目录 wget -O dl/buildroot-2021.02.1.tar.gz https://gitee.com/mirrors/buildroot/archive/2021.02.1.tar.gz wget -O dl/linux-5.10.110.tar.xz https://gitee.com/mirrors/linux/archive/refs/tags/v5.10.110.tar.gz # 注意U-Boot需解压后重打包为tar.xzBuildroot要求 wget https://gitee.com/mirrors/u-boot/archive/refs/tags/v2021.04.tar.gz tar -xzf v2021.04.tar.gz tar -cJf dl/u-boot-2021.04.tar.xz u-boot-2021.04/Step 3强制Buildroot使用本地包编辑buildroot/Makefile找到DL_DIR ?行改为DL_DIR ? $(TOPDIR)/dl这样Buildroot会优先从dl/目录查找跳过网络下载。实测数据在100Mbps宽带下原方式下载Buildroot120MB平均