Davinci DM6446 Codec Engine双核通信环境的搭建

根据前几篇文章，一个 DM6446 的系统已经架构完成。但是有很多人都喜欢 TI 的机制，毕竟双核软件开发对很多工程师来说是非常麻烦的事情，既然 TI 提供开发套件和开发包，那么直接做 OEM 就可以了，底层的东西不需要关心很多，所以我们在这里开始讨论双核通信机制（包含 DSP SERVER ）。特别是 TI 提供 H.264 、 JPEG 、 MPEG4 、 G711 等算法调用例子，让很多系统集成工程师看到项目的希望。网上有很多朋友都介绍 DVSDK1.0 的 Codec 和 DSP SERVER ，他们都写得不错，本篇部分内容介绍也借鉴他们的，在此基础上重点介绍 dvsdk_2_00_00_22 ，毕竟 TI 的 dvsdk 原理几乎都一样。 TI 有几个文档： sprued5.pdf 、 sprued6.pdf 、 sprue67.pdf 和 spruec8b.pdf ，都是学习 Codec Engine 的不错资料。

 

一、dvsdk_2_00_00_22 介绍

在我们讨论 TI Codec Engine 原理 之前，先检查大家安装的 dvsdk_2_00_00_22 ，看看还有什么没有安装的，见下图。先让大家有个感性的认识，否则先讲 Codec Engine 原理的话，估计有不少人还没看完就兴致消失了。 dvsdk_2_00_00_22 是基于 TI EVM 的硬件平台的，有些朋友自己设计独创的 DM6446 板子，要利用 TI Codec Engine ，就需要做很多移植工作，这是经验之谈。 本人在《 TI Davinci DM6446开发攻略――开发环境搭建 》里，也介绍一些基本软件包的安装，本人这里多装了一个低版本的 c6x code generation tools ，其实用 dvsdk_2_00_00_22 自带的 cg6x_6_0_23 就可以了。 dsplink-1_61_03-prebuilt_bk 是因为本人要编译 dsplink-1_61_03-prebuilt ，所以备份一下，防止出问题，其他 dvsdk_2_00_00_22 的软件包（ codec_engine_2_23_01 、 dvsdk_demos_2_00_00_07 ，等等）都有原始备份，毕竟本人不是牛人，这些东西开始时不是非常熟悉，所以改动前都要备份一下，以便以后出问题进行比较和还原。根据 TI dvsdk_2_00_00_22 的 Codec Engine 要求， local_power_manager_1_23_01 是要安装的，有些例子就需要这里边的 lpm_dm6446.ko 和 ocvc_dm6446.ko 。这些都可以通过 TI 的网站上下载（一个网友说得好：内事不决问老婆，项目不决问 google ！ ）。

 

dvsdk_2_00_00_22 里每个软件包和工具包内都有文档介绍说明，见 dm6446_2_00_00_22_release_notes.html 的介绍（懒得连文档都不愿看的人或急功近利直接拿来的人，进步是不大的，除非是天才。中国有很多有天才资质的人，但在中国是不会出现天才的，所以，好好看文档吧，呵呵。），而 Rules.make 是一个很重要的文件，见《开发环境搭建》里有介绍。其中：

bios_5_33_06 ： 是TI的DSP实时操作系统，本人下载比较新的版本。和C6x Code Generation Tools一样，这里的DSP/BIOS也是Linux环境下的版本。DSP系统工程师需要了解这个操作系统。

cg6x_6_0_23 ：这个是 dsp 的交叉编译链，即在 linux 下生成可以在 c64 系列 dsp 上运行的程序；

codec_engine_2_23_01 ：是 TI 机制的重点所在， 实现ARM和DSP或协处理器的协同工作 ，以它为基础进行算法等开发。开发 codec_engine_2_23_01 前，如果你不是公认的牛人，请生成自己的 Codec Engine 例子的目录―― <CE_EXAMPLES_INSTALL_DIR> ， e.g. /usr/work/examples ，就是把 codec_engine_2_23_01/ examples 给 COPY 到你的工作目录，备份一下。

dm6446_dvsdk_combos_2_05 ： Codecs for both encoding and decoding H.264 and decoding MPEG2 。 玩H264的朋友就应该知道这个文件包的价值。

dmai_1_20_00_06 ：里边有 Capture ， Disaplay ， V4L2 等内核驱动接口， encode ， ecode ， encodedecode 这些例子调用这些驱动接口。

dvsdk_demos_2_00_00_07 ：里边有 encode ， ecode ， encodedecode 的应用例子；

dvtb_4_00_08 ：这是一个在 ARM 端运行，基于脚本语言的测试 codec 的应用程序。用户不需要写任何 C 代码就可以处理 Linux I/O, codec API 以及一些与线程有关的问题 ;

dsplink-1_61_03-prebuilt ： 是实现ARM和DSP之间通信的底层软件，Codec Engine就是建立在这个底层软件之上。编译出来的 dsplinkko.ko 是 Codec Engine E 基本元素之一。

edma3_lld_1_05_00 ：里边包括 EDMA3 的低层驱动；

framework_components_2_23_01 ： 是TI提供的一个软件模块，负责DSP侧的memory 和DMA资源管理。因此，DSP算法工程师需要了解这个软件模块。

linuxutils_2_23_01 ：里边有 cmem.ko ，这个也是 Codec Engine 基本元素之一。

local_power_manager_1_23_01 ：里边有 lpm_dm6446.ko 和 ocvc_dm6446.ko ，这个 ko 有些 DM6446 的例子是没有用到。但在 OMAP 的芯片中， DVSDK3.0 基本上用到这个元素。

PSP_02_00_00_140 ：里边包括TI提供的FLASH TOOL，UBL的BIN文件，UBOOT-1.2.0等源代码，audio,ccdc，gpio，V4L2的例子源代码。

xdais_6_23 ： 是一个标准，它定义了TI DSP算法接口的标准。这样大大提高了DSP算法软件的通用性。DSP算法工程师要写出能被ARM通过Codec Engine调用的算法，必须保证自己的算法接口符合这个标准。因此，DSP算法工程师也必须了解这个软件模块。

xdctools_3_10_03 ：XDC Tools和gmake类似，是用来编译和打包的工具，能够创建实时软件组件包RTSC(Real Time Software Component).与其他编译工具一样，它能根据源文件和库文件编译生成可执行文件。不同的是它能够自动的进行性能优化和版本控制。XDC还能够根据所提供的配置脚本语言产生代码，这一特性在编译如编解码器、服务器和引擎等可执行程序时尤为重要。XDC根据用户定义的一套build指令，通过调用用户指定的ARM 工具链（Tool Chain）和DSP编译器（C6x Code Generation Tools ）build出ARM侧和DSP侧的可执行文件。可以先不必细究这个工具，只需通过编Codec Engine的例子，就知道如何设置build指令就可以了。有关XDC的用法，下面这段是参考一个网友的，本人放到这里，让大家更好去理解XDC。

XDC 的调用语法格式： XDC <target files> <XDCPATH> <XDCBUILDCFG>
target files: 指编译产生的目标文件。可以通过命令脚本来指定要产生哪些目标文件;
XDCPTH:       编译时所要查找的目录;
XDCBUILDCFG: 由"config.bld"文件指定，包含了与平台有关的编译指令。后面细说。
以上命令模式可能在参数过多是很复杂，通常把它写成shell脚本来运行。

与XDC相关的三个配置文件：package.xdc: 主要包含与包package有关的信息：依赖信息、模块信息、版本信息。由自己提供。package.bld: 主要作用是定义一个包应该如何被编译。文件内容用Javascript来描述。其中包含目标平台集的定义[MVArm9,Linux86]、编译版本的定义[release]、确定源文件集、生成的可执行文件信息等等。这两个文件都是在server目录下，可见每个codec都有自己的package信息描述文件，然后XDC根据再依之生成一个package包。config.bld: 这个文件处在codec_engine_##目录下，为各个codec所共有，它主要定义了与平台有关的特性，包含如下几部分：DSP Target、Arm Target、Linux Host Target、Build Targets、Pkg.attrs.Profile、Pkg.lib等具体信息。通常都是基于TI提供的模板对这三个配置文件做修改。

   其实说这么多的 xdais 和XDC，我们先不用一下子就理解很透彻，TI提供的软件包example和工具包都帮我们设置好的，我们要做的就是修改makefile, Rules.make, xdcpaths.mak ，user.bld的工作。上面介绍的软件包工具包是开发Codec Engine必不可少的元素，如果要深入学习，得好好看 sprued5.pdf 、 sprued6.pdf 、 sprue67.pdf 和 spruec8b.pdf 。

 

二、TI DAVINCI 软件架构原理介绍

软件架构分为应用层、信号处理层和 I/O 层三部分， TI 提供的达芬奇参考软件框架就是基于这样的结构，如下图。 Davinci 的应用工程师 可以在系统的用户空间在系统功能性上添加和发挥自己的特色。信号处理层通常都运行在 DSP 一侧负责信号处理，包括音视频编解码算法、 Codec Engine 、 DSP 的实时操作系统 DSP/BIOS 及和 ARM 通信的模块。 I/O 层就是我们通常所说的驱动，是针对 Davinci 外设模块的驱动程序。在 DAVINCI 系统中， Davinci 的ARM是HOST，负责操作系统应用， DSP 是协处理器， 负责运行音频视频 codec 算法处理，ARM通过TI的 Codec Engine 机制调用DSP侧的 codec 。

 

 

 

其中应用层通过 Codec Engine 的 VISA(Video, Image, Speech, Audio)API 来调用 DSP 侧的算法，通过 EPSI(Easy Peripheral Software Interface)API 来访问和操作 Davinci 的外设。这三个部分通常对应三个 Davinci 软件开发小组。当然还需要一个系统集成工程师把这三个部分集成起来，不过 VISA API 和 EPSI API 的存在已经大大简化了集成工作的复杂程度。 Codec Engine 是连接ARM和DSP或协处理器的桥梁，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块。ARM应用程序调用 Codec Engine 的 VISA （ Video, Image, Speech, Audio ） API ，如下图中 VIDENC_process(a, b, c ) 。 Codec Engine 的 stub （ARM侧）会把参数 a, b, c 以及要调用 DSP 侧 process 这个信息打包，通过消息队列（ message queue ）传递到 DSP 。 Codec Engine 的 skeleton （ DSP 侧）会解开这个参数包，把参数a, b, c转换成DSP侧对应的参数x, y, z（比如ARM侧传递的是虚拟地址，而DSP只能认物理地址），DSP侧的 server （优先级较低，负责和ARM通信的任务）会根据 process 这一信息创建一个DSP侧的 process(x, y, x) 任务最终实现 VIDENC_process(a, b, c) 的操作。

 

 

 

 

 

要真正了解DM6446 软件架构，先从自己所处的角色说起，本人认为，开发 DM6446 软件一般分为： 双核系统集成工程师、ARM应用程序工程师、DSP算法工程师和DSP系统工程师。牛的人一般都兼职四个角色！

ARM 应用程序工程师：应用层开发设计

DSP 算法工程师:DSP算法设计

DSP 系统工程师：集成算法LIB和 DSP/BIOS 的 DSP Server 设计；

双核系统集成工程师：UBL、UBOOT、LINUX内核、根文件系统、设备驱动程序设计、总体系统集成。

每个角色的具体分工，可以看看 sprue67.pdf 。以下是一个网友提供的资料， 如图下图所示， DaVinci 的软件开发通常需要四个步骤 ( 本文以 codec 运行在 DSP 为例 ) ：

 

 

软件系统分为应用层、信号处理层和 I/O 层三部分，达芬奇软件开发通常需要以上四个步骤。

 

第一步， DSP 算法 工程师需要基于 DSP 利用 CCS 开发自己的音视频编解码算法，编译生成一个编解码算法的库文件 *.lib( 等同于 Linux 环境下的 *.a64P ，直接在 Linux 环境下修改文件后缀名即可 ) 。如果要通过 Codec Engine 调用这个库文件中的算法函数，那么这些算法实现需要符合 xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media) 标准； Codec Engine 机制下不符合 xDM 标准的算法实现需要创建算法自己的 Stub 和 Skeleton( 具体请参考 spraae7.pdf) 。

第二步，生成一个在 DSP 上运行的可执行程序 *.x64P( 即 .out 文件 ) ，也就是 DSP Server 。

第三步，根据 DSP Server 的名字及其中包含的具体的音视频编解码算法创建 Codec Engine 的配置文件 *.cfg 。这个文件定义 Engine 的不同配置，包括 Engine 的名字、每个 Engine 里包括的 codecs 及每个 codec 运行在 ARM 还是 DSP 侧等等 ( 具体说明，请参考 sprue67.pdf 的第 5 章 Integrating an Engine) 。

  最后，应用工程师收到不同的 codec 包、 DSP Server 和 Engine 配置文件 *.cfg ，把自己的应用程序通过编译、链接，最终生成 ARM 侧可执行文件。

 

三、利用 Codec Engine 进行自己的项目

如何利用Codec engine进行自己的项目呢？例子――TI提供的例子，会让你省掉很多复杂的过程，例子先给你个感性的认识，以后用多了，慢慢你就会了解xDAIS、xDM标准和XDC TOOL，xDM只是xDAIS的扩展。你要做的是修改 相应工具包、软件包里的 makefile, Rules.make, xdcpaths.mak ，user.bld，config.bld等等。我们就拿dvsdk_2_00_00_22\dvsdk_demos_2_00_00_07\dm6446\encodedecode 说事，因为这个例子调用 H.264 的 codec 。

首先确保以下关键元素可以编译通过：

dvsdk_2_00_00_22\codec_engine_2_23_01\examples

dvsdk_2_00_00_22\dm6446_dvsdk_combos_2_05

dvsdk_2_00_00_22\dmai_1_20_00_06

dvsdk_2_00_00_22\dsplink-1_61_03-prebuilt

dvsdk_2_00_00_22\dvsdk_demos_2_00_00_07\dm6446

dvsdk_2_00_00_22\linuxutils_2_23_01\packages\ti\sdo\linuxutils\cmem

 

编译通不过的原因就是相关的makefile, Rules.make, xdcpaths.mak ，user.bld没有修改好。请参考各个软件包的文档，比如 dvsdk_2_00_00_22/codec_engine_2_23_01/examples/build_instructions.html 等，怎么编译，是使用 make ， gmake 还是 xdc 设置，文档都有介绍，如果要在这里都列出来，那太耗时间了。我们重点讲一下上面软件包的之间的关系，让大家进一步了解 Codec Engine 。 dvsdk_2_00_00_22\dsplink-1_61_03-prebuilt 里可以生产 dsplinkko.ko ， dvsdk_2_00_00_22\linuxutils_2_23_01\packages\ti\sdo\linuxutils\cmem 里产生cmem.ko。 dsplinkko.ko,cmem.ko 这些在开发包里有，由于这些驱动编译时使用的内核和你的内核不一致，所以在目标板子上运行 encodedecode 的例子时， insmod 会出错，你要以你的内核为准，重新编译这些驱动。 encodedecode 的例子会用到dm6446_dvsdk_combos_2_05里DSP Server的loopbackCombo.x64P，而这些codec 和 server就是建立在codec_engine_2_23_01的基础上的。encodedecode的例子调用linux内核驱动，是通过dmai_1_20_00_06。这样分析，大家应该对dvsdk_2_00_00_22有个比较全面的认识了，很多工作可以进行了。 经过一段时间看文档和实际摸索，终于调通 TI CODEC ENGINE ，这样就轻易调用 h.264 ， g711 音频的算法，在我们帮客户设计的硬件平台上，我们成功的帮组客户实现 TI 机制开发要求，这样客户基本上不用花太多时间就可以设计出自己的产品，加快产品上市时间。有关 Codec Engine 包括 DSP Server ，本文先介绍 DAVINCI 的双核通信机制，有关 DSP Server 的搭建，本人打算参考一个网友的文章，因为他写得很不错，他在 dvsdk_1.0 上介绍的，本人针对 dvsdk_2.0 对 DSP Server 的原理再添加点内容。

本人写文章，目的主要是给大家介绍开发方法，动手的还得大家自己去做，这样你个人能力才会有质的飞跃，一上来就加本人博客公告里的QQ，要这要那，本人觉得是一种很肤浅的行为。本人一再声明，QQ是谈生意和项目合作、技术支持的，是为客户服务的。写技术文章，就是培养一种技术氛围。技术氛围是一个很广泛的东西，没有这种良好氛围，科技就会发展很慢，浮躁急功近利的氛围，只有被动挨打，任人宰割。任何科技发明，科技创新，都需要良好的技术氛围。学习别人先进的东西，总会没错的，否则浮躁急功近利，只会变成实实在在的机器工人，而不是有思维、有创造力的人。