• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1245 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

[TDA4] Deploy big neural net on C7

[TDA4] Extend memory for C7x

Dominic Fellner
Prodigy 200 points

Hi,

unfortunately my old thread was locked during the holidays, so I create this follow up thread.


I can confirm that the proposed way from Dec 7th works for now, but what is not clear to me:

Following your solution, we carve out 320 MB for the C7x Scratch and Heap section from the shared mem section, but leave the other cores as they are.

Doesn't that mean that the other cores may write in their shared mem section which includes the carved out memory on C7x? In my understanding that leads to unpredicted behavior, even though in my small demo app the other cores don't seem to use so much shared mem.

I tried limiting the shared mem for all other cores to 256 MB (like for the C7x, so our new section should be save from memory accesses by other cores), but when sourcing opt/vision_apps/vision_apps_init.sh, I could see that the cores could not allocate their memory any more and my application stopped working. So I probably failed in seeing all the implications of limiting the shared mem size.

On the other hand, I tried increasing the new memory section even further and found sizes of up to 560 MB to work. With an even greater size, the C7x failed allocating during init.

So I have two questions remaining:

1) Is my understanding correct that the proposed way is highly dangerous? What would I have to change to limit the other cores' shared mem sections accordingly and rule out any interference of memory accesses?

2) Is there a reason to limit the new memory section size to 320 MB as proposed in your solution or can I increase it to 560 MB or even further? Naively thought, there should be 0x100000000 - 0xCC000000 = 832 MB left (4 GB of memory in the system), but I see it only working up to 560 MB (So the section ends at memory location 0xEF000000)



Thanks and Regards

Dom

  • 0
    TI__Genius 10355 points

    Hi Dom,

    We have 4GB of on-chip DDR on J721E EVM and the DDR address starts from 0x8000_0000

    Both A72 and C7x are 64-bit cores but R5Fs and C66 DSPs are 32-bit cores.

    if you open the system_memory_map.html in location,

    psdk_rtos_auto_j7_06_01_00_15/vision_apps/apps/basic_demos/app_tirtos/tirtos_linux/system_memory_map.html

    You can observe the various sections carved out,

    Address 0x8000_0000 to 0x9FFF_FFFF is for Linux kernel

    Address 0xA000_0000 to 0xDFFF_FFFF is for Linux resource table, IPC memory and code/data memory for each core, tiovx object descriptor, shared memory etc.

    Address 0xE000_0000 to 0x0000_0001_7FFF_FFFF is mapped as Linux virtual memory.

    Currently the total sizing of DDR_SHARED_MEM is based on what each core needs so except C7x DSP we dont see that other cores need more than 256MB.

    Now, in your application if you want to allocate more memory to each core then you will have to take care while carving out a dedicated section from DDR_SHARED_MEM. What was done is only an example and not a one-size-fit-all.

    We can certainly allocate more memory in DDR_SHARED_MEM and even more to C7x DSP as well, but just take care of the 32-bit boundary spill over. The C7x DSP can handle the spill over as its a 64-bit DSP but other 32-bit cores like R5F and C66 DSP will have to stay within the 32-bit address limit. Of-course we need to inform linux accordingly  (appropriately size the virtual memory)

    Regards,
    Shyam