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 内核作为支持 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