OMAP3530资料

OMAP3 CPU

OMAP35x系列启动流程：（自己总结的）

第一步：配置CPU的启动方式（sys_boot）；
第二步：bootROM会从NAND 中读取x-loader，ECC校验通过以后，就跳转执行x-loader 
第三步：x-loader接管，初始化PLL和DDR，由x-loader去读取u-boot，然后执行u-boot.

第四步：u-boot在SDRAM中运行，并引导Linux内核启动。

注：

bootROM是CPU内部（112KB ROM）已经固化好的程序代码，属于TI公司，不开放。

x-loader烧写在启动设备中，开发板提供源代码。

u-boot因为较大，CPU内部SRAM放不下，所以在DDR中运行，开发板提供源代码。

Linux开发板提供源代码。

TI 所有DSP，如OMAP,DM644x的ROM都是芯片出厂时掩膜掩好的。客户只能读，不能擦。ROM里存放BOOT代码，有些DSP的ROM会存放一些数学库函数等。

启动时omap35x会把0x4000 0000起的1M空间映射到0x0000 0000。 0x4000 0000起始的80k空间存放的是加解密使用的代码／数据。当然开头那几十个字节是arm的跳转向量表。其中reset会跳到bootrom（0x0001 4000或0x4001 4000起始的32k代码空间）中执行，其它向量会跳到sram的固定地址去执行。reset时只需要往sram的固定地址填上几个转跳指令就可以让其它向量的处理跳回bootrom的处理代码中执行。而对于uboot这样不使用mmu的bootloader只需要改变那几个地址的指令就可以跳到uboot自己的处理代码中。启用了mmu的linux当然就不需要这样做了。

仿真器主要是芯片级调试，或者DSP算法调试，跑了OS以后，仿真器就基本没有用了 
可以通过CCS来保存你想要的内容

主要用仿真器来荡内存，俺习惯把printk的串口输出注释掉，把printk的buffer开的很大，所有debug信息都放在内存里。因为用串口调试，串口本身不仅在好多环境下不能用，而且还会引起不必要的麻烦。用只print到内存的pintk，干干净净，俺放心

OMAP3适合在ARM9、11处理能力不够的嵌入式场合，由于功耗比较小，便携应用是强项，也提供工业级版本，在工业医疗方面也可以应用。

OMAP3不是单颗芯片，目前4颗是完全pin2pin兼容的，有分别带DSP和3D的芯片，具体如下： 
omap3503 COTEX-A8 + 外设 
omap3515 COTEX-A8 + 外设 + 3D加速 
omap3525 COTEX-A8 + 外设 + DSP及视频硬件加速 
omap3530 COTEX-A8 + 外设 + DSP及视频硬件加速 + 3D加速 
同样一个硬件设计，可以覆盖不同等级的产品需求。

问：

BeagleBoard采用x-loader+u-boot的方式来启动内核，我看了一下x-loader的代码，是u-boot的精简版，主要实现的功能是初始化硬件，然后根据启动方式从nand flash或mmc/sd拷贝u-boot代码到内存，运行之。 
我的问题是： 
u-boot下面同样执行了硬件的初始化，u-boot也支持读取mmc/sd文件，那为何不直接使用u-boot来引导，而在前面添加一个x-loader呢？这其中有什么重要的原因吗？谢谢。

答：

U-BOOT 太大，塞不进 OMAP3的内部RAM。 所以 用x-load。 
OMAP3 上电的时候，读取x-load 到 内部RAM，然后执行。 
X-LOAD 初始化memory controller，把 u-boot 读进外部 RAM，然后跳到外部RAM 执行u-boot。

可以把UBOOT直接通过CCS下载啊，然后运行。。。 
记得下载ELF的文件，不要下载.bin哦

问：

如果nand flash启动的话，修改一下u-boot应该也能做到。问题是mmc/sd启动的时候，需要读取mmc/sd里面的东西，这里涉及到fat文件系统，这个光用汇编的话估计很难实现，所以才另外写一个精简版的u-boot（x-loader），不知道是否这个原因？

Xloader的作用是把初始化代码load到片内ram，做芯片和外设的初始化，xload非常小，只有几K大小，主要是初始化PLL，DDR，只有初始化了DDR，才能把uboot下载到DDR里面执行 
所以可以认为是如下几级启动过程： 
1. 片内ROM -- 支持UART，USB，NAND，NOR，MMC1， MMC2，OneNAND等启动 
2. xloader，初始化PLL和DDR，下载UBOOT 
3. uboot/eboot启动 
4. linux/wince kernel启动

答：

xloader和文件系统没有关系，不管是nand，onenand还是mmc/sd，都是xloader，只不过在fat32里面必须更名称MLO才能识别。如果可以把uboot精简到16K以内，不用xloader也可以，呵呵

uboot也是可以把USB搞起来的，当然也可以用串口打印，或者串口下载uboot 
理论上，也可以用USB下载UBOOT和kernel调试，但是目前缺少一个调试工具，现成的是通过USB下载xloader或者mini-uboot到片内RAM： 
http://groups.google.com/group/beagleboard/browse_thread/thread/2b9e99886bb7a747 
xloader/uboot也可以用510/560仿真器+CCS跟踪调试

问：

1、TI内部boot rom的源代码公开吗？ 
2、请问哪里可以下载？

答：

Bootrom code不对外开放

问：

OMAP3图形处理关系？

答：

三个核是完全独立的，一般看到的OS和控制，GUI等等都是直接在ARM上跑的 
视频有两种方式，一种是直接用ARM或NEON加速软解码，另一种是启动DSP以及视频硬加速做媒体加速，可以认为DSP只是协处理器，只是从memory到memory的算法处理，如何做，数据流如何走完全由ARM控制，比如可以直接解码放到最终显示的视频驱动buf （video0/1) 
同样，3D模块也是纯硬件加速，由ARM控制，一般是3D直接输出到OSD的buffer(graphic) 
最终显示到屏上或者DVI或者S-video，可以通过sysfs控制如何进行视频buf和OSDbuf的叠加或半透明效果。

基于OMAP35x系列的是用TI的CODEC ENG软件框架，媒体处理的算法可以放在ARM也可以放在DSP，上层调用已经抽象化有限的一些接口，比如Ceate(), Control(), Process(), Delete()，如果用DSP加速，算法是在DSP的微码里面，通过这些控制命令接口来进行编解码处理等。

问：

OMAP35x的裸板测试程序在哪可以下载？

答：

SDK开发包的board_utility里面有ITBOK（Is the board OK?) 
集成在uboot里面进行板级硬件测试

问：NAND启动

答：

nand启动，首先要看是不是在支持的boot deviceID里面（如下） 
启动代码需要写在0-4个块 
然后xloader需要加上8字节的头，用signGP工具 
还有值得注意的是ECC，需要用硬件ECC 
以及注意xloader的load address之类的 
如果还不行，恐怕需要用仿真器来调试了。。。 

Table 26-32. Supported NAND Devices 
Capacity Device ID Bus Width Page Size in KB 
64Mb E6h 8 512 
128Mb 33h 8 512 
128Mb 73h 8 512 
128Mb 43h 16 512 
128Mb 53h 16 512 

我大致说一下我这边的情况： 
1、flash用的是三星的片子：k9f1g08，id为0xf1，2k page，128Mbyte，在TI支持的列表里可以找到。 
2、启动代码写在0块0地址 
3、x-loader加上了8字节的头部(到sd卡上能正常启动) 
4、烧写的时候使用了nand ecc hw(使用硬件ECC) 
5、按照芯片datasheet的介绍，nand falsh片选接到cpu的CS0，nand flash忙引脚接到cpu的wait0，在u-boot下操作没问题 

满足以上条件，可以就是不能nand boot~ 

现在我最大的怀疑是ecc出了问题，可是我使用的是beagleboard提供的u-boot，flash驱动使用原来的，只是稍微修改一下flash的ID和位宽而已(beagle board使用的flash为16 bit，而我们使用的是8 bit)，不知道从以上信息能否定位出问题的所在？(TI固化代码没有打印任何错误信息，不然就好办了^_^)

换成8bit的nand，有几个地方需要修改： 
xloader中配置GPMC_CONFIG1，默认的是配置成16bit了，这里要修改成8bit 
NAND的option中把16bit的宏定义干掉 
在ECC的OOBINFO中，由于8bit nand只用一个字节表示是否是坏块，但是默认的uboot中配置成16 bit的两个字节，也就是ECC值要从第二个字节开始放，不是第三个字节 
其他都用默认的代码，应该就可以了 
记得烧录xloader的时候要加上8字节的头，并且必须使用hwecc

我只看了在8bit下ecc的结果,却没注意存放的位置.

我修改了ecc存储位置,示波器观察片选,应该能确定部分代码被拷贝到内部ram,但是依然无法启动:( 
貌似数据在一直拷贝. 
不知道是不是因为用了cpld做转换造成的. 3.3的nand. 
或者是tmx的片子? 2.1版，原来我看的文档rom不支持mlc的nand，现在文档说也支持了。

另外一个比较容易忽略的地方是GPMC的位宽，默认在xloader代码里面设成16bit的模式，如果用8bit的，需要注意修改GPMC的CONFIG1寄存器。

".......................................貌似数据在一直拷贝. "，你指的是退出nand boot后(比如进入uart3 boot，可以看到串口打印40T)用示波器测试发现nand flash片选引脚一直有信号吗？ 

我们之前也存在这样的问题，后来证实是hw ecc的存放位置不对所致(TI启动代码对于8 bit nand flash的hw ecc的存放位置和16 bit的nand flasht刚好错开了一位)，另外注意一下u-boot下gpmc bank 0 的位宽要设置正确，good luck。

DJBean，因为我只是测试是否能从nand启动，所以按我理解应该是omap的rom会把整个x－load内容拷贝到sram运行，这样的话哪怕x－load代码错误（如GPMC），也是能启动x－load的，比如串口发送数据等，只是不能接着运行u-boot罢了，对么？ 

luofuchong，我后来在nand启动失败后用560仿真器观察拷贝的地址和数据，发现如果x-load大于某个大小后的数据是错误的，如果代码小，比如4k这样内容是正确的，但是依然无法启动。 


我现在的ecc obb是这样的，您看对么？ 
eccbytes = 12, 
.eccpos = {1, 2, 3, 4, 5, 6, 7, 8, 
9, 10, 11, 12}, 
.oobfree = { 
{.offset = 13, 
.length = 51 } }

为什么烧录xloader必须使用hwecc ？我这样理解：BOOTROM加载x-loader时用的是hwecc ，而x-loader load uboot时用的是swecc。

我现在的问题是，用工具把x-loadr 烧写进nand flash后，串口什么信息也打印不出来，但GPMC_cs0引脚是有信号的。我用工具读出NF中的数据和我下载前对比了一下，完全相同。难道又是hwecc造成的？如果下载软件本身和hwecc有关系，那我就怀疑是我的下载工具有问题。。。。。。

我现在调的是wince的bootloader，和linux的一样也是两级boot（x-load和eboot），TI提供了一个下载工具 EVMFlash，可以直接把x-load download NAND Flash。我现在是下载成功了，从NF读出数据和下载之前的比较，是完全一样的，但不知为什么不执行程序。

USB问题：

关于USB的问题，默认是没有打开hot plug-in的，也就是如果上电的时候有USB hub，系统是可以检测到，如果上电时候没有插USB Hub，等系统起来以后再加上，有可能检测不到，方法是执行如下命令 （也可以放在rcS里面）： 
echo "S" >/proc/driver/musb_hdrc 
这样就可以支持USB Hub和USB设备的热插拔了 
如zqdsp所说，由于供电问题，你需要用带外部电源的usb hub

beagle的USB OTG是不能直接接U盘等外设的，因为OTG接口的电源供电是由TWL4030直接给的，最大供电电流100ma。所以要挂鼠标、键盘、U盘等必须外接USB hub，并且这个HUB还必须是有源HUB，有外部的供电。 
再建议大家，不要图便宜在市场上买些特便宜的有源USB HUB。我当时在市场上前前后后共买了4个HUB，20的，30的，50的，100的。最后还是100的好用，其他的插上鼠标等都没反应。以上为个人经验，仅供参考。 

大佬，是USB虚拟串口设备，也就是USB作为串口的gadget 
实际速度是USB的速度，不是串口的速度

问：

关于omap3530+tps65930开机流程. 

我用的是devkit8000板子, 一接电源, 代码就跑起来了. 

但做手持设备的应是按power键2秒才上电开机的吧, 这应怎么实现啊??

答：

bootloader中判断有没有GPIO按下去，计时启动，否则bootloader直接把电源管理芯片shutdown

请教各位高手DevKit8000如何安装ubuntu-arm的步骤，debian也可以 
按照http://elinux.org/BeagleBoardHandheldsMojo 
http://elinux.org/BeagleBoardDebian 
做了，载入内核到 
boot kernel后就被卡住不动了 

请教各位高手问题出在哪里了，uboot的arch_number也已经改成beagle的了。高手帮忙，或者给个操作步骤~~

我们的OMAP3530板子调试出了一些问题，由于比较复杂，不知道能否提些建议或帮忙找相关人员回复一下，国内TI的FAE在说到这些具体问题时好像也不是很清楚： 
1）OMAP3530是否必须和TPS65930配合使用，如果去掉TPS65930，会有什么影响？ 
2）我是按照瑞泰的MINI板做设计的，但是在焊接过程中发现TPS65930制板出了问题，没法焊接，所以只有做弥补工作，主要包括电源、26M时钟、32.768K时钟的改动，现在通过JTAG调试，发现电源、两路时钟都可以了，芯片应该能工作了，但就是没有办法从SD卡启动，请问是SD卡的INS脚连到了TPS65930的CARD DETECT脚但我没有办法焊接TPS65930导致的吗？如果是，能不能通过修改什么东西绕过它，还是只能改动OMAP3530的BOOT ROM？但BOOT ROM恐怕只有TI才能改了。 
3）如果2）中无法解决，我想从OMAP3530的串口3启动，不知怎样做？ 
4）如果2）、3）仍无法解决，从OMAP3530的USB1、USB2能否启动？怎样启动？USB0在TPS65930上的，没有办法使用。 
5）如果以上都不行，那就只有重做印制板了？

从UART3启动吧！ 找TI的FAE要EVMFlash工具就可以搞定！但串口只能下bootloader，内核或镜像从以太网下载吧。

ARM与DSP协调：

DSP完全可以访问McBSP, 同样的操作memory map的寄存器就好了 
除了有些特殊说明的接口, DSP都是可以访问的, 不过通用应用一般不建议这样使用, 因为由ARM管理外设和驱动更为标准和合适, 有些特殊应用, 也可以用DSP访问外设。

你说的 同样的操作memory map的寄存器即可， 我对这个不大懂。是不是说DSP端和ARM端都是操作相同的McBSP寄存器？ 
我看OMAP3530的data sheet 上的McBSP那一章，讲到McBSP的控制寄存器地址，比如：McBSP1 的基地址是 0x48074000，大小有4K Bytes ，那是不是ARM和DSP都是通过访问0x48074000处的寄存器来控制McBSP1的？ 我浏览了data sheet，其它地方似乎是没有映射到McBSP1的寄存器的地址了。是不是DSP和ARM 共用那4G的地址空间？ 对这种双核的地址空间分布感觉有点混乱，概念不清楚。

又阅读了下memory mapping的章节，MPU和IVA2.2都有自己的4G的地址空间，这2个4G空间中，只有一小部分地址是有对应部分的，另外的则是完全不相干的。比如：在ARM侧的地址：0x5C00 0000 ~ 0x5CFF FFFF 对应的是 DSP端的：0x0000 0000 ~ 0x00F1 7FFFF ， 这部分可以访问L1 Rom Ram， L2 Rom Ram 。 但是我就是没找到McBSP在DSP侧的寄存器地址。

我用仿真器试过了，带的demo一个是在arm上跑的，一个是在dsp上跑的，应该是两个程序都可以使用相同的地址访问外设（我测试的是UART1，McBSP1的几个寄存器，读出来的寄存器的复位值与datasheet上的描述的一模一样），而且我在ARM侧跑的程序上做了修改后，然后再启动DSP侧的程序查看相关的内存和寄存器的值，跟我在ARM侧上修改的一致。所以dsp是可以直接访问外设的。

烧写xloader和uboot到oamp3530的flash的方法？

在u-boot中： 
烧写XLoader到NandFlash： 
OMAP3 Miniboard # mw.b 80000000 ff 80000 
OMAP3 Miniboard # mmcinit 
OMAP3 Miniboard # fatload mmc 0:1 80000000 x-load.bin.ift 
reading x-load.bin.ift 
11412 bytes read 
OMAP3 Miniboard # nandecc hw 
OMAP3 Miniboard # nand erase 0 80000 
NAND erase: device 0 offset 0x0, size 0x80000 
Erasing at 0x60000 -- 100% complete. 
OK 
OMAP3 Miniboard # nand write 80000000 0 80000 
NAND write: device 0 offset 0x0, size 0x80000 
524288 bytes written: OK 

烧写 U-Boot: 

OMAP3 beagleboard.org # mmc init 
OMAP3 beagleboard.org # fatload mmc 0:1 80000000 u-boot.bin 
reading u-boot.bin 

147424 bytes read 
OMAP3 beagleboard.org # nand unlock 
(Note - if you are using a more recent version of U-Boot, nand unlock is missing 
simply skip this step. i.e. U-boot 2009.08) 
device 0 whole chip 
nand_unlock: start: 00000000, length: 268435456! 
NAND flash successfully unlocked 
OMAP3 beagleboard.org # nandecc sw 
OMAP3 beagleboard.org # nand erase 80000 160000 

NAND erase: device 0 offset 0x80000, size 0x160000 
Erasing at 0x1c0000 -- 100% complete. 
OK 
OMAP3 beagleboard.org # nand write 80000000 80000 160000 

NAND write: device 0 offset 0x80000, size 0x160000 
1441792 bytes written: OK 
OMAP3 beagleboard.org #

在u-boot已经存在的状况下这是最佳方案。 
兄弟遇没遇到这种情况：omap里没有uboot，或者u-boot损坏，该怎样烧写

ICETEK-OMAP3530-MINI任何时候都可以从sd卡启动，即从sd卡启动u-boot然后再烧写flash

串口启动需要先下载xloader，然后在xloader里面下载uboot

mini板每次重启（裸机情况）都会按顺序从flash，USB，串口，以及sd卡启动，每次启动都会从串口输出一串字符，我用OMAP-U-Boot-Utils工具中的pserial下载x-loader到flash，做法如下： ./pserial -p /dev/ttyS0 -f ./u-boot.bin,再启动终端输出内容毫无变化，这是怎么回事？是否下载不成功

flash 全空的情况下，下载u-boot是通过什么方式。串口还是那种简易的JTAG仿真器。 
dsp的调试通过打印可以吗。

Flash空片写入可以用EVMFlash工具，USB和串口都可以写入。 
Beagle那边也有提供类似的工具。

把SD卡格式化成fat32格式，首先把MLO文件拷贝到卡中，再把u-boot.bin拷贝到卡中，就可以从SD卡启动uboot了，再用uboot烧xboot到nand

NAND flash都有Bad block，如果你的映像文件跟分区一样大，可能因为有Bad block写不完整，一般分区要多分配几个块做后备。

ES3.1是芯片的版本号，芯片的版本号不同，有些芯片bug不太一样

双核通信：

双核就意味这每个核是独立的，需要单独开发，然后两个核之间进行通信交换数据，和多芯片不同就在于通信方式不同 
所以要在DSP上开发，要用DSP的开环工具--CCS或者CGtools 
然后可以基于DVSDK的软件框架进行双核通信

问：

OMAP 3530 MINI 板 是ARM和DSP双核的 它们硬件是通过DSP 中的HPI连接起来的,那么在DSP处理完的数据,ARM 要怎样调用了 是要用什么指令吗,还是用LINUX 命令来实现,各位辛苦了!!!!

答：

用DSP/BIOS LINK,专门提供一套API用于ARM侧的调用

共享memory或者mailbox通信，可以用dsplink做底层通信软件 
双核需要单独开发，通信需要严格统一，memory避免冲突

问：

D大，您好，请问OMAP3的DSP可不可以这样用： 
在OMAP的MPU下运行一个LINUX系统作应用（如网络服务等），DSP则用于轮询一个GPIO（不用中断）， 要求这两部分并行处理，一旦DSP处理完成，则通知MPU（中断？）读取DSP处理后得到的数据。 
可以吗？具体一点如何实现？ 

答：

是可以这样使用，不觉得这样太浪费了么？ 
一般ARM是用来跑操作系统，驱动，应用，gui之类的东东，DSP是做算法加速，也就是DSP基本是memory到memory的算法处理

问：

ARM 下用的是linux多任务的操作系统 ARM要怎么调用和dsp共享存储器里的东西了??? 它不象单片机那样可以直接寻址

答：

芯片是可以访问任何物理地址空间的，linux的用户层是访问虚地址，所以需要cmem之类的驱动来访问物理地址空间，或者其他驱动 
首先要给DSP预留出DSP的运行空间，然后ARM通过内核驱动访问，DSP是可以访问任何物理空间

分享一个很不错的代码，DirectFB 
里面有把DSP虚拟成一个外设的例子，很不错的说，而且也有相互通信的例子，供参考……

这个不是MMU的原因，是OMAP3的电源管理导致的 
首先解释初衷，JTAG只能做芯片级的仿真，如果跑了OS以后，进行JTAG断点处理以后，OS就崩溃了，所以在OS起来以后，假定是不会连仿真器的；比如Davinci，如果跑了OS以后，连仿真器以后，OS就会崩溃 
再说OMAP3，EMU是一个独立的电源域，是可以通过PRCM完全关掉的，在OS起来以后，会把EMU的电源域关掉，包括时钟，所以这个时候连不上 
当芯片刚刚启动，或者是SW1跳线吧EMU0拉底，EMU是工作的，可以连仿真器

windows xp下如何开发omap3530？

bootloader 怎么开发呢？ 
有类似Xloader这样的启动程序吗？

这个X-loader 可以在CCS上编译吗？与linux下用的X-loader有什么区别？

CCS不能直接编译xloader，因为gnu gcc的汇编编译器和CCS的不一样编译好的xloader可以通过CCS+JTAG下载到板子上去做调试

DSP/BIOS 内核

DSP/BIOS 内核作为支持 TI DSP 和微处理器设备的实时操作系统，由 TI 直接支持并免费提供。 DSP/BIOS 内核与 Code Composer Studio™ (CCStudio) 集成开发环境 (IDE) 完全集成，且同时支持单核和多核器件。

· DSP/BIOS 内核提供 DSP/BIOS 5.x 和 DSP/BIOS 6.x 两种版本。 

o DSP/BIOS 5.x 与 CCStudio 3.x 和 4.x 两个版本均兼容，并且支持 2010 年之前发布的所有 TI DSP。 有关特性与器件支持的完整详细信息，请参阅 DSP/BIOS 5.x 产品文件夹。 

o DSP/BIOS 6.x 需要 CCStudio 4.x；而且除了较新的 DSP 器件，它还支持 ARM 和 MSP430 微处理器设备。 与 DSP/BIOS 5.x 相比，它还提供多个额外的

ARM + DSP双核架构开发：

对于芯片的外设接口，ARM核和DSP核都可以访问，典型的情况是ARM控制所有的外设，通过OS上的驱动去控制和管理，这部分和传统的ARM芯片类似；DSP主要是进行算法加速，只是和memory打交道，为了保持芯片的资源管理的一致性，尽量避免由DSP去访问外设。当然，根据具体的应用需求，DSP也是可以控制外设接口进行数据的收发，这时，需要做好系统的管理，避免双核操作的冲突。

过应用程序进行DSP程序的下载和DSP芯片的控制。外部RAM空间，即DDR存储区，是ARM和DSP共享存在的，但是在系统设计的时候，需要把ARM和DSP使用的内存严格物理地址分开，以及预留出一部分用来交互的内存空间。一般情况，ARM是用低端地址，DSP通过CMD文件分配高端地址，中间预留部分空间用来做数据交互，比如在OMAP3的Linux下的DVSDK中，128MB的DDR空间被分成三部分，低端地址从0x8000000到0x85800000-1的88MB空间给Linux内核使用；从0x85800000到0x86800000-1的16MB给CMEM的驱动，用来做ARM和DSP的大块数据交互，从0x86800000到0x88000000-1的24MB是DSP的代码和数据空间。

芯片的启动也是需要重点考虑的问题，一般情况下，是ARM启动，和传统的单核ARM一样，支持不同的启动方式，比如可以支持NAND，NOR，UART，SPI，USB，PCI等接口启动。DSP默认处于复位状态，只有通过ARM的应用下载代码并且解除复位以后，DSP才能跑起来。有些应用场景，需要DSP直接从外部上电就自启动，有些芯片也是支持这种模式的。

最后，关于芯片的通信和同步，这个是困扰很多工程师的问题，为了便于客户的开发和使用，TI提供了DSPLINK，CODEC ENGINE的DVSDK开发套件，基于DVSDK可以很方便的进行ARM+DSP的应用开发，下面对DVSDK的软件架构，各个软件模块的功能等做简要介绍。

DVSDK是多个软件模块的集成，包括纯DSP端的软件模块，ARM的软件模块和双核交互的软件模块。DVSDK的软件包都是基于实时软件模块（Real-Time-Software-Component：RTSC）的，还需要安装RTSC的工具XDC，XDC是TI开源的一个工具，可以支持跨平台的开发，能够最大程度的代码重用；如果需要进行纯ARM的开发，还需要ARM的编译工具以及Linux内核或者Wince的BSP；如果需要进行DSP的算法开发或者DSP端开执行代码生成，还需要安装DSP的编译器cgtools和DSP/BIOS；为了便于配置生成DSP端的可执行代码，通过向导生成Codec的RTSC包和可执行代码，还可以选装ceutils和cg_xml。

DVSDK的核心是Codec Engine，所有的其他软件模块基本都是围绕Codec Engine的。Codec Engine是连接ARM和DSP的桥梁，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块，在编译DSP端可执行代码和ARM端应用程序时，都需要Codec Engine的支持。Codec Engine主要有两部分： 
ARM端应用适配层，提供了精简的API和对应的库给应用层使用。 
DSP的算法调用层，提供了DSP算法的接口封装规范，是的所有的算法通过简单的配置就可以编译到DSP的可执行程序中。

最终的应用程序需要通过Codec Engine的API接口来下载DSP代码，调用DSP端的封装好的算法，以及进行ARM和DSP的通信。 
关于Codec Engine的介绍，可以参考《帮您快速入门Codec Engine》。 
Codec Engine底层ARM和DSP的通信是建立在DSP/BIOS Link之上的，DSP/BIOS Link真正实现ARM和DSP交互的软件模块。由于DSP/BIOS Link是跨平台的，也是有ARM部分和DSP部分组成，其中在ARM端，包括基于OS的驱动和供应用调用的库文件，DSP端，必须要用DSP/BIOS，DSP的可执行代码需要包含DSP/BIOS Link的库文件。DSP/BIOS Link常用的主要有如下几部分的软件模块： 
 PROC相关的，主要是用来做DSP芯片的控制，比如启动，停止等，下载DSP的可执行代码，以及直接读写DSP端的memory空间等 
 MSGQ相关，ARM和DSP的通信是基于MSGQ的，MSGQ有轮询等待的方式或者中断的方式，MSG是基于共享内存池的方式。Codec Engine通过MSGQ交互一些关键数据，比如控制，和一些大块数据的地址指针等。大量的数据交互需要通过cmem实现。 
在ARM端，配合Codec Engine使用的软件模块有LinuxUtils或者WinceUtils，包含cmem，SDMA等，cmem是用来在OS之外分配连续物理内存空间，进行物理地址到虚地址，以及虚地址到物理地址空间转化的。为了避免数据的多次复制，需要开辟一块ARM和DSP共享的数据空间，ARM和DSP都可以直接访问，这部分空间需要通过CMEM管理。对ARM来说，CMEM是OS上的一个驱动程序，需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间，通过ARM传给DSP的指针必须是物理地址。 
为了适配一些播放器的接口，DVSDK还提供了DMAI（Digital Media Application Interface），DMAI提供了更为精简的媒体接口和基于OS的音视频捕捉、回放等接口，在Linux下的gstreamer和Wince下的dshow filter都是基于DMAI的。并且DMAI也提供了最基本的测试应用例子，可以很方便的进行修改和测试。 
如果只是调用现成的或者第三方的算法库，可以只了解ARM端的软件模块，Codec Engine或者DMAI已经提供了丰富的应用接口，DSP可以认为是个单纯的媒体加速器，把ARM+DSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能，就需要对DSP进行开发了。Codec Engine对DSP的算法只是规范了接口，以便于和Codec Engine一起生成DSP的可执行程序。 
开发DSP算法的工程师，和传统的单核的DSP开发模式类似，只需要操作DSP核，基于CCS进行算法开发，最后封装成xDM的接口就可以了。具体如何进行DSP的打包，如何生成DSP的可执行程序，在后续的文章继续讨论。

前段时间才做好omap3530的设计，emif,dss,cam等等接口都是1.8V,而目前通用的lcd屏和coms传感器等等都是3.3vIO，于是不得不加了coolrunner cpld做电平转换。不过想想omap主要面向手持平台，也就算了... 

然后现在在做一个dm357的东西，357也是一样采用了1.8v的IO,这就有点让人费解了，dm357本来是为了h264监控系统的平台，这个也搞1.8V就太不合适了，挂tvp5146要转换，挂个大容量nand也要转换，（1.8v的nand也特难买）.uart等等也要转换，平台成本和pcb空间大大增加。比如1.8V的ttl2rs232差不多20块，而3.3的5块就够了。 

虽然1.8是趋势，但是为什么不作成可以选择的IO电压呢？ 
比如atmel这点就做得很好,相应的IO Bank有不同的电源管脚，接1.8就是1.8的IO，3.3也兼容，多好。

TI现在有全新的Level Shift，价格低性能好，可以提供全面的1.8V到3.3V的互转，请访问http://www.ti.com/translation

OMAP3530是有ARM+DSP+3D加速处理，是多核处理器，更宏观的看，可以认为是多个芯片合成一个芯片，也就是DSP的核可以认为是独立的DSP芯片做开发，ARM核是纯ARM的OS/应用开发，3D也完全可以这样认为ARM是控制核心，其他是加速处理。为了方便多核开发，TI提供了一个CODEC ENG的软件框架，用于和DSP之间交互。 
在涉及具体开发之前，先给软件工程师分分工，目前芯片这么复杂，不可能一个人负责所有的东西，并且ARM的应用开发和DSP开发的知识背景也不一样： 
首先做DSP的算法工程师，可以完全忽略ARM处理器内核，可以基于CCS开发纯DSP的算法，和传统DSP的工作职责一样，这里需要明确的是所有的算法可以认为是从memory到memroy的处理，和外设没有关系，外设只是一个数据通道而已。做了算法以后，需要封装成xDM的标准接口，方便应用集成和多个不同DSP算法链接生成DSP的微码。 
ARM上做媒体应用或算法调用的工程师，需要了解CODEC ENG的框架，DSP端可以通过几个配置吧xDM接口的算法生成DSP的微码，在linux下的开发，TI提供了一些软件包，比如：BIOS，XDCtools，CGTools，Framecomponent等，可以生成DSP的微码。CODEC ENG在ARM端提供有限的几个标准接口，方便应用可以移植到不同的平台，并且能直接调用DSP端的算法进行加速上层系统或应用工程师，就是做传统的ARM上应用开发，完全不需要考虑DSP或者3D是如何具体实现的做驱动的更是和DSP没有任何关系咯

如果需要3D，可以从这儿下载OpenGL ES2.0的SDK （免费的），在PC上（windows和Linux都支持）仿真，最后在omap3上交叉编译一下就得了 

Open GL ES documents (open) 
http://www.khronos.org/opengles/ 
Generic Graphic SDK 
http://www.imgtec.com/powervr/insider/powervr-sdk.asp 
Other 3D software provider/partners 
www.altsoftware.com 
www.ardites.com 
www.ingenient.com 
www.intelligraphics.com 
www.vuemerang.com