VSDK/VisionSDK UserGuide MemoryMap

Memory Map of Vision SDK by Shiju Sivasankaran, ADAS Software, Processor BU

ABSTRACT

TDA2x and TDA3x series of automotive processor are designed to be used in automotive safety systems. TI Vision SDK is a multi-processor multi-channel software development platform, which enables the easy integration of new vision applications using different heterogeneous CPUs of TI ADAS SoCs. VISION SDK allows different usecases for different platforms and hence a generic memory map might not be sufficient for all users. This document gives insight on different sections of the memory map that a user can change for their usecases. The document discusses about the Vision SDK (VSDK) memory map implementation on TDA2xx, TDA2Ex, TDA2Px and TDA3xx

Introduction

It is expected that the user has gone through the below documentations to understand the hardware and software architecture/partitioning.

Description	Document name
TDAxx SoC architecture	TDAxx SoC Technical Reference Manuel (TRM)
Vision SDK (Links & chain) Framework UserGuides	VisionSDK_SW_Architecture_Details.pdf, VisionSDK_SW_Architecture_Overview.pdf
VSDK Developer guides	VisionSDK_DevelopmentGuide.pdf, VisionSDK_Linux_DevelopmentGuide.pdf

Memory Sections of VISION SDK Memory Map

VISION SDK has multiple memory map configurations supported based on the usage scenarios and available total memory on various platforms. The total system memory is divided into various sub-sections/processors. The broad classification of the sections is listed below:

Shared regions: SRs are different memory partitions that are shared across processors

• SR0: Shared Region 0. This shared region is used to allocate memory for data structures needed for inter processor communication. This shared region is not cached on any of the processor cores.
• SR1_FRAME_BUFFER_MEM: This memory region is used for allocating data buffers for capturing video data, scaling, Alg processing & displaying video frames. Accessible & cached from all cores.
• SR2_MEM: Used only with VSDK Linux reserving memory for CMEM allocations (contiguous memory for Linux)
• SYSTEM_IPC_SHM_MEM: Non-Cached Memory section for keeping IPC link data structures

Log Mem:

• REMOTE_LOG_MEM: Non-Cached Memory section reserved and accessible from all processor cores to dump the debug/profile print messages. Each processor core uses VPS_printf() to dump the status/debug messages on this memory region. Remote Debug Client running on master cores (IPU1-0 for Bios and A15 in case of Linux) reads this memory region and prints the content on the (UART) console.
• LINK_STATS_MEM: Non Cached Memory section reserved and accessible from all processor cores to dump the Link statistics
• TRACE_BUF: Remote proc logs, non-Cached, used only with VSDK Linux

DDR Code/data:

• CODE_MEM: Partition for code section of each core’s executable binary
• DATA_MEM: Partition for data section of each core’s executable binary

Internal memory:

• OCMC_RAM: Internal Memory section accessible from all processor cores
• L2_SRAM: DSP L2 Internal Memory section, only accessible from DSP core

Linux mem:

• Memory partitions given to Linux kernel memory manager

Others:

• HDVPSS_DESC_MEM: Memory section used by BSP/STW. It is used by these drivers for its internal descriptor data structures.

VSDK Memory Map Table

Refer the .xs file under /vision_sdk/<apps>/build/<SoC>/ for the complete memory map configuration,
For example, /vision_sdk/apps/build/tda2xx/mem_segment_definition_bios.xs, defines the memory map for TDA2xx BIOS only with 512MB DDR.
Also refer the generated map files under
/vision_sdk/binaries/<apps>/<tdaxx_evm_bios_all>/vision_sdk/bin/<tdaxx-evm>/, For example, vision_sdk_ipu1_0_release.xem4.map, to know how the Memory sections are arranged

Refer /vision_sdk/links_fw/include/link_api/systemLink_common_if.h for the available Memory Heaps,
Here is a brief list; detailed description is in systemLink_common_if.h file

• SYSTEM_HEAPID_DDR_NON_CACHED_SR0: Heap ID of heap in DDR, This is non-cached memory
• SYSTEM_HEAPID_DDR_CACHED_SR1: Heap ID of heap in DDR, This is cached memory
• SYSTEM_HEAPID_OCMC_SR2: Heap ID of heap in OCMC
• SYSTEM_HEAPID_RESERVED1: Heap ID of heap in DDR, This is cached memory
• SYSTEM_HEAPID_RESERVED2: Heap ID of heap in L2 Memory, Internal memory

Software and Hardware Constraints to Consider For Deciding Memory Map

Hardware Constraints

• AMMU in IPU1/2 handles large memory segments of size 512MB/32MB only and there can be 4 such segments.
• For EVE we have only 32 TLB entries to map the memory, one TLB can map a max of 16MB

Software Constraints

• For VSDK Linux, the first 64MB from 0x8000 0000 is reserved for Linux Kernel
• Frame Buffer Shared Region (SR1) is mapped on A15 Linux. But if user wants Linux side app/links to allocate memory/buffers from any other heap, then user need to mmap the physical address in the application code to map those memory/buffers on A15.

Important things to pay attention to, while porting the map file are:

• DDR, OCMC & DSP/EVE SRAM sizes
• Core specific code/data/vecs sizes
• Size of the shared frame buffer pools

DDR is divided into 2 sections: cached and non-cached.

• The cached part is used mainly for frame buffer (SR1) and core specific code/data sections.
• The non-cached part is used mainly for Vision SDK log buffers, IPC shared data structure (SR0), HDVPSS descriptors etc.

Memory Allocation

This section describes the different methods by which memory is allocated in the Vision SDK framework. The Vision SDK framework also supports static memory allocation.

Memory in Vision SDK framework is allocated for the following purposes

Purpose	Region in memory used for allocation	Type of allocation (Dynamic, Static)
External Buffer memory for storing video, algorithms results and/or HW engine results	SR1_FRAME_BUFFER_MEM	Dynamic (heap based) and/or Static
Internal Buffer memory for storing algorithms results and/or HW engine results	OCMC_RAM	Dynamic (heap based) and/or Static
Notify Shared region – ONLY used during Notify setup (IPC_Start()), not used later	SR0	Dynamic (heap based)
Temporary scratch memory in internal memory for algorithms results	DMEM in EVE or L2SRAM in DSP	Dynamic (non-heap, linear allocation)
Shared memory for remote core print logs	REMOTE_LOG_MEM	Static
Shared memory for link statistics	LINK_STATS_MEM	Static
Shared memory for inter processor communication	SYSTEM_IPC_SHM_MEM	Static
VPDMA descriptor memory for VIP, VPE HW engines	HDVPSS_DESC_MEM	Static
CPU specific memory for BIOS objects like semaphores, tasks, interrupts, clocks	CPU specific data section	Static

The subsequent sections provide more details on each type of memory allocation In the below description,
<soc> = tda2xx, tda2ex, tda3xx, tda2x-entry & TDA2Px
<ddr_size> = 128MB, 256MB, 512MB, 1024MB
<os_type> = Bios, Linux

External Buffer Memory Allocation

Location where memory map is specified

• The memory region used for external buffer memory allocation is specified via the below file

    File: /vision_sdk/<apps>/build/<soc>/mem_segment_definition_<os_type>.xs
      Variable SR1_FRAME_BUFFER_SIZE

• The heap from which memory is allocated is defined in file

    FILE: /vision_sdk/links_fw/src/rtos/utils_common/src/utils_mem_ipu1_0.c
      #pragma DATA_SECTION(gUtils_memHeapDDR, ".bss:heapMemDDR")
    This heap is placed in “SR1_FRAME_BUFFER” section via the IPU1-0 cfg file
    FILE: /vision_sdk/links_fw/src/rtos/bios_app_common/<soc>/ipu1_0/Ipu1_0.cfg
      Program.sectMap[".bss:heapMemDDR"]   = "SR1_FRAME_BUFFER_MEM";

• The heap is defined only on IPU1-0 CPU; all other CPUs sends message to IPU1-0 to allocate memory. This is done internally inside the Utils_memAlloc APIs.

API to allocate and free memory

• Below APIs are used to allocate and free memory

    FILE: /vision_sdk/links_fw/src/rtos/utils_common/include/utils_mem.h
    API:
      Utils_memAlloc() with heapId as SYSTEM_HEAPID_DDR_CACHED_SR1
      Utils_memFree() with heapId as SYSTEM_HEAPID_DDR_CACHED_SR1
      Utils_memGetHeapStats() with heapId as SYSTEM_HEAPID_DDR_CACHED_SR1

• Other APIs from this file are not recommended to be used by users and are used internally by the framework

Using static memory allocation

• When a system wants to use static memory allocation and avoid the heap, it should set the size of this heap segment as 0 by modifying the #define in utils_mem_cfg.h file
• Define static memory objects (arrays, data structures) in IPU1-0 use-case file. Make sure the objects are placed in data section “.bss:heapMemDDR" via #pragma
• The links which support static memory allocation allow passing of memory region pointers from use-case file via System_LinkMemAllocInfo data structure
• When creating a link from a use-case, user should now pass memory pointer allocated statically from use-case file. This prevents the link for allocating memory internally. Thus dynamic memory allocation is avoided

      See capture link “captureLink.h” for example
      See use-case “/vision_sdk/apps/src/rtos/usecases/vip_single_cam_view” for sample usage of passing user memory pointer to a link
      NOTE: In the use-case the memory allocation is still done using Utils_memAlloc APIs. In a fully static memory system, this API won’t be used by the user.

• The links assert if the memory segment size passed to it is smaller than what is needed. In this case, it also reports the size required by the link.
• When creating user specific AlgPlugins same mechanism should be used, i.e algorithm plugin should take memory pointer passed from use-case file rather than allocating memory internally. See “Capture” link for example

Internal Buffer Memory Allocation

Location where memory is specified

• The memory region used for buffer memory allocation is specified via the below file

    File: /vision_sdk/<apps>/build/<soc>/mem_segment_definition_<os_type>.xs
      Variable OCMC1_SIZE

• The heap from which memory is allocated is defined in file

    FILE: /vision_sdk/links_fw/src/rtos /utils_common/src/utils_mem_ipu1_0.c
      #pragma DATA_SECTION(gUtils_memHeapOCMC, ".bss:heapMemOCMC")
    FILE: /vision_sdk/links_fw/src/rtos /utils_common/include/utils_mem_cfg.h
      #define UTILS_MEM_HEAP_OCMC_SIZE
    This heap is placed in “OCMC” section via the IPU1-0 cfg file
    FILE: /vision_sdk/links_fw/src/rtos/bios_app_common/<soc>/ipu1_0/Ipu1_0.cfg
      Program.sectMap[".bss:heapMemOCMC"]     = "OCMC_RAM";

• The heap is defined only on IPU1-0 CPU; all other CPUs send a command to IPU1-0 to allocate memory. This is done internally inside the Utils_memAlloc APIs.

API to allocate and free memory

• Below APIs are used to allocate and free memory

    FILE: /vision_sdk/links_fw/src/rtos/utils_common/include/utils_mem.h
    API:
      Utils_memAlloc() with heapId as SYSTEM_HEAPID_OCMC_SR2
      Utils_memFree() with heapId as SYSTEM_HEAPID_OCMC_SR2
      Utils_memGetHeapStats() with heapId as SYSTEM_HEAPID_OCMC_SR2

• Other APIs from this file are not recommended to be used by users and are used internally by the framework

Static Memory Sections Allocation

• The memory region used for these sections are specified via the below file

    File: /vision_sdk/<apps>/build/<soc>/mem_segment_definition_<os_type>.xs
      Variable “REMOTE_LOG_SIZE” for Remote Log memory
      Variable “SYSTEM_IPC_SHM_SIZE” for inter-processor communication
      Variable “LINK_STATS_SIZE” for Link Statistics
      Variable “HDVPSS_DESC_SIZE” for VPDMA descriptors

Memory Map of the Application

Memory map of the entire usecase is governed by following artifacts.
DDR_MEM variable in /vision_sdk/apps/configs/tdaxxx_evm_<OS>_all/cfg.mk

List of VSDK files need to be reviewed & modified

1. /vision_sdk/apps/build/tdaxxx/mem_segment_definition_<OS>.xs
2. /vision_sdk/links_fw/rtos/src/utils_common/include/utils_mem_cfg.h
3. /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxx/ipu1_0/ Ammu1.cfg or Ammu1_linux.cfg (if you modify the IPU1 memory map)
4. /vision_sdk/links_fw/src/rtos/ bios_app_common/tdaxx/ipu2/ Ammu2.cfg or Ammu2_linux.cfg (if you modify the IPU2 memory map)
5. /vision_sdk/links_fw/src/rtos/links_ipu/system/system_bsp_init.c (vpsInitPrms.virtBaseAddr & vpsInitPrms.physBaseAddr translation)
6. /vision_sdk/links_fw/include/link_api/system_vring_config.h (only for Linux/HLOS build)
7. /vision_sdk/links_fw/src/hlos/osa/include/osa_mem_map.h (Generated file, only for Linux/HLOS build)
8. /vision_sdk/links_fw/src/rtos /links_common/system/system_rsc_table_ipu.h (only for Linux/HLOS build, if resource table modification required)
9. /vision_sdk/links_fw/src/rtos /links_common/system/system_rsc_table_dsp.h (only for Linux/HLOS build, if resource table modification required)
10. /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/<ipu2 or ipu1>/gen_system_mem_map.xs (only for Linux/HLOS build, This file auto generates a .h file using XDC varaiables defined in mem_segment_definition_<OS>.xs

List of Linux Kernel files need to be modified

1. /ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra7-evm-infoadas.dts (For TDA2x)
2. /ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra72-evm-infoadas.dts (For TDA2Ex)
3. /ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra76-evm-infoadas.dts (For TDA2Px)

• DDR_MEM is an environment variable that tells build system which .xs is to be picked up for the final executable.
• The .xs file overrides default implementation for the platform defined by xdc.runtime. This file can be modified to increase/decrease size of a section or add/remove sections from the memory map. For Linux/HLOS, Linux enables L2MMU for each core, so all the addresses mentioned in the .xs file are slave virtual addresses.
• The .dts file is used to reserve memory from Linux, this is a platform specific file. This ensures Linux and bios side don’t overwrite into each other. Typically the bios side needs some memory sections and rest all can be given to Linux. Essentially this creates a few holes in Linux memory that is later mapped to user space at the application startup time.

Adding a new Section to Memory map

While adding a new section in the memory map of ipu/dsp/eve/A15, following things needs to be taken care of: A

1. dd a new section in appropriate .xs file by defining NEW_SECTION_SIZE, NEW_SECTION_ADDR & NEW_SECTION_MEM (just follow the convention used in .xs file)
2. Its advised to remove or reduce some unwanted sections to free-up the memory required for the new section
3. Make sure the total memory should not exceeds the total available physical memory
4. Make sure the new section doesn’t overlap with any other sections.
5. If you add any new memory section and, the data/code corresponding to that can be placed into the section by adding Program.sectMap in the appropriate /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/<cpu>/<cpu>.cfg file.
6. In case of Linux, it should lie within the hole of memory declared in .dts file in kernel using /memreserve
7. If needed, /memreserve can be used to increase the size of the hole accommodate new section’s memory requirement.
8. If this newly added section has to be mapped into L2MMU of ipu/dsp by Linux and hence it needs to be added in the resource table i.e. in system_rsc_table_ipu.h or system_rsc_table_dsp.h accordingly.
9. If this section is going to be accessed from Linux user space or kernel space, this mapping needs to be taken care by the application or through OSA_mem module in vision_sdk
10. If you are changing base addresses and sizes for IPU’s, DSP’s carve-out sections (code/data) and if you plan to change CMA address in linux kernel (.dts) please ensure you also make this changes to /vision_sdk/links_fw/include/link_api/system_vring_config.h.
11. Refer section “6.4: How To – Modify Linux/Bios VSDK Memory Map” for more details

Changing size of a Section in the Memory map

While changing the size of the section in the memory map from ipu/dsp/eve/A15, following things needs to be taken care of:

1. Do changes in respective .xs file for the section sizes
2. Its advised to reduce some unwanted sections to free-up the memory required for new size (increase)
3. Make sure the total memory should not exceeds the total available physical memory
4. Make sure the new section doesn’t overlap with any other sections.
5. In case of Linux, it should lie within the hole of memory declared in .dts file in kernel using /memreserve
6. If needed, /memreserve can be used to increase the size of the hole accommodate new section’s memory requirement.
7. As you are modifying existing section, no need to change resource table mappings, the updated value will be picked up in resource table in the build process.
8. If you are changing base addresses and sizes for IPU’s, DSP’s carve-out sections (code/data) and if you plan to change CMA address in linux kernel (.dts) please ensure you also make this changes to /vision_sdk/links_fw/include/link_api/system_vring_config.h.
9. Refer section “6.4: How To – Modify Linux/Bios VSDK Memory Map” for more details

How To - Add a new Memory map

In general, if you are planning to have your own memory map for the application, you can follow these steps

• Evaluate memory requirements of the sections e.g. (Is 256 MB SR1 sufficient or you need more or less?)
• Add appropriate .xs file under $INSTALL_DIR/vision_sdk/apps/build/tdaxxx/, for example mem_segment_definition_bios.xs
• Modify DDR_MEM_XXXX, for example DDR_MEM_512M variable in /vision_sdk/apps/configs/tdaxxx_evm_<OS>_all/cfg.mk
• Modify appropriate platform ISI build files to pick the correct memory map (.xs) file, for example, refer below files for TDA2x,

1. /vision_sdk/build/rtos/tda2xx/config_arp32.bld
2. /vision_sdk/build/rtos/tda2xx/config_c66.bld
3. /vision_sdk/build/rtos/tda2xx/config_m4.bld
4. /vision_sdk/build/rtos/tda2xx/config_a15.bld

• Now follow the section “6.4: How To – Modify Linux/Bios VSDK Memory Map” for more details and how to modify all necessary VSDK and Linux kernel files

How To – Modify Linux/Bios VSDK Memory Map

The memory map of complete VISION SDK is controlled in
/vision_sdk/build/rtos/tdaxxx/config_<ISI>.bld

The mem_segment_definition (for example - mem_segment_definition_linux.xs) file is included in this build configuration file, size of each sections are reconfigured in .xs file. For example, DSP code size and DSP data size section can be changed by modifying the following entries.

   DSP1_CODE_SIZE              = 3*MB;
   DSP1_DATA_SIZE              = 13*MB;

The base addresses of each section are incremented based on the base address of previous section and the size of the previous section. For example, if sections are created in the numerical order, base address of Section 2 is calculated as below:
<Start Addr of Sect 2> = <Start Addr of Sec 1> + <Size of Sect 1>

VSDK need one cached and one non-cached memory segments in the memory map (.xs) file.
Cached segment: You can place any memory sections in this segment except the ones listed under Non-cached segments

Non-cached segments: Below sections must be placed under non-cached segments

   SR0_ADDR   
   REMOTE_LOG_ADDR    
   LINK_STATS_ADDR        
   SYSTEM_IPC_SHM_ADDR 
   HDVPSS_DESC_ADDR         
   OPENVX_SHM_ADDR         

Below Sections are used only for A15 Linux memory map

   TRACE_BUF_BASE   
   EXC_DATA_BASE    
   PM_DATA_BASE  

To modify the memory map, user needs to consider the following:

• Refer to the hardware limitations and software limitations in section 4:

1. We assume a one-to-one mapping of AMMU virtual address to physical address.

• The other sections like “Remote Debug”, “HDVPSS Shared Memory” etc. are read directly from the build configuration file
• Changes in the Linux memory size in build configuration file has to be reflected in the boot arguments of the Linux kernel using “mem=<SIZE>M” entry.
• Consider the overall buffer requirement for the specific usecase before modifying the Frame Buffer or Meta data buffer or BitsBuffer section sizes.

The current default memory maps of VSDK (as per 3.0 releases) as below

1. TDA2xx Bios – 512 MB
2. TDA2xx Linux – 1024 MB
3. TDA2Ex Bios – 512 MB
4. TDA2Ex Linux – 1024 MB
5. TDA3xx Bios – 512 MB
6. TDA3xx Bios – 128 MB
7. TDA2Px Bios – 512 MB
8. TDA2Px Linux – 1024 MB

Cache and MMU configurations

List of VSDK files sets the Cache and MMU configurations
<1> DSP
DSP L1 & L2 Cache configuration is in /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/cfg/DSP_common.cfg,
Below the default cache size setting for L1P, L1D and L2 as 32K

   var Cache = xdc.useModule('ti.sysbios.family.c66.Cache');
   Cache.initSize.l1pSize = Cache.L1Size_32K;
   Cache.initSize.l1dSize = Cache.L1Size_32K;
   Cache.initSize.l2Size  = Cache.L2Size_32K;

Cache ON/OFF setting of DSP also in /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/cfg/DSP_common.cfg

   /* Set cache sections */
   /* configure MARs, by default cache is enabled for the entire memory region */
   for (var i = 0; i < Program.cpu.memoryMap.length; i++)
   {
     memSegment = Program.cpu.memoryMap[i];
     Cache.setMarMeta(memSegment.base, memSegment.len, Cache.Mar_ENABLE);
   }

   /* set non-cached sections */
   for (var i = 0; i < Program.cpu.memoryMap.length; i++)
   {
     memSegment = Program.cpu.memoryMap[i];
     if ((memSegment.name == "SR0") ||
         (memSegment.name == "REMOTE_LOG_MEM") ||
         (memSegment.name == "LINK_STATS_MEM") ||
         (memSegment.name == "SYSTEM_IPC_SHM_MEM") ||
         (memSegment.name == "OPENVX_SHM_MEM"))
     {
       Cache.setMarMeta(memSegment.base, memSegment.len, Cache.Mar_DISABLE);
     }
   }

If you plan to add any new non-cached DSP section, then add the same section in above code snippet in DSP_common.cfg.

<2> IPU
Refer below files which set the AMMU of IPU to configure MMU and Cache settings

1. /vision_sdk/links_fw/src/rtos/bios_app_common/tdaXxx/ipu1_0/Ammu1_bios.cfg or Ammu1_linux.cfg
2. /vision_sdk/links_fw/src/rtos/bios_app_common /tdaXxx/ipu2/Ammu2_bios.cfg or Ammu2_linux.cfg

• Map program code/data & other cached memory into ammu (cacheable) by AMMU.largePages[1]
• Map SR_0 & other non-cached data memory into ammu (non-cacheable) by AMMU.largePages[2]

Note: Only for TDA3x, IPU1 AMMU setting is done in SBL.
Refer /vision_sdk/links_fw/src/rtos/bios_app_common/tda3xx/ipu1_0/Ammu1_bios.cfg,

   AMMU.configureAmmu = false;

If configureAmmu is set to false, then AMMU setting is done in SBL.

<3> EVE
Refer /vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/eve_common/tlb_config_eve_common.c for EVE memory mapping by programming the TLB registers, each TLB can map a max of 16MB contiguous region and 16MB aligned.
No changes required in this file as it has been taken care automatically.

<4> A15 (Bios)
If A15 running Bios, then /vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/a15_0/ a15_0.cfg does the MMU & cache configurations,

   Mmu.setSecondLevelDescMeta();

Modify default Memory maps of VSDK

Please revisit & modify the list of below files (as required)

List of VSDK files

<1>

/vision_sdk/apps/build/tdaxxx/mem_segment_definition_<OS>.xs.
A single file that configures the entire memory map of all cores in the SoC, and the major file to be modified if you want to make changes in VSDK memory map. This file defines all the memory sections for IPU, DSP, EVE, A15 and other heaps such as SR1, SR0 etc. Below a sample section,

 DSP1_START_ADDR           = 0x99000000;
 DSP1_CODE_SIZE              = 2*MB;
 DSP1_DATA_SIZE              = 24*MB;
 ………………………………………………………….
 ………………………………………………………….
 DSP1_CODE_ADDR              = DSP1_START_ADDR;
 DSP1_DATA_ADDR              = DSP1_CODE_ADDR        + DSP1_CODE_SIZE;
 ………………………………………………………….
 ………………………………………………………….

 function getMemSegmentDefinition_external(core)
 {
   memory[index++] = ["DSP1_CODE_MEM", {
   comment : "DSP1_CODE_MEM",
   name    : "DSP1_CODE_MEM",
   base    : DSP1_CODE_ADDR,
   len     : DSP1_CODE_SIZE
   }];
   ………………………………………………………….
   ………………………………………………………….
 }

If you add any new memory section and, the data/code corresponding to that can be placed into the section by adding Program.sectMap[] in the appropriate /vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/<cpu>/<cpu>.cfg file.
For example, /vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/dsp1/Dsp1.cfg is the file for DSP1 of TDA2x, and below code place “bss:extMemNonCache:ipcShm” into the memory section “SYSTEM_IPC_SHM_MEM”

 Program.sectMap[".bss:extMemNonCache:ipcShm"] = "SYSTEM_IPC_SHM_MEM";
 Program.sectMap[".bss:extMemNonCache:linkStats"] = "LINK_STATS_MEM";

Same apply for all cores like IPU1-0, IPU1-1, IPU2, A15, DSP1-2 and EVE1-4 of TDA2x, TDA2Px, TDA2Ex and TDA3x.

The .xs file to look at depends on SoC, A15 OS and DDR memory config selected; here is a list of default memory map of VSDK 3.1.0.0

Header text	A15 OS	DDR config	.xs file
TDA2XX_BUILD	Bios	TDA2XX_512MB_DDR	vision_sdk/apps/build/tda2xx/mem_segment_definition_bios.xs
TDA2XX_BUILD	Linux	TDA2XX_1024MB_DDR	vision_sdk/ apps/build/tda2xx/mem_segment_definition_linux.xs
TDA3XX_BUILD	NA	TDA3XX_128MB_DDR	vision_sdk/ apps/build/tda3xx/mem_segment_definition_128mb.xs
TDA3XX_BUILD	NA	TDA3XX_512MB_DDR	vision_sdk/ apps/build/tda3xx/mem_segment_definition_512mb.xs
TDA2EX_BUILD	Bios	TDA2EX_512MB_DDR	vision_sdk/ apps/build/tda2ex/mem_segment_definition_bios.xs
TDA2EX_BUILD	Linux	TDA2EX_1024MB_DDR	vision_sdk/ apps/build/tda2ex/mem_segment_definition_linux.xs
TDA2PX_BUILD	Bios	TDA2PX_512MB_DDR	vision_sdk/apps/build/tda2px/mem_segment_definition_bios.xs
TDA2PX_BUILD	Linux	TDA2PX_1024MB_DDR	vision_sdk/ apps/build/tda2px/mem_segment_definition_linux.xs

Modify “start address”, “size” or even add/remove a memory section to change the memory map as per your requirement.

<2>
/vision_sdk/links_fw/src/rtos/utils_common/include/utils_mem_cfg.h
This file defines the size of major internal memory heaps, and these sizes need to be in sync with above .xs file. The memory allocation utility/API refers this file for the heap size. Any modification of these heap size to be updated in both utils_mem_cfg.h & mem_segment_definition_<OS>.xs file.

 #define UTILS_MEM_HEAP_L2_SIZE  (224*1024) – DSP internal memory (SRAM)
 #define UTILS_MEM_HEAP_L2_SIZE  (24*1024) - EVE internal memory (SRAM)
 #define UTILS_MEM_HEAP_OCMC_SIZE        (512*1024) – Shared OCMC internal memory
 #define UTILS_MEM_HEAP_DDR_CACHED_SIZE      (256*1024*1024) – Shared cached DDR heap memory.

<3>
/vision_sdk/links_fw/src/rtos/links_ipu/system/system_bsp_init.c (vpsInitPrms.virtBaseAddr & vpsInitPrms.physBaseAddr translation)

    /* This one to one mapping is required for the 1GB builds */
    vpsInitPrms.virtBaseAddr = 0x80000000U;
    vpsInitPrms.physBaseAddr = 0x80000000U;
    /* if Virtual address != Physical address then enable translation */
    vpsInitPrms.isAddrTransReq = FALSE;

    /* This one to one mapping is required for the 512MB builds */
    vpsInitPrms.virtBaseAddr = 0xA0000000U;
    vpsInitPrms.physBaseAddr = 0x80000000U;
    /* if Virtual address != Physical address then enable translation */
    vpsInitPrms.isAddrTransReq = TRUE;

<4>
/vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/ipu1_0/Ammu1_bios.cfg or Ammu1_linux.cfg (if you modify the IPU1 memory map)
/vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/ipu2/Ammu2_bios.cfg or Ammu2_linux.cfg (if you modify the IPU2 memory map)
This file set IPU subsystem (core 0 and core 1) AMMU and Cache configurations. IPU can access only the memory sections mapped via AMMU. A sinle AMMU sets the memory map of both cores (core 0 & core 1) of an IPU subsystem.

 function init()
 {
   ………………………………………………………….
   ………………………………………………………….
   Map program code/data & other cached memory into ammu (cacheable) by AMMU.largePages[1]
   Map SR_0 & other non-cached data memory into ammu (non-cacheable) by AMMU.largePages[2]
   ………………………………………………………….
   ………………………………………………………….
 }

<5>
/vision_sdk/links_fw/src/rtos/bios_app_common/tda2xx/eve_common/tlb_config_eve_common.c (if you modify any EVE1-4 memory map)
This file implements common MMU configuration for all EVE as per Vision SDK requirements
There are only 32 TLB entries in EVE, Each TBL entry can maps a max of 16MB, and need 16MB alignment,
No changes required in this file as it has been taken care automatically.

<6>
/vision_sdk/links_fw/include/link_api/system_vring_config.h (used only in A15 Linux Build)
Vring virtual addresses (For Start address) of IPU & DSP are used by IPC, if it is changed in .XS file, same need to be updated in this system_vring_config.h also.

 #ifdef BUILD_M4_0
   #define IPU_PHYS_MEM_IPC_VRING      0x9e000000	
 #endif
 #ifdef BUILD_DSP_1
   #define DSP_PHYS_MEM_IPC_VRING      0xa1000000
 #endif
 #ifdef BUILD_DSP_2
   #define DSP_PHYS_MEM_IPC_VRING      0xa3000000
 #endif 
 #ifdef BUILD_M4_2
   #define IPU_PHYS_MEM_IPC_VRING      0x99000000
 #endif

<7>
/vision_sdk/links_fw/src/hlos/osa/include/osa_mem_map.h (Build time generated file, used only in A15 Linux Build)
This is an auto generated file from [gen_system_mem_map.xs], please check and confirm the entries in osa_mem_map.h is matching with .XS file or the MAP file

 #define SR0_ADDR    0xa0100000
 #define SR0_SIZE    0x100000
 #define SYSTEM_IPC_SHM_MEM_ADDR    0xa02c0000
 #define SYSTEM_IPC_SHM_MEM_SIZE    0x80000
 #define REMOTE_LOG_MEM_ADDR       0xa0200000
 #define REMOTE_LOG_MEM_SIZE       0x40000
 #define SR1_FRAME_BUFFER_MEM_ADDR 0x84203000
 #define SR1_FRAME_BUFFER_MEM_SIZE 0xfa00000
 #define SR2_FRAME_BUFFER_MEM_ADDR 0xa9000000
 #define SR2_FRAME_BUFFER_MEM_SIZE 0x4000000
 #define OPENVX_OBJ_DESC_MEM_ADDR 0xa0440000
 #define OPENVX_OBJ_DESC_MEM_SIZE 0x200000

<8>
If a newly added section has to be mapped into L2MMU of ipu/dsp by Linux and hence it needs to be added in the resource table i.e. in system_rsc_table_ipu.h or system_rsc_table_dsp.h accordingly.
/vision_sdk/links_fw/src/rtos/links_common/system/system_rsc_table_ipu.h (modify if required, used only in A15 Linux Build )

 struct my_resource_table {…}
 struct my_resource_table ti_ipc_remoteproc_ResourceTable = {…}

system_rsc_table_ipu.h define the resource table entries for all IPU cores. This will be incorporated into corresponding base images, and used by the remoteproc on the host-side to allocated/reserve resources.
/vision_sdk/links_fw/src/rtos/links_common/system/system_rsc_table_dsp.h (modify if required, used only in A15 Linux Build)

 struct my_resource_table {…}
 struct my_resource_table ti_ipc_remoteproc_ResourceTable = {…}

system_rsc_table_dsp.h define the resource table entries for all DSP cores. This will be incorporated into corresponding base images, and used by the remoteproc on the host-side to allocated/reserve resources.

<9>
/vision_sdk/links_fw/src/rtos/bios_app_common/tdaxxx/<ipu2 or ipu1>/gen_system_mem_map.xs (only for Linux/HLOS build, This file auto generates a .h file using XDC varaiables defined in mem_segment_definition_<OS>.xs
Change this file only when you want to create a 512MB or <512MB Linux memory map

List of Linux Kernel files

<1>
/ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra7-evm-infoadas.dts (for TDA2x only)
Modify the start address of IPU1, IPU2, DSP1, DSP2 or CMEM, if any of this is changed in the memory map,

 /* Update the CMA regions for Vision SDK binaries */
 &ipu2_cma_pool {
    reg = <0x0 0x99000000 0x0 0x5000000>;
 };
 &dsp1_cma_pool {
    reg = <0x0 0xa1000000 0x0 0x2000000>;
 };
 &ipu1_cma_pool {
    reg = <0x0 0x9e000000 0x0 0x2000000>;
 };
 &dsp2_cma_pool {
    reg = <0x0 0xa3000000 0x0 0x2000000>;
 };

This file reserves the memory for SR1, SR0, CMEM and EVE data/code memory sections and the size. Additional memory regions required for Vision SDK Keep this in sync with VSDK apps/build/tda2xx/mem_segment_definition_linux.xs

 &reserved_mem {
   cmem_ocmc: cmem@40300000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x40300000 0x0 0x300000>;
     sram = <&ocmcram1>;
     no-map;
     status = "okay";
   };
   cmem_pool: cmem@A9000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA9000000 0x0 0x4000000>;
     no-map;
     status = "okay";
   };
   vsdk_sr1_mem: vsdk_sr1_mem@84000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x84000000 0x0 0x10000000>;
     status = "okay";
   };
   vsdk_sr0_mem: vsdk_sr0_mem@A0000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA0000000 0x0 0x1000000>;
     status = "okay";
   };
   vsdk_eve_mem: vsdk_eve_mem@A5000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA5000000 0x0 0x4000000>;
     status = "okay";
   };
 };

<2>
/ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra72-evm-infoadas.dts (for TDA2Ex only)
Modify the start address of IPU1, IPU2, DSP1 or CMEM, if any of this is changed in the memory map,

 /* Update the CMA regions for Vision SDK binaries */
 &ipu2_cma_pool {
   reg = <0x0 0x99000000 0x0 0x5000000>;
 };
 &dsp1_cma_pool {
   reg = <0x0 0xa1000000 0x0 0x2000000>;
 };
 &ipu1_cma_pool {
   reg = <0x0 0x9e000000 0x0 0x2000000>;
 };

This file reserves the memory for SR1, SR0 and CMEM sections and the size. Additional memory regions required for Vision SDK Keep this in sync with VSDK apps/build/tda2Ex/mem_segment_definition_linux.xs

 &reserved_mem {
   cmem_ocmc: cmem@40300000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x40300000 0x0 0x300000>;
     sram = <&ocmcram1>;
     no-map;
     status = "okay";
   };
   cmem_pool: cmem@A9000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA9000000 0x0 0x4000000>;
     no-map;
     status = "okay";
   };
   vsdk_sr1_mem: vsdk_sr1_mem@84000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x84000000 0x0 0x10000000>;
     status = "okay";
   };
   vsdk_sr0_mem: vsdk_sr0_mem@A0000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA0000000 0x0 0x1000000>;
     status = "okay";
   };
 };

<3>
/ti_components/os_tools/kernel/omap/arch/arm/boot/dts/dra76-evm-infoadas.dts (for TDA2Px only)
Modify the start address of IPU1, IPU2, DSP1, DSP2 or CMEM, if any of this is changed in the memory map,

 /* Update the CMA regions for Vision SDK binaries */
 &ipu2_cma_pool {
   reg = <0x0 0x99000000 0x0 0x5000000>;
 };
 &dsp1_cma_pool {
   reg = <0x0 0xa1000000 0x0 0x2000000>;
 };
 &ipu1_cma_pool {
   reg = <0x0 0x9e000000 0x0 0x2000000>;
 };
 &dsp2_cma_pool {
   reg = <0x0 0xa3000000 0x0 0x2000000>;
 };

This file reserves the memory for SR1, SR0, CMEM and EVE data/code memory sections and the size. Additional memory regions required for Vision SDK Keep this in sync with VSDK apps/build/tda2Px/mem_segment_definition_linux.xs

 &reserved_mem {
   cmem_ocmc: cmem@40300000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x40300000 0x0 0x300000>;
     sram = <&ocmcram1>;
     no-map;
     status = "okay";
   };
   cmem_pool: cmem@A9000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA9000000 0x0 0x4000000>;
     no-map;
     status = "okay";
   };
   vsdk_sr1_mem: vsdk_sr1_mem@84000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0x84000000 0x0 0x10000000>;
     status = "okay";
   };
   vsdk_sr0_mem: vsdk_sr0_mem@A0000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA0000000 0x0 0x1000000>;
     status = "okay";
   };
   vsdk_eve_mem: vsdk_eve_mem@A5000000 {
     compatible = "shared-dma-pool";
     reg = <0x0 0xA5000000 0x0 0x4000000>;
     status = "okay";
   };
 };

Clean and Rebuild Kernel & VSDK.
Note1: If SR1 or IPU1-2 memory needs to be increased to very high value, then Move DSP1-2 or EVE1-4 out of 0xA000 0000 address space. This will avoid the need of any IPU AMMU reconfiguration.
Note2: To build SBL, Build appropriate secondary boot loader as per your memory configuration. Refer file /vision_sdk/build/rtos/makerules/build_sbl.mk for all valid configurations. For examples, EMIFMODE = DUAL_EMIF_1GB_512MB (default) or DUAL_EMIF_2X512MB or SINGLE_EMIF_256MB
Note3: In case of A15 Linux, You also need to change DMM configuration in Uboot to set the DDR configuration, i.e., the EMIF and LISA map configuration as per custom board or memory map.

How To – Modify 512MB Bios Memory map to 1GB Bios Memory map

Sample patch - Assume TDA2xx build

Subject: [PATCH] 1GB Bios memory map for TDA2x

• All default cores enabled
• DSP and EVE moved to the second 512MB

File:0001-1GB-Bios-memory-map-for-TDA2x.patch

1GB Bios memory map for TDA2x

list of files modified in this patch

apps/build/tda2xx/mem_segment_definition_bios.xs   | 53 ++++++++++++----------
build/rtos/makerules/build_sbl.mk                  |  2 +-
.../rtos/bios_app_common/tda2xx/a15_0/a15_0.cfg    |  2 +-
.../bios_app_common/tda2xx/ipu1_0/Ammu1_bios.cfg   |  6 +--
.../bios_app_common/tda2xx/ipu2/Ammu2_bios.cfg     |  6 +--
.../src/rtos/links_ipu/system/system_bsp_init.c    |  4 +-

--

How To - Modify 1GB Linux Memory map to 512MB Linux Memory map

Sample patch - Assume TDA2xx build
You need below 2 patches on top of VSDK3.1

1. VSDK patch : 0001-Do-not-merge-512MB-map-for-VSDK-Linux.patch
2. Linux Kernel patch : 0001-Do-not-merge-Kernel-patch-512MB-map-for-VSDK-Linux.patch

Sample patch for TDA2xx VSDK files modification

Subject: [PATCH] [vsdk.30] - TDA2x 512MB linux build

• VSDK changes to make TDA2x 512MB linux build
• All EVE cores and IPU1 are disabled

File:0001-Do-not-merge-512MB-map-for-VSDK-Linux.patch

VSDK patch for VSDK Linux 512MB memory map on TDA2x

list of files modified in this patch

apps/build/tda2xx/mem_segment_definition_linux.xs  | 70 ++++++++++++----------
apps/configs/tda2xx_evm_linux_all/cfg.mk           | 10 ++--
build/Rules.make                                   |  2 +-
links_fw/include/link_api/system_vring_config.h    | 16 ++---
links_fw/src/hlos/osa/include/osa_mem_map.h        | 15 ++---
.../tda2xx/ipu2/gen_system_mem_map.xs              |  6 +-
.../links_common/system/system_rsc_table_ipu.h     | 24 ++++++--
.../src/rtos/links_ipu/system/system_bsp_init.c    |  4 +-

--

Sample patch for TDA2xx Linux Kernel modification

Subject: [PATCH] Linux kernel- TDA2x 512MB VSDK build

• Changes in DRA7x infoAdas dts for 512MB VSDK linux build

File:0001-Do-not-merge-Kernel-patch-512MB-map-for-VSDK-Linux.patch

Linux Kernel patch for VSDK Linux 512MB memory map on TDA2x

list of files modified in this patch

arch/arm/boot/dts/dra7-evm-infoadas.dts | 22 +++++++++++-----------

--

Revision History

Version #	date	Author	Revision History
0.1	26/12/2016	Shiju S	First draft
0.2	28/6/2017	Shiju S	Updated for VSDK3.0
0.3	16/10/2017	Shiju S	Updated for VSDK3.1