Introduction Memory markup, i.e. Breakdown into sections, in devices on MTK chips is produced using a file called "scatter file".
It is used by flash programs, the so-called. flashers (from the English "flasher") when flashing a full image of memory or its individual parts, called partitions.
The scatter file structure contains the description of all existing sections of memory, regardless of what they will contain in the working device.
The structure of the scatter file. There are two versions of the scatter file structure. Consider the first version used in most mobile devices on MTxx chips.
A full description of the memory section is a set of lines of the form:
[__NODL_] name offset [length]
{
} where
- __NODL_ - "No download" is a sign that the partition will be skipped by the flasher and does not require a firmware file for its operation. Such a section can be generally excluded from the scatter file;
- name - section name;
- offset - offset of the section from the beginning of the memory in hexadecimal form, byte;
- length - section length in hexadecimal view, byte.
Square brackets mean optional parameter.
The most commonly used abbreviated form is:
Such a description of the memory sections assumes that:
- each section has a length before the next one;
- between the two sections there is no third (hidden) one.
For example, I will give a typical scatter-file for MT6589. It has the following form:
PRELOADER 0x0
{
}
MBR 0x600000
{
}
EBR1 0x680000
{
}
__NODL_PMT 0x700000
{
}
__NODL_PRO_INFO 0xb00000
{
}
__NODL_NVRAM 0xe00000
{
}
__NODL_PROTECT_F 0x1300000
{
}
__NODL_PROTECT_S 0x1d00000
{
}
__NODL_SECCFG 0x2700000
{
}
UBOOT 0x2720000
{
}
BOOTIMG 0x2780000
{
}
RECOVERY 0x2d80000
{
}
SEC_RO 0x3380000
{
}
__NODL_MISC 0x3980000
{
}
LOGO 0x3a00000
{
}
EBR2 0x3d00000
{
}
__NODL_EXPDB 0x3d80000
{
}
ANDROID 0x4780000
{
}
CACHE 0x2d180000
{
}
USRDATA 0x34f80000
{
}
__NODL_FAT 0x74f80000
{
}
__NODL_BMTPOOL 0xffff00a8
{
}
Consider the structure of the second version of the scatter file.
A complete description of each section of memory is a set of lines of the form:
partition_index: SYS1
partition_name: MBR
file_name: MBR
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x80000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00, where
- - partition_index - index number of the partition, for example, SYS1;
- - partition_name - the name of the partition, for example, MBR;
- - file_name is the name of the file containing the partition image, or NONE;
- - is_download - sign of partition load (something like __NODL_);
- - type - section type. Indicates the contents of a section. It can take the following values:
EXT4_IMG - the partition contains part of the EXT4 file system;
NORMAL_ROM - the section contains a saved image or a separate file;
SV5_BL_BIN - the section contains the raw code (Raw Code), i.e. executable code;
- - linear_start_addr - starting address for placing the section in the firmware file, byte;
- - physical_start_addr - the starting address of the partition in the device memory (physical address), bytes;
- - partition_size - partition size, bytes;
- - region - partition location. It can take the following values:
EMMC_BOOT_1 -
EMMC_USER -
- - storage - HW_STORAGE_EMMC
- - boundary_check — flag to mark the interface (in the internal database or PMT);
- - is_reserved - indication of the need for backup;
- - operation_type - type of operation. It can take the following values:
BINREGION - the area of ​​"raw code";
BOOTLOADERS - bootloader;
INVISIBLE - invisible section;
PROTECTED - protected partition;
RESERVED - reserved;
UPDATE - updated section.
An example of a full scatter file of the second version is given in the file "Scatter_v2.txt".
Work with scatter file. Any flasher uses scatter file only for FULL memory markup.
If you are flashing one or more partitions, then the flasher takes the location of partitions from the internal "database" - the PMT file (Partitions Map Table). It reads the offset value for the partition (physical address) and copies, i.e. "flashing" the partition image into memory, starting with this physical address.
Because scatter file contains a list of the physical addresses of the location of all sections of memory, then changing it, you can re-mark this memory. To do this, you need to change the offset values ​​of the necessary sections.
For example, in the USRDATA section, data of user programs are located: logs of work and errors, data about records of games, etc. Therefore, this section is often overflowed, which leads to the appearance of messages like "Memory is full."
In the typical scatter file, it has an offset of 0x34f80000 and a size of 0x74f80000-0x34f80000 = 0x40000000 (or 1073741824 = 1GB). Increase it, for example, by 256MB (268435456). Then the size of the partition will be 1073741824 + 268435456 = 1342177280 (or 0x50000000 in hex). Those. we added another 0x10000000 bytes to the section. Then the next section offset will move by the same amount:
was - 0h74f80000
it became - 0x84f80000
If you do this with offsets of ALL subsequent partitions, then they ALL will move and the TOTAL size of the memory occupied by the firmware will increase by this amount. And this is unacceptable. Therefore, you need to reduce the size of any subsequent section. We have this user section (FAT).
We cannot change its size because it is located to the end of the existing memory. It will simply automatically shorten.
It would seem that everything, but you can shorten sections to a certain limit (to "zero"). Therefore, if the offset of the last partition goes beyond the upper limit of memory, then you will have to roll back all changes or reduce the size of the section “increase”.