Scatter loading is a mechanism provided by the ARM linker, which enables you to partition an executable image into regions that can be positioned independently in memory.
In a simple embedded computer system, memory is divided into ROM and RAM. The image produced by the linker is divided into the "Read-Only" segment, which contains the code and read-only data, and the "Read-Write" segment, which contains the initialized and non-initialized or zero-initialized (ZI) data. Usually, the "Read-Only" segment is placed in ROM and the "Read-Write" segment is copied from ROM to RAM before execution begins.
Embedded systems often use a more complex memory map, which can consist of ROM, SRAM, DRAM, FLASH and so on. The scatter loading mechanism lets you place various parts of the image in these distinct memory areas.
Scatter loading enables you to partition your program image into several regions of code and data which can be placed separately in the memory map. Each region is placed in a contiguous chunk of memory space. The location of a region can differ between load time and execute time, which the application copying code and data from its load address to its execution address.
The placement information is contained in a description file, the name of which is passed as a command line parameter to the linker.
Load Regions and Execution RegionsA program image consists of regions which may occupy different locations at load time and execution time.
This means that just before an image is executed, there are some regions which need to be moved from the locations at which they were initially loaded in memory. For example, initialized read-write data may reside in ROM, but it must be copied into RAM when the program starts executing.
There are two mechanisms available to describle where image regions should be placed in memory at execution time:
1) Using -RO and -RW command line options.
2) Scatter loading
Scatter Loading Definitions1) Load region
The memory which is occupied by a program before it starts executing, but after it has been loaded into memory, can be split into a set of disjoint load regions, each of which is contiguous chunk of bytes.
2) Execution region
The memory used by a program while it is executing can also be split into a set of disjoint execution regions.
Placing Regions with Scatter Loading1) Use the command line options
"-scatter descritption-file", this option will cause the linker to ignore the
"-RO -RW" options.
2) Scatter load images can be output in the following formats:
BINGenerates one file for each load region, in the directory given as the output filename. These can then be blown into ROM, Flash and so on as appropriate. The output name is treated as a directory name. Each load region is placed in a separate file in that directory, with the same name as the load region. Load region names must therefore not contain characters, or be of a length, unacceptable to the host file system.
ELF
Generates a single executable ELF file suitable for loading into the debugger. A single output file, containing one section per load region, is produced. The name of the file is given by the -output option.
Linker pre-defined symbols Using the region names given in the scatter loading description file, the linker generates the symbols required to allow each region to be copied from its load address to its execution address.
Neither the linker nor the C library provide the code required to copy an execution region from its load address or create a zero-initialized region; you must do this, as the application code writer.
The linker generates symbols which allow your routine to initialize all the execution regions that have different load and execution address. These symbols give the length, load address and execution address of each region.
For RO and RW segments:
Load$$region_name$$Base is the load address of the region
Image$$region_name$$Base is the execution address of the region
Image$$region_name$$Length is the execution region length in bytes
For zero-initiailized segments:
Image$$region_name$$ZI$$Base is the execution address of the region
Image$$region_name$$ZI$$Length is the execution region length in bytes.
These symbols can be imported and used by assembly language programs, or referred to as extern address from C (using the -fc compiler option which allow $ in identifiers).
Note
These symbols are generated for every region named in the scatter load description.
A scatter load image is not padded with zero, and requires the ZI data area to be created dynamically. This is similar to the case with a normal -bin file when the -nozeropad option is used. There is therefore no need for a load address symbol for ZI data.
The linker sorts AREAs within execution regions according to their attributes. For example, all initialized data area are grouped together. Therefore, you can assume that all initialized data that needs coping is contiguous.
Area orderingThe linker orders AREAs within each execution region by attributes. The ordering is:
Read-only code
Read-only based data
Read-only data
Read-write code
Based data
Other initialized data
Zero-initialized data
The pseudo-attributes FIRST and LAST can be used in the description file to mark the first and last AREAs in an execution region if the placement order is important (for example, if the ENTRY must be first and a checksum last).
Scatter loading and long distance branching The ARM instruction set has branch instructions that allow a branch forwards or backwards up to 32Mb. The BL (Branch with Link) instruction also preserves the return address in register 14 (Link Register, LR).
The Thumb instruction set has much shorter branch ranges. From 256 bytes in the case of conditional branches to 2048 bytes for unconditional branches. The BL instruction has a range of 4Mb.
The linker has to ensure that no branch or subroutine call violates these range restrictions. If you place your execution regions in such a way as to require inter-region branches beyond the range, the linker generates an error stating Relocated value too big for instruction sequence.
The description fileA Scatter Load Description is a text file describing how the AREAs in a linked image are assigned to separate regions of memory.
In a scatter load description
. You list the separate regions of memory in which your image will execute, and specify an execution base address of each region.
. You describe how execution regions are packed into regions of physical memory (called load regions). The linker generates a separately loadable chunk of image for each load region. In some image formats (for example BIN), each load region is written to its own output file; In others (for example ELF, AIF), each load region has its own section within a single output file. You can think of each load region corresponding to a separate persistent memory such as ROM, EPROM, FLASH, and so on.
. Using simple patterns and attributes you describe how armlink should assign the constituent AREAs of your image to execution regions.
Notes:
. If you want to execute a code region directly then you must ensure its execution address is the same as its load address. Consequently, you must assign the AREA containing your image's ENTRY point to such a region.
. Your scatter load description does not describe the objects which make up your image. You describe that in the same way for all image on its command line. The patterns you write in a scatter load description describe how to assign the AREAs which armlink has already selected to the execution regions you defined.
. You can describe execution regions which overlap, provided that you give each region the OVERLAY attribute. If you do this, the linker generates support code and data to allow overlapping regions to be swapped dynamically at execution time and adds a reference from the support code to an overlay manager. You must have included ARM's standard overlay manager, or one compatible with it, in your list of object files.
. ARM-Thumb interworking veneers are built an AREA called IWV$$Code, You can assign this AREA to an execution region just like any other area using the AREA selector:
*(IWV$$Code)
Although there is no associated module, * still matches. Because there is only one IWV$$Code AREA, this section is unambiguous.
