如何基于TMS320C6678设计多核DSP上电加载技术?
0 引言
本文引用地址:http://www.amcfsurvey.com/article/201808/385127.htm在视频检测、医疗影像及红外图像快速跟瞄系统应用中,越来越复杂的二维、三维甚至四维的图像处理,需要并行化的处理系统,并能够运行复杂的算法。要实现这些复杂的系统,高端FPGA+高性能DSP是目前普遍采用的方案,而单个DSP的性能已发展至极限,所以解决复杂的并行算法,多核DSP是现在发展的全新方向,其中多核DSP的根加载技术是其难点之一。
TI公司推出的DSP芯片TMS320C6678(C6678)具有8个内核的高性能DSP,每个内核工作频率均达1 GHz。
其支持的Boot 模式有SPI、I2C、EMAC、SRIO 和并口Emif16 NOR-FLASH。其中Emif16 NOR-FLASH模式是不用上位机参与、比较简单、独立成系统的一种,大多独立DSP系统采用该方式。
网上能搜索到关于C6472和C6678零星一些加载资料,都是借助于第三方转换工具,太过于笼统。下面是针对C6678 的并口Emif16NOR-FLASH的上电加载作详细的探讨。
1 C6678 的上电加载过程
所谓上电加载(上电自举),即是当DSP复位后,正常运行用户程序之前运行的一段小程序,就像PC机的BIOS 一样。多核加载同单核加载区别很大,不但要负责主核的加载而且还有其他核的加载与激活。C6678的Emif16 NOR-FLASH 可以直接执行程序(XIP)(这与C641x系列DSP不同),其上电加载过程示于图1。
上电复位后,DSP 首先运行固化在片上ROM位于地址0x20b00000的程序,称为片上Loader,片上Loader根据DSP硬件管脚状态,判断用户采用的Boot模式以跳转到相应模式的二级加载程序。如图1的 Emif16 NOR-FLASH模式中,运行片上Loader后,PC指针直接指向NOR-FLASH首地址0×70000000并开始执行FLASH上的二级Loader程序,二级Loader存储在FLASH开始地址0×70000000~0×70000400的范围内。从0×70000400开始保存应用程序的根表数据(即被烧烧写到FLASH中的应用程序的数据)。二级Loader的功能是将保存在 FLASH中的Core0~Core7的根表数据搬移到DSP相应的地址段内,搬移完后,二级Loader程序PC指针跳到Core0的主程序入口地址_c_int00处,开始执行Core0的应用程序。在Core0的应用程序开始加有使其他核激活运行的代码(这也是有别于单核的特殊之处),至此整个多核加载就此完成。事实上,如果你的应用程序很小,且运行速度要求不高,图1中的2、3和4过程都可以不要,只要把应用程序的原始代码数据烧写到FLASH从0×70000000开始的位置,上电正常运行即可(这在C641x 上是不行的),如此DSP 的许多高性能就体现不出来,且多核工程大多采用嵌入式sysbios工程,占用存储器比较大,所以正常的Boot过程必须采用图1所示的二级加载过程。
从图1中看出,一个完整多核加载过程,开发者需要做的是二级加载器Loader的编写、FLASH中映像文件的产生、FLASH烧写器的编写,主核对各辅助核的触发代码的编写(被加载的应用程序不在本范围内)。
2 多核映像文件的组成与产生
映像文件就是用户要烧写到外部FLASH上的全部数据文件,它是由二级加载器Loader的代码数据(在文件前部)和应用程序的根表(Boot Table)数据(文件后部)的合成数据文件。单核和多核的二级Loader 都一样,区别就是后部的根表数据。根表是应用程序的所有代码和数据以在片上占用的地址来分段存储的数据包,包的第一个4 B 是main()函数的入口地址_C_int00,后面由若干数据段组成,每个段前4 B为该段数据的字节长度Byte_count_x(x 为段序号),接着4 B Address_x 为该段在片上的存储地址,后面是Byte_count_x个字节的具体数据Data_x。所有数据段结束后是4个字节0作为根表的结束标记。该根表格式如表1所示。每一个段的数据字节数可能不是4的整数倍,根表中数据区就在后面添0按4 B的整数倍向上取整,故整个根表文件字节数必是4的整数倍。
根表数据产生很简单,由应用程序最终生成的Out文件,通过ccs自带工具hex6x.exe选择不同的参数而产生,产生的文件即是根表文件,可以选择生成二进制文件或文本文件,本研究采用二进制。其产生命令为(app为应用程序名,app.out为ccs产生的连接文件):
hex6x-boot -b -e _c_int00-order L-memwidth=32 -romwidth=32-o app.bin app.out
app.bin为产生的二进制根表文件,将二级Loader程序的二进制代码加到根表文件的头部即是app应用程序的映像文件。
多核的映像文件是由二级加载器Loader和多个核应用的根表合并而成的文件。多个核对应多个独立的工程,并由CCS产生多个out文件,再由hex6x.exe产生各核的根表文件。后对Core0的根表文件先去掉末尾4 个0字节,再将各辅助核的根表文件的开始的入口地址_C_int00和末尾4个0字节去掉,加到Core0被去掉了末尾字节的根表文件后,然后再将每个核的_C_int00当成一个4字节的数据段来保存到上面的合成文件的后面,而各_C_int00在片上的存放地址即为各核的专门固定地址Boot Magic Address,如Core1的Boot Magic Ad-dress为0x1187fffc,Core2为0x1287fffc,…,Core7为0x1787fffc。所有根表数据段构成后,再将4个0字节作为结尾标志加到文件的最后,这样合并后的根表文件如表2所示。同样,将二级Loader 的代码数据加到该文件头部即形成多核的映像文件。由hex6x 生成的单核根表文件到合成映像文件的产生,全是文件操作,可以用一般的C语言工具,甚至Matlab等工具都可以完成。
同表1相比,表2仅仅只是增加了所有辅助核数据段和各核的_C_int00特殊数据段而已,表头和结束字节都相同,因此完全适用于二级Loader按统一Boot Table格式搬移数据。需特别注意,各辅助核的out文件通过hex6x.exe产生的根表数据段中,当映射到L2(0×00800000~0x0087FFFF)的范围时,与Core0的地址是相互覆盖的,产生合成根表时必须加上各核的L2基地址0×10000000+n*0×1000000(n 为辅助核号),如Core1的地址0×00825000,映射为0×11825000,同样地址Core2映射为0×12825000,Core7映射为0×17825000。
评论