Memory Overview¶
The following describes the default memory layout for the MitySOM-AM57x platform.
Useful links:
https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_how_to_guides.html#customizing-memory-map-for-creating-multicore-applications-on-am57xx-using-ipc
https://www.ti.com/lit/an/sprac60/sprac60.pdf
DDR Memory¶
The AM57x has two EMIF banks, each connected to 1GB of DDR.
| Memory Interface | Physical Address |
| EMIF 1 | 0x80000000 |
| EMIF 2 | 0xC0000000 |
The DDR is mapped in the am57xx-mitysom.dtsi device tree which maps the 2GB of memory contiguously.
memory@0 {
device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
Multi-Core Memory Map¶
The two DSP cores and two IPU cores are mapped in the am57xx-mitysom-baseboard.dtsi device tree.
This can be modified for example to remove the IPUs and increase the DSPs memory ranges. The resource table
maps the virtual addressing for the processor to the physical address of the CMA regions at load time via the
remoteproc Linux driver. See Customizing Multicore Applications for more details on adjusting the memory sizes.
ipu2_memory_region: ipu2-memory@95800000 {
compatible = "shared-dma-pool";
reg = <0x0 0x95800000 0x0 0x3800000>;
reusable;
status = "okay";
};
dsp1_memory_region: dsp1-memory@99000000 {
compatible = "shared-dma-pool";
reg = <0x0 0x99000000 0x0 0x4000000>;
reusable;
status = "okay";
};
ipu1_memory_region: ipu1-memory@9d000000 {
compatible = "shared-dma-pool";
reg = <0x0 0x9d000000 0x0 0x2000000>;
reusable;
status = "okay";
};
dsp2_memory_region: dsp2-memory@9f000000 {
compatible = "shared-dma-pool";
reg = <0x0 0x9f000000 0x0 0x800000>;
reusable;
status = "okay";
};
DSP Virtual Memory Map¶
The DSP virtual memory maps are defined in rsc_table_vayu_dsp.h header that is part of the RTOS SDK. The default mapping is as follows:
| Section | Virtual Address | Size |
| DSP_MEM_TEXT | 0x95000000 | 0x00100000 |
| DSP_MEM_DATA | 0x95100000 | 0x00100000 |
| DSP_MEM_HEAP | 0x95200000 | 0x00300000 |
To setup a custom resource table, please refer to Customizing Multicore Applications.
The resource table maps the virtual addressing for the processor to the physical address of the CMA regions at load time via the
remoteproc Linux driver.
This can be seen in the default config.bld DSP file.
/* --- External Memory ---
* Virtual Physical Size Comment
* ------------------------------------------------------------------------
* 9500_0000 ????_???? 10_0000 ( ~1 MB) EXT_CODE
* 9510_0000 ????_???? 10_0000 ( 1 MB) EXT_DATA
* 9520_0000 ????_???? 30_0000 ( 3 MB) EXT_HEAP
* 9F00_0000 9F00_0000 6_0000 ( 384 kB) TRACE_BUF
* 9F06_0000 9F06_0000 1_0000 ( 64 kB) EXC_DATA
* 9F07_0000 9F07_0000 7_0000 ( 448 kB) PM_DATA (Power mgmt)
*/
var evmDRA7XX_ExtMemMapDsp = {
EXT_CODE: {
name: "EXT_CODE",
base: 0x95000000,
len: 0x00100000,
space: "code",
access: "RWX"
},
EXT_DATA: {
name: "EXT_DATA",
base: 0x95100000,
len: 0x00100000,
space: "data",
access: "RW"
},
EXT_HEAP: {
name: "EXT_HEAP",
base: 0x95200000,
len: 0x00300000,
space: "data",
access: "RW"
},
TRACE_BUF: {
name: "TRACE_BUF",
base: 0x9F000000,
len: 0x00060000,
space: "data",
access: "RW"
},
EXC_DATA: {
name: "EXC_DATA",
base: 0x9F060000,
len: 0x00010000,
space: "data",
access: "RW"
},
PM_DATA: {
name: "PM_DATA",
base: 0x9F070000,
len: 0x00070000,
space: "data",
access: "RWX" /* should this have execute perm? */
},
};
DSP Stack/Heap Allocation¶
The default DSP configuration allocates 1MB for the Stack and 3MB for the Heap. You can change how much of this is used in the Dsp.cfg file as follows:
// Allocates the stack to be 4KB
Program.stack = 0x1000;
var Memory = xdc.useModule('xdc.runtime.Memory');
var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
var heapMemParams = new HeapMem.Params();
// Allocates the heap to be 32KB
heapMemParams.size = 0x8000;
Memory.defaultHeapInstance = HeapMem.create(heapMemParams);
Additional Background¶
General background on the different places that specify virtual and physical addresses for remote processors like the DSPs. Similar concepts also apply for the IPU processors.
- Device Tree. The "reserved-memory" regions are system-wide and are specified with physical addresses. This is basically telling the kernel what areas of physical memory the Linux kernel needs to set aside and not be available for the Linux processes. The reserved-memory regions cannot overlap and are "reserved" for the different remote processors. The size of a reserved-memory region is the maximum total memory that will be made available to a particular remote processor.
- Technical Reference Manual: The TRM specifies the processor memory map in physical addresses. DDR usually starts at 0x80000000. Below 0x80000000 are regions used for different peripherals and other system functions. When you see addresses below 0x80000000 in the resource table, you can look the addresses up in the TRM to verify what they are being used for. https://www.ti.com/lit/ug/spruhz6l/spruhz6l.pdf
- Processor "config.bld" file. This is a linker file for a specific remote processor program and specifies where different memory areas of a program should be located. The addresses here are virtual addresses. The different areas like text and data will have sizes specified for them in this file. These sizes are the largest these areas can be before the linker starts to give errors. The sum of all the sizes for these regions must be less than or equal to the size of the "reserved-memory" region specified in the device tree. The virtual addresses are pretty much up to you. Both DSP1 and DSP2 can use the same virtual addresses. This might be convenient since if you look at addresses in the debugger, you could look at the address and know if it is text, data, or in the heap.
- Resource table. This is a file containing information used by the remoteproc loader and it combines the virtual addresses used in config.bld and the physical addresses. The resource table tells the loader how to set up the MMU for the remote processor.
- For regions below 0x80000000, the physical and virtual addresses are often the same. This is for convenience. These regions are included to provide the remote processor access to different peripherals
- For regions like text and data, the resource table specifies virtual addresses which must match what is in the config.bld. Areas of memory from config.bld do not specify the physical address since these areas are called a "carveout" and the loader will take a piece of memory from the "reserved-memory" region for the remote processor being loaded. I.e. the loader will figure out what physical address to use.
- For special regions intended for something like cmem buffers, the physical address specified has to match what is in the device-tree. The virtual address can be different but it might be convenient to make it the same.
- In general, the virtual memory map for a remote processor has to have non-overlapping regions.
- Between 2 processors, the virtual memory map could have overlaps. Just like 2 linux processes can use the same virtual memory addresses.
Go to top
