STM32开发笔记（二）——动态模块加载和ELFLoader

STM32动态模块加载

转载已于 2024-06-11 20:52:09 修改 · 5.8k 阅读

CC 4.0 BY-SA版权

原文链接：https://blog.youkuaiyun.com/iteye_7825/article/details/81596066?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-15&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-15%20%E2%80%94%E2%80%94%E2%80%94%E2%80%94%E2%8

文章标签：

#stm32 #笔记 #嵌入式硬件

于 2021-05-18 23:24:27 首次发布

ARM-M内核架构及指令集专栏收录该内容

12 篇文章

订阅专栏

本文探讨了STM32上的动态模块加载技术及其优势，并详细分析了动态链接库及ELF文件格式。介绍了ARM AIF格式的特点以及ELFLoader的不同实现，包括ContikiOS、ucLinux、VxWorks和Linux Kernel等。

STM32开发笔记（二）——动态模块加载和ELFLoader

小狼@http://blog.youkuaiyun.com/xiaolangyangyang

动态模块加载的好处
动态模块加载的好处很多，例如，当你升级一个系统的时候，可以只升级一个模块，而不必升级整个系统。你可以把不同的模块放在不同的介质上，并实施不同等级的保护，例如BIOS部分进行写保护。
有些系统允许用户进行二次开发，这个时候几乎一定是需要动态加载功能的，因为你不希望用户需要链接整个系统才能够进行二次开发，而且你可能希望支持多个用户模块，彼此不相互依赖，彼此不干扰。

Background
一般来说，C的编译器编译出来的代码，由以下几个重要的部分：
.code: 代码段
.data: 有初值的数据段
.bss：无初值的数据段

通常还有.rodata，是只读的数据段，在嵌入式系统中经常可以合并到.code段中.
注： .code, .data 和.bss这些段的命名不同的编译器可能会有不同。
由于不同段在实际运行的时候可能会被加载到不同的介质，例如.code和.rodata可以放在NOR FLASH上而.data,.bss放入RAM中，或者要满足所谓的scatter loading，因此编译器会努力使段可以自由移动。
但是要做到这一点，并不容易。

在代码段中运行的指令，要获取数据段中的数据，方法有：
a) 通过当前PC值＋偏移量
b) 通过绝对地址
c) 通过中间寄存器，寄存器里面：
c.1) 存放绝对地址
c.2) 偏移量

方法b通常只在CISC中存在，许多RISC机器由于指令长度受限制，并不存在方法b。

因此，从这里可以看出，要做到各段可以自由移动,有几种方法：
1) 保留一个寄存器专门用于指示数据段的起始地址
2) 运行前修改指令
3) 保留一小块数据段和代码段的相对位置不变，此片数据段作为指向实际数据段的入口表，运行前修改此表。

方法1和方法3通常会结合起来一起用，动态链接库就是用了这种技术。
方发2是一种通用的方法，实际上连接器就是这样生成可执行文件的。

ARM AIF
ARM公司的编译器有一项特殊的功能，即可以产生一种可自我重定位的可执行文件，即AIF格式。
在AIF文件中，包含了一个AIF头和一小段由编译器产生的重定位代码。运行AIF格式的文件，只需要告诉它起始地址，这段重定位代码就会负责修改余下的一些必要的信息达到重定位目的。目前还没有充分的公开的文档解释AIF内部的详细工作机制。

在我过去的一些项目中，AIF工作的很好，但是运行时外部无法获取AIF文件的更多信息，例如你无法去调用AIF映像中的某一个函数，因为你不知道它的地址。另外，AIF的执行映像中，.data必须紧跟在.code之后，对于想重定位到FLASH中执行的嵌入式系统就行不通了。

ELF
ELF文件是最常见的目标文件格式，它可能有很多扩展名，例如.o，.so,或者最终的可执行文件也是ELF。

ELF有几种：
* 可重定位
* 可动态链接
* 可执行
* 可执行＋可重定位

可执行的ELF如果没有可重定位信息，那就只能靠虚拟内存系统来支持它运行。但是对于许多嵌入式系统，有可能连MMU都不具备，因此我们只关心可重定位的ELF。（可动态链接ELF实际上也是可重定位的一种，附加很多额外信息）
有关ELF的详细信息，请参阅：http://www.skyfree.org/linux/references/ELF_Format.pdf

ELF Loader
我花了不少时间寻找小型的ELF Loader实现，但是真正适合嵌入式系统的却不多。

+Contiki OS:
在Contiki OS里面，有一个很有趣的ELF Loader实现，嗯，其实Contiki OS有很多有意思的东西 :)

+ucLinux:
ucLinux也是一个很有意思的例子。由于ucLinux没有启用虚拟内存系统，因此它在加载可执行文件的时候，就要进行重定位。为了加速重定位和减小ELF文件的体积，ucLinux提供了特殊的工具链，在产生ELF之前进行部分的“预重定位”，最后ELF中只需要携带很小体积的重定位信息。

+其它RTOS：
其它嵌入式OS，如VxWorks也实现了ELF Loader, eCos的ELF Loader看起来尚未完整。

+Linux Kernel:
哦，差点忘了一个最重要的，Linux Kernel。

Linux Kernel的模块是可以通过insmod动态地加入内核。虽然Linux的用户空间程序运行在虚拟内存中，整个内核的空间确只有一个。一些奉行micro kernel的人批评Linux的这种方式，但是一个单一空间的内核运行效率却是最高的。
在2.6内核中，模块重定位工作不再由insmod来完成，而是由内核来做所有的重定位工作。实现代码在：kernel/module.c中。
剥去那些处理特殊section的代码，Linux内核模块加载部分的代码其实是非常简单明了的，而且Linux支持数十种架构意味着你几乎不要担心架构移植的问题。

结论
在嵌入式系统中实现动态模块加载的技术是成熟的，可靠的，可以借鉴的开发源码的实现例子也有不少。一个参考数据：我最近在一个嵌入式RTOS上实现的ELF Loader，运行在ARM7 CPU上，从NAND FLASH中加载一个400K左右的ELF，耗时大约0.5秒。