《DAVINCI技术剖析及实战实用开发指南张亮第4章新》由会员分享，可在线阅读，更多相关《DAVINCI技术剖析及实战实用开发指南张亮第4章新（119页珍藏版）》请在金锄头文库上搜索。
1、1 1第4章 服务集成者Server 4.1 Server里的里的cfg文件文件 4.2 Server中的中的tcf文件文件 4.3 Server的生成方法的生成方法 4.4 小结小结2 2服务器集成者Server15生成一个Codec服务器，其中集成了容纳编码器、解码器所需的各种成分(例如DSP/BIOS、框架成分、连接驱动器和编码/解码器等)，并产生一个DSP端的可执行程序。本章对Server的配置文件：*.cfg文件和*.tcf文件进行详细描述，同时以OMAP3530和DM6467为例对Server的生成方法进行区分和讲解。3 3cfg是一个XDC的配置文件，它和当前目录下的packag
2、e.bld文件以及package.xdc文件在执行make命令后会生成当前目录下的package.mak文件。在cfg配置文件中需要设置OSAL及通信环境DSPLINK变量，并声明所使用到的各种编解码器。4.1 Server里的里的cfg文件文件4 44.1.1 配置需要的配置需要的Module在DM6467中，主要配置的Module16有Global、LogServer和Ipc三种。1. GlobalosalGlobal是对全局操作系统抽象层的配置，主要的配置如表4.1所示。5 5表4.1GlobalModule的配置6 6其中关于osalGlobal的具体结构和属性参数等可以查看目录/op
3、t/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/osal下的Global.xdc文件。这里的RuntimeEnv变量表明了运行环境，这个枚举型变量如表4.2所示。7 7表4.2枚举型变量RuntimeEnv8 8DM6467中设置该变量为DSPLINK_BIOS。只有当这个RuntimeEnv是DSPBIOS或DSPLINK_BIOS时，才需要进行后面对于内存段的配置。一般通过Program.build.cfgArgs将参数传递给配置文件。根据平台类型是否相匹配，对内存段进行设置。“defaultMemSegId”参数默认为
4、“NULL”，如果不做修改，系统会寻找一段BIOS段作为“DDR”或是“DDR2”，但是这个自动寻找的内存段有可能被移除，因此，开发者最好直接对此属性进行设置，此处设置的为DDR2。9 9表4.3调试追踪Buffer大小的设置这里是对服务器调试追踪所用的Buffer进行大小设置。所有的调试追踪数据都存储在这个Buffer中，即我们常用的GT_trace中的参数数据。只有当RuntimeEnv是DSPBIOS或是DSPLINK_BIOS时，才需要对这个参数进行配置。开发人员根据需要，可以进行注释或者修改Buffer的大小。10102. LogServerLogServer是激活BIOS端的日志模
5、块，如图4.1所示。如果在ARM端设置TraceUtil使用BIOS日志，那么在DSP端的配置文件中也要加入相应的设置来表明使用此模块，如表4.4所示。1111图4.1BIOS的LOG1212表4.4LogServerModule的定义LogServer中只有一个属性参数stacksize，表示服务端日志线程的栈大小。在/opt/dvsdk_1_40_02_33/codec_engine_2_10_02/packages/ti/sdo/ce/bioslog目录下的LogServer.xdc文件中，已经将此参数初始化值为2048。13134.1.2 Codec的的Module在cfg文件中，包括
6、所有可能需要用到的算法Module，如表4.5所示。1414表4.5算法Module的定义1515续表 1616其中，通过xdc.useModule可以指定在配置中所使用的全部Module，如表4.5中提到的VIDDEC1_COPY、SPHDEC_COPY、G711ENC等。这个函数的返回值是Module对象，当找不到这个指定的Module时，会抛出一个异常xdc.services.global.XDCException。这个异常有以下两种：xdc.PACKAGE_NOT_FOUND：表明找不到指定的package；xdc.MODULE_NOT_FOUND：表明在指定的package中找不到指
7、定的Module。1717在这个例子中，明确指出了package的路径名称。如果要避免这样的情况，在当前package的目录下，可以使用xdc.om.$curpkg来建立当前包的对象，如表4.6所示。表4.6避免明确指出包路径的定义18184.1.3 配置配置Server主要对DSP端Server的接口进行配置，包括优先级和栈大小等，如表4.7所示。1919表4.7Server的配置2020对于Server的栈大小以及执行的优先级，可以通过线程的属性进行设置。线程的属性主要包括栈大小、内存段的ID以及优先级等，如表4.8所示。表4.8线程属性结构体2121对优先级而言，最低优先级为1，最高优先
8、级为15，如表4.9所示。表4.9优先级定义在表4.7的示例中，线程的优先级为最低优先级1。在对Server的配置中，最重要的是对服务端支持的所有算法属性配置，如表4.10所示。2222表4.10算法的属性配置2323续表 2424这个数组中配置的所有算法和上述添加的CodecModule是相匹配的。其中algs的结构主要如表4.11所示。表4.11描述算法实例的结构体2525第一项name是Server生成的实例名称；第二项mod指明算法实例中具体实现的Module；第三项threadAttrs指出了线程在处理实例请求时的一些具体属性；最后一项groupId指明这个Codec应该放进哪一个资
9、源共享组，但并不是所有的系统都支持资源共享。对于不支持的系统，这个参数可以忽略不管。26264.1.4 配置配置DSKT2DSKT217负责管理系统中所有xDAIS算法的memory需求，DSKT2和应用层的接口是非常简单地Create、Execute和Delete。系统集成工程师需用memory初始化DSKT2模块。DSKT2模块包括两种类型的memory18永久性的memory(只要这个算法存在，它就会被占用的memory)和scratchmemory(算法之间可以共享的memory)。只有当一个算法被创建时，永久性memory才会被DSKT2分配给这个算法，在算法被删除的时候，这段mem
10、ory返回到heap。2727当一个算法申请scratchmemory时，会被分配一个memorypool，这个pool被拥有同一个scratchpoolID的其他算法共享。也就是说，共享scratchmemory的算法属于同一个优先级，不能中断对方。对DSKT2的配置，参看表4.12的例子。2828表4.12DSKT2关于memory的配置2929需要注意的是，这里的每一个scratchmemorypool的大小需要通过数组的形式定义，数组的第一个元素对应scratchpoolID0，第二个元素对应scratchpoolID1，依次类推。其中，heap名为“L1DHEAP”，这表明：如果算法
11、对于DARAM0的需求为5K，则DSKT2就要从L1DHEAP中分配5K的内存。如果可行，就完成算法分配，如果L1DHEAP中没有5K的大小，则算法创建失败。这里的heap名要和*.tcf文件中的heap名一致，*.tcf文件会在4.2中已讲解。此外，如果允许DSKT2使用外部临时内存scratchmemory，则添加如表4.13所示的声明。3030表4.13DSKT2关于外部内存的配置设置ALLOW_EXTERNAL_SCRATCH属性为“true”，意味着如果一个临时内存请求在内存中不能获得，并且连续固有的内存无法为这个请求分配内存时，DSKT2将使用外部内存。如果在上述的例子中，这个属性
12、设置成“false”，这就表示在没有足够的临时内存或足够的固有内存满足这个请求时，DSKT2_createAlg将失败。3131在上述例子中，分别提及了DARAM、SARAM、ESDATA、IPROG和EPROG等，这些都映射到了IALG的内存空间IALG_DARAM、IALG_SARAM、IALG_ESDATA、IALG_IRPOG和IALG_EPROG。其结构可以查看/opt/dvsdk_1_40_02_33/xdais_6_10_01/packages/ti/xdais目录下的ialg.h文件，其中的IALG_MemSpace如表4.14所示。3232表4.14枚举型变量IALG_Mem
13、Space3333其中的SARAM(Single-AccessRAM)与DARAM(Dual-AccessRAM)是按CPU每个机器周期对内存进行访问的次数来划分的两种内存。SARAM在一个机器周期内只能被访问一次，而DARAM在一个机器周期内能被访问两次，如TMS320C54系列的DSP中就配置有这两种内存。其他的ESDATA、IPROG和EPROG分别表示片外数据存储器、内部程序存储器和外部程序存储器。34344.1.5 配置配置DMAN3DMAN3主要管理DMA。关于DMAN3的配置如果无效，表示因为没有足够的内存，算法创建失败。表4.15是DMAN3的配置例子。3535表4.15DMA
14、N3的配置3636因为DMA需要memory存放PARAM和其他的通道配置，所以在DMAN3中分配有heap(分为internalheap和externalheap)。其中：heapInternal为DMAN3对象分配动态堆。heapExternal为私有的DMAN3数据分配动态堆。idma3Internal为IDMA3对象分配内存堆，如果值为false，表示IDMA3对象将从heapExternal分配堆，否则从heapInternal分配。3737scratchAllocFxn和scratchFreeFxn分别表示从scratchmemory分配/释放IDMA3对象通道。paRamBase
15、Index是通过baseindex和需要的数量进行分配的，数目范围是0255。numQdmaChannels和qdmaChannels的设置表明DMAN3有8个可用的物理QDMA通道。从numPaRamEntries和numPaRamGroup的设置表明DMAN3分配有48个PARAM。tcc是通过bitmask来分配的。38384.1.6 配置配置RMANRMAN19对基于IRES接口配置的逻辑资源进行管理(IRES是向符合xDAIS标准的特殊类型资源的管理和使用提供接口)，其配置如表4.16所示。表4.16RMAN的配置3939其中RMAN.useDSKT2=true表明需要使用DSKT2
16、进行算法内存的分配；此外，semCreateFxn、semDeleteFxn、semPendFxn和semPostFxn分别是对RMAN进行资源管理时使用到的信号量进行具体操作的函数指针。4040tcf文件20主要用来配置DSP/BIOS应用。4.2.1 environment环境数组变量环境数组变量Tconf创建一个名为environment的数组变量，其中可以定义一些文件名称、文件路径和硬件平台等内容，如表4.17所示。4.2 Server中的中的tcf文件文件4141表4.17环境变量environment的设置在表4.17的例子中定义了硬件平台，此外还可以定义以下变量：environm
17、entconfig.importPath。定义Tconf查找文件的路径，其中包括平台文件。DSP/BIOS应用的平台文件一般都是在/opt/dvsdk_1_40_02_33/bios_5_32_01/packages目录下，由于这个文件在Tconf初始化时就加到了config.importPath中，因此大部分情况下，这个变量不需要设置。4242但是，如果开发者创建自己的平台文件或是Tconf文件包含在其他的Tconf文件中，并且这些文件位于其他目录下，这时需要设置config.importPath指向新文件的位置。environmentconfig.rootDir包含Tconf应用时可执行文
18、件的路径，这个路径一般就是/opt/dvsdk_1_40_02_33/bios_5_32_01/xdctools。environmentconfig.scriptName包含通过命令行传递给Tconf的脚本名称。如果没有传递脚本，则将这个变量设为一个空串。此外还有environmentconfig.path、pilerOpts等。43434.2.2 内存映射的内存映射的mem_ext数组数组在DAVINCI的开发版中，有256MB的物理内存DDR221。这个内存是ARM和DSP可以共享的。ARM通过MMU(MemoryManagementUnit)看到的是内存的虚拟地址，而DSP直接使用物理地
19、址。内存分配具体如图4.2所示。由图4.2可以看出，256M的DDR222分为Linux、CMEM、DDRALGHEAP、DDR、DSPLINKMEM、RESET_VECTOR和UNUSED。由于Linux和CMEM会单独限定其内存的大小，因此在tcf文件中主要是对除此之外的其他内存进行分配，如表4.18所示。44444545表4.18对内存进行分配的mem_ext数组4646续表 除去Linux和CMEM占用的共128MB的空间，DDRALGHEAP的起始地址会从128MB开始。这里的设置都是按照图4.2中的默认设置的。如果有需要可以自行修改，但要注意起始地址和大小，防止发生内存覆盖等其他问
20、题。 47471. LinuxLinux使用虚拟地址向进程间提供内存保护，保证进程仅访问有权限的内存，否则会出现段错误，同时操作系统结束进程。分配给Linux的内存供ARM使用，由ARMLinux管理使用，应用程序无法直接访问这些内存。分配的Linux内存划分按页存储，最小的分配单元为4KB，所以通过malloc()分配的内存空间是4KB的倍数。开发者不但不能控制物理内存的分配，而且也不知道内存的物理地址是否连续。此外，这部分内存还应用于各种各样的内部I/O缓存等，所以这个分区越大越好。4848Linux分区的大小一般在串口向开发板设置启动参数bootargs时指定，例如对于TMS320DM6
21、467，启动时有如表4.19所示的设置。4949表4.19开发板启动参数其中，rwip后的IP为平台的IP地址，nfsroot后的IP为Linux服务器的IP地址。50502. CMEMDSP端是没有MMU的，这就导致DSP无法像ARM那样利用虚拟地址，无法将物理上不连续的内存区域映射为虚拟内存的连续区域。ARM分配的连续空间未必是物理上连续的，当将这个空间传递给DSP作为参数时就出现问题了，这也是CMEM存在的原因。CMEM(ContinuousMemoryAllocator)是一个连续物理存储空间分配模块，使得ARM端Linux进程和DSP端算法之间能够共享缓冲区。当应用程序需要在共享缓存
22、区动态申请一个连续的物理空间时，通过调用CMEM的API可以实现。5151申请得到的空间可以供DSP端访问，进行算法处理时数据的传递与处理。CMEM是一种基于缓冲池的配置，可以避免内存碎片，同时确保在系统运行了很长的一段时间之后仍然有大而连续的物理内存块。在/opt/dvsdk_1_40_02_33/codec_engine_2_10_02/examples/apps/system_files/davinci/DM6467目录下，文件loadmodules.sh使用insmod命令安装cmemk.ko驱动模块时，指定了CMEM起止物理地址，如表4.20所示。5252表4.20装载CMEM模块上
23、述例子表明在内存0x878000000x8ba00000上开辟内存池，分别是1个4147200字节的缓存、10个3458400字节的缓存、10个1434240字节的缓存、11个663552字节的缓存和4个60000字节的缓存。在CMEM模块安装路径下/opt/dvsdk_1_40_02_331/cmem_2_10，可进行如表4.21所示的操作来实现cmemk.ko的编译。5353表4.21cmem.ko的生成运行后，即对cmem模块进行编译，编译后的文件为在如下目录下生成的cmem.ko模块：/opt/dvsdk_1_40_02_331/cmem_2_10./packages/ti/sdo/l
24、inuxutils/cmem/src/module此外，Linux的用户可以在启动板子并执行loadmodules.sh后，通过执行“cat/proc/cmem”来获得由CMEM管理的Buffer和pool的状态信息。图4.3所示内容是未执行ARM端的可执行文件前各pool的状态信息。5454图4.3Buffer和pool的状态信息55553. DDRALGHEAPDDRALGHEAP包含了DSP端运行的算法(当前active的Codec实例)所使用的堆区。堆区(heap)一般由程序员分配并且释放，若程序员不释放，程序结束时可以由OS回收。但要注意堆区与数据结构中的堆是两回事，堆区分配方式有点
25、类似于链表。一般开发人员使用的malloc等动态分配的区域都在堆区。DDRALGHEAP的大小必须大于在同一时刻，当所有的算法实例都处于active状态时所需要的外部缓存的总和。因此可以通过计算算法实例所需缓存的大小得到DDRALGHEAP的大小。5656在早期的版本(如CE1.10)中，有个名为Enigne_getUsedMem()的API可以计算Server端的总内存使用情况，但这个总量中包括了DDR。可以分别在Engine_open()之后，任何一个算法实例创建之前和创建一个算法实例之后均调用这个Enigne_getUsedMem()函数(没有任何算法实例时，DDRALGHEAP的使用大
26、小为0)，这样就可以做差，得到DDRALGHEAP的大小。在CE1.20之后的版本，经过改进，可以精确地得到所需段的大小。通过表4.22所示代码便可实现，并得到当前状态下的DDRALGHEAP的大小。5757表4.22获得DDRALGHEAP的大小58584. DDRDDR用于存放DSP端，除了堆区之外的数据，包括栈区、全局区、文字常量区、程序代码区。栈区(stack)：由编译器自动分配释放，存放函数的参数值、局部变量的值等，其操作方式类似于数据结构中的栈。全局区(静态区、static)：用于存储全局变量和静态变量。已经初始化的全局变量和静态变量存在于一块区域中，未初始化的全局变量和未初始化的
27、静态变量存储在相邻的另一块区域。程序结束后会由系统释放。5959文字常量区：用于存储常量字符串，程序结束后由系统释放。程序代码区：用于存放函数体的二进制代码。60605. DSPLINKMEMDSPLINKMEM用于存放DSPLINK23模块的相关数据，该模块用于CodecEngine在ARM和DSP之间的通信，默认的大小为1MB。6. RESET_VECTORRESET_VECTOR用于存放DSP的复位向量表，它必须存放在奇数个MB的起始地址，因此一般情况下会在它之前存在一个1MB的unusedmomery，并且此复位向量区的大小必须是128B。61614.2.3 设置设置device_re
28、gsdevice_regs结构中包含与平台相关的参数信息。一般使用2级的Cache+外部内存(externalmemory)的结构，Level1Cache按照功能分为L1ProgramCache和L1DataCache。Level2Memory其实是片内内存，大小为1024kB，可以设置为L2Cache或普通内存。device_regs主要对Cache进行设置，如表4.23所示。6262表4.23device_regs中的Cache参数63634.2.4 设置设置params params结构中同样定义了与平台相关的参数信息，如时钟频率和设备名等，如表4.24所示。6464表4.24param
29、s平台相关参数6565其中需要注意和修改的是：clockRate：表示时钟频率，float型，指出CPU的时钟频率，这个变量必须设置。deviceName：表示设备名称，string型，指出板子上的DSP名称，这个变量必须设置。catalogName：string型，指出DSP的目录，这个变量必须设置，DSP/BIOS提供以下目录：“ti.catalog.c2800”、“ti.catalog.c5400”、“ti.catalog.c5500”和“ti.catalog.c6000”。6666regs：与目标平台相关的属性对象。mem：描述外部缓存的数组。Tconf并不检查“regs”和“mem”
30、一致性的问题，所以开发者必须保证片外的内存映射属性和平台定义的值一致。67674.2.5 utils.loadPlatform的使用的使用utils.loadPlatform用来装载平台定义的目标设备，如表4.25所示。表4.25目标设备的装载当开发者需要移植应用到另一个平台时，tcf文件中的utils.loadPlatform的参数名称是需要修改的。68684.2.6 配置配置bios命名空间命名空间utils.loadPlatform除了用来装载平台之外，还创建了一个名为“bios”的命名空间，用来简化对Module和Instance对象的引用。例如，一个LOG_system对象的属性bu
31、fLen的标准语法如表4.26所示。6969表.26完整的对象引用语法如果用“bios”命名空间后，可以把Module和Instance直接引用简化为表4.27所示。表4.27使用命名空间简化的对象引用语法在tcf文件中主要使用bios命名空间配置属性，如表4.28所示。7070表4.28具体对象的属性配置71714.2.7 prog.gen()的使用的使用在Tconf文件的最后使用prog.gen()方法进行相关文件生成。如表4.29所示。表4.29prog.gen()方法7272它生成了应用中所需要的CDB(ConfigurationDataBase)文件、源文件、头文件和链接文件。一般必
32、须包含这个方法。如果脚本文件中有prog.gen()方法，那么运行脚本文件之后会生成如下类型的文件：cfg_c.c：定义DSP/BIOS结构和属性的C源文件。cfg.h：包含DSP/BIOSModule的头文件，并且包含在配置文件中声明的外部对象变量。cfg.s#：关于DSP/BIOS设置的汇编文件，#指明采用的DSP平台。7373cfg.h#：汇编语言的头文件，包含在cfg.s#中。cfg.cmd：链接命令文件，主要是存储器的分配。.cdb：配置数据库文件，是一个只读文件。7474为了生成一个Server，开发者需要一个完整的package，其中还应该包括生成Server需要的库文件和关于S
33、erver的配置文件。package的信息中还应该包括Server的编译器版本和Codec的版本等。本节提及的生成Server的前提是Codec端的package是直接通过已有videnc_copy目录进行修改而生成的。4.3 Server的生成方法的生成方法7575当创建一个Server时，需要提供如下的信息：Server的名称；编译和链接的具体创建操作；在Server中可以实现的算法列表。76764.3.1 Server端文件的修改端文件的修改根据算法的需要，开发者可以对Server端的cfg文件中的数组Server.algs进行修改。如果不需要其他相应的编解码算法，即可在这个数组中去掉这
34、些编解码的对应项。例如，在本例的face_tracing中，需要H.264的编解码算法，不需要其他的诸如JPEG或是G711等的编解码算法，这样就可以在Server.algs数组中只保留H.264的编解码项，如表4.30所示。7777表4.30cfg文件中的algs数组7878此外，对于tcf文件中的mem_ext数组，默认的内存起止地址可先不做修改，但是如果出现无法分配Buffer等异常情况，则表示DDRALGHEAP等的现有内存分配不够，此时就需要适当地做出调整。这时不仅要修改tcf文件中的内容，还需要修改loadmodule.sh文件中关于CMEM的内存起止地址。例如，如果需要将DDRA
35、LGHEAP的大小由64MB增大到66MB，tcf需要做出如下的修改，如表4.31所示。7979表4.31tcf文件中对内存的修改同时，对于loadmodule.sh文件也需要做出调整，如表4.32所示。8080表4.32loadmodule.sh文件的修改8181由于在这个loadmodule.sh文件中，修改起止地址之后，CMEM的总大小仍然满足现有的pool分配，因此pool的大小和数量不需要修改。但是如果不能满足，就需要适当减少pool的数量或是大小，但不能影响算法的内存需求。上述修改执行完毕之后，就可执行make命令(如果是修改后第二次执行make，则需要先执行makeclean命令
36、，再执行make命令)，这个操作会依据Makefile文件在当前的目录下生成一个DSP端的可执行文件x64P。这个文件在生成之后，是需要拷贝到开发板所挂载的文件系统下的。82824.3.2 基于基于XDC生成生成Server Package这种方法主要应用在OMAP3530中生成DSP端的可执行文件x64P，因此这里以OMAP3530为例进行讲述。如果开发者通过XDC创建Server，则需要package.bld文件，同时Makefile文件是很短的。在package.bld中，需要把包含生成的Server信息的相对路径“package/info”加入到Pkg.otherFiles中，pack
37、age.bld文件中的代码如表4.33所示。8383表4.33package.bld文件中的Pkg.otherFiles此外，需要修改Makefile文件使之运行xdcrelease，其步骤如表4.34所示。8484表4.34Makefile文件8585之后，执行make命令，会在当前目录下生成一个Server端的all.x64P文件，具体如表4.35所示。(此处应该注意的是生成x64P的目录是在Servers下的“all_codecs/bin/ti_platforms_evm3530”中，路径与DM6467不一样。)8686表4.35OMAP3530中生成的x64P文件87874.3.3 使
38、用基于使用基于configuro的的Makefile文件生成文件生成Server Package这种基于configuro的方法是利用Makefile文件生成ServerPackage。通常不建议使用这种方法，因为在Engine_createFromServer()时会出现错误。configuro是一种通过用户提供的.cfg文件生成对象和链接文件的工具。如果基于configuro生成Server，则它是根据Makefile文件进行驱动的，必须在Makefile文件中添加相应的步骤。8888通过configuro创建DSPServer需要一个package，这个package创建生成Server
39、端的可交付使用的文件，在这个package中，必须包含Server端的可执行文件和基于configuro生成的“package/info/*”文件。每一种使用configuro的Makefile文件都是各不相同的，以下是TMS320DM6467中的Makefile文件，如表4.36所示。8989表4.36使用基于configuro的Makefile文件9090在这个例子中，我们通过给定的package名称$(SERVER_PKG)、给定的Server可执行文件名称$(Server_EXE)和配置文件名称$(CONFIGPKG)自动生成XDCpackage。而且基于configuro生成的文件在
40、$(CONFIGPKG)目录下。同时，如果运行上述的例子，Makefile文件和Server的可执行文件都必须在以“ti/sdo/ce/examples/servers/video_copy/evmDM6467”路径结尾的目录下，这是因为我们给定的Server的package名称为“ti.sdo.ce.examples.servers.video_copy.evmDM6467”。上述修改执行完毕之后，就可执行make命令，其输出如表4.37所示。9191表4.37Server端执行make命令的部分输出9292续表 9393由表4.37中可以看出，与Codec相似，也是先指出了编译时的路径，即
41、xdcpath.mak文件中指明的路径；其次指明了链接videnc_copy.a64P库文件，路径为“ti.sdo.ce.examples.codecs.videnc_copy:lib/videnc_copy.a64P”。这个make操作之后，会在当前的目录下生成一个DSP端的可执行文件video_copy.x64P，如表4.38所示。9494表4.38SERVER端的生成文件9595本章主要对Server端的文件以及生成方法进行了描述。在Server端最为重要的是.cfg文件和.tcf文件，因此对于此文件进行了详细的讲解。其中，.cfg文件主要对使用的Module进行了定义和参数的配置，包括
42、Codec端需要的Module(即Codec端具体所包含的所有算法)，还有DMAN3和DSKT2等的定义和配置，这些具体的Module在使用中有不同的功能，可根据需要在此文件中进行设置。4.4 小小 结结9696*.tcf文件中值得一提的是对内存的映射。在DM6467中默认的内存大小是256MB，将这256MB的内存根据需要分配给Linux、CMEM和DDRALGHEAP等，但是由于算法的不同，对这些内存大小的配置也各不相同，同样的，需要的总内存大小也不一定是256MB，因此此处的配置必不可少。同时，应注意内存配置的起始地址，还应该与loadmodule.sh文件中关于CMEM的起始地址相匹配
43、、相连续，不要出现相邻内存地址覆盖的情况。9797对于Server端的生成方法，对OMAP3530和DM6467进行了简单的区分和描述。此外，不论是OMAP3530还是DM6467，都可以使用RTSC生成Server端的Package，这个与Codec端是相类似的。具体使用哪一种方法，开发者可以根据需要自行选择。9898在线教务辅导网：在线教务辅导网：http:/ 更多课程配套课件资源请访问在线教务辅导网更多课程配套课件资源请访问在线教务辅导网9999100100101101102102103103104104馋死105105106106107107108108109109110110111111112112113113114114115115116116117117P P T研 究 院PO W E R PO I N T A C A D E M Y118118119119
