BF561的双核协调工作方法
阅读：585发布：2024-01-03
专利汇可以提供BF561的双核协调工作方法专利检索，专利查询，专利分析的服务。并且本 发明 涉及BF561的双核协调工作方法，包括以下步骤：得到CORE A的格式为ELF，得到CORE B的格式为DXE，对比字段，得到可执行文件格式的差异；把CORE B程序格式转化为CORE A可执行的程序格式；把CORE B的DXE可执行文件中的加载地址改为uclinux实际加载的地址，并重新编译生成一个DXE文件，这个DXE文件就是可为uClinux执行的与FLAT兼容的可执行文件；H.264 算法 所需的MIPS合理的分配到CORE A跟CORE B去。本发明解决了blackfin单核满足不了H.264 BP D1编码的计算量而双核又无法协同工作负载均衡的难题。，下面是BF561的双核协调工作方法专利的具体信息内容。
1、BF561的双核协调工作方法，其特征在于包括以下步骤：
(1)、通过分析对比BF561芯片内CORE A上运行的嵌入式LINUX操作系统的可 执行文件格式(ELF)以及CORE B上运行的VDSP编译生成的H.264视频压缩编 码算法软件程序格式(DXE)，得出二者可执行程序格式的差异性和相似性；
(2)、通过修改VDSP编译生成的H.264算法软件DXE程序中的加载地址的方法， 将原本用于CORE B执行的软件转化为CORE A运行的嵌入式LINUX下的可执行 程序；
(3)、在实现CORE A可加载CORE B的VDSP算法程序后，将H.264@D1视频实时 编码算法所需的计算负载合理的分配到CORE A跟CORE B去，使得双核共同分担 H.264@D1实时编码所需的高运算量。
技术领域
背景技术
以单颗ADSP BF561@500MHz实现H.264 D1网络摄像(IPCAMERA)产品系 统所需的嵌入式LINUX的主控系统、H.264 BP D1的视频实时编码和基于标准RTP 的流媒体传输协议软件。根本原因缘自ADSP BF561的对称双核构架：正是由于 ADSP BF561的这种对称双核构架，阻碍了它单芯片实现H.264 D1 IPCAMERA产 品。双核我们称之为CORE A跟CORE B，CORE A只能用来跑嵌入式操作系统，我 们采用的是嵌入式LINUX操作系统，而CORE B则是用来跑视频压缩编码算法 (H.264)，用ADI提供的集成开发环境Visual DSP++来进行编译和运行测试。 目前业界存在的问题是，CORE A运行的LINUX软件跟CORE B运行的VDSP编译 出来的软件是不同的，彼此完全不兼容，跑嵌入式LINUX操作系统的CORE A是 无法运行VDSP编译的软件的；而以CORE B单核提供的计算能力(MIPS)是远不 能满足H.264 BP@D1实时编码的计算量的，除非另外一个核CORE A也能分担一 部分编码的计算，但编码的算法软件是独立的VDSP编译出来的程序，CORE A的 嵌入式LINUX操作系统是无法执行的。CORE A无法为CORE B分担视频压缩编码 算法所需的大量的计算，造成双核负载的不均衡，使得系统实现失败，这便是问 题的根本症结所在。问题的关键在于CORER A跟CORE B运行的软件完全不同， 一个是基于LINUX操作系统下的应用软件，而另一个则是完全没有操作系统下的 算法软件，彼此不兼容，所以不能互相分担任务。那么可以的尝试就不外乎解决 这个兼容性问题，这个则又可归结到一个编译器的问题上，如果两边采用同样的 编译器，则就可解决兼容性的问题。但无论嵌入式LINUX操作系统还是H.264 视频编码算法都不是一套简单的软件系统，都非常复杂，更换编译器带来的编译 问题、解决编译后的稳定性问题、性能损失问题等，都很多。下面的尝试均不可 避免的遭遇这些难题。
CORE A采用嵌入式LINUX操作系统，编译器为GNU CC，简称gcc；CORE B 的软件用VDSP编译，编译器为ADI提供的编译器。VDSP携带的编译器生成的代 码效率要远远高于gcc生成的代码，所以，对于性能优化要求极高的视频压缩编 码算法而言，采用VDSP编译环境才能获得最佳的性能。
尝试1：CORE A采用嵌入式LINUX操作系统，将H.264编码算法移植到嵌入 式LINUX下面，整合到例如FFMPEG等软件里面去，采用gcc统一进行编译，则 可统一由嵌入式LINUX操作系统进行控制以及视频压缩编码的计算。
这样做有两个最大的问题：
(1)嵌入式LINUX对B核的管理，因为这种方式由嵌入式LINUX统一管理双核， 那其实就是一个对称多处理(SMP)系统，而SMP的实现需要对目前稳定的嵌入 式LINUX操作系统做大量的改动，这个的实现难度太大，而且日后的稳定性不可 保证；
(2)Gcc编译出来的H.264视频压缩算法的效率低下，比VDSP下生成的代码需 要更多的MIPS来完成同样的工作，不可取。
鉴于此，目前此方法无一成功。
尝试2：CORE A采用嵌入式LINUX操作系统，但将其移植到VDSP环境下，用VDSP 的编译器取代gcc来进行编译。这样，双核的软件统一在VDSP环境下统一编译， 可实现相互调用。
这种方式存在的问题：
目前我司已可完成嵌入式LINUX内核在VDSP下的编译，并可下载到CORE A 运行起来；但尚未解决对LINUX下应用程序(ELF-FLAT可执行文件格式)加载 的难关，目前只能通过直接修改ELF-FLAT可执行文件的二进制文件的方式来加 载最基本的init/shell等进程，而对于IPCAMERA产品所需的更多复杂的应用软 件和协议软件则尚无法加载。
尝试3：CORE A采用更为精简的RTOS：uCOS-II，它已经由micrium公司完 成对blackfin的移植支持，采用VDSP开发环境进行编译，已开放在其官方网站 供下载，那么这种方式也是将双核的软件统一在VDSP下编译开发，则可顺利的 实现软件的互通调用，并完成双核的负载均衡。
这种方式存在的问题：
uCOS-II以精简而著称，故可很方便的移植到VDSP环境下进行编译；但精简 带来的问题就是软件资源的匮乏。IPCAMERA产品需要大量的网络软件的支撑， 包括DDNS、PPP协议栈、PPPoE协议软件、HTTP/WEB SERVER、FTP SERVER、DHCP C/S等等；此外还有文件系统的需求，而这些都是uCOS-II所缺乏的，虽然uCOS-II 也有一些TCP/IP协议栈、uC-FS等外挂软件包，但它们的支持还是远远不够的， 还需要大量的移植、完善和稳定性测试，这个工作量非常大；而对于嵌入式LINUX 系统，这些都是久经测试，稳定可靠的，而且由于其开放性，资源丰富，软件扩 展性远高于uCOS-II；
CORE A采用嵌入式LINUX操作系统，编译器为GNU CC，简称gcc；CORE B 的软件用VDSP编译，编译器为ADI提供的编译器。VDSP携带的编译器生成的代 码效率要远远高于gcc生成的代码，所以，对于性能优化要求极高的视频压缩编 码算法而言，采用VDSP编译环境才能获得最佳的性能。
尝试1：CORE A采用嵌入式LINUX操作系统，将H.264编码算法移植到嵌入 式LINUX下面，整合到例如FFMPEG等软件里面去，采用gcc统一进行编译，则 可统一由嵌入式LINUX操作系统进行控制以及视频压缩编码的计算。
这样做有两个最大的问题：
(1)嵌入式LINUX对B核的管理，因为这种方式由嵌入式LINUX统一管理双核， 那其实就是一个对称多处理(SMP)系统，而SMP的实现需要对目前稳定的嵌入 式LINUX操作系统做大量的改动，这个的实现难度太大，而且日后的稳定性不可 保证；
(2)Gcc编译出来的H.264视频压缩算法的效率低下，比VDSP下生成的代码需 要更多的MIPS来完成同样的工作，不可取。
鉴于此，目前此方法无一成功。
尝试2：CORE A采用嵌入式LINUX操作系统，但将其移植到VDSP环境下，用VDSP 的编译器取代gcc来进行编译。这样，双核的软件统一在VDSP环境下统一编译， 可实现相互调用。
这种方式存在的问题：
目前我司已可完成嵌入式LINUX内核在VDSP下的编译，并可下载到CORE A 运行起来；但尚未解决对LINUX下应用程序(ELF-FLAT可执行文件格式)加载 的难关，目前只能通过直接修改ELF-FLAT可执行文件的二进制文件的方式来加 载最基本的init/shell等进程，而对于IPCAMERA产品所需的更多复杂的应用软 件和协议软件则尚无法加载。
尝试3：CORE A采用更为精简的RTOS：uCOS-II，它已经由micrium公司完 成对blackfin的移植支持，采用VDSP开发环境进行编译，已开放在其官方网站 供下载，那么这种方式也是将双核的软件统一在VDSP下编译开发，则可顺利的 实现软件的互通调用，并完成双核的负载均衡。
这种方式存在的问题：
uCOS-II以精简而著称，故可很方便的移植到VDSP环境下进行编译；但精简 带来的问题就是软件资源的匮乏。IPCAMERA产品需要大量的网络软件的支撑， 包括DDNS、PPP协议栈、PPPoE协议软件、HTTP/WEB SERVER、FTP SERVER、DHCP C/S等等；此外还有文件系统的需求，而这些都是uCOS-II所缺乏的，虽然uCOS-II 也有一些TCP/IP协议栈、uC-FS等外挂软件包，但它们的支持还是远远不够的， 还需要大量的移植、完善和稳定性测试，这个工作量非常大；而对于嵌入式LINUX 系统，这些都是久经测试，稳定可靠的，而且由于其开放性，资源丰富，软件扩 展性远高于uCOS-II；
发明内容
本发明针对现有技术的不足，克服单核满足不了H.264 BP D1编码的计算量 而双核又无法协同工作负载均衡的难题，从而使得单BLACKFIN芯片实现D1 H.264嵌入式网络摄像机成为可能。
本发明是通过以下技术方案实现的：
基于BF561的嵌入式LINUX下H.264@D1视频实时编码方法，其特征在于包括以 下步骤：
(1)、通过分析对比BF561芯片内CORE A上运行的嵌入式LINUX操作系统的可 执行文件格式(ELF)以及CORE B上运行的VDSP编译生成的H.264视频压缩编 码算法软件程序格式(DXE)，得出二者可执行程序格式的差异性和相似性；
(2)、通过修改VDSP编译生成的H.264算法软件DXE程序中的加载地址的方法， 将原本用于CORE B执行的软件转化为CORE A运行的嵌入式LINUX下的可执行 程序，从而解决软件互通性的问题。
(3)、在实现CORE A可加载CORE B的VDSP算法程序后，将H.264@D1视频实时 编码算法所需的计算负载合理的分配到CORE A跟CORE B去，使得双核共同分担 H.264@D1实时编码所需的高运算量，并同时保证了CORE A原有嵌入式LINUX系 统及其通信协议软件的顺利运行。
本发明鉴于BF561芯片内部的两个核CORE A跟CORE B分别运行嵌入式LINUX 操作系统跟H.264@D1视频压缩编码算法软件，而H.264@D1的视频实时压缩编码 算法的计算复杂度远远超出了CORE B单核所能提供的计算能力(MIPS)，CORE A 运行的嵌入式LINUX操作系统则有计算能力的空余，因此本发明实现了CORE A 的LINUX系统能分担一部分CORE B的H.264编码任务，实现负载均衡；解决了 CORE A与CORE B软件的互通性和兼容性。从而克服blackfin单核满足不了H.264 BP D1编码的计算量而双核又无法协同工作负载均衡的难题。在blackfin平台 上可实现D1(704 x 576)分辨率的视频监控，使单颗BLACKFIN芯片实现D1 H.264 嵌入式网络摄像机可提供更高的清晰度，满足日益增长的监控安防行业对图像清 晰度的要求；为我国平安城市工程提供更优质的视频监控图像和录像，并可达到 监控行业对分辨率要求的行业标准，有着重大的经济效益和社会效益。
本发明是通过以下技术方案实现的：
基于BF561的嵌入式LINUX下H.264@D1视频实时编码方法，其特征在于包括以 下步骤：
(1)、通过分析对比BF561芯片内CORE A上运行的嵌入式LINUX操作系统的可 执行文件格式(ELF)以及CORE B上运行的VDSP编译生成的H.264视频压缩编 码算法软件程序格式(DXE)，得出二者可执行程序格式的差异性和相似性；
(2)、通过修改VDSP编译生成的H.264算法软件DXE程序中的加载地址的方法， 将原本用于CORE B执行的软件转化为CORE A运行的嵌入式LINUX下的可执行 程序，从而解决软件互通性的问题。
(3)、在实现CORE A可加载CORE B的VDSP算法程序后，将H.264@D1视频实时 编码算法所需的计算负载合理的分配到CORE A跟CORE B去，使得双核共同分担 H.264@D1实时编码所需的高运算量，并同时保证了CORE A原有嵌入式LINUX系 统及其通信协议软件的顺利运行。
本发明鉴于BF561芯片内部的两个核CORE A跟CORE B分别运行嵌入式LINUX 操作系统跟H.264@D1视频压缩编码算法软件，而H.264@D1的视频实时压缩编码 算法的计算复杂度远远超出了CORE B单核所能提供的计算能力(MIPS)，CORE A 运行的嵌入式LINUX操作系统则有计算能力的空余，因此本发明实现了CORE A 的LINUX系统能分担一部分CORE B的H.264编码任务，实现负载均衡；解决了 CORE A与CORE B软件的互通性和兼容性。从而克服blackfin单核满足不了H.264 BP D1编码的计算量而双核又无法协同工作负载均衡的难题。在blackfin平台 上可实现D1(704 x 576)分辨率的视频监控，使单颗BLACKFIN芯片实现D1 H.264 嵌入式网络摄像机可提供更高的清晰度，满足日益增长的监控安防行业对图像清 晰度的要求；为我国平安城市工程提供更优质的视频监控图像和录像，并可达到 监控行业对分辨率要求的行业标准，有着重大的经济效益和社会效益。
具体实施方式
在CORE A的嵌入式LINUX操作系统下，为CORE B的视频编码算法定制了一 个加载器，并通过独创优化的负载均衡的算法，使得双核各自分担一部分编码算 法所需的MIPS，同时CORE A还在稳定运行嵌入式LINUX操作系统、外围设备的 驱动以及流媒体传输协议栈软件，从而满足了一个H.264 D1 IPCAMERA的系统资 源需求。现分述如下：
1)首先解释下CORE A运行的LINUX操作系统下的可执行文件格式——ELF格式 每个操作系统都会有自己的可执行文件的格式，比如以前的是用 a.out格式的，现代的Unix/Linux类系统均使用elf格式，是使用 基于COFF格式的可执行文件。
ELF文件有三种类型：可重定位文件：也就是通常称的目标文件，后缀为.o。 共享文件：也就是通常称的库文件，后缀为.so。可执行文件：本文主要讨论的 文件格式，总的来说，可执行文件的格式与上述两种文件的格式之间的区别主要 在于观察的角度不同：一种称为连接视图(Linking View)，一种称为执行视图 (Execution View)。
几个重要的概念：
relocations的概念
动态连接技术，a.out格式不能支持动态链接，ELF可支持。
elf的动态连接库是内存位置无关的，就是说你可以把这个库加载到内存的 任何位置都没有影响。这就叫做position independent。而a.out的动态连接 库是内存位置有关的，它一定要被加载到规定的内存地址才能工作。在编译内存 位置无关的动态连接库时，要给编译器加上-fpic选项，让编译器产生的目标 文件是内存位置无关的还会尽量减少对变量引用时使用绝对地址。把库编译成内 存位置无关会带来一些花费，编译器会保留一个寄存器来指向全局偏移量表 (global offset table(or GOT for short))，这就会导致编译器在优化代码 时少了一个寄存器可以使用，但是在最坏的情况下这种性能的减少只有3％，在 其他情况下是大大小于3％的。
Elf的另一个特点是它的动态连接库是在运行时处理符号的，这是通过用符 号表和再布置(relocation)表来实现的。在载入文件时并不能立即执行，要在 处理完符号表把所有的地址都relocation完后才可以执行。
当从动态连接库中读一个全局变量时与从非-fpic编译的目标文件读是不 同的。读动态连接的库中的变量是通过GOT来寻找到目标变量的，GOT已经由某 一个寄存器指向了。GOT本生就是一个指针列表，找到GOT中的某一个指针就可 以读到所要的全局变量了，有了GOT我们要读出一个变量只要做一次 relocation。
下面是对LINUX操作系统对ELF文件加载过程的一个简单描述：
1：内核首先读ELF文件的头部，然后根据头部的数据指示分别读入各种数 据结构，找到标记为可加载(loadable)的段，并调用函数mmap()把段内容加 载到内存中。在加载之前，内核把段的标记直接传递给mmap()，段的标记指示 该段在内存中是否可读、可写，可执行。显然，文本段是只读可执行，而数据段 是可读可写。这种方式是利用了现代操作系统和处理器对内存的保护功能。
2：内核分析出ELF文件标记为PT_INTERP的段中所对应的动态连接器名称， 并加载动态连接器。现代LINUX系统的动态连接器通常是 /lib/ld-linux.so.2。
3：内核在新进程的堆栈中设置一些标记-值对，以指示动态连接器的相关操 作。
4：内核把控制传递给动态连接器。
5：动态连接器检查程序对外部文件(共享库)的依赖性，并在需要时对其 进行加载。
6：动态连接器对程序的外部引用进行重定位，通俗的讲，就是告诉程序其 引用的外部变量/函数的地址，此地址位于共享库被加载在内存的区间内。动态 连接还有一个延迟(Lazy)定位的特性，即只在″真正″需要引用符号时才重定位， 这对提高程序运行效率有极大帮助。
7：动态连接器执行在ELF文件中标记为.init的节的代码，进行程序运行 的初始化。在早期系统中，初始化代码对应函数_init(void)(函数名强制固定)。
8：动态连接器把控制传递给程序，从ELF文件头部中定义的程序进入点开 始执行。在a.out格式和ELF格式中，程序进入点的值是显式存在的，在COFF 格式中则是由规范隐含定义。
从上面的描述可以看出，加载文件最重要的是完成两件事情：加载程序段和 数据段到内存；进行外部定义符号的重定位。重定位是程序连接中一个重要概念。 一个可执行程序通常是由一个含有main()的主程序文件、若干目标文件、若干 共享库(Shared Libraries)组成。(注：采用一些特别的技巧，也可编写没有main 函数的程序，请参阅参考资料2)一个C程序可能引用共享库定义的变量或函 数，换句话说就是程序运行时必须知道这些变量/函数的地址。
2)关于CORE B下运行的VDSP编译生成的H.264算法程序的可执行文件格 式——DXE文件格式
DXE文件是VDSP下编译的软件的可执行文件格式，它实际上是ELF格式的一 种变种。
链接描述文件(.LDF)定义了整个系统的存储器配置和程序中数据及代码的 具体存放位置。加载核文件(.DXE)是指加载引导核程序，其大小为32bit，放在 加载文件的起始部分，其功能是用来实现ADSP Blackfin的正确引导。加载文件 是由引导加载器(elfloader)将可执行文件进行一定的格式变化，并在起始位置 附加上加载核文件生成的。
DXE文件是在elf文件格式的基础上添加了一些VDSP特有的配置，如elf 文件头中的e_type设置，还有一些特殊的调试段.annotations，.attributs等 等。但是在这其中只有几个段是必须的：
空段：这是elf文件中的第一个段，其中不包含任何信息，其段头配置全为0。
至少一个保存字符串的段：这个段通常为第二个段，用以存放段名称等字符串。
程序段：就是程序代码，每个段不超过65535个字节。
processor：这个段不是必须的，VisualDSP通过这个段来识别程序所针对的DSP 类型。它的内容是一个字符串，如“ADSP-BF531”、“ADSP-BF561”等等。如果 没有这个段，Visual DSP将认为DXE程序就是针对设置好的session开发的。 将VDSP++编译生成H.264算法软件的可执行文件(.dxe文件)，利用VDSP提供 的elf2flt工具将这个dxe文件转换成flt格式。嵌入式LINUX是一种特殊的 Linux，叫uClinux，它的可执行文件的格式是由ELF经转换生成的FLAT格式。 在uclinux中，对FLAT可执行文件的加载是由fs/binfmt_flat.c这个文件来完 成的，所需要做的是在这个文件的合适位置断下来，并取得相关的指针，进行数 据分析，以求获得.dxe与FLAT格式的差异，为转换提供支持。
经过对此文件的分析，可以在load_flat_file这个函数中设置断点，并进 行单步跟踪。在此过程中还发现VDSP会将转换生成的flt格式文件的rev字段 设置为5，而uclinux只支持2和4的版本，在此处还需要将rev的值改为4。
我们就可以取得这个FLT文件在内存中的分布位置了，将code，data，bss 这三个段的起始位置和结束位置记录下来。
为了保证VDSP中生成的DXE文件中的调试信息地址与uclinux加载的地址 一致，还需要回过头修改VDSP工程LDF文件中的几个地址。
把COREB的DXE可执行文件中的加载地址改为uclinux实际加载的地址，并 重新编译生成一个DXE文件，则这个.dxe文件就是可为uClinux执行的与FLAT 兼容的可执行文件。
关于负载均衡算法：
相比网络通信等应用领域的负载均衡算法，我们这里的负载均衡算法就要简 单很多，主要目的就是将优化过的H.264算法所需的MIPS合理的分配到CORE A 跟CORE B去，使得单芯片BF561可在CORE A运行嵌入式LINUX操作系统进行外 围控制和网络协议栈的同时，可顺利完成视频流的H.264 D1实时编码。
1)首先解释下CORE A运行的LINUX操作系统下的可执行文件格式——ELF格式 每个操作系统都会有自己的可执行文件的格式，比如以前的是用 a.out格式的，现代的Unix/Linux类系统均使用elf格式，是使用 基于COFF格式的可执行文件。
ELF文件有三种类型：可重定位文件：也就是通常称的目标文件，后缀为.o。 共享文件：也就是通常称的库文件，后缀为.so。可执行文件：本文主要讨论的 文件格式，总的来说，可执行文件的格式与上述两种文件的格式之间的区别主要 在于观察的角度不同：一种称为连接视图(Linking View)，一种称为执行视图 (Execution View)。
几个重要的概念：
relocations的概念
动态连接技术，a.out格式不能支持动态链接，ELF可支持。
elf的动态连接库是内存位置无关的，就是说你可以把这个库加载到内存的 任何位置都没有影响。这就叫做position independent。而a.out的动态连接 库是内存位置有关的，它一定要被加载到规定的内存地址才能工作。在编译内存 位置无关的动态连接库时，要给编译器加上-fpic选项，让编译器产生的目标 文件是内存位置无关的还会尽量减少对变量引用时使用绝对地址。把库编译成内 存位置无关会带来一些花费，编译器会保留一个寄存器来指向全局偏移量表 (global offset table(or GOT for short))，这就会导致编译器在优化代码 时少了一个寄存器可以使用，但是在最坏的情况下这种性能的减少只有3％，在 其他情况下是大大小于3％的。
Elf的另一个特点是它的动态连接库是在运行时处理符号的，这是通过用符 号表和再布置(relocation)表来实现的。在载入文件时并不能立即执行，要在 处理完符号表把所有的地址都relocation完后才可以执行。
当从动态连接库中读一个全局变量时与从非-fpic编译的目标文件读是不 同的。读动态连接的库中的变量是通过GOT来寻找到目标变量的，GOT已经由某 一个寄存器指向了。GOT本生就是一个指针列表，找到GOT中的某一个指针就可 以读到所要的全局变量了，有了GOT我们要读出一个变量只要做一次 relocation。
下面是对LINUX操作系统对ELF文件加载过程的一个简单描述：
1：内核首先读ELF文件的头部，然后根据头部的数据指示分别读入各种数 据结构，找到标记为可加载(loadable)的段，并调用函数mmap()把段内容加 载到内存中。在加载之前，内核把段的标记直接传递给mmap()，段的标记指示 该段在内存中是否可读、可写，可执行。显然，文本段是只读可执行，而数据段 是可读可写。这种方式是利用了现代操作系统和处理器对内存的保护功能。
2：内核分析出ELF文件标记为PT_INTERP的段中所对应的动态连接器名称， 并加载动态连接器。现代LINUX系统的动态连接器通常是 /lib/ld-linux.so.2。
3：内核在新进程的堆栈中设置一些标记-值对，以指示动态连接器的相关操 作。
4：内核把控制传递给动态连接器。
5：动态连接器检查程序对外部文件(共享库)的依赖性，并在需要时对其 进行加载。
6：动态连接器对程序的外部引用进行重定位，通俗的讲，就是告诉程序其 引用的外部变量/函数的地址，此地址位于共享库被加载在内存的区间内。动态 连接还有一个延迟(Lazy)定位的特性，即只在″真正″需要引用符号时才重定位， 这对提高程序运行效率有极大帮助。
7：动态连接器执行在ELF文件中标记为.init的节的代码，进行程序运行 的初始化。在早期系统中，初始化代码对应函数_init(void)(函数名强制固定)。
8：动态连接器把控制传递给程序，从ELF文件头部中定义的程序进入点开 始执行。在a.out格式和ELF格式中，程序进入点的值是显式存在的，在COFF 格式中则是由规范隐含定义。
从上面的描述可以看出，加载文件最重要的是完成两件事情：加载程序段和 数据段到内存；进行外部定义符号的重定位。重定位是程序连接中一个重要概念。 一个可执行程序通常是由一个含有main()的主程序文件、若干目标文件、若干 共享库(Shared Libraries)组成。(注：采用一些特别的技巧，也可编写没有main 函数的程序，请参阅参考资料2)一个C程序可能引用共享库定义的变量或函 数，换句话说就是程序运行时必须知道这些变量/函数的地址。
2)关于CORE B下运行的VDSP编译生成的H.264算法程序的可执行文件格 式——DXE文件格式
DXE文件是VDSP下编译的软件的可执行文件格式，它实际上是ELF格式的一 种变种。
链接描述文件(.LDF)定义了整个系统的存储器配置和程序中数据及代码的 具体存放位置。加载核文件(.DXE)是指加载引导核程序，其大小为32bit，放在 加载文件的起始部分，其功能是用来实现ADSP Blackfin的正确引导。加载文件 是由引导加载器(elfloader)将可执行文件进行一定的格式变化，并在起始位置 附加上加载核文件生成的。
DXE文件是在elf文件格式的基础上添加了一些VDSP特有的配置，如elf 文件头中的e_type设置，还有一些特殊的调试段.annotations，.attributs等 等。但是在这其中只有几个段是必须的：
空段：这是elf文件中的第一个段，其中不包含任何信息，其段头配置全为0。
至少一个保存字符串的段：这个段通常为第二个段，用以存放段名称等字符串。
程序段：就是程序代码，每个段不超过65535个字节。
processor：这个段不是必须的，VisualDSP通过这个段来识别程序所针对的DSP 类型。它的内容是一个字符串，如“ADSP-BF531”、“ADSP-BF561”等等。如果 没有这个段，Visual DSP将认为DXE程序就是针对设置好的session开发的。 将VDSP++编译生成H.264算法软件的可执行文件(.dxe文件)，利用VDSP提供 的elf2flt工具将这个dxe文件转换成flt格式。嵌入式LINUX是一种特殊的 Linux，叫uClinux，它的可执行文件的格式是由ELF经转换生成的FLAT格式。 在uclinux中，对FLAT可执行文件的加载是由fs/binfmt_flat.c这个文件来完 成的，所需要做的是在这个文件的合适位置断下来，并取得相关的指针，进行数 据分析，以求获得.dxe与FLAT格式的差异，为转换提供支持。
经过对此文件的分析，可以在load_flat_file这个函数中设置断点，并进 行单步跟踪。在此过程中还发现VDSP会将转换生成的flt格式文件的rev字段 设置为5，而uclinux只支持2和4的版本，在此处还需要将rev的值改为4。
我们就可以取得这个FLT文件在内存中的分布位置了，将code，data，bss 这三个段的起始位置和结束位置记录下来。
为了保证VDSP中生成的DXE文件中的调试信息地址与uclinux加载的地址 一致，还需要回过头修改VDSP工程LDF文件中的几个地址。
把COREB的DXE可执行文件中的加载地址改为uclinux实际加载的地址，并 重新编译生成一个DXE文件，则这个.dxe文件就是可为uClinux执行的与FLAT 兼容的可执行文件。
关于负载均衡算法：
相比网络通信等应用领域的负载均衡算法，我们这里的负载均衡算法就要简 单很多，主要目的就是将优化过的H.264算法所需的MIPS合理的分配到CORE A 跟CORE B去，使得单芯片BF561可在CORE A运行嵌入式LINUX操作系统进行外 围控制和网络协议栈的同时，可顺利完成视频流的H.264 D1实时编码。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种超声波测量膜厚的标定装置及其测定方法 | 2020-05-08 | 6 |
| 一种便携式多胞胎心电监测仪及其监测方法 | 2020-05-08 | 37 |
| 一种智能身高测量装置及测量方法 | 2020-05-08 | 442 |
| 传感器网络节点的数据处理方法及传感器网络节点 | 2020-05-08 | 27 |
| 一种基于光纤M-Z干涉仪检测硫化氢气体的装置 | 2020-05-08 | 44 |
| 用于提供带有标记的容器的系统及方法 | 2020-05-11 | 39 |
| 一种微小透镜快速定心胶合装置及方法 | 2020-05-08 | 699 |
| 叉车电池状态监测方法、装置及嵌入式设备、存储介质 | 2020-05-08 | 627 |
| 在不同磁阻随机存取存储器阵列中具有不同磁性隧道结的半导体管芯 | 2020-05-08 | 146 |
| 基于ARM和FPGA的工件位置获取系统 | 2020-05-11 | 84 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈