基于TI Davinci架构的双核嵌入式应用处理器OMAPL138开发入门

基于TI Davinci架构的双核嵌入式应用处理器OMAPL138开发入门

一、简介 


TI的达芬奇架构嵌入式应用处理器使用DSP与ARM结合的非对称多核结构，当然现在也有管脚全兼容的单核。本文要介绍的就是其中的一款低功耗处理器OMAP L138。 

OMAP L138包括一个主频300M的ARM9处理器内核和一个300M的C6748DSP内核（均是32位处理器）。此外还有大量外设在此不做说明，与通用的ARM与DSP内核相比有如下一些不同点： 

1.内存映射，该处理器的外设与内存统一编址，DSP与ARM共享4G内存空间。但其中有一部分DSP仅可见（如DSP的数据指令缓存），一部分ARM仅可见（如ARM的内部RAM），其余的两者都可以访问，具体的请参考其芯片资料。 

2.中断，与通用的DSP与ARM相比，达芬奇架构并没有在这两个核中增加用于双核通信及相互控制的指令（也许是本人没发现吧！如果你发现相关的说明，请发个email告诉我，谢谢！），然而却增加两个核之间的中断，共计7个。当双核需要进行通信时，首先把数据放在双方可以访问的内存上，然后给对方一个中断，对方在中断中接收传递过来的数据，以此实现双方的通信，个人认为这就是DSP Link实现的基本原理吧：） 

3.能源与休眠配置模块（PSC），这个模块主要负责整个系统的能源管理，可以使能或者休眠ARM核，DSP核以及大部分外设ARM核与DSP核的相互控制主要就依赖这个模块。 
对于OMAPL138，上电时默认的是ARM核被禁止，DSP核被使能。说以开机时是DSP核先启动，然后是DSP的ROM Bootloader做一些初始化后使能ARM核后，ARM核才开始运行。不同的达芬奇处理器是不同的，比如OMAPL137就是反过来的，网上资料鱼龙混杂，弄不清楚的话就去看PSC模块中的ARM和DSP核的默认值就可以了。 
  

二、启动过程 


1.开机上电，用户在BOOT 管脚上配置的启动方式被锁定采样到SYSCFG模块的BOOTCFG寄存器，从而确定可处理器的启动方式。 

2.PSC模块中的启动默认值是：ARM核休眠，DSP核使能。所以这时候DSP启动，DSP从片内DSP L2 ROM处读取指令执行。这里有TI已经固化的仅DSP核可以访问的ROM Bloader，简称DSP RBL。

3.DSP的RBL做一些简单的初始化后，就通过PSC模块使能ARM核，休眠自己。然后ARM就开从片内的RAM Local ROM处读取指令并执行，这里面有TI已经固化好的ARM ROM Bootloader，简称ARM RBL。 

4.ARM的RBL做一些初始化后，根据BOOTCFG寄存器的设定，从指定的地方读取用于启动U-Boot的Bootloader，即U-Boot BootLoader，简称UBL。UBL可以放在Nandflash，或者通过串口下载等方式取得。值得说明的是，这里的UBL是(AIS Application Image Script )格式，而不是通常的BIN格式。 

5.当ARM RBL读取到UBL后就根据AIS格式中的命令初始化、加载并运行UBL。然后就是UBL加载运行U-Boot，U-Boot根据启动参数启动Linux，Linux根据启动参数加载根文件系统。 

6.这时ARM核上的Linux就运行起来了，但DSP还处于休眠状态。在Linux经过一系列初始化后会执行跟文件系统中/etc/profile的指令。我们在这里添加插入DSP Link内核模块的命令，就会在/dev目录下产生一个叫dsplink的设备文件。这个DSP Link内核模块就是通过前面所说的中断和PSC设定就可以完成与DSP的通信与控制。 

7. 然后再执行我们自己的ARM端程序，在ARM端程序中使用DSP Link的库函数来访问dsplink设备，从而在用户空间实现对DSP核的控制与通信。在我们写的ARM端程序中使用DSP Link库函数加载DSP端的应用程序到内存，使用DSP Link的PROC函数启动DSP核。然后ARM核和DSP核就都各自独立运行起来了，通过DSP Link来进行通信。 

  

三、OMAPL138 相关软件包及开发工具 


开发环境说明：除了CCS3.3是在WindowsXP上外，其他的都是在Fedora14上。 

1. OMAP_L138_1_00_00_11.bin - TI的OMAPL138 SDK，对于其他的达芬奇架构处理器有都有对应的DVSDK可供下载，内容大同小异。 
  这里面包含的有如下内容： 
    pspdrivers - DSP BIOS 平台驱动，包括csl等，编写驱动程序需要参考其中内容。 
    biosutils - DSP端OS工具集，如csl片级支持库等。 
    codec_engine - 基于DSP Link与CMEM之上的更高级的双核间通信方式。 
    dsplink -用于ARM与DSP间通信。 
    REL_EDMA3_LDD_BIOS5 - DSP端的DMA驱动库，方便DMA的管理及使用。 
    fc(Framework Components) - DSP端软件框架，包括资源管理等。 
    linuxutils - Linux端工具集，cmem就在其中。 
    xdais - TI DSP算法接口标准库。 
    ase(Audio SOC Example) -使用DSP Link 进行音频编解码的例子。 
    Davinci-PSP-SDK - TI 提供的Davinci平台软件包，包括nandwriter，ubl，uboot和rootfs等。 

2. bios_setuplinux_5_41_02_14.bin - DSP BIOS 5 DSP端的实时操作系统。 

3. ti_cgt_c6000_6.1.9_setup_linux_x86.bin - TI DSP C6000交叉编译器。 

4. xdctools_setuplinux_3_16_01_27 - RTSC(实时软件组件)工具集，这是Eclipse基金会的一个开源项目。用于工程管理，类似于Make，但比Make更强大。 

5. cs1omapl138_1_00_00-v2_setup_linux.bin -基于OMAP L138的Codec Engine服务器例子，其中有jpeg等编解码算法的例子程序。 

6. sourcery g++ - ARM9交叉编译器，可以自己去sourcery的官方去下载。 

7.CCS - 这里使用的是CCS3.3，主要用于编译nandwritter，ubl，烧写ubl和uboot。 

  

四、 BootLoader 


相关说明： 
1.OMAPL138中的nandwritter是运行在ARM上的，用于把AIS格式UBL和U-Boot烧到Nandflash上的一个程序，使用CCS编译，然后用仿真器加载在ARM核上运行，通过交互式对话框就可以把UBL和U-Boot烧到指定设备上。 

2.UBL也是使用CCS创建的ARM端裸机程序，首先编译成bin格式的目标程序，然后使用AIS生成工具转换成AIS格式，最后使用nandwritter烧到nandflash中。 

编译烧写步骤： 
1. 用CCS打开Davinci-PSP-SDK 中提供的ubl，编译生成bin目标文件。 
2.使用AIS生成工具，再根据开发板进行配置，把bin文件转换成AIS文件。 
3.用CCS打开Davinci-PSP-SDK 中提供的nandwritter，编译并使用仿真器加载运行。 
4.在出现的交互式对话框中依次填入要烧写ubl核uboot.bin路径即可。 

  

五、DSP Link 


DSP Link是TI为达芬奇架构处理器提供的一种双核通信架构。在DSP端，DSP Link作为DSP BIOS的一个驱动而存在。在ARM端，DSP Link最为一个Linux的外设而存在，并通过应用层的函数库访问这个设备的形式进行操作。 

进行DSP Link的软件开发需要以下的软件包： 
  sourcery - ARM交叉编译器。 
  linux - Linux 内核，编译DSP Link内核模块需要。 
  cgt600 - DSP交叉编译器。 
  DSP BIOS - DSP实时操作系统，DSP端使用DSP Link就必须这个。 
  xdctools - RTSC工具集，DSP BIOS以及很多TI的软件包都使用这个进行工程管理。 
  dsplink - DSP Link软件包。 


编译步骤： 
  1.解压或安装以上软件包到同一个目录，如/opt/OMAPL138_SDK。 
  2.然后修改dsplink顶层目录中Makefile中的软件包路径到正确的为只可。 
  3.在命令行中输入make编译即可。 


额外说明： 
  使用我修改过的软件包可以大大简化编译过程，具体说明参考软件包顶层Makefile中的说明即可。 

  

六、CMem 


由于DSP Link中的共享内存分配功能比较弱，无法分配太大的连续内存，所以TI又推出了CMem，用于分配大片连续共享内存。 

  

七、Codec Engine 


由于DSP Link比较底层，使用起来也不方便，所以TI又在此基础上设计了Codec Engine。Codec Engine的底层实现依然是依赖于DSP Link和CMem的，在上层对TI的xDAIS算法接口标准进行扩展xDAIS-DM，简称xDM。 

xDM使用面向对象的编程方法，把算法抽象成4类对象：视频，图像，语音和音频，即VISA。 

Codec Engie工程管理使用XDC工具，所以所有模块间的访问，模块定义或模块实现等等都要遵循RTSC标准。RTSC软件包的配置使用xdcscript脚本语言，模块接口定义使用xdcspec脚本语言，这两种脚本语言都是JavaScript脚本语言的扩展。包括用来进行DSP BIOS配置的TextConf语言也是JavaScript的扩展。JavaScript实际上是ECMA-262标准中的ECMAScript脚本语言，参考其中内容将有利于理解这几种脚本语言。 


  

八、双核技术展望 


目前TI的DSP BIOS 6 已经改名为SYS BIOS 6，不仅仅可以在DSP上运行，也可以在ARM等其他处理器上运行，支持多个不同的处理期间的通信。在DSP端把原本的任务间通信和现在的处理器间通信合并在一起并进行了增强，叫IPC。在非DSP BIOS操作系统上叫SYS Link，取代原来的DSP Link，同样也对其进行了增强，不再需要CMem了。而且这些模块的配置都可以动态进行，API的功能也越来越强大，使用很灵活。但可惜的是Codec Engine只能支持旧版的DSP Link。 

今年，双核的处理器已经进入手机领域，不久的将来双核讲无处不在。在达芬奇的多核架构中，DSP多用于处理计算任务，而ARM处理，存储核显示网络等任务。这仅仅是功能的划分，但试想一下：如果两个核都是ARM，一个运行RTOS，一个运行Linux呢？ 
在RTOS上处理实时任务，在Linux处理非实时任务，也许可以解决当前Linux不时实，RTOS软件资源匮乏的现状呢？这只是一种臆想，仅仅是抛砖引而已。 

  

九、参考文档 


DataSheet： 
OMAP-L138 Low-Power Applications Processor 
TMS320C6745C6747 DSP System Reference Guide 
TMS320C674x DSP Megamodule Reference Guide 
OMAP-L138 Applications Processor System Reference Guide 
TMS320C674x OMAP-L1x Processor Peripherals Reference Guide 

BootLoader： 
Using the OMAP-L1x8 Bootloader 

SDK： 
Building The OMAP-L1 SDK 

RTSC&XDCTools： 
Real Time Software Components for Embedded Platforms 

DSP BIOS： 
DSP BIOS TextConf User's Guide 
TMS320C6000 DSPBIOS 5.x Application Programming Interface (API) Reference Guide 

xDAIS： 
TMS320 DSP Algorithm Standard Rules and Guidelines User's Guide 
TMS320 DSP Algorithm Standard API Reference User's Guide 

xDM： 
xDAIS-DM (Digital Media) User Guide 

DSP Link & CMem： 
Mastering the Art of Memory Map Configuration for Systems 
Multicore Programming Guide 
DSP BIOS Link-Based GPP-DSP System 

Codec Engine： 
A Technical Overview of eXpressDSP-Compliant Algorithms for DSP Software Producers  
Codec Engine Application Developer User's Guide 
Codec Engine Server Integrator User's Guide 
Codec Engine Algorithm Creator User’s Guide 

  

十、文档说明 


人在网络，不能总是予取予求。 

特此把自己在TI双核开发上的点点肤浅经验贡献出来。 

愿对同行有所帮助，共同勉励前行！ 

个人理解难免存在错误，欢迎批评指正！ 

欢迎任意转载，但请保留出处！ 


本文最初发布在www.ourdev.com的ARM分坛上，相关软件包，工具和版本更新，如无特说明，均在此处