TDA4VM: How to boot OS from high memory space to make the best use of 32-bit low memory space?

Dear Sijie,

     1. You need to put kernel in low 32bit code otherwise you need to modify quite a large part of the kernel code. 

     2. Have you put C7X in high 32bit address yet? You can move C7X to high address to gain more address for R5 and C6x.

     3. Could you explain why you need more address for R5 and C6X? Usually the default allocation should be enough.

BR

Sikai

Hello Sikai,

1. A large part of kernel code for Linux or QNX? Is it possible to reserve like ~128MB for QNX kernel in low 32bit? Cuz it is taking 512MB which is a lot.

2. Not yet, since we need another 512MB while C7 is taking 128 or 256MB in low memory space, which is not enough.

3. Our new product is gonna use 6*200MP camera. And our customer is asking for the possibility to expand DDR_SHARED_MEM to 1GB.

Regards,

Sijie Zhu

Dear Sijie,

     Once you changed the address to high 32-bit, here are several issues you need to think of:

     1. You need to change the load address of Linux&DTB.

     2. You need to change all the firmwares' resource table and OPTEE.

     3. Since R5F cannot access high 32-bit address directly. Once you changed A72 to high 32-bit address, you need to add RAT module between all communications between R5F and A72.

     As a result, I believe it would be quite a lot of work to do.

Dear Suman,

     Please help review my answer and feel free to correct me, thanks.

BR

Sikai

Hi Sijie,

The remote processor firmware memory maps already start from 0xA0000000 today, and the Vision Apps firmware memory is already using all the remaining 32-bit address space (1 GB  + 448 MB) as you noticed. So, this is already 1 GB. 

You are only changing the base address of the memory-map, without increasing any memory-size (I do not see where you are trying to increase the 512 MB to 1 GB change).

Outside of the RTOS DDR memory-map dtsi changes, you would have to adjust a whole lot of U-Boot and OPTEE locations in order to run the U-Boot and the loading addresses in U-Boot of various firmwares. 

Your above change is trying to relocate the memory-maps differently without any added advantage. 

Sikai,

Sikai Lu said:

   3. Since R5F cannot access high 32-bit address directly. Once you changed A72 to high 32-bit address, you need to add RAT module between all communications between R5F and A72.

You are correct on all other points. This is not needed though. Sijie's comment is about using the lower 32-bit addresses for firmwares. The IPC region already falls into this, and so RAT configuration is not required on the firmware side.

There is no support for loading firmwares that use RAT, so all R5F and C66x firmwares need to be in the 32-bit address space.

regards

Suman

Dear Suman,

     Thanks for your comment. Could you help share an example of exactly changing the memory size? 

Suman Anna said:

without increasing any memory-size (I do not see where you are trying to increase the 512 MB to 1 GB change).

BR

Sikai

Sikai,

I want couple of clarifications:

• Finally which OS needs to be booted?
• What is the address that the OS needs to be loaded to?
• What is the total RAM size?

Best Regards,
Keerthy

Dear Suman,

     I think there is some misunderstand here, customer wants to use the memory from 0x80000000 - 0xA0000000 rather than the remaining space.

Suman Anna said:

The remote processor firmware memory maps already start from 0xA0000000 today, and the Vision Apps firmware memory is already using all the remaining 32-bit address space (1 GB  + 448 MB) as you noticed. So, this is already 1 GB. 

    Sijie will update his diff file, could you help check if he modified correctly? Thanks.

Suman Anna said:

Outside of the RTOS DDR memory-map dtsi changes, you would have to adjust a whole lot of U-Boot and OPTEE locations in order to run the U-Boot and the loading addresses in U-Boot of various firmwares. 

Dear Keerthy,

    1. They will use QNX.

    2. They want to put HLOS from High 32-bit address, so from 0x800000000.

    3. Their DDR is 8G.

Dear Sijie,

     Could you help upload your Diff patch and describe why you need to enlarge the memory size? 

BR

Sikai

From eb7647319b5b8dd3cda8daa20ea3b0212be20f38 Mon Sep 17 00:00:00 2001
From: "sijie.zhu" <sijie.zhu@hirain.com>
Date: Thu, 8 Dec 2022 12:33:20 +0800
Subject: [PATCH] [MEMMAP] +dddr_shared_mem_size->1024MB

Change-Id: I909703df238b8b28b189f483a2a7e9f587fc6fe5
---
 psdkqa/qnx/bsp/images/j721e-evm-ti-emmc-hirain.build        | 2 +-
 .../basic_demos/app_tirtos/tirtos_qnx/gen_linker_mem_map.py | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/psdkqa/qnx/bsp/images/j721e-evm-ti-emmc-hirain.build b/psdkqa/qnx/bsp/images/j721e-evm-ti-emmc-hirain.build
index ab905091..213b1793 100644
--- a/psdkqa/qnx/bsp/images/j721e-evm-ti-emmc-hirain.build
+++ b/psdkqa/qnx/bsp/images/j721e-evm-ti-emmc-hirain.build
@@ -12,7 +12,7 @@
     #    -r0xA0000000,0xA0000000,1: Carveout memory for remore cores (Added by TI)
     #    -d: Use when display is managed by the R5 core (Added by TI)
     ##########################################################################
-    [+keeplinked] startup-j721e-evm -v -r0xA0000000,0x60000000,1 -r0x880000000,0x40000000,1 -d
+    [+keeplinked] startup-j721e-evm -v -r0x80000000,0x80000000,1 -r0x880000000,0x40000000,1 -d
     PATH=/proc/boot:/bin:/usr/bin:/sbin:/usr/sbin:/usr/lib
     LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll:/lib/dll/pci procnto-smp-instr -v
 }
diff --git a/vision_apps/apps/basic_demos/app_tirtos/tirtos_qnx/gen_linker_mem_map.py b/vision_apps/apps/basic_demos/app_tirtos/tirtos_qnx/gen_linker_mem_map.py
index b3c4e788..dfebace2 100644
--- a/vision_apps/apps/basic_demos/app_tirtos/tirtos_qnx/gen_linker_mem_map.py
+++ b/vision_apps/apps/basic_demos/app_tirtos/tirtos_qnx/gen_linker_mem_map.py
@@ -113,8 +113,8 @@ GB = KB*MB;
 # virtual lower DDR address range 0x0001_0000_0000
 #
 
-ddr_mem_addr  = 0xa0000000;
-ddr_mem_size  = 1*GB + 448*MB; # Last 64MB is used by Linux
+ddr_mem_addr  = 0x80000000;
+ddr_mem_size  = 1*GB + (448+512)*MB; # Last 64MB is used by Linux
 
 ddr_mem_addr_hi = 0x100000000;
 ddr_mem_size_hi = 1*GB;
@@ -251,7 +251,7 @@ tiovx_log_rt_mem_size   = 32*MB;
 
 # Shared memory for Buffers/ION allocator
 ddr_shared_mem_addr     = tiovx_log_rt_mem_addr + tiovx_log_rt_mem_size;
-ddr_shared_mem_size     = 512*MB;
+ddr_shared_mem_size     = 1024*MB;
 
 # Core specific Local Memory Heap, Non Cached Regions
 mcu2_0_ddr_non_cache_addr   = ddr_shared_mem_addr + ddr_shared_mem_size;
-- 
2.17.1

Hello Sikai,

The patch is attached, please help me check what I have missed.

The reason we want to expand the DDR_SHARED_MEM is because we are going to upgrade camera resolusion in the project (100MP-> 200MP). Therefore we though all the buffers in the openvx framework (and openvx uses DDR_SHARED_MEM ) have to be doubled as well. Please correct me in this if I am wrong.

Regards,

Sijie Zhu

Dear Sijie,

     Could you please uncomment this flag and see the exactly occupation of your shared memory?

     How do you know that your tiovx runs out of memory and needs to enlarge the space?

BR

Sikai