OMAP35xx_boot

OMAP3CPU

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

第一步：配置CPU的启动方式（sys_boot）；第步bootROM会从NAND中读取x-loader，ECC校验通过以后，就跳转执行x-loader第步x-loader接管，由x-loader去读取u-boot，然后执行u-boot.u-boot在SDRAM中运行，并引导Linux内核启动。

注：

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

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

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

Linux开发板提供源代码。



TI所有DSP，如OMAP,DM644x的ROM都是芯片出厂时掩膜掩好的。客户只能读，不能擦。ROM里存放BOOT代码，有些DSP的ROM会存放一些数学库函数。启动时omap35x会把0x40000000起的1M空间映射到0x00000000。0x40000000起始的80k空间存放的是加解密使用的代码／数据。当然开头那几十个字节是arm的跳转向量表。其中reset会跳到bootrom（0x00014000或0x40014000起始的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的芯片，具体如下：omap3503COTEX-A8+外设omap3515COTEX-A8+外设+3D加速omap3525COTEX-A8+外设+DSP及视频硬件加速omap3530COTEX-A8+外设+DSP及视频硬件加速+3D加速同样一个硬件设计，可以覆盖不同等级的产品需求。BeagleBoard采用x-loader+u-boot的方式来启动内核，我看了一下x-loader的代码，是u-boot的精简版，主要实现的功能是初始化硬件，然后根据启动方式从nandflash或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初始化memorycontroller，把u-boot读进外部RAM，然后跳到外部RAM执行u-boot。可以把UBOOT直接通过CCS下载啊，然后运行。。。记得下载ELF的文件，不要下载.bin哦如果nandflash启动的话，修改一下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，下载UBOOT3.uboot/eboot启动4.linux/wincekernel启动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/2b9e99886bb7a747xloader/uboot也可以用510/560仿真器+CCS跟踪调试1、TI内部bootrom的源代码公开吗？2、请问哪里可以下载？Bootromcode不对外开放三个核是完全独立的，一般看到的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的CODECENG软件框架，媒体处理的算法可以放在ARM也可以放在DSP，上层调用已经抽象化有限的一些接口，比如Ceate(),Control(),Process(),Delete()，如果用DSP加速，算法是在DSP的微码里面，通过这些控制命令接口来进行编解码处理等。OMAP35x的裸板测试程序在哪可以下载？SDK开发包的board_utility里面有ITBOK（IstheboardOK?)集成在uboot里面进行板级硬件测试nand启动，首先要看是不是在支持的bootdeviceID里面（如下）启动代码需要写在0-4个块然后xloader需要加上8字节的头，用signGP工具还有值得注意的是ECC，需要用硬件ECC以及注意xloader的loadaddress之类的如果还不行，恐怕需要用仿真器来调试了。。。Table26-32.SupportedNANDDevicesCapacityDeviceIDBusWidthPageSizeinKB64MbE6h8512128Mb33h8512128Mb73h8512128Mb43h16512128Mb53h16512

我大致说一下我这边的情况：1、flash用的是三星的片子：k9f1g08，id为0xf1，2kpage，128Mbyte，在TI支持的列表里可以找到。2、启动代码写在0块0地址3、x-loader加上了8字节的头部(到sd卡上能正常启动)4、烧写的时候使用了nandecchw(使用硬件ECC)5、按照芯片datasheet的介绍，nandfalsh片选接到cpu的CS0，nandflash忙引脚接到cpu的wait0，在u-boot下操作没问题满足以上条件，可以就是不能nandboot~现在我最大的怀疑是ecc出了问题，可是我使用的是beagleboard提供的u-boot，flash驱动使用原来的，只是稍微修改一下flash的ID和位宽而已(beagleboard使用的flash为16bit，而我们使用的是8bit)，不知道从以上信息能否定位出问题的所在？(TI固化代码没有打印任何错误信息，不然就好办了^_^)换成8bit的nand，有几个地方需要修改：xloader中配置GPMC_CONFIG1，默认的是配置成16bit了，这里要修改成8bitNAND的option中把16bit的宏定义干掉在ECC的OOBINFO中，由于8bitnand只用一个字节表示是否是坏块，但是默认的uboot中配置成16bit的两个字节，也就是ECC值要从第二个字节开始放，不是第三个字节其他都用默认的代码，应该就可以了记得烧录xloader的时候要加上8字节的头，并且必须使用hwecc我只看了在8bit下ecc的结果,却没注意存放的位置.我修改了ecc存储位置,示波器观察片选,应该能确定部分代码被拷贝到内部ram,但是依然无法启动:(貌似数据在一直拷贝.不知道是不是因为用了cpld做转换造成的.3.3的nand.或者是tmx的片子?2.1版，原来我看的文档rom不支持mlc的nand，现在文档说也支持了。另外一个比较容易忽略的地方是GPMC的位宽，默认在xloader代码里面设成16bit的模式，如果用8bit的，需要注意修改GPMC的CONFIG1寄存器".......................................貌似数据在一直拷贝."，你指的是退出nandboot后(比如进入uart3boot，可以看到串口打印40T)用示波器测试发现nandflash片选引脚一直有信号吗？我们之前也存在这样的问题，后来证实是hwecc的存放位置不对所致(TI启动代码对于8bitnandflash的hwecc的存放位置和16bit的nandflasht刚好错开了一位)，另外注意一下u-boot下gpmcbank0的位宽要设置正确，goodluck。DJBean，因为我只是测试是否能从nand启动，所以按我理解应该是omap的rom会整个x－load内容拷贝到sram运行，这样的话哪怕x－load代码错误（如GPMC），也是能启动x－load的，比如串口发送数据等，只是不能接着运行u-boot罢了，对么？luofuchong，我后来在nand启动失败后用560仿真器观察拷贝的地址和数据，发现如果x-load大于某个大小后的数据是错误的，如果代码小，比如4k这样内容是正确的，但是依然无法启动。我现在的eccobb是这样的，您看对么？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-loaderloaduboot时用的是swecc。我现在的问题是，用工具把x-loadr烧写进nandflash后，串口什么信息也打印不出来，但GPMC_cs0引脚是有信号的。我用工具读出NF中的数据和我下载前对比了一下，完全相同。难道又是hwecc造成的？如果下载软件本身和hwecc有关系，那我就怀疑是我的下载工具有问题。。。。。。我现在调的是wince的bootloader，和linux的一样也是两级boot（x-load和eboot），TI提供了一个下载工具EVMFlash，可以直接把x-loaddownloadNANDFlash。我现在是下载成功了，从NF读出数据和下载之前的比较，是完全一样的，但不知为什么不执行程序。关于USB的问题，默认是没有打开hotplug-in的，也就是如果上电的时候有USBhub，系统是可以检测到，如果上电时候没有插USBHub，等系统起来以后再加上，有可能检测不到，方法是执行如下命令（也可以放在rcS里面）：echo"S">/proc/driver/musb_hdrc这样就可以支持USBHub和USB设备的热插拔了如zqdsp所说，由于供电问题，你需要用带外部电源的usbhubbeagle的USBOTG是不能直接接U盘等外设的，因为OTG接口的电源供电是由TWL4030直接给的，最大供电电流100ma。所以要挂鼠标、键盘、U盘等必须外接USBhub，并且这个HUB还必须是有源HUB，有外部的供电。再建议大家，不要图便宜在市场上买些特便宜的有源USBHUB。我当时在市场上前前后后共买了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/BeagleBoardHandheldsMojohttp://elinux.org/BeagleBoardDebian做了，载入内核到bootkernel后就被卡住不动了请教各位高手问题出在哪里了，uboot的arch_number也已经改成beagle的了。高手帮忙，或者给个操作步骤~~我们的OMAP3530板子调试出了一些问题，由于比较复杂，不知道能否提些建议或帮忙找相关人员回复一下，国内TI的FAE在说到这些具体问题时好像也不是很清楚：1）OMAP3530是否必须和TPS65930配合使用，如果去掉TPS65930，会有什么影响？2）我是按照瑞泰的MINI板做设计的，但是在焊接过程中发现TPS65930制板出了问题，没法焊接，所以只有做弥补工作，主要包括电源、26M时钟、32.768K时钟的改动，现在通过JTAG调试，发现电源、两路时钟都可以了，芯片应该能工作了，但就是没有办法从SD卡启动，请问是SD卡的INS脚连到了TPS65930的CARDDETECT脚但我没有办法焊接TPS65930导致的吗？如果是，能不能通过修改什么东西绕过它，还是只能改动OMAP3530的BOOTROM？但BOOTROM恐怕只有TI才能改了。3）如果2）中无法解决，我想从OMAP3530的串口3启动，不知怎样做？4）如果2）、3）仍无法解决，从OMAP3530的USB1、USB2能否启动？怎样启动？USB0在TPS65930上的，没有办法使用。5）如果以上都不行，那就只有重做印制板了？

从UART3启动吧！找TI的FAE要EVMFlash工具就可以搞定！但串口只能下bootlder，内核或镜像从以太网下载吧。DSP完全可以访问McBSP,同样的操作memorymap的寄存器就好了除了有些特殊说明的接口,DSP都是可以访问的,不过通用应用一般不建议这样使用,因为由ARM管理外设和驱动更为标准和合适,有些特殊应用,也可以用DSP访问外设你说的同样的操作memorymap的寄存器即可，我对这个不大懂。是不是说DSP端和ARM端都是操作相同的McBSP寄存器？我看OMAP3530的datasheet上的McBSP那一章，讲到McBSP的控制寄存器地址，比如：McBSP1的基地址是0x48074000，大小有4KBytes，那是不是ARM和DSP都是通过访问0x48074000处的寄存器来控制McBSP1的？我浏览了datasheet，其它地方似乎是没有映射到McBSP1的寄存器的地址了。是不是DSP和ARM共用那4G的地址空间？对这种双核的地址空间分布感觉有点混乱，概念不清楚。又阅读了下memorymapping的章节，MPU和IVA2.2都有自己的4G的地址空间，这2个4G空间中，只有一小部分地址是有对应部分的，另外的则是完全不相干的。比如：在ARM侧的地址：0x5C000000~0x5CFFFFFF对应的是DSP端的：0x00000000~0x00F17FFFF，这部分可以访问L1RomRam，L2RomRam。但是我就是没找到McBSP在DSP侧的寄存器地址。我用仿真器试过了，带的demo一个是在arm上跑的，一个是在dsp上跑的，应该是两个程序都可以使用相同的地址访问外设（我测试的是UART1，McBSP1的几个寄存器，读出来的寄存器的复位值与datasheet上的描述的一模一样），而且我在ARM侧跑的程序上做了修改后，然后再启动DSP侧的程序查看相关的内存和寄存器的值，跟我在ARM侧上修改的一致。所以dsp是可以直接访问外设的。烧写xloader和uboot到oamp3530的flash的方法？在u-boot中：烧写XLoader到NandFlash：OMAP3Miniboard#mw.b80000000ff80000OMAP3Miniboard#mmcinitOMAP3Miniboard#fatloadmmc0:180000000x-load.bin.iftreadingx-load.bin.ift11412bytesreadOMAP3Miniboard#nandecchwOMAP3Miniboard#nanderase080000NANDerase:device0offset0x0,size0x80000Erasingat0x60000--100%complete.OKOMAP3Miniboard#nandwrite80000000080000NANDwrite:device0offset0x0,size0x80000524288byteswritten:OK烧写U-Boot:OMAP3beagleboard.org#mmcinitOMAP3beagleboard.org#fatloadmmc0:180000000u-boot.binreadingu-boot.bin147424bytesreadOMAP3beagleboard.org#nandunlock(Note-ifyouareusingamorerecentversionofU-Boot,nandunlockismissingsimplyskipthisstep.i.e.U-boot2009.08)device0wholechipnand_unlock:start:00000000,length:268435456!NANDflashsuccessfullyunlockedOMAP3beagleboard.org#nandeccswOMAP3beagleboard.org#nanderase80000160000NANDerase:device0offset0x80000,size0x160000Erasingat0x1c0000--100%complete.OKOMAP3beagleboard.org#nandwrite8000000080000160000NANDwrite:device0offset0x80000,size0x1600001441792byteswritten:OKOMAP3beagleboard.org#



在u-boot已经存在的状况下这是最佳方案。兄弟遇没遇到这种情况：omap里没有uboot，或者u-boot损坏，该怎样烧写ICETEK-OMAP3530-MINI任何时候都可以从sd卡启动，即从sd卡启动u-boot然后再烧写flash串口启动需要先下载xloader，然后在xloader里面下载ubootmini板每次重启（裸机情况）都会按顺序从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到nandNANDflash都有Badblock，如果你的映像文件跟分区一样大，可能因为有Badblock写不完整，一般分区要多分配几个块做后备。ES3.1是芯片的版本号，芯片的版本号不同，有些芯片bug不太一样双核就意味这每个核是独立的，需要单独开发，然后两个核之间进行通信交换数据，和多芯片不同就在于通信方式不同所以要在DSP上开发，要用DSP的开环工具--CCS或者CGtools然后可以基于DVSDK的软件框架进行双核通信OMAP3530MINI板是ARM和DSP双核的它们硬件是通过DSP中的HPI连接起来的,那么在DSP处理完的数据,ARM要怎样调用了是要用什么指令吗,还是用LINUX命令来实现,各位辛苦了!!!!用DSP/BIOSLINK,专门提供一套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是工作的，可以连仿真器windowsxp下如何开发omap3530？bootloader怎么开发呢？有类似Xloader这样的启动程序吗？这个X-loader可以在CCS上编译吗？与linux下用的X-loader有什么区别？CCS不能直接编译xloader，因为gnugcc的汇编编译器和CCS的不一样编译好的xloader可以通过CCS+JTAG下载到板子上去做调试DSP/BIOS内核

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

DSP/BIOS内核提供DSP/BIOS5.x和DSP/BIOS6.x两种版本。

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

DSP/BIOS6.x需要CCStudio4.x；而且除了较新的DSP器件，它还支持ARM和MSP430微处理器设备。与DSP/BIOS5.x相比，它还提供多个额外的对于芯片的外设接口，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，CODECENGINE的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的核心是CodecEngine，所有的其他软件模块基本都是围绕CodecEngine的。CodecEngine是连接ARM和DSP的桥梁，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块，在编译DSP端可执行代码和ARM端应用程序时，都需要CodecEngine的支持。CodecEngine主要有两部分：ARM端应用适配层，提供了精简的API和对应的库给应用层使用。DSP的算法调用层，提供了DSP算法的接口封装规范，是的所有的算法通过简单的配置就可以编译到DSP的可执行程序中。最终的应用程序需要通过CodecEngine的API接口来下载DSP代码，调用DSP端的封装好的算法，以及进行ARM和DSP的通信。关于CodecEngine的介绍，可以参考《帮您快速入门CodecEngine》。CodecEngine底层ARM和DSP的通信是建立在DSP/BIOSLink之上的，DSP/BIOSLink真正实现ARM和DSP交互的软件模块。由于DSP/BIOSLink是跨平台的，也是有ARM部分和DSP部分组成，其中在ARM端，包括基于OS的驱动和供应用调用的库文件，DSP端，必须要用DSP/BIOS，DSP的可执行代码需要包含DSP/BIOSLink的库文件。DSP/BIOSLink常用的主要有如下几部分的软件模块：PROC相关的，主要是用来做DSP芯片的控制，比如启动，停止等，下载DSP的可执行代码，以及直接读写DSP端的memory空间等MSGQ相关，ARM和DSP的通信是基于MSGQ的，MSGQ有轮询等待的方式或者中断的方式，MSG是基于共享内存池的方式。CodecEngine通过MSGQ交互一些关键数据，比如控制，和一些大块数据的地址指针等。大量的数据交互需要通过cmem实现。在ARM端，配合CodecEngine使用的软件模块有LinuxUtils或者WinceUtils，包含cmem，SDMA等，cmem是用来在OS之外分配连续物理内存空间，进行物理地址到虚地址，以及虚地址到物理地址空间转化的。为了避免数据的多次复制，需要开辟一块ARM和DSP共享的数据空间，ARM和DSP都可以直接访问，这部分空间需要通过CMEM管理。对ARM来说，CMEM是OS上的一个驱动程序，需要通过IOCTL来实现内存分配或者地址空间转化。由于DSP可以访问任何物理地址空间，通过ARM传给DSP的指针必须是物理地址。为了适配一些播放器的接口，DVSDK还提供了DMAI（DigitalMediaApplicationInterface），DMAI提供了更为精简的媒体接口和基于OS的音视频捕捉、回放等接口，在Linux下的gstreamer和Wince下的dshowfilter都是基于DMAI的。并且DMAI也提供了最基本的测试应用例子，可以很方便的进行修改和测试。如果只是调用现成的或者第三方的算法库，可以只了解ARM端的软件模块，CodecEngine或者DMAI已经提供了丰富的应用接口，DSP可以认为是个单纯的媒体加速器，把ARM+DSP的芯片当作ASIC一样使用。如果要充分发挥DSP的性能，就需要对DSP进行开发了。CodecEngine对DSP的算法只是规范了接口，以便于和CodecEngine一起生成DSP的可执行程序。开发DSP算法的工程师，和传统的单核的DSP开发模式类似，只需要操作DSP核，基于CCS进行算法开发，最后封装成xDM的接口就可以了。具体如何进行DSP的打包，如何生成DSP的可执行程序，在后续的文章继续讨论。前段时间才做好omap3530的设计，emif,dss,cam等等接口都是1.8V,而目前通用的lcd屏和coms传感器等等都是3.3vIO，于是不得不加了coolrunnercpld做电平转换。不过想想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这点就做得很好,相应的IOBank有不同的电源管脚，接1.8就是1.8的IO，3.3也兼容，多好。TI现在有全新的LevelShift，价格低性能好，可以提供全面的1.8V到3.3V的互转，请访问http://www.ti.com/translationOMAP3530是有ARM+DSP+3D加速处理，是多核处理器，更宏观的看，可以认为是多个芯片合成一个芯片，也就是DSP的核可以认为是独立的DSP芯片做开发，ARM核是纯ARM的OS/应用开发，3D也完全可以这样认为ARM是控制核心，其他是加速处理。为了方便多核开发，TI提供了一个CODECENG的软件框架，用于和DSP之间交互。在涉及具体开发之前，先给软件工程师分分工，目前芯片这么复杂，不可能一个人负责所有的东西，并且ARM的应用开发和DSP开发的知识背景也不一样：首先做DSP的算法工程师，可以完全忽略ARM处理器内核，可以基于CCS开发纯DSP的算法，和传统DSP的工作职责一样，这里需要明确的是所有的算法可以认为是从memory到memroy的处理，和外设没有关系，外设只是一个数据通道而已。做了算法以后，需要封装成xDM的标准接口，方便应用集成和多个不同DSP算法链接生成DSP的微码。ARM上做媒体应用或算法调用的工程师，需要了解CODECENG的框架，DSP端可以通过几个配置吧xDM接口的算法生成DSP的微码，在linux下的开发，TI提供了一些软件包，比如：BIOS，XDCtools，CGTools，Framecomponent等，可以生成DSP的微码。CODECENG在ARM端提供有限的几个标准接口，方便应用可以移植到不同的平台，并且能直接调用DSP端的算法进行加速上层系统或应用工程师，就是做传统的ARM上应用开发，完全不需要考虑DSP或者3D是如何具体实现的做驱动的更是和DSP没有任何关系咯如果需要3D，可以从这儿下载OpenGLES2.0的SDK（免费的），在PC上（windows和Linux都支持）仿真，最后在omap3上交叉编译一下就得了OpenGLESdocuments(open)http://www.khronos.org/opengles/GenericGraphicSDKhttp://www.imgtec.com/powervr/insider/powervr-sdk.aspOther3Dsoftwareprovider/partnerswww.altsoftware.comwww.ardites.comwww.ingenient.comwww.intelligraphics.comwww.vuemerang.com