当我们获取到SDK时，第一眼看到的是十几个顶层目录。它们并不都是"源码"------有的是构建框架，有的是配置，有的纯粹是产物中转站。分不清这三类，后面找源码、找配置、找产物都容易走错。 上篇文章先把顶层地图按用途摊开，再沿着7 个符号链接进入device/rockchip，最后一路看到output/ 和rockdev/。读完后，你会清楚整个SDK的"源码树→构建产物"链路是怎么串起来的。
本文以触觉智能RK3506开发板作为案例进行演示，带大家走一遍完整流程~
一、顶层全景
先按用途 分组，比按字母顺序看要清晰得多：
| 分组 | 目录 | 职责 |
|---|---|---|
| 构建框架 | device/rockchip/ | 板级配置与构建框架本体 |
| 源码 | u-boot/ | 引导加载器 |
| kernel-6.1/ | Linux 内核 | |
| buildroot/ | 根文件系统构建系统 | |
| rtos/、hal/ | RT-Thread 与硬件抽象层（AMP 双系统用） | |
| yocto/ | 另一条 rootfs 构建线 | |
| rootfs/ | Ubuntu rootfs 的预置镜像 | |
| 上层组件 | app/ | 应用代码（rkadk、lvgl_demo） |
| external/ | 官方与第三方组件（rkscript、recovery、rkwifibt...） | |
| prebuilts/ | 预编译的交叉工具链 | |
| rkbin/ | Rockchip 二进制（DDR 初始化、Loader 等） | |
| tools/ | 主机侧工具（linux/mac/windows） | |
| 产物 | output/ | 全部构建产物 |
| 文档 | docs/ 及各类 *_series/ | 说明与教程 |
一个快速的规模感：u-boot/有65 个一级条目、buildroot/ 35 个、rtos/ 24 个------都是完整的上游项目原样收编，SDK 自己的工作集中在 device/rockchip/。
二、七个符号链接：伪装成文件的入口
顶层看到的 build.sh、Makefile、kernel 这些，没有一个是真实文件 ，全是符号链接：
build.sh -> device/rockchip/common/scripts/build.shMakefile -> device/rockchip/common/MakefileREADME.md -> device/rockchip/common/README.mdrkflash.sh -> device/rockchip/common/scripts/rkflash.shcommon -> device/rockchip/commonkernel -> kernel-6.1rockdev -> output/firmware这样安排有两个好处：命令都在顶层敲（./build.sh、make），而实现和配置集中在device/rockchip/，整个SDK是多仓库拼起来的，顶层只保留统一入口。
其中kernel -> kernel-6.1这个链接值得注意：内核目录带版本号，链接名不带。后续如果Linux内核升级到6.6，只需要改链接指向，build.sh里的路径不用动。
注意：正因为 build.sh 是符号链接，git status 里看到的修改会出现在 device/rockchip/common/scripts/ 下，而不是顶层。改构建脚本时不要找错位置。
三、device/rockchip/：三层职责
这个目录是 SDK 真正"自己写"的部分，内部又分三层：
device/rockchip/├── common/ # 构建框架：与芯片无关的通用逻辑│ ├── build-hooks/ # 分阶段的构建钩子（00-config ~ 99-all）│ ├── post-hooks/ # 根文件系统后期处理│ ├── scripts/ # build.sh 本体与各 mk-*.sh│ ├── configs/ # Kconfig 定义│ ├── overlays/ # 通用 rootfs overlay│ └── kconfig/ # 配置系统├── .chips/│ └── rk3506/ # 芯片相关：板级 defconfig、parameter、its└── .chip -> .chips/rk3506 # "当前选中的芯片"common/ 处理"怎么构建"，.chips/<芯片>/ 处理"构建成什么样"。 两者的分界线很干净：换一块别的 Rockchip 板子，common/ 基本不动，改的是 .chips/ 下的配置。
.chip这个链接是"当前芯片"的指针。构建脚本里大量使用$RK_CHIP_DIR，展开就是device/rockchip/.chip，也就是当前芯片目录。切芯片本质上是改这个链接。
四、output/：产物都去哪了
所有构建产物都在output/下，一次构建之后的结构：
output/├── .config # SDK 级配置（RK_* 变量）├── defconfig -> ../device/rockchip/.chips/rk3506/<板级 defconfig>├── sessions/ # 每次构建的日志与环境快照├── firmware/ # 最终可烧录镜像├── buildroot/ # buildroot 的完整输出├── recovery/ # recovery 镜像├── extra-parts/ # oem / userdata 分区镜像└── update/ # update.img其中sessions/是排查构建问题时最该先看的地方。每次构建会新建一个以时间戳命名的目录：
output/sessions/2026-09-26_20-22-17/├── 99-all-build_<时间戳>.log # 顶层构建日志├── br-rockchip_rk3506_<时间戳>.log # buildroot 的完整日志├── build_<时间戳>.log├── .config # 本次构建用的配置快照├── initial.env / final.env # 构建前后的环境变量快照└── part-table # 本次算出的分区表initial.env和final.env特别有用------它们记录了本次构建实际生效 的所有 RK_* 变量，比看 .config 更直接，能确认某个开关有没有真的传下去。
五、rockdev 与 output/firmware：同一个目录
rockdev -> output/firmware两个名字指向同一个地方。rockdev/是Rockchip工具链的历史习惯用法（烧录工具默认从这里取镜像），output/firmware/是新的组织方式，用链接保持兼容。
这个目录里的内容有个特点：全是符号链接，没有一个是真实文件 。
$ ls -l output/firmware/boot.img -> ../../kernel-6.1/zboot.imguboot.img -> ../../u-boot/uboot.imgMiniLoaderAll.bin -> ../../u-boot/rk3506_spl_loader_v1.06.111.binrootfs.img -> ../../buildroot/output/rockchip_rk3506/images/rootfs.ubirecovery.img -> ../recovery/ramboot.imgparameter.txt -> ../../device/rockchip/.chips/rk3506/parameter-flash.txtoem.img -> ../extra-parts/oem.imguserdata.img -> ../extra-parts/userdata.imgupdate.img -> ../update/Image/update.imgmisc.img -> ../misc.img这样设计的好处是产物只有一份 。rootfs.img 永远指向最新构建出来的 rootfs.ubi，不存在"rockdev 里是旧的、buildroot 里是新的"这种同步问题。烧录工具读 rockdev/，拿到的就是最新产物。
上篇看到这儿，SDK 的目录地图基本就印在脑子里了：
-
入口是顶层那几个符号链接，大脑是device/rockchip，仓库是output；
-
rockdev/ 就是output/firmware/ 的另一个名字，产物只有一份，随便翻。
不过产物归产物，板子还没上场。下篇我们要带着这张地图上板：512 字节扇区怎么变成 /proc/mtd 上的字节，UBI 卷是谁挂起来的，想改配置该去哪个目录------都会讲到。相关资料，请关注深圳触觉智能