ARM映像文件 he 编译器自动生成的启动函数-电子工程世界

分享到: 微博; QQ; 微信; LinkedIn

什么是arm的映像文件

arm映像文件其实就是可执行文件，包括bin或hex两种格式，可以直接烧到rom里执行。在axd调试过程中，我们调试的是axf文件，其实这也是一种映像文件，它只是在bin文件中加了一个文件头和一些调试信息。

可以参考下面的pdf:ARM映像文件及执行机理

part1 part3

映像文件的组成

ARM映像文件是一个层次性结构的文件，包括了域（region），输出段(output section)和输入段(input section)。

所谓域，指的就是整个bin映像文件所处在的区域，它又分为加载域和运行域。

加载域就是映像文件被静态存放的工作区域，一般来说flash里的整个bin文件所在的地址空间就是加载域，当然在程序一般都不会放在 flash里执行，一般都会搬到sdram里运行工作，它们在被搬到sdram里工作所处的地址空间就是运行域。

ARM映像文件一开始总是存储在ROM／Flash里面的，其RO部分既可以在ROM／Flash里面执行，也可以转移到速度更快的RAM中执行；而RW和ZI这两部分是必须转移到可写的RAM里去，其实RW包括ZI区域。

什么是RO段、RW段和ZI段

一个ARM程序包含3部分：RO，RW和ZI

RO就是ReadOnly，程序中的指令和常量

RW就是Read/Write，程序中的已初始化变量

ZI就是Zero Init，程序中的未初始化的变量

Image文件包含了RO和RW数据。

之所以Image文件不包含ZI数据，是因为ZI数据都是0，没必要包含，只要程序运行之前将ZI数据所在的区域一律清零即可。包含进去反而浪费存储空间。

Q：为什么Image中必须包含RO和RW？

A：因为RO中的指令和常量以及RW中初始化过的变量是不能像ZI那样“无中生有”的。

ARM程序的执行过程

从以上两点可以知道，烧录到ROM中的image文件与实际运行时的ARM程序之间并不是完全一样的。因此就有必要了解ARM程序是如何从ROM中的image到达实际运行状态的。

实际上，RO中的指令至少应该有这样的功能：

1. 将RW从ROM中搬到RAM中，因为RW是变量，变量不能存在ROM中。

2. 将ZI所在的RAM区域全部清零，因为ZI区域并不在Image中，所以需要程序根据编译器给出的ZI地址及大小来将相应得RAM区域清零。ZI中也是变量，同理：变量不能存在ROM中

在程序运行的最初阶段，RO中的指令完成了这两项工作后C程序才能正常访问变量。否则只能运行不含变量的代码。

为了更直观说明RO,RW,ZI在C中的意思，请看下面例子：

1)RO

看下面两段程序，他们之间差了一条语句，这条语句就是声明一个字符常量。因此按照我们之前说的，他们之间应该只会在RO数据中相差一个字节（字符常量为1字节）。

Prog1：

#include

void main(void)

{

;

}

Prog2：

#include

const char a = 5；

void main(void)

{

;

}

Prog1编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

===========================================================

Prog2编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 61 0 96 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1009 ( 0.99kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1009 ( 0.99kB)

===========================================================

以上两个程序编译出来后的信息可以看出：

Prog1和Prog2的RO包含了Code和RO Data两类数据。他们的唯一区别就是Prog2的RO Data比Prog1多了1个字节。这正和之前的推测一致。

如果增加的是一条指令而不是一个常量，则结果应该是Code数据大小有差别。

2)RW

同样再看两个程序，他们之间只相差一个“已初始化的变量”，按照之前所讲的，已初始化的变量应该是算在RW中的，所以两个程序之间应该是RW大小有区别。

Prog3：

#include

void main(void)

{

;

}

Prog4：

#include

char a = 5；

void main(void)

{

;

}

Prog3编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

===========================================================

Prog4编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 60 1 96 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 97 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1009 ( 0.99kB)

===========================================================

可以看出Prog3和Prog4之间确实只有RW Data之间相差了1个字节，这个字节正是被初始化过的一个字符型变量“a”所引起的。

3) ZI

再看两个程序，他们之间的差别是一个未初始化的变量“a”，从之前的了解中，应该可以推测，这两个程序之间应该只有ZI大小有差别。

Prog5：

#include

void main(void)

{

;

}

Prog6：

#include

char a；

void main(void)

{

;

}

Prog5编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

===========================================================

Prog6编译出来后的信息如下：

===========================================================

Code RO Data RW Data ZI Data Debug

948 60 0 97 0 Grand Totals

===========================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 97 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

===========================================================

编译的结果完全符合推测，只有ZI数据相差了1个字节。这个字节正是未初始化的一个字符型变量“a”所引起的。

注意：如果一个变量被初始化为0，则该变量的处理方法与未初始化华变量一样放在ZI区域。

[page]

即：ARM C程序中，所有的未初始化变量都会被自动初始化为0。

总结：

1)C中的指令以及常量被编译后是RO类型数据。

2)C中的未被初始化或初始化为0的变量编译后是ZI类型数据。

3) C中的已被初始化成非0值的变量编译后市RW类型数据。

附：

程序的编译命令（假定C程序名为tst.c）：

armcc -c -o tst.o tst.c

armlink -noremove -elf -nodebug -info totals -info sizes -map -list aa.map -o tst.elf tst.o

编译后的信息就在aa.map文件中。

ROM主要指：NAND Flash，Nor Flash

RAM主要指：PSRAM，SDRAM，SRAM，DDRAM

启动代码中Image$$??$$Limit 的含义

对于刚学习ARM的人来说，如果分析它的启动代码，往往不明白下面几个变量的含义：|Image$$RO$$Limit|、|Image$$RW$$Base|、|Image$$ZI$$Base|。

|Image$$RO$$Base| ：RO段起始地址

|Image$$RO$$Limit| ：RO段结束地址加1

|Image$$RW$$Base| ：RW段起始地址

|Image$$RW$$Limit| ：ZI段结束地址加1

|Image$$ZI$$Base| ：ZI段起始地址

|Image$$ZI$$Limit| ：ZI段结束地址加1

首先申明我使用的调试软件为ADS1.2，当我们把程序编写好以后，就要进行编译和链接了，在ADS1.2中选择MAKE按钮，会出现一个Errors and Warnings 的对话框，在该栏中显示编译和链接的结果，如果没有错误，在文件的最后应该能看到Image component sizes，后面紧跟的依次是Code，RO Data ，RW Data ，ZI Data ，Debug 各个项目的字节数，最后会有他们的一个统计数据：

Code 163632 ，RO Data 20939 ，RW Data 53 ，ZI Data 17028

Tatal RO size (Code+ RO Data) 184571 (180.25kB)

Tatal RW size(RW Data+ ZI Data) 17081(16.68 kB)

Tatal ROM size(Code+ RO Data+ RW Data) 184624(180.30 kB)

后面的字节数是根据用户不同的程序而来的，下面就以上面的数据为例来介绍那几个变量的计算。

在ADS的Debug Settings中有一栏是Linker/ARM Linker，在output选项中有一个RO base选项，下面应该有一个地址，我这里是0x 0c100000，后面的RW base 地址是0x0c200000，然后在Options选项中有Image entry point ，是一个初始程序的入口地址，我这里是0x0c100000 。

Linker/ARM Linker：RO base—0x0c100000 RW base—0x0c200000

Options：Image entry point—0x0c100000

有了上面这些信息我们就可以完全知道这几个变量是怎么来的了：

|Image$$RO$$Base| = Image entry point = 0x0c100000 ;表示程序代码存放的起始地址

|Image$$RO$$Limit|=程序代码起始地址+代码长度+1=0x0c100000+Tatal RO size+1

= 0x0c100000 + 184571 + 1 = 0x0c100000 +0x2D0FB + 1

= 0x0c12d0fc

|Image$$RW$$Base| = 0x0c200000 ;由RW base 地址指定

|Image$$RW$$Limit| =|Image$$RW$$Base|+ RW Data 53 = 0x0c200000+0x37（4的倍数,0到55，共56个单元）

=0x0c200037

|Image$$ZI$$Base| = |Image$$RW$$Limit| + 1 =0x0c200038

|Image$$ZI$$Limit| = |Image$$ZI$$Base| + ZI Data 17028

=0x0c200038 + 0x4284

=0x0c2042bc

也可以由此计算：

|Image$$ZI$$Limit| = |Image$$RW$$Base| +TatalRWsize(RWData+ZIData) 17081

=0x0c200000+0x42b9+3（要满足4的倍数）

=0x0c2042bc

2410启动代码注释

BaseOfROM DCD |Image$$RO$$Base|

TopOfROM DCD |Image$$RO$$Limit|

BaseOfBSS DCD |Image$$RW$$Base|

BaseOfZero DCD |Image$$ZI$$Base|

EndOfBSS DCD |Image$$ZI$$Limit|

adr r0, ResetEntry;ResetEntry是复位运行时域的起始地址，在boot nand中一般是0

ldr r2, BaseOfROM;

cmp r0, r2

ldreq r0, TopOfROM;TopOfROM=0x30001de0，代码段地址的结束

beq InitRam

ldr r3, TopOfROM

;part 1，通过比较，将ro搬到sdram里，搬到的目的地址从 | Image$$RO$$Base| 开始，到|Image$$RO$$Limit|结束

ldmia r0!, {r4-r7}

stmia r2!, {r4-r7}

cmp r2, r3

bcc �;

;part 2，搬rw段到sdram，目的地址从|Image$$RW$$Base| 开始，到|Image$$ZI$$Base|结束

sub r2, r2, r3;r2=0

sub r0, r0, r2;

InitRam ;carry rw to baseofBSS

ldr r2, BaseOfBSS ;TopOfROM=0x30001de0,baseofrw

ldr r3, BaseOfZero ;BaseOfZero=0x30001de0

cmp r2, r3

ldrcc r1, [r0], #4

strcc r1, [r2], #4

bcc �

;part 3，将sdram zi初始化为0，地址从|Image$$ZI$$Base|到|Image$$ZI$$Limit|

mov r0, #0;init 0

ldr r3, EndOfBSS;EndOfBSS=30001e40

cmp r2, r3

strcc r0, [r2], #4

bcc �

参考资料：

1) RO段、RW段和ZI段 | Computer, Electron and Technology

http://www.donevii.com/post/638.html

2) ARM映像文件简介及简单的初始化C运行环境 - 灿烂于草坪之上 - 博客大巴

http://kellycan.blogbus.com/logs/10962408.html

3) Image$$??$$Limit 的含义_蓝色天空

http://hi.baidu.com/liudefang888/blog/item/6192fd45620ecc3b86947378.html

4) 2440启动代码注解 - guokun的个人空间 - ITPUB个人空间 - powered by X-Space

http://space.itpub.net/13771794/viewspace-483446

5) ADS的基本设置 - 夏爵爷的脚步 - CSDN博客

http://blog.csdn.net/xtconan/archive/2009/05/26/4218106.aspx

关键字：ARM 映像文件编译器启动函数引用地址：ARM映像文件 he 编译器自动生成的启动函数

上一篇：STM32跳至硬件错误中断(HardFault_Handle)
下一篇：KEIL下分散加载文件的使用

推荐阅读最新更新时间：2024-03-16 14:29

opencv2.2 交叉编译及在arm开发板测试

环境：arm开发板是 ok6410，主机是Ubuntu10.04 1,准备工作：交叉编译工具用光盘自带的arm-linux-4.4.1.tar.gz，解压到/usr/local/arm目录下（将/usr/local/arm/bin加入环境变量）；下载opencv2.2的源码；安装cmake build-essential；安装必要的库： libgtk2.0-dev libavcodec-dev libavformat-dev libswscale-dev libjpeg62-dev libtiff4-dev libjasper-dev 2,用到的主要目录说明：交叉编译工具链所在 /usr/local/arm 编译好的opencv

[单片机]

微软内部测试ARM和AMD处理器的Surface型号

本周早些时候，有消息称微软内部正在研究基于高通骁龙8cx平台的Surface笔记本；而最新消息表明2019年款Surface还有望搭载AMD的处理器。援引外媒Petri报道，微软和英特尔之间的关系处于“不稳定状态”，但是目前尚不清楚具体原因。报道中还指出微软内部已经开始测试搭载ARM和AMD处理器的Surface型号了。代号Excalibur 消息人士透露，微软正在开发代号为Excalibur的基于ARM的Surface设备。该设备将采用高通最新的8cx处理器，可能是SCX8180，这提供的性能相当于具有8核和高达3 GHz时钟速率的英特尔酷睿i5处理器。目前我们还不知道新款设备外形尺寸是多少，但搭载了新款芯片的新设备

[嵌入式]

ARM Linux从入口到Start_kernel代码分析 - (1)

以2.6.19内核为版本. 1. Boot loader在跳转到kernel之前，必须完成 (1). CPU必须处于SVC(supervisor)模式,并且IRQ和FIQ中断都是禁止的; (2). MMU(内存管理单元)必须是关闭的, 此时虚拟地址对物理地址; (3). 数据cache(Data cache)必须是关闭的 (4). 指令cache(Instruction cache)可以是打开的,也可以是关闭的,这个没有强制要求; (5). CPU 通用寄存器0 (r0)必须是 0; (6). CPU 通用寄存器1 (r1)必须是 ARM Linux machine type (关于machine type

[单片机]

基于ARM9的心电模拟波形发生系统的设计

0 引言　　随着现在社会的发展，人们也日益开始关注健康事业的发展，对医学技术的要求也越来越高。现实中很多病例无法通过现实病例学习，更多的医生培养只能通过模拟设备进行，心电波形模拟波形发生系统的设计就是其中一个例子。　　心电模拟发生系统使用4种不同频率的标准心电波形及用于测试的方波、锯齿波、三角波和正弦波，通过算法拟合出病人的34种异常心电波形(包括成人和儿童的)，各周期波形可采用插入不同的延时子程序来实现。提取医院病人的异常心电波形，通过拟合的方法可以模拟和转换除颤后的正常波形，依据此方法设计出一个心电信号发生系统，系统可以采集、模拟任意导联心电信号，并将结果存储到心电数据库供研究分析使用。最后设计出一种用微控制器和波形输

[单片机]

基于<font color='red'>ARM</font>9的心电模拟波形发生系统的设计

ARM中国区CEO：NVIDIA收购ARM失败是好事

本月初NVIDIA、软银公司宣布了NVIDIA放弃收购ARM公司的消息，这笔价值高达660亿美元的半导体史上最贵收购终结了，NVIDIA花了一年多时间都没能说服监管部门批准，美国FTC尤其强烈反对NVIDIA收购ARM。　　对于这次的收购失败，ARM中国区CEO、董事长吴雄昂也发表了看法，他认为这样的结果对公司及芯片行业来说其实都是好事。　　吴雄昂表示，“大多数业内人士认为，如果ARM仍然是一家独立公司，对产业发展最有利，”吴雄昂还认为“监管部门审核会越来越收紧，特别是在大型芯片收购交易方面，所以我认为大规模并购会越来越困难。” 　　作为芯片行业的专家来说，吴雄昂这番表态没什么问题，不过他的身份在这次收购中也有点尴尬——

[半导体设计/制造]

欧盟暂停调查英伟达收购ARM

英伟达欲收购英国芯片设计公司ARM，根据欧盟委员会提供的资料显示，欧盟反垄断机构暂时停止了对收购案的调查，因为它们在等待更多信息。　　本来欧盟委员会设定的最后时间是11月25日，推迟并没有什么不正常的地方。受到新冠大流行的影响，一些客户面临封禁和劳工短缺问题，数字难以收集。英伟达是世界最大显卡及AI芯片制造商，上周美国FTC也站出来阻止交易。　　先是欧盟竞争机构声称交易会推高价格、减少选择、削弱创新，2个月后美国机构才发声。

[半导体设计/制造]

基于ARM控制器LPC2214的税控收款机系统的设计

引言税控收款机是指具有特定税控功能的电子收款机，它是集软硬件为一体的嵌入式系统，硬件设计考虑高性价比和高可靠性，软件设计考虑系统的稳定性和可靠性。根据这一原则，本文介绍了一种基于ARM控制器LPC2214的税控收款机的设计方案。税控收款机硬件系统的设计与实现税控收款机的硬件组成框图如图1所示，其硬件系统由中央处理模块、显示模块、打印模块、电源模块、时钟模块、IC卡接口、外部通讯接口(包括RS232串行接口、网络接口、USB接口等)、蜂鸣器，以及输入键盘、电子锁、条码扫描仪和手写板等几部分组成。图1 税控收款机硬件框图中央处理模块中央处理模块采用飞利浦公司基于32位ARM7TDMI-S内核的

[应用]

视频监控系统中快速实现ARM和DSP的通信和协同工作

　　　图1 达芬奇软件结构框图　　通过第一部分的介绍，我们知道了TI数字视频软件开发包(DVSDK)中的Codec Engine软件模块可以帮助我们轻松地实现ARM和DSP或协处理器的协同工作，以及Codec Engine软件模块的概要情况，下面我们将告诉你如何走完Codec Engine入门的第一步和第二步。欢迎转载,本文来自电子发烧友网(http://www.elecfans.com) 　　2. Codec Engine入门第一步　　有些初学者认为Codec Engine文件包结构复杂，很难找到自己想找的文档或例子。其实在Codec Engine文件包的根目下有一个发布说明文档，比如Codec

[单片机]