企业官网建设流程全解析

简介：《Rockchip RK3229 软件开发指南 V1.03》是瑞芯微面向软件开发工程师与技术支持工程师发布的芯片开发调试技术文档，针对 RK3229 平台在 Linux3.10 内核下适配 Android 6.0.1 与 7.1.2 的开发需求，系统梳理了从硬件兼容性到系统配置的关键信息。文档涵盖 DDR、NAND、EMMC、WiFi/BT 及多媒体编解码支持列表，SDK 软件包适用硬件说明，以及 system 分区大小配置、ODEX 预编译、禁用 SELinux、Jack-server 配置、USB 默认开启 ADB、开机视频与低内存优化、DRM WIDEVINE level 1 配置等开发者特性，并附工具版本更新、开机 logo 限制与序列号/Mac 烧写工具说明。资源包为 1 个 PDF 文件，大小约 1.61MB，单文件即完整覆盖开发流程各环节，便于按章节检索查阅。目前已有 627 人学习下载，适合需要快速上手 RK3229 开发与调试的工程师作为案头参考。

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

手里攥着一块 RK3229 的电视盒子板子，串口能出 log，但 SDK 编译报错、烧写工具认不到设备、WiFi 模块加载不起来——这种场景下，最省时间的做法不是去翻论坛零散帖子，而是找一份当年原厂给开发工程师看的开发指南。这份《Rockchip RK3229 软件开发指南 V1.03》就是干这个的：它把 SDK 获取、编译、烧写、U-Boot、内核 DTS、Android 常见配置、系统调试工具、量产工具串成一条线，覆盖 Linux3.10 + Android6.0.1/7.1.2 两套组合。适合谁？手上还有 RK3229 存量板子要做维护、二次开发、产测工装，或者想拿它当 Android 系统裁剪与嵌入式 Linux 调试的练手素材的工程师。它不是教程，是查得到参数、对得上工具版本的操作底稿。

2. 先看支持列表再动手：DDR、NAND、eMMC、WiFi 的选型边界

很多人拿到 SDK 第一件事就是make，结果编译过了、烧进去起不来，最后发现是 DDR 颗粒不在支持列表里。这份文档第 1 章的价值就在这——它把「能不能跑」的前置条件先摆出来，而不是等你烧废三块板子再回头查。

2.1 DDR 与存储颗粒：符号含义比型号本身更重要

RK3229 支持 DDR3、LPDDR2、LPDDR3 三类 DRAM。文档里给了一张符号表，这个符号体系是后面所有支持列表的通用语言：

NAND 和 eMMC 用的是同一套符号逻辑，只是 eMMC 多一条硬指标：RK3229 支持 eMMC 4.51、SDIO3.0、HS200 模式。文档里明确建议选顺序读 >200MB/s、顺序写 >40MB/s 的颗粒，这个数字不是拍脑袋——Android 系统分区读写频繁，低速 eMMC 会直接把开机时间和应用启动拖垮。我一般会在选型阶段就把厂商 datasheet 的 performance 章节翻出来对一遍，别等系统跑起来再用dd测。

具体型号要去RKDocs/Platform support lists目录下查对应的支持列表文档，文档本身只给符号规则和筛选建议，不重复贴全表。

2.2 WiFi/BT 与多媒体能力：驱动版本是硬门槛

WiFi/BT 这块有个容易被忽略的点：RK3229 内核是 Linux3.10，如果选的 WiFi 芯片原厂只提供更高版本内核的驱动，那就不是改改 DTS 能解决的，得让原厂补 3.10 的驱动。文档建议按支持列表里的型号选型，本质是降低驱动适配成本。

多媒体规格值得单独记一下，因为它决定了你这块板子能做什么产品：

• 解码：4K VP9、4K 10bit H265/H264，最高 60fps；1080P 多格式（VC-1、MPEG-1/2/4、VP8）；JPEG 解码
• 编码：1080P H.264；JPEG 编码
• Kodi：OMX 框架支持官方 16.1 Jarvis 和 17.0 Krypton，SDK 默认集成的是基于 16.1 深度优化的 RKMC 版本，支持 H265/H264/VP9 10bit@60fps 硬解、ISO/MKV Framepacking MVC3D、AC3/EAC3/TrueHD/DTS 最高 7.1 声道透传

如果你做的是播放器类产品，RKMC 和官方 Kodi 的差异要提前想清楚：RKMC 偏硬件加速和透传，官方版偏插件生态，二者不是简单替换关系。

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

SDK 是基于 Android6.0.1 及之后版本的 32bit 系统，适配 RK3229 Box EVB 开发板和 Box 样机板。内核配置的改动入口是RK3229-box.dts，硬件设计参考文档在RKDocs/Platform support lists/RK322X 硬件设计指南下。这一步的意义在于：你后面所有 DTS 修改都应该以这个文件为基线，而不是自己从零写一个。

3. SDK 编译与烧写：从源码到固件的完整链路

支持列表确认完，才轮到编译。这一章是整份文档里操作密度最高的部分，也是翻车最集中的地方。文档对应第 3 章，覆盖 SDK 获取、编译、固件烧写、量产烧写四段。

3.1 编译环境与 jack-server 配置

Android 7.1 引入 jack 编译工具链后，jack-server 的配置成了编译能否跑通的关键。文档 V1.02 版本专门补了这一节，说明当年这个问题坑了不少人。常见做法是先确认 jack 服务端和客户端的端口配置一致，再调并发数：

# 查看 jack 配置，确认服务端端口 cat ~/.jack-settings # 典型配置项（按机器内存调整） # SERVER_PORT_SERVICE=8072 # SERVER_PORT_ADMIN=8073 # ANDROID_JACK_VM_ARGS=-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G

逻辑说明：SERVER_PORT_SERVICE和SERVER_PORT_ADMIN是 jack 服务端监听端口，多用户或多任务并行编译时端口冲突会导致编译中途挂掉；ANDROID_JACK_VM_ARGS里的-Xmx4G是给 jack 的 JVM 堆上限，机器内存 8G 以下建议压到 2G～3G，否则容易触发 OOM 把编译进程杀掉。改完配置要重启 jack 服务再编译，不然读的还是旧参数。

3.2 分区大小、odex 预编译与 SELinux 开关

这三个配置在文档 3.2.6 节，属于「编译前必须定下来」的参数，因为改分区往往要动 parameter 文件，改完得重新烧写。

system 分区大小配置直接决定你能预置多少 APK 和系统资源。odex 预编译配置影响首次开机速度——预编译成 odex 可以减少开机时的 dex 优化时间，代价是 system 分区占用变大。禁用 SELinux 的方法文档也给了，但要注意：这只适合调试阶段，量产固件不建议长期关着，否则应用层的权限问题会被掩盖，等到产测阶段才暴露就麻烦了。

# 编译前确认分区参数文件中的 system 分区大小（单位通常为扇区） grep -n "system" parameter.txt # 全量编译入口（具体 lunch 目标以 SDK 内实际配置为准） source build/envsetup.sh lunch make -j8

参数说明：-j8的并发数按 CPU 核心数给，一般取核心数的 1～1.5 倍；内存不足时并发越高越容易在链接阶段被 OOM killer 干掉，表现是编译到一半突然退出、没有明确报错，这时候先降-j再看。

3.3 固件烧写与量产烧写：工具版本要对得上

烧写分两档：单板调试用 Android 开发工具，量产用量产工具。文档 2.2 节维护了一份工具版本列表，V1.03 还更新过这份列表——这不是形式主义，烧写工具和固件格式不匹配时，表现往往是「设备能被识别但烧写进度卡在某个百分比」，或者干脆认不到 loader 设备。

单板烧写的典型流程是：设备进 loader 模式 → 开发工具识别 → 选择固件 → 执行升级。量产烧写则要配合产测工装，文档 8.9 节有量产工具使用说明，8.10 节是 Box 厂测工具。这里有个血泪经验：调试阶段和量产阶段用的工具不要混，调试工具带很多交互确认，量产工具追求的是无人值守批量刷，混用会导致产线节拍对不上。

4. U-Boot 与内核配置：logo、DTS、GPIO 与温控

固件能烧进去只是第一步，板子起不起来、外设能不能用，取决于 U-Boot 和内核配置。文档第 4、5 章就是这块，内容不算多，但每一条都是高频改动点。

4.1 U-Boot logo 配置与开机 logo 限制

U-Boot 阶段就要显示开机 logo，相关配置在文档 4.5 节，V1.03 还补了 4.5.2 的开机 logo 限制描述。常见做法是把 logo 图片按平台要求的分辨率和格式处理好，再通过打包脚本塞进 resource 分区。这里容易翻车的点是图片格式和尺寸：分辨率超出显示能力、或者色彩格式不对，表现是开机黑屏几秒然后直接进系统，logo 一闪而过甚至完全不显示。

U-Boot 编译本身不复杂，关键是平台配置要对：

# 进入 U-Boot 目录后按平台配置编译（具体 defconfig 名以 SDK 为准） make rk3229_defconfig make -j8

逻辑说明：rk3229_defconfig是平台默认配置，编译产物需要按 SDK 的打包流程合入固件，不能单独烧。改 logo 相关配置后建议先只烧 U-Boot 分区验证，别每次都全量烧，省时间。

4.2 DTS 与 GPIO 对应关系：别信引脚编号，信原理图

内核配置的核心是 DTS，文档 5.1 节介绍 DTS，5.3 节专门提醒 GPIO 对应关系。这一条值得单独说：芯片手册上的 GPIO 编号、DTS 里的 bank/pin 编号、原理图上的网络标号，三者经常对不上。我一般会拿原理图 +RK322X 硬件设计指南交叉核对，再在 DTS 里按gpioX_Y的格式写，改完用万用表量电平验证，而不是改完就烧。

WiFi/BT 的配置也在 DTS 里，涉及供电 GPIO、使能脚、SDIO 或 USB 接口的挂载关系。ARM、GPU 频率修改和温控配置在 5.4、5.5 节——频率不是越高越好，RK3229 这类盒子芯片散热条件有限，温控阈值设得太宽松，长时间播放 4K 会触发降频甚至死机，表现是「播一会儿就卡」，很多人误以为是解码性能不够，其实是温控在起作用。

4.3 USB 默认打开 adb 调试

文档 5.7 节这条对调试效率提升最直接：USB 默认打开 adb，意味着板子插上就能adb devices，不用每次进系统设置里手动开调试。配置方式是在对应属性或 DTS 节点里打开，具体位置以 SDK 为准。改完之后如果adb devices还是空列表，先查 USB 口是不是 OTG 口、驱动有没有装对，再怀疑配置没生效。

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

到了 Android 层，改动点更碎，但文档第 6、7 章基本把高频需求都覆盖了。这一章挑几个实际项目里绕不开的说。

5.1 预置 APK、开机动画与新增分区

预置 APK 在 6.3 节，常见做法是放进packages/apps或厂商预置目录，再在编译配置里声明。要注意的是预置带 so 库的 APK 时，库文件要按 ABI 放对目录，否则装上了也起不来。开/关机动画及铃声在 6.4 节，和 U-Boot logo 一样，格式和分辨率对不上就是黑屏或无声。

新增分区配置在 6.6 节，配合 parameter 说明（6.5 节）一起看。新增分区不是改一个文件就完事：parameter 里要加分区定义，分区表要同步，文件系统挂载点也要在 fstab 里补。漏掉任何一环，表现都是分区存在但挂不上，或者挂上了但权限不对。

5.2 OTA 升级与系统灾难恢复

OTA 在 6.7 节，系统灾难恢复在 6.9 节。这两块建议一起设计：OTA 包签名、升级失败回滚、恢复模式入口，是一套东西。文档 8.6 节还有固件签名工具，量产固件必须签名，否则升级校验过不去。灾难恢复的价值在于——调试阶段改坏了系统分区，还能靠恢复模式救回来，不用拆机短接。

5.3 Android 7.1 的三个专项：开机视频、低内存优化、Widevine Level 1

V1.03 新增的 6.11～6.13 三节，都是 Android 7.1 才有的配置：

• 开机视频：替换静态 logo，注意视频编码格式和播放时机，配不好会拖慢开机
• 低内存优化：针对小内存机器，调整内存回收策略和后台进程限制，参数调过头会导致应用频繁被杀
• DRM Widevine Level 1：流媒体产品绕不开，Level 1 要求内容解密和渲染都在安全环境里完成，配置涉及 TA、密钥注入和 OMX 组件，不是改个属性就能过认证

5.4 调试工具四件套：adb、logcat、procrank、dumpsys

文档第 7 章这四个工具，是排查问题的基本盘。adb连不上先查 USB 和驱动；logcat看应用崩溃和系统异常；procrank看进程内存分布，定位内存泄漏比dumpsys meminfo更直观；dumpsys查系统服务状态。音视频问题还有专门的调试工具和文档，在 7.5 节。

# 按内存占用排序查看进程，定位内存大户 adb shell procrank | head -20 # 抓取指定进程的 log 并落盘，方便回看 adb logcat -v threadtime | grep -i "关键字"

逻辑说明：procrank输出里重点看 PSS 和 USS 两列，USS 是进程独占内存，持续上涨基本就是泄漏；logcat加-v threadtime能带上线程和时间戳，排查时序问题比默认格式好用。

6. 工具链与量产落地：签名、烧号、打包与厂测的排查清单

文档第 8 章是工具大全，也是实际项目里最容易出「玄学问题」的地方。这一章按工具用途拆开说，最后落到几条踩坑记录上。

6.1 update.img 打包、固件签名与 OemTool

update.img打包（8.5 节）是把各分区镜像合成一个整包，打包脚本对目录结构有要求，路径放错就是打包失败或包内容缺失。固件签名（8.6 节）在打包之后做，签名密钥要保管好，丢了就没法给已出货设备推 OTA。OemTool（8.8 节）用于制作 OEM 镜像，文档特别强调镜像制作文件夹路径有要求——这个要求不是随便定的，工具按固定相对路径找文件，路径层级不对就报找不到资源。

6.2 序列号/Mac/厂商信息烧写与 Box 厂测

WNpctool（8.7 节）负责烧序列号、Mac 和厂商信息，V1.03 更新过这个工具的使用说明。烧号前要先设工具模式，模式设错会写不进或写乱。Box 厂测工具（8.10 节）是 V1.01 新增的，用于产线功能测试，配合 PCBA 测试工具（8.2 节）和 StressTest（8.1 节）组成产测闭环。DDR 测试工具（8.3 节）在来料检验阶段用，能提前筛掉不良颗粒。

6.3 常见问题排查：五条踩坑记录

现象一：编译到一半突然退出，没有明确报错。原因：jack-server 的 JVM 堆上限不够，或者make -j并发过高触发 OOM killer。 解决：调低ANDROID_JACK_VM_ARGS的-Xmx，降-j并发数，重启 jack 服务后重编；用dmesg确认是否有 OOM 记录。

现象二：烧写工具能识别设备，但进度卡住不动。原因：烧写工具版本与固件格式不匹配，或 loader 与当前固件不配套。 解决：对照文档 2.2 节的工具版本列表换工具；确认 loader 是从当前 SDK 编出来的，不要混用不同批次的 loader。

现象三：开机 logo 不显示，直接进系统。原因：logo 图片分辨率或色彩格式超出平台限制，或打包时没进 resource 分区。 解决：按 4.5.2 节的限制重新处理图片，确认打包脚本输出里有 logo 资源，先单烧对应分区验证。

现象四：WiFi 模块加载失败，dmesg里看不到驱动初始化。原因：WiFi 芯片驱动不是 Linux3.10 版本，或 DTS 里供电/使能 GPIO 配错。 解决：找原厂要 3.10 驱动；按原理图核对 DTS 的 GPIO 配置，用万用表量使能脚电平。

现象五：播放 4K 一段时间后卡顿，重启恢复。原因：温控阈值配置过松，芯片过热降频。 解决：检查 5.5 节的温控配置，适当收紧降频触发点，同时确认散热设计；用logcat和内核 log 确认是否有降频记录。

6.4 一个验证习惯：改完配置先单分区验证

这份文档覆盖的配置项太多，全量烧写一次动辄几分钟，改一个参数就全量烧，时间全耗在等待上。我一般会按改动范围决定烧写粒度：只改 U-Boot 相关就单烧 U-Boot 分区，只改内核就单烧 boot 分区，确认没问题再打整包。整包打包和签名留到版本节点做，日常调试不碰。这个习惯是从一次「改了个 DTS 引脚定义，全量烧完发现起不来，回滚又花半小时」之后养成的。从那以后我每次改 DTS 或分区参数，都强制先单分区烧写验证一遍，再进整包流程。希望这份拆解能帮到你，少走几段弯路。

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