MEMORY LAYOUT

version 1.0

1. OVERVIEW

This article introduces the unique memory layout method on SStar platform, and some basic concepts related to mma heap.

2. MMAP

2.1. MMAP Introduction

MMAP(short for memorymap) is the memory layout of the entire SOC system. As shown below, the memory configured in the MMAP is divided into two parts.

  1. Hardware IP private memory.

  2. LX_MEM, the memory that Linux Kernel can use.

Figure2-1

The user of each memory must ensure that the memory use are in the range. For example, the memory used by the Linux kernel is guaranteed by the internal mechanism of Linux, and the memory used by the HW IP is guaranteed by the hardware.

There may be several pieces of LX_MEM. For example, there are dual-channel DDRs on some SOCs, and one piece of LX_MEM is allocated to each DDR. Multiple LX_MEM may also be allocated on a DDR. The naming rules are LX_MEM1, LX_MEM2, and so on.

Pull out a piece from LX_MEM for MMA Heap to use. Like cma in Linux. This memory pool is dynamically allocated to HW IP through software by MI SYS, which is different from the statically allocated memory private to Hardware IP in MMAP, it has been allocated when the system is initialized and is only used by this IP.

The memory allocated by MMA Heap and HW IP Layout is physically continuous. The part used by Linux Kernel in LX_MEM may be converted into virtual addresses by LINUX MMU, which is not physically continuous.

Each DDR has a corresponding MIU. All HW IPs, whether statically or dynamically allocated memory, can access the DDR through MIU.

There are many versions of SOC, so does the MMAP, which are currently classified by Chip Name.

MMAP storage path: ALKAID/project/board/$(CHIP)/

For example, some chips have 64MB, 128MB, 256MB, which can be judged by the file name. Configure the use by setting the script variable MMAP = xxx in Build config.

The MMAP file has a .h suffix, but currently it will not be compiled into the code. When the program is compiled and run, it will be dynamically loaded into the memory and parsed through the private mmap parser function. Detailed introduction in later chapters.

2.2. MMAP Processing In System Packaging Stage

In the previous section, the memory configuration in the Linux kernel depends on the location and size of LX_MEM in MMAP, and the native Linux kernel configures memory in DTS.

In order for the kernel image to be compatible with multiple memory configurations, the SStar platform passes the memory size and address to the kernel through bootargs, so that there is no need to change the image memory.

The ALKAID project is compatible with the packaging process of multiple platforms and manages a lot of build config, so there are also many MMAPs. Relying on manual maintenance of LX_MEM in the build config, the configuration will be very cumbersome and error-prone. Therefore, an application running on the build server was developed, executed through a packaged shell, parsed MMAP, and obtained some strings as parameters to be passed to LX_MEM in bootargs.

Code path:

ALKAID/project/image/makefiletools/src/mmappaser/

Enter it and execute gcc ./*.c -o mmappaser to generate a binary executable file(mmappaser) in the current directory.

mmappaser has been compiled and placed in ALKAID/project/image/makefiletools/bin/. When the system is packaging, the Makefile will automatically find this path and execute the default mmappaser without automatic compilation. If mmappaser needs to be changed, please also release the compiled executable file to the bin folder.

Regarding the realization of parsing MMAP code, mmappaser is the same as after the board is up. The purpose is to cooperate with the compilation system and output the value of the specified field in the MMAP.

“mmappaser” command execution format:

./mmappaser [MMAP Path] [CHIP] [cmd para0] [cmd para1]

After "mmappaser" is executed, the result will be printed out, which can be obtained by the shell script and passed as a parameter value. The execution of mmappaser in the packaging stage is the process of automatically parsing the corresponding string and passing it to bootargs as the system parameter value by configuring the MMAP path and CHIP.

The file for parsing MMAP is saved in /config/mmap.ini, which is renamed by the file with .h suffix in ALKAID/project/board/$(CHIP)/.

"Mmappaser" can get the address and size of a block of memory in Physical And MIU Address

./mmappaser [MMAP Path] [CHIP] [MEMORY NAME] phyaddr

./mmappaser [MMAP Path] [CHIP] [MEMORY NAME] miuaddr

./mmappaser [MMAP Path] [CHIP] [MEMORY NAME] size

Makefile/Shell script sample:

File: ALKAID/project/setup_config.sh

Figure2-2

Compiling and executing setup_config.sh will automatically add similar fields in config/current.configs:

KERNEL_MEMADR = $(shell /home/malloc.peng/ALKAID/project/image/makefiletools/bin/mmapparser /home/malloc.peng/ALKAID/project/board/$(CHIP)/mmap/$(MMAP) $(CHIP) E_LX_MEM phyaddr)
KERNEL_MEMLEN = $(shell /home/malloc.peng/ALKAID/project/image/makefiletools/bin/mmapparser /home/malloc.peng/ALKAID/project/board/$(CHIP)/mmap/$(MMAP) $(CHIP) E_LX_MEM size)

2.3. Bootarg Memory Configuration

The previous section mentioned that in the process of system packaging, LX_MEM in MMAP will be automatically parsed to obtain the address and size, and passed to the linux kernel as bootargs.

After the packaging is completed, it will be displayed in the system's set_config as follows:

Figure2-3

LX_MEM is the memory size on miu0. It starts from the beginning address by default and cannot be modified. To configure LX_MEM2, you need to add the starting value of the physical address. For example, configurations of LX_MEM are as follows:

Figure2-4

The setting of mma heap in Bootargs cannot be generated automatically. It needs to be modified manually according to the build config, which will be introduced in the other section.

2.4. MMAP Processing During System Initialization

The processing of MMAP during system initialization is divided into two parts:

  1. The processing of reading bootargs in the Linux kernel initialization phase:

    Code path： kernel/driver/sstar/cpu/memory.c

    Parse the relevant fields in bootargs through the kernel standard process.

    Figure2-5

    Figure2-6

    Function: void __init prom_meminit(void).

    It will be executed when the system is initialized. The main logic will first remove the memory configured in dts, and then add the memory in bootargs to the system.

    Figure2-7

  2. Processing in MI_SYS phase after Linux Kernel is loaded:

    In the kernel initialization phase, only LX_MEM in MMAP will be used, and all configurations in MMAP will be read in MI_SYS and stored in a private structure.

    Use /config/dump_mmap to dump the mmap configuration read by SYS:

    Figure2-8

2.5. Use SCA Modify MMAP

It is troublesome to modify the address offset and size in MMAP, and Manual modification is not recommended but the SCA tool.

  1. Open

    Figure2-9

  2. Add

    Figure2-10

  3. Modify

    Memory modification includes the change of buf size and location and the adjustment of DDR size. All the memories should be filled after changed, and there should be no memory overflow or omission, otherwise an error will be reported when saving.

    Figure2-11

  4. Delete

    Figure2-12

  5. Save

    Press Save button to operate.

2.6. Linux Available Memory

Get the memory size that can be used in the current kernel through cat/proc/meminfo, the formula is as follows:

Meminfo = (The sum of all LX_MEM sizes configured in Bootargs) - (All MMA size + Kernel reserve 5M)

2.7. Special Layout Example

  1. 128MB + 128MB with DLA MMAP

  2. As shown below, there are two DDRs, so LX_MEM will allocate two. There is a DLA memory layout on MIU1. The input memory of DLA comes from the output port of DIVP, and the DLA memory address must be after its FW address. , So LX_MEM2 is laid out after E_MMAP_ID_DLA.

Figure2-13

The output memory used by DIVP must be configured to DLA on E_LX_MEM2 to be read, so mma_heap_name1 will be separately configured for DIVP on the mma heap, so that the output memory address is in E_LX_MEM2 of miu1 , Refer to bootargs configuration:

LX_MEM=0x7f00000 LX_MEM2=0xa6000000,0x2000000

mma_heap=mma_heap_name0,miu=0,sz=0x5000000

mma_heap=mma_heap_name1,miu=1,sz=0x500000

mma_heap=mma_heap_name2,miu=1,sz=0x1800000

3. MMA HEAP

3.1. Config And Dump

The size of mmap heap can be modified dynamically by modifying mma_heap in bootargs. In the build config of each project, a default mma heap size is configured for the application scenario. This size is only an estimated value, and FAE can accurately calculate the size for the application scenario on site.

Flags configured by Mmap_heap:

  1. mma_memblock_remove=1

    It represents whether to remove the memory reserved for mma from the kernel memory.

  2. max_start_off=$(MMA_START_OFFSET)

    The end address of the memory reserved by Mma from the kernel cannot exceed $(MMA_START_OFFSET), otherwise the application will fail.

Dump mma:

cat /proc/mi_modules/mi_sys_mma/mma_heap_name0

cat /proc/mi_modules/mi_sys_mma/mma_heap_name1

3.2. Physical And MIU Address

The physical address is on HW design, "CPU" accesses the physical address of DRAM.

For example, the starting physical address of dual-channel ddr CPU accessing MIU0 is 0x20000000, and the starting physical address of MIU1 is 0xA0000000.

The MIU address is the address where the HW IP accesses the DRAM through MIU. The address of MIU0 starts from 0x0, and the address of MIU1 starts from 0x80000000.