• Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 1005 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.

DM365 memory map optimization

Marco Braga
Expert 1780 points

Hi,

I'm trying to modify loadmodules.sh to optimize linux memory on DM365. After reading this page:

http://wiki.davincidsp.com/index.php/Changing_the_DVEVM_memory_map

I have more questions than answers since DM365 seems to be a simpler device than the DM6446 described in that page. Video encoding is done in hardware components instead of a more generic DSP part, so I suspect that the actual memory map is simpler than the one described in the document.

Looking at the loadmodules.sh supplied with DM365 no dsplink.ko module is loaded and also I've not found the files related to dsplink in my DVSDK. I suspect that no dsplink is used in this device, since there is no real DSP to actually run algorithms.

If this is true, there is also no DDRALGHEAP and DDR sections to be configured since there is no real server, no DSPLINKMEM and RESETVECTOR too. Basically memory is used for Linux and CMEM. Still, I am not sure if my assumptions are correct.

The default configuration supplied in loadmodules.sh for CMEM is this:

/sbin/insmod /opt/dsp/cmemk.ko phys_start=0x85000000 phys_end=0x88000000 pools=6x4096,2x8192,1x11908,2x13184,1x2697152,6x4096,1x30720,3x81920,1x3185664,64x56,1x320,1x640,1x81920,1x6650880,2x608,1x296,1x28,2x24,23x1548288,1x154288 allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672

And linux is loaded with MEM=80M (i.e. 0x80000000 - 0x85000000)

In fact CMEM allocates all available memory not used by linux, i.e. range 0x85000000 - 0x88000000 as per CMEM config. This also seems to confirm that no memory is used for DSP since there is no space in this map for other heaps or DSPLINK buffers.

If all this is true, then changing memory map on DM365 can be a lot easier than expected:

1) Calculate the size of CMEM and buffer pools

2) Configure cmem.ko and linux boot "MEM=" argument

Regarding CMEM buffers, I still have to understand if the requirements all depend on the Linux application allocated buffers (uncompressed and compressed video) or ther is more, but I suspect that the hardware compressor need memory that is actually taken from CMEM's pools.

In any case, the methods suggested in the "Changing DVEVM memory map" should be still valid.

Last mistery is this part of CMEM config: "allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672". It seems to reserve 28Kb from ARM's TCM (ARM RAM0, 0x0000-0x3FFF and ARM RAM1 0x4000-0x7FFF), I suspect the first 4Mb are left for ARM's IRQ vectors. Perhaps this memory area is used for DMA?

That's all for now, perhaps you can help me to understand better those points and explain me if I am correct.

Thanks!

 

  • TI__Mastermind 41665 points

    Marco Braga said:

    If all this is true, then changing memory map on DM365 can be a lot easier than expected:

    1) Calculate the size of CMEM and buffer pools

    2) Configure cmem.ko and linux boot "MEM=" argument

    This sounds about right, the memory map is much simpler in DM365 as it has no DSP, so you do not need to worry about allocating space that the DSP can use, you only need the CMEM buffers to be worked on by the accelerator.

    Marco Braga said:
    Last mistery is this part of CMEM config: "allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672". It seems to reserve 28Kb from ARM's TCM (ARM RAM0, 0x0000-0x3FFF and ARM RAM1 0x4000-0x7FFF), I suspect the first 4Mb are left for ARM's IRQ vectors. Perhaps this memory area is used for DMA?

    I am not sure exactly what this is being used for by the codec, but it would make sense to leverage this higher speed internal memory since it is available and Linux will not be using it.

  • in reply to Bernie Thompson TI
    Intellectual 960 points

    Hello, Marco and Bernie.

    The situation seems very suspicious to me: is it possible that accelerator does not use RAM at all? And I think that I observe that it does use!

    We have the UDWorks DVR board, which is configured with 68MB for CMEM. But when we try to overcome the about 30MB boundary we receive an error message, which effectively means that about 38MB are used by somebody else. Who is this?

    I suppose, that accelerator's memory need are satisfied dynamically, no?

    I hope, that Marco has solved the issue during last year - his mail is one year old...:-)

    Any help will be appreciated

  • in reply to Leon Pollak
    TI__Mastermind 19985 points

    Hi Leon,

    Just want to understand,  do you want to increase the CMEM area which means reduce the kernel memory (MEM= parameter of bootargs)? What are the exact sizes that you are looking for currently.

    For the accelerator using RAM question, yes the latest DM36x H.264 codecs use the ARM internal RAM for some optimizations. Which version of UDWorks DVR Ref Design software are you using?

    BTW, there is a new release from UDWorks (ver 2.0) which has reduced the kernel memory even further and increased the CMEM allocation. You might want to refer to the .config of the kernel of ver 2.0 release, if thats what you are looking for to reduce the kernel memory requirements.

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.

  • in reply to Anshuman Saxena
    Intellectual 960 points

    Thank you very much - you clarified our doubts and now we understand the situation better.

    For those who may be interested, as we were, in the memory layout of the UDWorks DVR unit:

    All the threads memory requirements may be easily found in their sources. What can not be found is the memory required by encoder and decoder. We found that:

    - encoder requires about 2434KB*2 for PAL and 2028KB for NTSC;

    - decoder requires about 2738KB*2 for PAL and 2364KB for NTSC.

    There are still some unclear questions we are investigating why display thread makes so strange memory requests(approx):

    PAL - 636KB*5, 3180KB*2, 692KB*7;

    NTSC - 530KB*5, 2650KB*2, 692KB*7.

     

    Thanks a lot for the help.

    I was not able to find how to mark the post as verified, as Anshuman asked.

    Best Regards