Locating code and data in memory (Scatterloading)
2008-07-06 11:45
435 查看
In most embedded systems, the code and data for an application will be permamently stored in non-volatile memory (e.g. ROM or Flash) so that it is available for execution at the moment of power-up. Normally though, parts of this code and data (e.g. interrupt handlers, global variables) will need to be copied from the non-volatile memory into volatile memory (RAM) in order for the application to be able to execute correctly. In ADS this is done using the linker's scatterloading mechanism.
Scatterloading allows you to partition an application into a number of separate code and data regions spread throughout the address map. The location of these regions can differ between load time and run time:
1) Load Regions contain application code and/or data used by the application at power-on/load time (typically ROM).
2) Execution Regions are used by the application whilst it is executing.
The details of the memory map used by a scatterloaded application are contained in a description file which is passed as a parameter to armlink. The benefit of using a scatter description file is that all the (target-pecific) absolute addresses chosen for your devices, code and data are located in one file, making maintenance easy. Furthermore, if you decide to change your memory map (e.g. if peripherals are moved), you do not need to rebuild your entire project - you only need to re-link the existing objects.
Within a scatter description file, a load region is represented by the outer set of braces, and this can contain a number of execution regions (the inner braces). Execution regions can be /'rooted/' (executed at their load address), or non-rooted (copied at run-time) regions. Consider the following typical example:
LOAD_FLASH 0x04000000 0x80000 ; start address and length
{
EXE_FLASH 0x04000000 0x80000
{
init.o (Init, +First) ; Put this area first in region
* (+RO) ; wildcard to collect all other RO
}
32bitRAM 0x0000 0x2000
{
vectors.o (Vect, +First) ; Put this area first in region
int_handler.o (+RO)
}
16bitRAM 0x2000 0x80000
{
* (+RW,+ZI) ; wildcard to collect RW & ZI
}
}
This defines one load region (LOAD_FLASH), and three execution regions (EXEC_FLASH, 32bitRAM, 16bitRAM):
The exception vectors (in vectors.s) and exception handlers (in int_handler.c) are relocated to 32bitRAM at address 0 (for speed)
The RW variables are copied from Flash to the 16bitRAM at address 0x2000
The ZI data will follow the RW data in the 16bitRAM
All other code (init, main program, libraries, etc) does not need to be relocated, so just runs from the Flash.
Note that one key point to remember is that the ordering of objects in the scatter file does not affect their ordering in the output image. Within each region, the linker collects together input sections with the same attribute (RO, RW or ZI). The basic placement rule for sections within a region is: RO sections precede RW sections which precede ZI sections. Within this ordering, sections will be ordered:
by attribute (e.g RO-Code before RO-Data), then by name, then by the order they were specified on the armlink command line.
A section may be placed first or last in an execution region using +FIRST and +LAST, e.g. to place a checksum at the end of a region (as long as this does not break the basic placement rules). It should also be noted that if a system implements ROM/RAM remapping (i.e. ROM is aliased to 0x0 at reset, but RAM is at 0x0 during normal execution), then the descriptor file should describe the memory map after remapping has occurred.
For more details of scatterloading please see:
ADS 1.0 - Tools Guide, Chapter 6, "The ARM linker" and Developer Guide, Chapter 7, "Writing Code for ROM"
ADS 1.1 - Compiler, Linker & Utilities Guide, Chapter 5, "The ARM linker" and Developer Guide, Chapter 6, "Writing Code for ROM"
Scatterloading allows you to partition an application into a number of separate code and data regions spread throughout the address map. The location of these regions can differ between load time and run time:
1) Load Regions contain application code and/or data used by the application at power-on/load time (typically ROM).
2) Execution Regions are used by the application whilst it is executing.
The details of the memory map used by a scatterloaded application are contained in a description file which is passed as a parameter to armlink. The benefit of using a scatter description file is that all the (target-pecific) absolute addresses chosen for your devices, code and data are located in one file, making maintenance easy. Furthermore, if you decide to change your memory map (e.g. if peripherals are moved), you do not need to rebuild your entire project - you only need to re-link the existing objects.
Within a scatter description file, a load region is represented by the outer set of braces, and this can contain a number of execution regions (the inner braces). Execution regions can be /'rooted/' (executed at their load address), or non-rooted (copied at run-time) regions. Consider the following typical example:
LOAD_FLASH 0x04000000 0x80000 ; start address and length
{
EXE_FLASH 0x04000000 0x80000
{
init.o (Init, +First) ; Put this area first in region
* (+RO) ; wildcard to collect all other RO
}
32bitRAM 0x0000 0x2000
{
vectors.o (Vect, +First) ; Put this area first in region
int_handler.o (+RO)
}
16bitRAM 0x2000 0x80000
{
* (+RW,+ZI) ; wildcard to collect RW & ZI
}
}
This defines one load region (LOAD_FLASH), and three execution regions (EXEC_FLASH, 32bitRAM, 16bitRAM):
The exception vectors (in vectors.s) and exception handlers (in int_handler.c) are relocated to 32bitRAM at address 0 (for speed)
The RW variables are copied from Flash to the 16bitRAM at address 0x2000
The ZI data will follow the RW data in the 16bitRAM
All other code (init, main program, libraries, etc) does not need to be relocated, so just runs from the Flash.
Note that one key point to remember is that the ordering of objects in the scatter file does not affect their ordering in the output image. Within each region, the linker collects together input sections with the same attribute (RO, RW or ZI). The basic placement rule for sections within a region is: RO sections precede RW sections which precede ZI sections. Within this ordering, sections will be ordered:
by attribute (e.g RO-Code before RO-Data), then by name, then by the order they were specified on the armlink command line.
A section may be placed first or last in an execution region using +FIRST and +LAST, e.g. to place a checksum at the end of a region (as long as this does not break the basic placement rules). It should also be noted that if a system implements ROM/RAM remapping (i.e. ROM is aliased to 0x0 at reset, but RAM is at 0x0 during normal execution), then the descriptor file should describe the memory map after remapping has occurred.
For more details of scatterloading please see:
ADS 1.0 - Tools Guide, Chapter 6, "The ARM linker" and Developer Guide, Chapter 7, "Writing Code for ROM"
ADS 1.1 - Compiler, Linker & Utilities Guide, Chapter 5, "The ARM linker" and Developer Guide, Chapter 6, "Writing Code for ROM"
相关文章推荐
- Structure of a C-Program in Memory | How Heap,Stack,Data and Code segments are stored in memory?
- Memory leak in Windows 8.1 with Killer E2200 and Windows Network Data Usage Monitoring
- Android: Simplified source code for parsing and working with XML data and web services in Android
- A real example of vioplot in R (sample data and code attached)
- FSharp.Data.SqlClient: Seamlessly integrating T-SQL and F# in the same code
- .net垃圾回收学习【NET Best Practice No: 1:- Detecting High Memory consuming functions in .NET code】【翻译&&学习】
- managed and unmanaged code in c#
- Export/Import DataPump Parameter ACCESS_METHOD - How to Enforce a Method of Loading and Unloading Data ? [ID 552424.1]
- NGINX + LUA实现复杂的控制 --源自http://outofmemory.cn/code-snippet/14396/nginx-and-lua
- (ZT)PC BIOS Code and Data Layout
- Posting only possible in periods 2013/02 and 2013/01 in company code 0001
- How to compile and debug VLC player source code in eclipse IDE on Ubuntu 10.04 (lucid)
- The Proccess of Loading and Executing a Specific Program in Linux Kernel
- Data Structures and Algorithm Analysis in C 学习之List
- •Persistence - Saving and Loading Data
- Separate code and data contexts: an architectural approach to virtual text sharing
- Float and the form of expression of floating-point number in memory
- How to backup and restore data and e-mail account settings in Outlook 2007
- Working with hashCode and equals methods in java
- How to Navigate, Group, Sort and Filter Data in WPF