Scatter file learning tutorial on MTK Platform

MTK PlatformAboutScatter FileLearning is the content to be introduced in this article, mainly to understandMTK PlatformMediumScatter FileFor more information, see this article.

Scatterloading is a mechanism provided by the ARM connector. This mechanism can split an executable image file (that is, a binfile) into different independent segments in the memory.

The Image file has two views: Loadview and executionview ). During the download, Imageregions is placed in memorymap. Before executing the Image, you may need to place some regions on the address at which they are executed and create ZIregions. For example, the RW data you initialize must be moved from the address in the ROM when it is downloaded to the RAM address when it is executed.

InScatter FileYou can specify different storage region addresses for each code or data segment during loading and execution,

The storage block of Scatlertoading can be divided into two types:

Load area: The Storage Area of the application when the system starts or loads.

Execution zone: the memory zone for application execution and data access after the system starts. The system can have one or more execution zones during real-time operation.

All the code and data in the image have a loading address and an operational address (the two may be the same or different, depending on the situation ). When the system starts, the _ main initialization code in the C function library performs the necessary copying and resetting operations to transfer the corresponding code and Data Segment of the application from the loading status to the execution status.

Why the Scatter file is required:

There are basically two methods for developing Memory maps (memorymap). One is to use the command line option during link, before the program is executed, use linkerpre-definesymbol to initialize section segments using the assembly language. Second, use scatterfile, that is, the "Distributed Loading Mechanism" is used ". The above two methods depend on the complexity of the application, one for the simple situation, and two for the complex situation.

Mobile phones are complicated and must use scatterfile.

Scatter File Syntax:

The scatter file is a simple text file that contains some simple syntax (the content after the semicolon is a comment ):

My_Region0x00000x1000; length of the starting address area in the region name Area

 
 

  
  
{
  
  
Thecontextofregion; zone content
  
  
}
 
 

Each partition is defined by a header title. The header contains at least the name and start address of the partition, and the maximum length and other attribute options. The content defined by the partition is included in a pair of curly braces that depend on specific system conditions.

A loading area must contain at least one execution segment. In practice, there are usually multiple execution segments.

An execution zone must contain at least one code or data segment. These are usually from target files such as source files or library functions; the wildcard Number * matches the remaining part of the specified attribute item that is not defined in the file.

Simple distributed loading example

In the example shown in figure 8, there is only one loading zone, which contains all the code and data. The starting address is 0. This loading area corresponds to two execution segments. One contains all RO code and data, and the execution address is the same as the loading address. The other starting address is 0x10000, which contains all RW and ZI data. In this way, when the system starts to start, it starts to run from the first execution segment (the execution address is equal to the loading address). During the execution, some initialization code will transfer some code in the loading area to another execution segment.

The following is the scatter description file, which describes the above memory ing method.

 
 

  
  
LOAD_ROM0x4000
  
  
{
  
  
EXE_ROM0x00000x4000
  
  
{
  
  
* <+ RO>; all code and constant data
  
  
}
  
  
RAM0x100000x8000
  
  
{
  
  
* <+ RW, + ZI>; all mass data
  
  
}
  
  
}
 
 

Place objects in Distributed files

In most applications, all attributes are not put together in a simple way like metadata. users need to control the location of specific code and data segments. You canScatter FileDefine and implement a single target file, instead of simply relying on wildcards.

To override the standard connector layout rules, we can use the + FIRST and + LAST Distributed Loading commands. A typical example is to place the interrupt vector table at the beginning of the execution segment:

 
 

  
  
LOAD_ROM0x00000x4000  
  
  
｛  
  
  
EXEC_ROM0x00000x4000  
  
  
｛  
  
  
vectors.o〈Vect,+FIRST〉  
  
  
*〈+RO〉  
  
  
｝  
  
  
;moreexecregions...  
  
  
｝ 
 
 

In this scatter file, the Vect field in vextors. o is saved to address 0x0000.

Scatter.txt detailed analysis

ROM0x000x800000; Name: ROM zone. The starting address is 0x00, and the length of the zone is 0x800000. The region name is unique. The MTK platform limits the size of the first partition to 8 Mbytes.

{

ROM0x00FIXED0x3D8000; The name is the ROM execution segment, which is unique among all execution segments. The starting address of the segment is 0x00, and the length is fixed to 0x3D8000.

{

Bootarm. obj (C $ code, + First); First refers to putting the code at the starting address of this section. The meaning of C $ code may be the name of a block.

*. Obj (LEADING_PART, + First); the meaning should be: Put the LEADING_PART block of the file suffixed with. obj next to it (that is, the end of bootarm. obj.

*. L (+ RO); the executable code and constants of all files suffixed with. l are placed here.

* Bmt. lib (+ RO); the executable code and constants of all files ending with bmt. lib are placed here.

 
 

  
  
* Adaptation. lib (+ RO)
  
  
* Config. lib (+ RO)
  
  
* Custom. lib (+ RO)
  
  
* Drv. lib (+ RO)
  
  
* OFDM. lib (+ RO)
  
  
* Init. lib (+ RO)
  
  
* Kal. lib (+ RO)
  
  
* Lw.classb.lib (+ RO)
  
  
* Nucleus us. lib (+ RO)
  
  
* Nucleus us_int.lib (+ RO)
  
  
* Nucleus us_debug.lib (+ RO)
  
  
* Stacklib. lib (+ RO)
  
  
* Sst. lib (+ RO)
  
  
* Tst. lib (+ RO)
  
  
* Mtkapp. lib (+ RO)
  
  
* Usb. lib (+ RO)
  
  
; * J2me_hi.lib (+ RO); this line of statements has been commented out and is invalid.
  
  
* Nvram. lib (+ RO)
  
  
* Nvram_sec.lib (+ RO)
  
  
* Ft. lib (+ RO)
  
  
* Irda. lib (+ RO)
  
  
* Fs. lib (+ RO)
  
  
* Media. lib (+ RO)
  
  
* Media_sec.lib (+ RO)
  
  
* Dsp_ram.lib (+ RO)
  
  
; * Plutommi. lib (+ RO)
  
  
ScreenRotation. obj (+ RO)
  
  
Wingui. obj (+ RO)
  
  
Wgui_categories.obj (+ RO)
  
  
; * Media. lib (+ RO)
  
  
Png_decoder_sw.obj (PRIMARY_CODE); Put the PRIMARY_CODE block (which can be code or data) in the png_decoder_sw.obj file here.
  
  
; * Mmiresource. lib (+ RO)
  
  
CustNFBProgressImg. obj (+ RO)
  
  
Gui_wrapper.obj (+ RO)
  
  
}
  
  
DYNAMIC_CODE20xA0018800OVERLAY0x2800; compare with the address space table of MT6228 chip, DYNAMIC_CODE2 pieces will be placed in TCM.
  
  
{
  
  
* (G3D_DYNAMIC_CODE, G3D_DYNAMIC_ZI); put the code and data contained in G3D_DYNAMIC_CODE and G3D_DYNAMIC_ZI.
  
  
}
  
  
DYNAMIC_CODE10xA001B000OVERLAY0x5000
  
  
{
  
  
* (AMR515_DYNAMIC_CODE, AMR515_DYNAMIC_ZI)
  
  
}
  
  
DYNAMIC_CODE30xA001B000OVERLAY0x5000
  
  
{
  
  
* (CTM_DYNAMIC_CODE, CTM_DYNAMIC_ZI)
  
  
}
  
  
DYNAMIC_CODE40xA001B000OVERLAY0x5000
  
  
{
  
  
* (G729_DYNAMIC_CODE, G729_DYNAMIC_ZI)
  
  
}
  
  
DYNAMIC_CODE50xA001B000OVERLAY0x5000
  
  
{
  
  
* (SBC_DYNAMIC_CODE, SBC_DYNAMIC_ZI)
  
  
}
  
  
PRIMARY_EXTSRAM0x400000FIXED0x400000; the segment name is PRIMARY_EXTSRAM, the starting address is 0x400000, And the length is fixed to 0x400000.
  
  
{
  
  
*. L (+ RW)
  
  
* Bmt. lib (+ RW)
  
  
* Adaptation. lib (+ RW); Put the read and write data of all files ending with adaptation. lib here.
  
  
* Config. lib (+ RW)
  
  
* Custom. lib (+ RW)
  
  
* Drv. lib (+ RW)
  
  
* OFDM. lib (+ RW)
  
  
* Init. lib (+ RW)
  
  
* Kal. lib (+ RW)
  
  
* Lw.classb.lib (+ RW)
  
  
* Nucleus us. lib (+ RW)
  
  
* Nucleus us_int.lib (+ RW)
  
  
* Nucleus us_debug.lib (+ RW)
  
  
* Stacklib. lib (+ RW)
  
  
* Sst. lib (+ RW)
  
  
* Tst. lib (+ RW)
  
  
* Mtkapp. lib (+ RW)
  
  
* Usb. lib (+ RW)
  
  
* J2me_hi.lib (+ RW)
  
  
* Nvram. lib (+ RW)
  
  
* Nvram_sec.lib (+ RW)
  
  
* Ft. lib (+ RW)
  
  
* Irda. lib (+ RW)
  
  
* Fs. lib (+ RW)
  
  
* Media. lib (+ RW)
  
  
* Media_sec.lib (+ RW)
  
  
* Dsp_ram.lib (+ RW)
  
  
; * Plutommi. lib (+ RW); the Code has been commented out and is invalid.
  
  
ScreenRotation. obj (+ RW)
  
  
Wingui. obj (+ RW)
  
  
Wgui_categories.obj (+ RW)
  
  
; * Mmiresource. lib (+ RW)
  
  
CustNFBProgressImg. obj (+ RW)
  
  
Gui_wrapper.obj (+ RW)
  
  
; ZIchunk
  
  
* (+ ZI); the data in all other files is stored here, and the data is cleared during startup.
  
  
}
 
 

Summary:MTK PlatformAboutScatter FileThe content of the tutorial is complete.MTK platform Scatter FileThe learning of application content is helpful to you!