STLinux

Memory partitioning

Dual boot is based on a static memory partition model. This means that the memory map and firmware image for each processor is pre-defined at system boot time and never changes. Although in theory this limits the flexibility of the system, in practice the memory requirements of multimedia firmware can usually be determined. The EMBX component of the STMicroelectronics Multicom software can also provide a single memory pool shared by all processors, which can be used to minimize the use of the C library heap on companion processors.

The memory map used by the host and the firmware vary from processor to processor (and from application to application) but the general structure is always the same. Linux will use the area of memory with the lowest address, which is followed by an optional area of memory to hold large buffers shared by all processors (this area is optional as it can instead be allocated from the Linux area using bigphysaddr calls). The area at the top of memory will then be used by the coprocessors.

The base address of the Linux area forms part of the compiled-in kernel configuration and does not need to be specified. The size of the total memory available (and known by the Linux kernel) is controlled by the mem= kernel parameter.

The kernel will also need to know the base addresses of the address spaces of each coprocessor, as it must inject code into that address space when booting the coprocessor. This is managed by the coprocessor_mem= kernel parameter. The general form of this parameter is:

... coprocessor_mem=<size0>@<offset0>,<size1>@<offset1>[,...] ...

where:
<sizeN>@<offsetN>

defines the memory amount and the starting offset of the N-th coprocessor. This is an offset from the start of RAM.

For example, with 64 MiB of total memory amount and having two coprocessors on-board, we can allocate 4 MiB for both coprocessors starting respectively from 0x06000000 and 0x07000000. These addresses depends on the coprocessor memory layout. So a typical linux command line could be:

... mem=64m coprocessor_mem=4m@0x06000000,4m@0x07000000 ...

See the specific SoC descriptions below for more examples.