简介：《Rockchip RK3229 软件开发指南 V1.03》是瑞芯微面向软件开发工程师与技术支持工程师编写的芯片开发调试参考文档，聚焦 RK3229 在 Linux3.10 内核下搭配 Android 6.0.1 与 7.1.2 的完整开发流程，适合嵌入式底层开发与方案移植人员查阅。资源包共 1 个文件，为 1.61MB 的 PDF 文档，单册即涵盖全部章节，便于离线检索与随查随用。目前已有 627 人学习下载。内容从 DDR、NAND、EMMC、WiFi/BT 及多媒体编解码支持列表切入，明确硬件选型边界；随后讲解 SDK 获取、编译与固件烧写，并给出 system 分区大小配置、odex 预编译、禁用 SELinux、jack-server 配置、USB 默认开启 ADB、开机视频与低内存优化、DRM WIDEVINE level 1 等实操说明，另附 Box 产测工具、序列号/Mac 烧写工具与开机 logo 限制描述，可帮助读者快速定位配置项、少走调试弯路。

1. 一份 2017 年的 RK3229 开发指南，为什么现在还有人翻出来用

手里攥着一块 RK3229 的电视盒子板子，串口接上，上电，U-Boot 跑完就卡住，或者 Android 起来了但 ADB 死活连不上——这种场景在二手盒子、定制机顶盒、广告机主板上太常见了。RK3229 是四核 Cortex-A7 的 32 位 SoC，定位就是低成本多媒体盒子，2017 年前后出货量很大，如今大量板子流入开发者手里，配套的 SDK 和文档却散落在各处。这份《Rockchip RK3229 软件开发指南 V1.03》就是当年随 SDK 发布的官方开发手册，覆盖 Linux3.10 内核 + Android 6.0.1/7.1.2 两套系统，从 DDR/NAND/eMMC 选型、SDK 编译烧写、U-Boot 配置、内核 DTS 修改，一直到 Android 分区、OTA、低内存优化、Widevine DRM 配置和量产工具链，基本把从点亮板子到小批量产的全流程串了一遍。它适合两类人：手里有 RK3229 硬件、想自己编译固件或改系统的嵌入式工程师；以及需要理解这套老平台启动链路和分区结构、做维护或二次开发的技术支持。不适合想找“最新最全”资料的人——这是 2017 年的文档，很多工具版本和路径已经和现在的环境对不上，但平台本身的硬件约束和启动逻辑没变，这才是它仍然值钱的地方。

2. 先看清平台边界：DDR、eMMC、WiFi 选型与 SDK 适用硬件

拿到一份老 SDK，最忌讳上来就make。RK3229 这套东西对物料是有硬性白名单的，选错颗粒，编译再顺也起不来。这一章把文档里最影响“能不能跑”的硬件约束和 SDK 适用范围拆开讲，先立住选型逻辑，再谈动手。

2.1 DDR 与存储颗粒：只认 √ 和 T/A 标记

RK3229 的 DRAM 支持 DDR3、LPDDR2、LPDDR3 三类，但“支持这个类型”和“支持你手上这颗具体型号”是两回事。文档里明确指向RKDocs\Platform support lists目录下的《RK DDR Support List Ver2.24》，颗粒支持程度用符号标注：

NAND 和 eMMC 是同一套逻辑，分别对应《RKNandFlashSupportList》和《RKeMMCSupportList》。这里有个血泪经验：很多人从旧盒子上拆一颗 eMMC 焊到新板子上，觉得“都是 eMMC 4.51，应该能跑”，结果卡在 U-Boot 的存储初始化阶段，串口只打印几行就没了。原因就是那颗颗粒不在支持列表里，时序参数对不上。RK3229 支持 eMMC 4.51、SDIO3.0、HS200 模式，文档还专门提了高性能颗粒的筛选标准——顺序读 >200MB/s、顺序写 >40MB/s，这个门槛在当年算中上，现在看依然是个合理的性能基线。选型时直接翻厂商 Datasheet 的 performance 章节对一遍，比事后调时序省事得多。

WiFi/BT 更严格。RK3229 跑的是 Linux3.10 内核，WiFi 驱动必须匹配这个内核版本。文档指向《Rockchip_WiFi_Situation_20170214》，列表里是大量实测过的芯片。如果你手上是一颗列表外的 WiFi 模组，唯一的路是让模组原厂提供 Linux3.10 版本的内核驱动源码，自己往 SDK 里移植。这一步的坑在于：很多模组厂只维护 Android 高版本内核的驱动，3.10 的代码早就归档了，拿不到就只能换料。

2.2 SDK 适用硬件与内核配置入口

这份 SDK 是基于 Android 6.0.1 及之后的 32 位系统，适配 RK3229 Box EVB 开发板和 Box 样机板。内核配置的改动入口是RK3229-box.dts，这是整份文档里出现频率最高的文件名之一。硬件设计参考文档在RKDocs\Platform support lists\RK322X 硬件设计指南，EVB 和样机板共用同一份。

实际动手时，我一般先做三件事确认平台边界，再碰编译：

# 1. 确认 SDK 目录结构里 RKDocs 和 kernel 都在 ls -d RKDocs kernel u-boot device 2>/dev/null # 2. 查当前 dts 用的是哪个板级配置 ls kernel/arch/arm/boot/dts/ | grep -i rk3229 # 3. 确认交叉编译工具链版本（文档对应的是 2017 年前后的 gcc 4.6/4.9 系列） arm-linux-gnueabihf-gcc --version | head -1

第一行是确认 SDK 完整性，缺RKDocs说明拿到的包被裁剪过，支持列表查不了；第二行定位板级 dts，RK3229 常见的有rk3229-box.dts、rk3229-sdk.dts等变体，改错文件等于白改；第三行是工具链核对，用太新的 gcc 编 3.10 内核大概率报一堆 warning 甚至 error，文档时代的工具链是 gcc 4.6/4.9，这个版本约束后面编译章节还会踩到。

提示：支持列表文档的版本号（如 DDR Ver2.24、eMMC Ver1.33）是判断 SDK 新旧的一个侧面依据，如果手上的列表版本比文档里写的还老，说明这个 SDK 包可能被替换过，编译前先跟硬件实际物料对一遍。

3. SDK 编译与烧写：从 source 到 update.img 的完整链路

平台边界清楚了，进入真正的动手环节。这一章按“取 SDK → 编译 → 烧写 → 量产”的顺序走，每一步给出可抄的命令和参数含义，重点放在编译配置和烧写模式选择上，因为这两处是新手翻车最集中的地方。

3.1 SDK 编译：环境变量、lunch 选择与 jack-server

RK3229 SDK 的编译流程是 Rockchip 那套经典结构：先source环境脚本，再lunch选目标，最后make。文档 3.2 节覆盖了编译配置，3.2.6 补了 system 分区大小、odex 预编译、禁用 selinux 三项，3.2.7 专门讲 jack-server 配置——这个不是可选项，Android 7.1 编译必须过 jack。

# 进入 SDK 根目录后，先加载编译环境 source build/envsetup.sh # 列出可选目标，RK3229 通常对应 rk3229_box-userdebug 之类 lunch # 选定目标后开始编译，-j 按 CPU 核数给，一般 核数+2 make -j8 # 如果编译报 jack-server 相关错误，先看配置 cat ~/.jack-settings

source build/envsetup.sh把lunch、m、mm这些函数注入当前 shell，不执行这步后面所有命令都找不到；lunch不带参数会打印可选目标列表，RK3229 的 Box 配置一般带rk3229和box字样，选错目标会导致 dts 和分区表不匹配；make -j8的并行度不是越大越好，老机器上-j16反而因为内存不足触发 OOM，编译中途被杀，日志里只留一句Killed，很容易误判成代码问题。

jack-server 的坑值得单独说。Android 7.1 用 jack 编译 Java 部分，它默认起一个本地服务，端口和 TLS 配置写在~/.jack-settings和~/.jack-server/config.properties里。常见现象是编译到一半报Failed to contact Jack server，原因多半是之前编译残留的 jack 进程占着端口，或者jack.server.service.port和jack.server.admin.port被别的程序占了。解决办法是先jack-admin kill-server，再检查两个端口是否空闲，必要时改配置里的端口号。文档 3.2.7 给的就是这套配置说明，照着改比盲目重装环境靠谱。

system 分区大小和 odex 预编译也在这一节。system 分区在parameter文件里定义，改小了刷机后空间不足，改大了浪费 eMMC；odex 预编译影响首次开机速度和 system 占用，量产固件一般开，调试固件可以关掉省编译时间。禁用 selinux 的方法文档也放在 3.2.6，调试阶段关掉能少一堆权限报错，但量产前必须恢复，这个后面避坑章节会再提。

3.2 固件烧写与量产：Maskrom 模式与工具选择

编译产物最终要落到板子上。文档 3.3 讲固件烧写，3.4 讲量产烧写，工具侧在 8.5 到 8.9 有 update.img 打包、固件签名、WNpctool 烧序列号/MAC、OemTool 打包、量产工具。烧写的第一道坎是让板子进对模式。

RK3229 常见的烧写模式有两种：Loader 模式和 Maskrom 模式。Loader 模式要求板子上已有可用的 U-Boot，工具通过它来写 flash；Maskrom 模式是芯片级的，板子完全没系统或者 U-Boot 坏了也能进，通常靠按住 recovery 键上电或者短接 flash 的特定引脚触发。新手最容易卡在“工具识别不到设备”，八成是模式没进对。

# 板子进 Maskrom 后，Linux 主机上确认 USB 设备是否枚举 lsusb | grep -i rockchip # 用 upgrade_tool 查询设备状态（工具在 RKTools 目录下） sudo ./upgrade_tool ld # 烧写完整 update.img sudo ./upgrade_tool uf update.img

lsusb能看到 Rockchip 的 USB 设备，说明 Maskrom 进成功了，看不到就回去检查按键时序和 USB 线（劣质线只供电不传数据是经典坑）；upgrade_tool ld列出当前连接的设备，返回Maskrom或Loader字样；uf是烧写完整固件，如果只想烧单个分区（比如只更新 boot 或 kernel），用di -p partition_name image_file更省时间。量产阶段则走 8.9 的量产工具，配合 8.7 的 WNpctool 烧序列号和 MAC——这一步在产线上是独立工位，因为序列号和 MAC 必须一机一码，不能打进公共 update.img 里。

注意：固件签名（8.6）在开启安全启动的板子上是必须的，签名工具和密钥管理要提前规划，临时补签会导致已烧写的板子无法升级。

4. U-Boot 与内核配置：logo、DTS、GPIO 与频率调整

系统能起来之后，接下来就是“按产品需求改”。这一层的工作集中在 U-Boot 和内核 dts，改动看似零散，但每一处都直接对应一个可见的产品行为：开机画面、WiFi 能不能用、GPIO 电平对不对、跑多快、热不热。

4.1 U-Boot logo 与固件生成

文档第 4 章讲 U-Boot 开发，4.1 是简介，4.2 平台配置，4.3 固件生成，4.4 编译，4.5 是 logo 相关配置，其中 4.5.2 在 V1.03 里新增了开机 logo 限制描述。U-Boot 阶段的 logo 和 Android 开机动画是两回事：前者是内核起来之前显示的那张图，后者是bootanimation.zip。U-Boot logo 的限制主要在分辨率和格式，超出范围要么不显示，要么花屏。

# U-Boot 编译（在 u-boot 目录下） make rk3229_defconfig make -j8 # 固件生成依赖 rkbin 里的 loader 和 trust，确认路径 ls ../rkbin/RK3229* 2>/dev/null

make rk3229_defconfig载入平台默认配置，如果 SDK 里 defconfig 名字不同，用ls configs/ | grep 3229找；make -j8产出u-boot.bin等文件；第三行确认rkbin目录下有对应的 loader 和 trust 二进制，缺了会在打包阶段报错，而不是编译阶段，容易误判。logo 替换一般改u-boot里的 logo 源文件后重新编译，具体格式和尺寸限制看 4.5.2，文档明确写了限制条件，照着卡就不会花屏。

4.2 内核 DTS：WiFi/BT、GPIO 映射与频率温控

第 5 章是内核常见配置，5.1 DTS 介绍，5.2 WiFi&BT 配置，5.3 GPIO 对应关系，5.4 ARM/GPU 频率修改，5.5 温控配置，5.6 PWM IR，5.7 USB 默认打开 adb。这一章信息密度很高，几乎每条都是实际项目必改项。

DTS 是设备树，RK3229 的板级差异全在这里。WiFi/BT 配置涉及供电 GPIO、使能引脚、SDIO 总线参数，改错一个 GPIO 编号，WiFi 就扫不到热点。GPIO 对应关系（5.3）是重灾区：芯片手册的 GPIO 编号、dts 里的编号、sysfs 里看到的编号，三者换算关系不统一，文档专门列了注意点。我一般改完 dts 后先在 sysfs 里验证：

# 查看某个 GPIO 的当前方向和电平（编号需按平台换算） cat /sys/kernel/debug/gpio # 确认 WiFi 模组供电脚状态 cat /sys/class/gpio/gpioXX/value

/sys/kernel/debug/gpio列出所有已申请 GPIO 的归属和状态，能快速看出 dts 里配的引脚有没有被别的驱动占用；第二行读具体引脚电平，验证供电和使能时序。频率修改（5.4）和温控（5.5）要一起看：把 ARM/GPU 频率拉高，性能上去了，但温控阈值没同步调，机器跑一会儿就降频甚至关机。5.7 的 USB 默认打开 adb 调试是 V1.02 新增的，对调试阶段很实用，改的是 dts 或 defconfig 里的 adb 属性，量产前记得评估是否保留。

5. Android 层配置与系统调试：分区、OTA、低内存与 DRM

内核和 U-Boot 搞定，产品差异化的重头戏在 Android 层。第 6 章覆盖了预置 APK、开关机动画、parameter 分区、新增分区、OTA、预制 Demo、灾难恢复、禁用 selinux，以及 Android 7.1 专属的开机视频、低内存优化、Widevine Level 1 配置。第 7 章是调试工具：ADB、Logcat、Procrank、Dumpsys、音视频调试。这两章合起来，基本就是“把公版系统改成你的产品”的全部动作。

5.1 分区、OTA 与灾难恢复

parameter 文件定义分区表，6.5 专门讲它，6.6 讲新增分区。改分区表是高风险操作：改错起始地址或大小，轻则某个分区挂载失败，重则整机起不来。新增分区的典型场景是给客户预置一块数据区，做法是在 parameter 里加一行，再在 fstab 和 recovery 里同步，三处缺一不可。

OTA 升级（6.7）依赖分区布局和签名，改过分区表之后，旧的 OTA 包直接失效，必须重新出包。系统灾难恢复（6.9）是救砖手段，配合 Maskrom 模式使用，板子刷坏后能通过特定组合键或短接进入恢复流程。这两块建议在改分区之前就把恢复路径验证一遍，别等刷坏了才找后悔药。

5.2 低内存优化与 Widevine Level 1

6.12 的低内存优化是 V1.03 新增的 Android 7.1 配置。RK3229 定位低成本盒子，很多板子只有 512MB 或 1GB 内存，Android 7.1 默认的内存策略在这种配置上会频繁杀后台。文档给的优化项包括调整 lowmemorykiller 阈值、裁剪系统服务、控制缓存进程数。这些参数不是照抄就完事，要结合具体内存大小调：

6.13 的 Widevine Level 1 配置是流媒体产品绕不开的。Level 1 要求内容解密和视频解码都在可信执行环境里完成，配置涉及 trust 固件、keybox 和 OMX 组件，文档给的是配置步骤，但 keybox 本身需要走认证流程，不是改几个文件就能拿到。这一点要提前跟项目方对齐预期，别做到一半才发现认证周期比开发周期还长。

5.3 调试工具链：Procrank 与 Dumpsys 看什么

第 7 章的工具里，ADB 和 Logcat 大家都熟，真正拉开排查效率的是 Procrank 和 Dumpsys。Procrank（7.3）按内存占用排序进程，配合文档里的进程内存跟踪图，能快速定位是谁把内存吃光了；Dumpsys（7.4）能导出各系统服务的内部状态，比如dumpsys meminfo看整体内存分布、dumpsys activity看 Activity 栈。

# 按 PSS 排序看进程内存占用 procrank | head -20 # 看系统整体内存分布 dumpsys meminfo # 抓某个应用的详细内存 dumpsys meminfo com.example.app

procrank输出里重点看 PSS 列，USS 更能反映进程独占内存；dumpsys meminfo顶部的 Total PSS 和 Free RAM 是判断是否触发低内存回收的直接依据；第三条针对具体包名，能看到 Java Heap、Native Heap、Code 各段占用，定位是代码泄漏还是 native 库吃内存。音视频问题（7.5）文档指向专门的工具和文档，这类问题靠 log 很难定位，一般要配合码流分析和 OMX 组件日志。

6. 避坑与排查：五个真实翻车点

文档读得再细，实操还是会踩坑。这一章列五个高频问题，按“现象 → 原因 → 解决”写，都是这套平台上反复出现的。

6.1 编译报错找不到工具链

现象：make一开始就报arm-linux-gnueabihf-gcc: command not found或版本不匹配。原因：环境里装了新版工具链，PATH 优先命中，或者根本没装文档对应版本。解决：显式指定工具链路径，在device/rockchip相关配置里改TARGET_TOOLCHAIN，或者临时export PATH=/opt/gcc-arm-4.9/bin:$PATH前置。别用系统自带的 gcc 编 3.10 内核，warning 会淹没有效信息。

6.2 烧写工具识别不到设备

现象：upgrade_tool ld返回空，或 lsusb 看不到 Rockchip 设备。原因：板子没进 Maskrom/Loader 模式，或者 USB 线只供电。解决：先换一根确认能传数据的线，再按文档时序重新进 Maskrom（按住 recovery 上电，保持几秒再松）。如果板子之前刷过半截固件，可能停在异常状态，断电冷却后重试。

6.3 改完 dts 后 WiFi 不工作

现象：系统起来，WiFi 开关打不开或扫不到热点。原因：dts 里 WiFi 供电 GPIO 或使能引脚配错，或者 SDIO 总线参数和模组不匹配。解决：用/sys/kernel/debug/gpio核对引脚归属，用示波器或万用表量供电脚时序，再对照模组 Datasheet 检查 SDIO 时钟和总线宽度。改一处验证一处，别一次改五个参数。

6.4 低内存优化后桌面反复重载

现象：按 6.12 调完参数，切回桌面时 launcher 重新加载，体验很差。原因：lowmemorykiller 阈值调得太激进，把 launcher 的缓存进程也杀了。解决：把 launcher 相关进程加入白名单（oom_adj调低），或者适度放宽阈值，用procrank观察调整前后的 PSS 变化，找到平衡点。

6.5 禁用 selinux 后量产固件出问题

现象：调试阶段关了 selinux，功能都正常，量产固件恢复 selinux 后大量权限拒绝。原因：调试期依赖了宽松策略，没补对应的 sepolicy 规则。解决：调试阶段就用permissive而不是完全关闭，把 avc denied 日志收集起来补规则，量产前切回enforcing做一轮完整回归。这个坑的代价很高，量产后才发现要重新出固件。

7. 进阶验证：用 Kodi 与多媒体规格反推平台能力边界

文档第 1 章的支持列表里，有两块内容经常被忽略，但对判断“这块板子到底能干什么”特别有用：1.6 的多媒体编解码支持列表和 1.7 的 Kodi 支持程度。RK3229 的多媒体规格是 4K VP9 和 4K 10bit H265/H264 解码到 60fps，1080P 多格式解码（VC-1、MPEG-1/2/4、VP8），JPEG 解码，编码侧是 1080P H.264 和 JPEG。这些数字不是拿来背的，是拿来验证的。

我一般用 Kodi 做一轮平台能力压测，因为它同时压解码、音频透传和渲染。文档说 RK3229 的 OMX 框架支持官方 Kodi 16.1 Jarvis 和 17.0 Krypton，最高 4K 10bit 60fps 播放，17.0 还支持 AudioTrack 音频透传；同时推荐基于官方 16.1 深度定制的 RKMC 版本，默认集成在 SDK 里，额外支持 H265/H264/VP9 10bit@60fps 输出、ISO/MKV Framepacking MVC3D、AC3/EAC3/TrueHD/DTS/DTSHD 最高 7.1 声道透传、硬件去噪和去交错。验证时按这个顺序走：

如果 4K 片源播放时 CPU 占用飙到很高，说明走的是软解，OMX 硬解没生效，回去查 dts 里的 VPU 节点和 OMX 组件配置；音频透传失败，先确认 Kodi 音频输出设成了 passthrough，再查 HDMI 的 EDID 是否上报了对应格式。这套验证做完，平台的能力边界就清楚了，客户提“能不能播 4K”时你能给出有依据的答复，而不是拍脑袋。

从那以后我每次拿到一块 RK3229 的板子，都强制先跑一遍支持列表核对加 Kodi 压测，再动编译和改配置——先知道它能干什么，再决定让它干什么，比反过来省太多时间。希望帮到你。

本文还有配套的精品资源，点击获取