简介Amlogic T982/T968技术开发文档是一份面向技术支持工程师和软件开发工程师的官方技术手册聚焦基于BDS Android R SDK的芯片方案开发适合需要完成Android系统定制、底层调试及产线烧录的嵌入式开发者。内容覆盖SDK代码获取与版本编译、GIT使用方法、开发板使用、烧录工具PC USB烧录、U盘烧录、EMMC预烧录等、外设接口调试、PIN MUX配置、Ethernet与Uart唤醒、DDR与PCIE配置以及开机动画/视频、屏参、key烧录、4k UI、HDMI ONLY等具体设置项并给出编码Debug方法能帮助开发者减少环境搭建与硬件适配中的弯路。资源为单个PDF文档大小8.44MB目录结构按代码、编译、烧录、外设、调试等模块划分查阅方便。目前已有550人学习下载。文档提供0.1至0.5版本变更记录便于使用者追踪更新节点快速定位新增内容和历史调整无论是进行T982/T968平台开发、驱动适配还是量产预烧录这份资料都提供了较为完整的操作指引。1. Amlogic T982/T968 技术开发文档先搞懂这颗芯片是来解决什么问题的做电视盒子、广告机、视频会议终端或者边缘 IP 摄像头方案的开发者看到 Amlogic T982/T968 这两个型号通常不是来长见识而是带着具体任务来的要在某个板子上把系统跑起来要调视频解码要确认 NPU 能不能扛住自己的算法。这两颗芯片属于同一家族却因为定位差异开发文档的读法和落地路径完全不同。T982 一般带 NPU适合做轻量 AI 检测和 8K 级别的多媒体处理T968 更偏成本敏感的 4K 平台。如果你的项目只需要稳定播放、接口齐全T968 可能更务实如果算法要跑在端侧就必须考虑 T982。这篇文章按选型、环境、烧录、避坑、验证的顺序讲尽量做到拿到手能照着走。2. T982 与 T968 的定位差异先选对芯片再谈开发文档2.1 两颗芯片的参数分水岭不是只看 CPU 核数很多开发者的第一反应是看 CPU 核心数和主频实际项目里最影响工作量的往往不是 CPU而是视频解码能力、NPU 的有无、内存接口以及外设引脚的复用关系。T982 和 T968 芯片都采用 ARM 处理器架构但面向的市场层级明显不同。T982 通常被用在需要更强视频处理能力、或者需要本地跑一个小型神经网络的盒子类设备上T968 则更常见于 4K 播放器、广告机、瘦客户机这类以流媒体解码为主要任务的场景。从开发角度说最关键的分水岭是 NPU。T982 片上集成了 NPU可以做图像分类、目标检测、人脸检测这类轻量级推理T968 一般不带 NPU如果项目有 AI 需求要么外挂要么只能退到 CPU 上跑非常轻的算法。另一个分水岭是视频解码规格。T982 的解码上限高于 T968但这里有个容易误判的地方解码规格高不等于播放器就好用实际能不能硬解某类码流还要看 SDK 里的解码库和容器适配情况。我在实际评估时一般会列一张表把项目需求按「必须有、可以有、不需要」三档拆开再看芯片差异而不是先比参数。对比维度T982T968定位高配多媒体、端侧 AI 边缘盒成本敏感、纯影音类设备NPU有适合轻量视觉推理通常无AI 能力有限解码规格更高支持大分辨率高码流4K 级别为主典型产品智能盒子、视频会议一体机广告机、播放器、瘦客户机2.2 开发文档拿到手先读四份Datasheet、User Manual、SDK Release Note、GPIO 复用表拿到平台的开发文档最常见的问题不是资料少而是资料太多不知道从哪看起。我建议按这个顺序读先看 Datasheet重点看启动模式、电源域、引脚定义再看 User Manual主要看寄存器、时钟树和显示接口接着看 SDK Release Note确认这个版本解决了什么问题、引入过什么限制最后是 GPIO 复用表这项往往决定硬件能不能直接照着自己画的板子调试。Datasheet 里最容易忽略的是启动相关的引脚。T982/T968 这类芯片一般支持多种启动方式比如从 eMMC、SD 卡、USB 烧录口启动。如果板子上电后在 bootloader 阶段就卡住多半是启动引脚配置和烧录方式不匹配而不是软件逻辑写错。User Manual 主要是在改设备树时用。比如要反复切换一个引脚的复用功能靠猜会浪费时间。先用文字搜一遍寄存器说明再去看 SDK 里的 dts 文件匹配度会高很多。SDK Release Note 一定要看很多坑就藏在「本版本已知问题」清单里。我常遇到的情况是某段代码在旧 SDK 里能跑升级到新版工具链后编不过release note 会直接告诉你哪个模块被替换了。GPIO 复用表要配合硬件原理图一起看。开发板原理图里看起来名字叫 UART_TX 的引脚在最终量产板上可能被复用成其它功能或者被拉去做别的信号。这种问题通常只有在开发后期、量产导入阶段才会爆发所以前期对照复查能省很多返工成本。2.3 通过产品形态倒推选型盒子、广告机、网关、边缘计算盒子选型不能只看芯片本身还要看产品形态和成本天花板。做 4K 电视盒子如果业务只是播放腾讯、爱奇艺这类固定码流的在线视频T968 通常足够。把解码、显示、网络这几个环节调稳剩下的就是系统稳定性工作。但同样是盒子如果客户要求在本地做画面内容识别比如统计屏幕前人数或检测区域入侵T982 的 NPU 就有明显价值。广告机也类似。纯轮播图片和 4K 视频T968 就可以如果广告机要装摄像头统计观看人次、识别年龄性别那就只能是 T982 这类带 NPU 的芯片。网关产品要关注的点不太一样通常是外设接口数量和实时性。说明文档里对 PCIe、USB、以太网口的支持列表比 CPU 性能更需要仔细核对。对于边缘计算盒子我一般建议即使算法暂时没定也优先选择带 NPU 的 T982。原因很简单硬件一旦定下来就很难改后期算法上了 NPU 平台还得重新做量化和适配。宁可前期多花一点成本也比重新画板更可控。2.4 同套 SDK 里两颗芯片如何共用代码defconfig、dtb 与宏隔离一个项目里同时维护 T982 和 T968 两种主板很常见。大多数方案商的 SDK 会把这两颗芯片放在同一套源码仓库里通过 defconfig、设备树文件和编译宏区分。目录结构上kernel、bootloader、系统框架是共享的差异集中在arch/arm64/boot/dts/下的板级 dts 文件以及编译配置里选中的 defconfig。不要直接把 T968 的 dts 改给 T982 用。虽然两颗芯片同为 Arm 架构处理器但 NPU、视频解码 IP 和部分时钟控制在设备树里的节点不一定一致直接复制改个名字经常出现内核启动后某个外设 probe 失败。正确做法是找对应芯片的默认 dts 作为底稿再把自己的板级差异加进去。编译宏隔离也要注意。如果代码里写了#ifdef来区分两颗芯片就要确认宏在头文件里的定义路径不要靠 xxxx_sdk 默认配置。有一次我把 T982 的配置直接套到 T968 板上编译内核起来了但 Wifi 模块一直枚举不到原因就是宏定义里把一个 GPIO 的默认状态改了。3. 搭建本地开发环境交叉编译一个最小工程的完整路径3.1 SDK 目录骨架一版源码同时容纳两块芯片拿到 SDK 解压后典型目录结构包括 bootloader、kernel、device、system、vendor、toolchain、out 这类目录。bootloader 对应 U-Boot 源码kernel 是 Linux 内核device 和 vendor 里放板级配置与二进制库toolchain 是交叉编译器out 或 build 目录放中间产物和最终镜像。开发节奏建议这么安排先在 bootloader 阶段确认启动链路再进 kernel 看设备树最后做系统层和业务层。T982/T968 的初始化大多涉及 DDR、显示、HDMI、内存带宽任何一项跑不过都会导致后续看不到系统界面。所以第一步不是写业务代码而是把厂家的默认配置编译出来烧进板子确认板子能开机。常见做法是SDK 根目录提供一个环境配置脚本比如source envsetup.sh然后通过菜单选择或命令行参数挑选目标芯片和板型。执行之后会在/proc/device或者内核配置里生成对应的板级信息。建议第一次编译前先把目录下所有 README 和*.md文件扫一遍很多目录结构说明已经写清楚了。3.2 最小工程一个 hello 的交叉编译流程不管用 T982 还是 T968建议先做一个不依赖任何硬件外围的最小可执行文件验证交叉编译环境是否正常。下面是一个基于 CMake 的最小工程工程文件名可以叫hello_t9xx。CMakeLists.txtcmake_minimum_required(VERSION 3.13) project(hello_t9xx C) set(CMAKE_C_STANDARD 99) add_executable(hello_t9xx main.c)main.c#include stdio.h int main(void) { printf(hello t982/t968\n); return 0; }编译命令# 假设工具链已经解压在 SDK 的 toolchain 目录 export CROSS_COMPILEaarch64-linux-gnu- export PATH$PATH:/path/to/toolchain/bin cmake -S . -B build \ -DCMAKE_C_COMPILER${CROSS_COMPILE}gcc \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_C_FLAGS-mcpucortex-a55 cmake --build build -j8参数说明CROSS_COMPILE是交叉编译器的前缀实际编译时${CROSS_COMPILE}gcc会展开成aarch64-linux-gnu-gcc。-mcpucortex-a55用于让编译器按目标 CPU 的指令集优化具体目标核心以实际规格为准不确定时可以不加。-j8是并行编译任务数按机器核数调整一般 4 到 16 都可以。编译完成后把生成的hello_t9xx放进根文件系统或者用adb push推到板子上运行。执行后输出字符串就说明从编译到运行的环境是通的。3.3 首次编译必须确认的三个配置项第一是工具链路径。很多新手在环境变量没配置时直接编译报command not found其实只要确认aarch64-linux-gnu-gcc能敲出来就行。第二是输出目录。SDK 默认输出目录可能带日期或用户名不同项目并行编译时容易把镜像混到一起建议每次编译前显式指定OUT_DIR或类似变量。第三是分区大小和文件系统类型。这个值决定了最终镜像能不能被烧录工具接受。export OUT_DIR$HOME/build/t982_out mkdir -p $OUT_DIR make product_t982_demo_defconfig make -j8 OUT_DIR$OUT_DIR这里OUT_DIR控制了所有镜像产物的落点。好处是编译不同板卡时互不污染出问题时也能马上找到对应的boot.img和system.img。如果编译脚本不支持自定义输出目录至少把整个 SDK 复制一份再改配置避免一个工程把两个板卡的配置混在一起。3.4 编译产物与镜像打包不是所有软件项目都有 MakefileT982/T968 的编译产物一般包括 U-Boot 镜像、内核镜像、根文件系统镜像最终会打包成一个升级用镜像。在编译内核时常见产物路径是out/arch/arm64/boot/Image或Image.gz。系统镜像则要看文件系统类型比如system.img可能是 ext4 或 erofs。打包这一步最容易翻车的是分区偏移和镜像大小。SDK 里的打包脚本一般会读取一个分区表配置比如device/xxx/board_cfg或单独的.xml文件。如果你自己裁剪了系统导致镜像体积变大就一定要同步修改分区大小否则烧录工具会卡在写入后半段。# 常见打包命令示意具体以 SDK 脚本为准 ./build.sh -c t982 -o $OUT_DIR -p demo这条命令里的-c指定芯片型号-o指定输出目录-p指定产品配置。不同 SDK 的参数名可能完全不同有的用环境变量有的用菜单选择。先看build.sh开头的 help 输出再动手执行能省不少时间。4. 烧录和启动把镜像送进机器后的排错顺序4.1 典型分区表bootloader、boot、system、data、miscT982/T968 的存储分区不是固定的方案商有很大调整空间。常见布局是从第 0 块开始放 bootloader随后依次是 boot、system、data、misc 等分区。烧录工具和 U-Boot 都依赖这个布局任何一个分区偏移不匹配都会导致启动阶段找不到内核或根文件系统。下表是常见分区说明只作为理解参考实际板卡一定要以 SDK 里自带的配置为准。分区名存储内容注意事项bootloaderU-Boot 及 DDR 初始化代码烧错会直接变砖boot内核与 dtb改动频率最高system根文件系统与系统库分区大小要匹配data用户数据区可反复擦写misc启动标记、恢复模式配置普通开发很少碰分区表里的偏移地址在烧录配置里可见。如果是定制板要注意 eMMC 的块大小和烧录工具里定义的 size 是否一致。我见过一个项目烧录配置里 system 分区比实际镜像小了 32MB结果每次烧到末尾都报错而报错位置看起来像是硬件问题实际只是分区表没同步更新。4.2 两种常用烧录方式USB 烧录和 TF 卡烧录低速调试阶段最常见的是 USB 烧录。把板子通过 USB 线连到电脑驱动安装后按住或短接特定的烧录按键/触点让芯片进入烧录模式然后工具里加载烧录配置和镜像。这种方式刷写速度快也适合全量重刷。风险在于烧录期间如果断电设备可能停留在烧录模式需要重新进一次烧录流程。以下是 TF 卡烧录的常见命令行做法适合没有 USB 烧录工具或者需要快速测试多块板子的场景# 请确认 /dev/sdX 是你的 TF 卡不要误写为硬盘设备 sudo dd ifupdate.img of/dev/sdX bs4M convfsync statusprogress sync参数说明if指定烧录镜像of指定设备节点bs4M是每次读写块大小convfsync确保写入完成后数据落到物理介质statusprogress显示进度。TF 卡烧录的好处是不依赖 USB 驱动缺点是容易把 SD 卡整卡覆盖操作前一定确认设备节点。TF 卡烧录完成后板卡首次启动直接从 TF 卡引导。如果想回到 eMMC 启动需要移除 TF 卡并设置启动引脚或 U-Boot 命令具体以 SDK 说明为准。4.3 串口日志怎么抓115200 8N1 是最常见的起点抓串口日志在启动调试里是刚需。T982/T968 的开发板通常提供一个调试串口接线时注意 TX、RX 交叉连接GND 一定要共地。波特率默认常见是 115200数据位 8无校验停止位 1。部分定制板也会用 921600如果日志是乱码先尝试换波特率。常用抓取命令是 minicom 或 screen# 安装 minicom 后把 p 口参数设置为 115200 8N1 minicom -D /dev/ttyUSB0 -b 115200 # 或用 screen 直接打开 screen /dev/ttyUSB0 115200参数说明-D指定串口设备-b指定波特率。连接后重新给板子上电观察 U-Boot 输出到内核启动再到 init 进程的完整日志。如果日志停在一个反复出现的地址多半是 DDR 初始化失败如果内核日志打印了但最后没有登录提示符就要看根文件系统挂载和 console 配置。4.4 启动日志里需要注意的几行U-Boot 阶段建议看 DDR 初始化、启动介质识别、dtb 加载。内核阶段看Booting Linux之后有没有 panic设备树里各外设节点是否probe成功。系统阶段关注/sbin/init是否正常执行init进程卡住时常用consolenull之类的配置也会导致看起来像死机。如果日志在某一行重复打印比如mmc错误往往不是串口问题而是 eMMC 驱动或电源时序问题。此时先回头查分区表和 dts 里的 MMC 节点而不是反复换烧录工具。5. 开发中四个高频翻车点现象、原因与后悔药5.1 串口只有零碎乱码没进到内核现象给板子上电后串口工具显示一堆乱码偶尔能认出几个字符然后没有后续输出。原因最常见的是波特率不匹配或者是调试串口引脚被复用成了其它功能。T982/T968 会有多个 UART 控制器不是每个 UART 默认都接在调试位置上。另一个原因是 USB 转串口线质量不好地线接触不良导致信号参考电平漂移。解决先确认硬件原理图上的调试串口是哪一个控制器再对照 GPIO 复用表修改 dts把对应引脚复用为 UART 功能。波特率按板卡文档设置一般试 115200 和 921600 两档。换一根质量好一点的 USB 转串口线避免在高速波特率下信号失真。5.2 开机反复重启不进系统现象上电后 U-Boot 能起但打印完 DDR 相关信息后板子重启或者在内核解压阶段突然断电式重启。原因多数是 DDR 参数与板子上实际使用的内存颗粒不匹配。方案商 SDK 默认带的 DDR 初始化配置是为其参考板调好的换了不同容量的颗粒或者不同厂商的颗粒后必须重新适配。解决先不要自己改时序参数参考 SDK 里同一系列芯片相近板型的 ddr 配置优先降低频率验证。确认内存电源电压无误后再逐步调时序。这块没有捷径只能靠板子上的示波器和反复开关机确认稳定性。5.3 视频解码出来是花屏和绿条现象用系统自带播放器播 4K 视频出现花屏、绿条部分码流完全黑屏。原因显示图层参数和视频解码帧缓冲格式不匹配常见于视频输出分辨率、HDR、色彩格式与显示驱动默认设置不一致。T982 和 T968 的视频解码 IP 能力不同但花屏问题更多出在显示链路。解决先用厂家 demo 的播放器参数跑一遍同码流如果没问题说明解码链路是通的问题在自己的显示参数配置。随后检查 dts 里的显示节点、HDMI 输出分辨率、帧缓冲格式。色深和 HDR 参数也要确认不支持 HDR 的显示链路强行开启 HDR 也会花屏。5.4 烧录卡在中间工具报错后不掉电现象USB 烧录到一半工具提示写入失败进度条停在 7% 或 70%。原因7% 附近通常是 bootloader 分区70% 附近通常是 system 或 data 分区。卡在 7% 多为主控不能稳定进入烧录模式或 USB 连接不稳卡在 70% 多为镜像体积与分区配置不符。解决换一根短线连接 USB 口尽量减少转接头给板卡额外供电避免电脑 USB 供电不稳。烧录配置里检查分区大小尤其是 system 分区和镜像文件实际大小。把烧录工具的连接超时时间调大一些有些失败是擦除 eMMC 时耗时过长导致工具误判。6. 进阶用几条命令验证系统是否真正跑在预期状态板子能开机只是第一步真正要确认的是 CPU 是否按预期调频、NPU 是否被内核识别、视频编解码节点是否出现。这里有几个我每次拿到板子都会跑一遍的检查命令。查看 CPU 核心信息和当前频率cat /proc/cpuinfo cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq第一类命令用于确认系统看到了几个核心第二类看当前工作频率。如果频率停留在最低档且长时间不变多半是负载不够或者温控策略过于保守。跑一个持续的解码或 NPU 负载后再看频率是否抬起来。查看 NPU 驱动是否加载dmesg | grep -i npu ls /dev | grep -i npu如果dmesg里没有任何 npu 相关输出要回头确认内核有没有把 NPU 驱动编进去以及 dts 里 NPU 节点是否存在。这里最容易踩的坑就是拿 T968 的 dts 改给 T982 用NPU 设备一直枚举不到。查看视频编解码设备节点ls /dev/video* v4l2-ctl --list-devicesT982/T968 的硬解能力最终会体现在 V4L2 节点和闭源解码库的配合上。如果播放器不能调用硬解先看这些节点是否存在再确认解码库是否加载成功。跑一个官方解码 demo循环播放几轮后查看dmesg是否有解码错误。这里有个血泪教训我之前调试一块 T982 板子系统启动和 UI 都正常只是每次跑视频检测算法就卡顿。排查了很久后来发现 NPU 节点没有起来算法实际跑在了 CPU 上负载飙升导致掉帧。原因就是拿错了设备树NPU 的电源域没初始化。之后凡是新板子我第一件事就是确认硬件相关内核节点全部 probe 成功而不是急着放业务代码。希望你拿到新板子时也能先做这一步省下后面一整天的排查时间。本文还有配套的精品资源点击获取