Generally speaking, a program includes a read-only code segment and a readable and writable data segment. In the ARM integrated development environment, the read-only code segment and constants are called RO segments (ReadOnly); readable and writable global variables and static variables are called RW segments (ReadWrite); and variables in the RW segment that are to be initialized to zero are called ZI segments (ZeroInit). For embedded systems, program images are stored in some non-volatile devices such as Flash memory, and at runtime, the RW segment in the program must be reloaded into the readable and writable RAM. This involves the program's loading domain and runtime domain. Simply put, the program's loading domain refers to the state of the program burned into the Flash, and the runtime domain refers to the state of the program when it is executed. For simpler cases, you can specify RO BASE and RW BASE in the ARM LINKER option of the ADS integrated development environment to inform the connector of the connection base addresses of RO and RW. For complex cases, such as when the RO segment is divided into several parts and mapped to multiple places in the storage space, you need to create a text file called a "distributed loading description file" to notify the connector to connect a certain part of the program to a certain address space in the memory. It should be pointed out that the definition in the distribution loading description file should be carried out according to the memory distribution after the system is redirected. After the boot program completes the initialization task, the main program should be transferred to the RAM to run in order to speed up the system.
What is an arm image file? An arm image file is actually an executable file, including bin or hex formats, which can be directly burned into the rom for execution. In the axd debugging process, we debug the axf file, which is actually an image file. It just adds a file header and some debugging information to the bin file. An image file is generally composed of domains, and a domain is composed of up to three output segments (RO, RW, ZI), and the output segment is composed of input segments. The so-called domain refers to the area where the entire bin image file is located, which is divided into a loading domain and a running domain. The loading domain is the working area where the image file is statically stored. Generally speaking, the address space where the entire bin file in the flash is located is the loading domain. Of course, programs are generally not placed in the flash for execution, and are generally moved to the sdram for operation. The address space where they are moved to the sdram for operation is the running domain. The code we input generally has a code part and a data part, which is the so-called input segment. After compilation, it becomes the ro segment and the rw segment in the bin file, and the so-called zi segment, which is the output segment. For the output segment in the load domain, generally speaking, the ro segment is followed by the rw segment, and the rw segment is followed by the zi segment. In the run domain, these output segments are not continuous, but rw and zi must be connected. The data in the zi segment and the rw segment can actually be rw attributes.
| Image$$RO$$Base| |Image$$RO$$Limit|
|Image$$RW$$Base| |Image$$ZI$$Base| |Image$$ZI$$Limit| These variables are notified by the compiler, and we
can see their values in the makefile file. They indicate the address space where each output segment is located in the run domain. | Image$$RO$$Base| is the starting address of the ro segment in the run domain, | Image$$RO$$Limit| is the ending address of the ro segment in the run domain, and so on. We can specify in the linker output that in simple mode, ro base corresponds to |Image$$RO$$Base|, rw base corresponds to |Image$$RW$$Base|, and since rw and zi are connected, |Image$$ZI$$Base| is equal to |Image$$RW$$limit|. The other values are automatically calculated by the compiler.
Below is the part of the 2410 startup code that I commented on:
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 is the starting address of the reset runtime domain, which is usually 0 in the boot nand
ldr r2, BaseOfROM;
cmp r0, r2
ldreq r0, TopOfROM; TopOfROM=0x30001de0, the end of the code segment address
beq InitRam
ldr r3, TopOfROM
; part 1, by comparison, move ro to sdram, and the destination address
starts from | Image$$RO$$Base| and ends at | Image$$RO$$Limit|
0
ldmia r0!, {r4-r7}; Transfer the value of r0 as the 4 consecutive 32-bit numbers at the address (ResetEntry) to r4, r5, r6, r7 in sequence; and r0 increases.
stmia r2!, {r4-r7}; Store the values of r4, r5, r6, r7 in |Image$$RO$$Base| in sequence; and r2 increases.
cmp r2, r3
bcc �;
;part 2, move rw segment to sdram, the destination address starts from |Image$$RW$$Base| and ends at |Image$$ZI$$Base|
sub r2, r2, r3;r2=0 ;When copying above, 4 double words (32 bits) are copied each time, but the RO segment size is not necessarily an integer multiple of 4, so several double words may be copied, r2-r3 gets the number of copiessub
r0, r0, r2 ;r0-(r2-r3) can make r0 point to the end address of RO in boot nandInitRam
;carry rw
to baseofBSS
ldr r2, BaseOfBSS ;TopOfROM=0x30001de0,baseofrw
ldr r3, BaseOfZero ;BaseOfZero=0x30001de0
0
cmp r2, r3
ldrcc r1, [r0], #4
strcc r1, [r2], #4
bcc
� ;part 3,initialize sdram zi to 0, address from |Image$$ZI$$Base| to |Image$$ZI$$Limit|
mov r0, #0;init 0
ldr r3, EndOfBSS;EndOfBSS=30001e40
1
cmp r2, r3
strcc r0, [r2], #4
bcc
� At this point, the copying and initialization of the three output segments (RO, RW, ZI) are completed.
Keywords:ARM
Reference address:ARM startup code learning (I) What do RO, RW and ZI stand for?
What is an arm image file? An arm image file is actually an executable file, including bin or hex formats, which can be directly burned into the rom for execution. In the axd debugging process, we debug the axf file, which is actually an image file. It just adds a file header and some debugging information to the bin file. An image file is generally composed of domains, and a domain is composed of up to three output segments (RO, RW, ZI), and the output segment is composed of input segments. The so-called domain refers to the area where the entire bin image file is located, which is divided into a loading domain and a running domain. The loading domain is the working area where the image file is statically stored. Generally speaking, the address space where the entire bin file in the flash is located is the loading domain. Of course, programs are generally not placed in the flash for execution, and are generally moved to the sdram for operation. The address space where they are moved to the sdram for operation is the running domain. The code we input generally has a code part and a data part, which is the so-called input segment. After compilation, it becomes the ro segment and the rw segment in the bin file, and the so-called zi segment, which is the output segment. For the output segment in the load domain, generally speaking, the ro segment is followed by the rw segment, and the rw segment is followed by the zi segment. In the run domain, these output segments are not continuous, but rw and zi must be connected. The data in the zi segment and the rw segment can actually be rw attributes.
|Image$$RW$$Base| |Image$$ZI$$Base| |Image$$ZI$$Limit| These variables are notified by the compiler, and we
can see their values in the makefile file. They indicate the address space where each output segment is located in the run domain. | Image$$RO$$Base| is the starting address of the ro segment in the run domain, | Image$$RO$$Limit| is the ending address of the ro segment in the run domain, and so on. We can specify in the linker output that in simple mode, ro base corresponds to |Image$$RO$$Base|, rw base corresponds to |Image$$RW$$Base|, and since rw and zi are connected, |Image$$ZI$$Base| is equal to |Image$$RW$$limit|. The other values are automatically calculated by the compiler.
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 is the starting address of the reset runtime domain, which is usually 0 in the boot nand
ldr r2, BaseOfROM;
cmp r0, r2
ldreq r0, TopOfROM; TopOfROM=0x30001de0, the end of the code segment address
beq InitRam
ldr r3, TopOfROM
; part 1, by comparison, move ro to sdram, and the destination address
starts from | Image$$RO$$Base| and ends at | Image$$RO$$Limit|
0
ldmia r0!, {r4-r7}; Transfer the value of r0 as the 4 consecutive 32-bit numbers at the address (ResetEntry) to r4, r5, r6, r7 in sequence; and r0 increases.
stmia r2!, {r4-r7}; Store the values of r4, r5, r6, r7 in |Image$$RO$$Base| in sequence; and r2 increases.
cmp r2, r3
bcc �;
;part 2, move rw segment to sdram, the destination address starts from |Image$$RW$$Base| and ends at |Image$$ZI$$Base|
sub r2, r2, r3;r2=0 ;When copying above, 4 double words (32 bits) are copied each time, but the RO segment size is not necessarily an integer multiple of 4, so several double words may be copied, r2-r3 gets the number of copiessub
r0, r0, r2 ;r0-(r2-r3) can make r0 point to the end address of RO in boot nandInitRam
;carry rw
to baseofBSS
ldr r2, BaseOfBSS ;TopOfROM=0x30001de0,baseofrw
ldr r3, BaseOfZero ;BaseOfZero=0x30001de0
0
cmp r2, r3
ldrcc r1, [r0], #4
strcc r1, [r2], #4
bcc
� ;part 3,initialize sdram zi to 0, address from |Image$$ZI$$Base| to |Image$$ZI$$Limit|
mov r0, #0;init 0
ldr r3, EndOfBSS;EndOfBSS=30001e40
1
cmp r2, r3
strcc r0, [r2], #4
bcc
� At this point, the copying and initialization of the three output segments (RO, RW, ZI) are completed.
Previous article:Detailed explanation of arm startup code
Next article:How should beginners learn with development boards such as 2440 and 6410?
- Popular Resources
- Popular amplifiers
Recommended Content
Latest Microcontroller Articles
- Learn ARM development(16)
- Learn ARM development(17)
- Learn ARM development(18)
- Embedded system debugging simulation tool
- A small question that has been bothering me recently has finally been solved~~
- Learn ARM development (1)
- Learn ARM development (2)
- Learn ARM development (4)
- Learn ARM development (6)
He Limin Column
Microcontroller and Embedded Systems Bible
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
MoreSelected Circuit Diagrams
MorePopular Articles
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
MoreDaily News
- Analysis of the application of several common contact parts in high-voltage connectors of new energy vehicles
- Wiring harness durability test and contact voltage drop test method
- From probes to power supplies, Tektronix is leading the way in comprehensive innovation in power electronics testing
- From probes to power supplies, Tektronix is leading the way in comprehensive innovation in power electronics testing
- Sn-doped CuO nanostructure-based ethanol gas sensor for real-time drunk driving detection in vehicles
- Design considerations for automotive battery wiring harness
- Do you know all the various motors commonly used in automotive electronics?
- What are the functions of the Internet of Vehicles? What are the uses and benefits of the Internet of Vehicles?
- Power Inverter - A critical safety system for electric vehicles
- Analysis of the information security mechanism of AUTOSAR, the automotive embedded software framework
Guess you like
- TI Voltage Reference (VREF) Application Design Tips and Tricks
- Banknote number recognition system based on ARM.pdf
- My knowledge of computers
- Sampling rate of MCU ADC
- Let’s talk about the first big event in 2019...
- Wifi controlled LED screen
- IIoT opens up more possibilities beyond the factory floor
- Recommended one: [Lingsheng] MCU code automatic generator (automatic programming tool)
- Learning 3D visualization scene hierarchy from scratch (1)
- What are the differences and connections between compilers and integrated development environments?