接上篇博文 《 TI-Davinci开发系列之六CCS5.2调试Linux内核 》， 在简单介绍了 CCS5.2 的安装及使用方法之后，接下来本文将介绍 DVSDK4.03 的目录结构，而实际上 DVSDK4.03 目录及其子目录下都有docs目录，TI的文档是海量的，只要你有耐心大部分问题都可以从文档中找到靠谱的参考，不过本着抛砖引玉的着眼点，本文简要介绍DVSDK4.03的目录结构，希望能给新来者以帮助同时 记录下学习的过程 。 毕竟 DM3730非常强大， 1G Hz 的 COTEX-A8 加 800M Hz的 TMS320C64x 跑一些网络视频服务器还是游刃有余的。
/******************************************************************************************************************************************/
/******************************************************************************************************************************************/
1.1DVSDK4_03 软件包及元素介绍
1.1.1 docs 文件夹
我们要具体了解整个 DVSDK4_03 ，就必须认真读读 TMS320DM3730_Software_Developers_Guide.pdf ，里边非常详细介绍整个 DVSDK 的结构。而 dvsdk_4_03_00_06_dm3730_Release_Notes.pdf 只是介绍这个 DVSDK4_03 的特点。
1.1.2根目录 Makefile 和 Rules.make
在 dvsdk4_03 根目录下，这个 Makefile 文件告诉你如何编译整个开发包各个元素，而 Rules.make 里边脚本定义很重要的各个元素所处的路径、名字。使用在 dvsdk4_03 目录下直接vim Makefile 和 vim Rules.make 看看就明白一切，这里特别指出，那些 make xxxx_install 命令会把对应编译出来的 *.ko 、 cs.x64P 和应用程序 COPY 到 EXEC_DIR=/home/gqb/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk 的路径下，而对应的 *.ko （特别是 cmemk.ko ， dsplinkk.ko ， lpm_omap3530.ko ， sdmak.ko ）会直接 COPY 到 /home/gqb/dm3730/dvsdk4_03/filesystem/dm3730rootfs/opt/dvsdk/dsp 的目录下，我们已经在根目录下 Makefile 改好路径了。
在根目录下执行make命令则其编译顺序为
Linux kernel à cmem à sdma à dsplink à lpm à c6run à c6accel à codecs à dmai à demos
上面的编译顺序是不能颠倒的。当然有些元素只需要编译一次，因为我们大部分开发是 codecs， dmai ， demos ，那就得按上面的顺序编译。 很多人一直没有正常编译 dmai 啊 demos啊，是因为他们根本没看手册，根本不了解这些元素的编译顺序。
下面介绍 DVSDK 元素包：
见 TMS320DM3730_Software_Developers_Guide.pdf 里第 11 页，读懂这个框图就读懂整个 DVSDK 的开发包的内在关系：
注意蓝色标的元素是 TI 自己开发的 Software 。整个图从上到下逐层调用，有些直接调用 DSP，有些是需要中间件等等。
1.1.4 bin 文件夹
这个是安装 DVSDK4_03 的时候，用到的安装脚本，可以打开看看这些脚本理解，和编译无关。
1.1.5 biosutils_1_02_02 文件夹
这个进去看看 doc 文件夹里边的 pdf 文件和 release_notes.html 就可以了解， BIOS 相关 LIB，不需要我们单独编译和开发。
1.1.6 cgt6x_6_1_14
这个也不需要我们编译，但是是很重要的 LIB 和编译工具；
1.1.7 dspbios_5_41_03_17
Dsplink依赖于此源码包，实际上DM3730架构DSP可以看作ARM的外设，而dsplink则是DSP的驱动模块，而dsplink又将dsplink包含了进来，实际上DSPBIOS是 跑在TI DSP上的BIOS操作系统；
1.1.8 edma3lld_01_11_02_05
这个也不需要我们编译， NX 的人可以去修改对应的驱动，负责DMA通信相关的工作；
1.1.9 framework-components_2_26_00_01
这个也不需要我们编译， NX 的人可以去修改对应的驱动；
1.1.10 xdais_6_26_01_03
这个就是被中国一些 DSP 工程师称为万恶的 XDAIS 算法接口，把中国很多只会使用 CCS 调试程序的工程师搞得半死，很多人一直停留在 DM642 这种单核的状态。其实多使用和研究透这个 XDAIS ，就发觉 TI 的良苦用心。本人改了 xdais_6_26_01_03\packages\ti\xdais\dm 里边 ividenc.h进行 ARM 传参数给 DSP 和 DSP 给 ARM 传参数，还改了 dmai_2_20_00_15\packages\ti\sdo\dmai\ce 里边的 Venc.c 和 Venc.h ，然后在 dvsdk-demos_4_02_00_01\omap3530\encode 例子 capture.c 里举例如何在 ARM 端调用 DSP 的算法 Venc_process() 。
1.1.11 xdctools_3_16_03_36
这个是整个 DVSDK 的编译工具。
1.1.12 psp
其实个人感觉这个目录应该叫做bsp（板级支持包），不知道为什么叫psp，反正该目录的源码都是系统软件层等非常底层，如x-loader（其工作原理及流程见下篇博文）用来从不同介质引导u-boot，而u-boot的作用则调试和引导Linux内核。
x-load-1.51 是支持 NAND BOOT 的；
x-load-1.51-mmc 是我们自己改出来的版本，是支持 SD 卡 BOOT 的，适合生产和产品维修，使用这个编译的文件进行 SD 卡 BOOT ；
注意： u-boot-2010.06-psp04.02.00.07.sdk 、 linux-driver-examples-psp04.02.00.07 和 linux-2.6.37-psp04.02.00.07.sdk 是 TI DVSDK4_03 安装的原始软件包。
1.1.13linuxutils_2_26_02_05
编译这个 cmem 和 sdma 元素之前，必须先编译内核 linux-2.6.37 ；
1.1.14 dsplink_1_65_01_05_eng
得到 dsplink.ko 文件，负责跑在ARM端的Linux与跑在DSP端的BIOS之间的通信，这部门可以作为一个单独的课题放在后续博文讨论；
1.1.15 local-power-manager_1_24_03_10_eng
这个元素是 OMAP 系列电源管理驱动，低功耗芯片特有的驱动。
1.1.16 c6run_0_98_03_03 文件夹
这个是一个重要的元素，你开发 demos 的时候用到，见 TMS320DM3730_Software_Developers_Guide.pdf 里第 16 页。
1.1.17 c6accel_1_01_00_07 文件夹
这个是一个重要的元素，你开发 demos 的时候用到，见 TMS320DM3730_Software_Developers_Guide.pd 里第 18 页。 c6accel_1_01_00_07\dsp\libs 里边有很多优化的 LIB ，适合图像处理和分析。这个东西非常有用，包括 DM8168 和 DM8148 这些平台的软件都有这个东西。 c6accel_1_01_00_07\dsp\libs 里边的 C64P_LIBPLUS.lib 、 fastrts64x.lib 、 IQmath_c64x+.lib 、 IQmath_RAM_c64x+.lib 、 vlib.l64p 等等，凡是深入做过 DSP 算法的工程师对这些 TI 优化的 LIB 肯定不陌生，以前开发 DM6446 是没有这些好东西的。 c6accel_1_01_00_07\dsp\alg 提供算法的例子，按照 CCS 工程的模式管理， TI 是照顾一下那些在 CCS 上开发算法的工程师的感受。
1.1.18 codec-engine_2_26_02_11
Codecengine 是 TI DAVINCI 双核的核心思想， codec-engine_2_26_02_11\packages\ti\sdo\ce 里边有很多算法接口，比 DM6446 多了一个 vidanalytics ，设计到图像分析 LIB ；
1.1.19 codecs-omap3530_4_02_00_00
这个 codecs-omap3530_4_02_00_00 是属于 codec-engine 的一个特例，里边有很多好东西，比如 packages\ti\sdo\codecs 里边的 h264enc ， h264dec ， jpegenc ， g711enc 。 packages\ti\sdo\server\cs 就是 DSP SERVER 的配置， 注意里边的相关脚本文件。
至于 CODECS 机制的原理有 几个 pdf 文档 ( sprued5.pdf 、 sprued6.pdf 、 spruec8.pdf 、 sprue67.pdf 、 spraae7.pdf ) ， TMS320 DSPAlgorithm Standard 算法标准提到的： SPRU352.pdf 、SPRU360.pdf 、 SPRU361.pdf 、 spru424.pdf 估计也没有人去下载看，这个 spraae7.pdf 文档还提到一个 CODEC 机制的例子 spraae7b.zip 。要想成为骨灰级双核算法工程师入门，这些都需要好好看看。 很多人问在这个 CODECS 机制里 DSP 算法 能不能使用 malloc 申请内存，我们说这是可以，它指向 dvsdk4_03\codecs-omap3530_4_02_00_00\packages\ti\sdo\server\cs\server.tcf里的定义的 bios.DDR2.heapSize = 0x500000 （ TI 默认很小才 128K ，所以你 malloc 大于 128K就崩溃了），而 DDR2 的段在 memmap.tci 定义。不过大的空间申请 TI 不建议这样使用。
1.1.20 dmai_2_20_00_15
这个是一个重要的元素，你开发 demos 的时候用到，见 TMS320DM3730_Software_Developers_Guide.pd 里第 20 页。里边 packages\ti\sdo\dmai\apps 有很多如何直接在 ARM 调用 DSP 的例子， 注意如果你要编译 dmai\apps\video_encode_io 的例子，就必须使用 dmai\ce 目录下的 Venc_org.c_bk 和 Venc_org.h_bk （记得改回名字 Venc.c 和 Venc.h ），而当前 Venc.c 和 Venc.h 被我们修改过满足从 ARM 端传输参数给 DSP 了，和 encode 例子配合的，更完美。
1.1.21 dvsdk-demos_4_02_00_01
encode 是进行 H264 encode 的 D1 例子，可以 D1 encode 和音频输入 G711 encode ，带显示输出；
decode 可以进行 H264 DECODE 和 G711 DECODE ；
edge_detection 是一个如何使用 c6accel 的例子，如何使用 VLIB ；
1.1.23 filesystem
DM3730 的文件系统，包括 NFS 文件系统和对应生成 ubifs 的工具；
1.1.24 dvtb_4_20_18
这个也是一个 CODEC 应用的特例。
1.1.25 example-applications
有关 matrix-gui-e-1.3 的开发包,主要是QT+html5框架的GUI图形界面开发接口，可扩展性非常强大。
1.1.26 graphics-sdk_4.03.00.02
DM3730集成PowerVR SGX530 GPU软核，本目录为该GPU模块内核态及用户态驱动（OpenGL ES1.0、OpenGL ES2.0、OpenCV实现）及一些OpenGL在移动设备和PC设备的demo程序；
1.1.27 gstreamer-ti_svnr919
著名流媒体开源软件框架，编译出来为gst-launch等一系列命令行工具，可以通过Linux V4L2视频框架采集的视频及ALSA音频框架采集的音频通过tcp/udp/rtp/rtsp等流媒体传输协议构建一个流媒体服务器，而其他终端上的流媒体体播放器则可以访问该流媒体服务器，如何利用好该开源框架，将会使开发工作达到事半功倍的效果。
总的来说， dvsdk-demos_4_02_00_01 里边的例子就是 LINUX 的上层应用软件，而 DMAI 是中间件，也是 LINUX 深一层的应用程序，是上层应用软件通过 DMAI 调用 codec-engine 、 dsplink、 framework 的等元素。其实双核就是 ARM 是 HOST ，而 DSP 只是一个屏蔽的外围设备， ARM 端通过初始化和调用一个函数就可以访问 DSP 了， DSP 处理的结果就放到共享内存里供 ARM使用。
总结：
TI 的 DSP 是个强大的好东西，特别非常适合自己开发算法的中国工程师（当然绝大部分算法都是 COPY 移植过来的），因为编程灵活，支持 C 语言，开发成本非常低（相对 FPGA ）。在嵌入式领域，处理数字信号算法等等，目前 COTEX-A15 1.4G 都跑不赢 800MHz 的 C64+ 。当然支持浮点的 C674X 和 C66X 系列 DSP 就更恐怖了。跟我们桐烨科技合作的一些博导，对这方面感触非常深。其实，应用 TI DSP ，他们还没有完全达到骨灰级的水平，因为很多片上资源和优化 LIB 都没用上。
扫一扫
292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
