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.

66ak2h14 linking ARM and DSP code / shared memory



Hi,

I am running DSP code using CCSv6 (similar to how I have done on a Keystone I) using a linker.cmd file to define data sections.

I am also able to cross compile in Linux (using the linaro tool chain) for the ARM cores (SMP A15). Is there a way to have a similar linker cmd file for the Linux side? I have seen a JSON cfg file in the MPM that looks similar. Can this be used to get memory addresses? Can it be derived from the DSP linker?

I would like to have processes on the ARM cores (SMP A15) to have the same data sections in shared memory as the DSP cores. Perhaps by deriving information from the linker.cmd file? Is this possible? I do not want to have the ARM and DSP applications to have their shared memories get out of sync.

Thanks,

-Dan

  • Hi Dan,

    Can you share which Linux SDK are you using?

    Best Regards,
    Yordan
  • Hi Yordan,

    Thank you for your quick reply.

    I am using MCSDK linux 3_01_04_07

    -Dan

  • Dan,

    First an apology - I am TI-RTOS guy and your question is LINUX question, So if my answer does not satisfy you I will forward the question to the LINUX expert.

    One more comment - the standard TI files tree has an IPC example as part of the startup matrix.  I attach a document that I wrote a long time ago for really early version of the software that shows how to build IPC example.  It is based on very old release but it can be of help.  Of course the IPC uses shared memory between the DSP and the ARM

    The best place to understand the IPC and the memories that are associated with it is a IPC FAQ   http://processors.wiki.ti.com/index.php/IPC_FAQ_for_Keystone_Devices and the demo at  processors.wiki.ti.com/.../File:Guide_Keystone_II_IPC_examples_.zip     Instructions how to run the demo are the following:

    Download the guide from here.

    This guide will have steps on
    1. Flashing the u-boot and boot u-boot.
    2. Flashing the UBIFS image ( Linux and root filesystem ) into NAND and boot Linux.
    3. Building the IPC package.
    4. Building and running the IPC examples ( ex02_MessageQ, ex44_compute, ex45_host and ex46_graph ) on target EVM.
    5. Real-time debugging on the DSP side programs using CCS.

     Thanks

    Ran

  • Hi,

    I have looked at the wiki and examples. Particularly the image demo that is referred to often. It uses MessageQ and mmap. I would prefer to not use MessageQ due to the high demands of my application (similar to how I have used it on the keystone I). I would like to use the QMSS LLD directly and read and write directly to shared memory (possibly using mmap).

    I have tried to use mmap with functions from the examples but with no success. I have been attempting to have the ARM cores read shared memory where the DSP has written data.

    The code is similar to this:

    //physical address is 0xC100000 from the DSP view

    dev_mem_fd = open("/dev/mem", (O_RDWR | O_SYNC))) //based on fw_memAllocInit() from fw_mem_allocator.c in QMSS eaxamples.

    map_base = mmap((void*)0xC100000, size, (PROT_READ|PROT_WRITE), MAP_SHARED, dev_mem_fd, (off_t)0); //based on fw_memMap() from fw_mem_allocator.c in QMSS eaxamples.

    When I read the virtual address returned it does not have the data I wrote from the DSP.

    Am I doing something wrong? Is this not a valid method of sharing data between the ARM and DSP? If not, how would I share memory between devices?

    Thank you,

    -Dan

  • Dan,

    Are you sure that the cache has been flushed or is unused on the DSP side? If cache is enabled for this memory region, after the DSP writes to the location the DSP must do a cache writeback operation to make sure it is all cleared.

    You can turn off cache to a certain area by clearing the MAR register bits for that memory region. Or you can completely turn off L1D/L2 caching in the RTOS setup or GEL file or under program control.

    In general, caching should be enabled for any regularly-used memory spaces, unless those memories can be updated by another master. In the case where the memory is used by multiple masters, as in your case, caching will need to be considered on a more specific use-case consideration, primarily by considering how often the various masters read or write to the memory region.

    For a small region of simple control words or flags, it might be best to turn off caching for that region. I am not sure how that is done on the ARM side or within Linux.

    For a large buffer of data, caching could be very useful and the best plan would be to enable caching and use the cache coherency commands.

    Regards,
    RandyP
  • Hi Randy,

    Thank you for the reply.

    I have resolved the issue. The memory was being mapped correctly. However when I let the DSP application run to completion the memory was getting scribbled over. I’m am not sure why this occurs, but if I stop the task before completion from the debugger I can read the memory fine. 

  • Dear Dan,

    I am Facing the same problem , i can read data before mapping fb0 to pointer from dsp , as soon as i mmap it to the fd My data becomes zero at arm side and DSP shows the same data .

    Can you help me solve this ?

  • Ammar,

    Please start a new thread with a full description of your issue. Dan's question is marked Answered to it is not a good place to get full support.

    Regards,
    RandyP
  • Dear Randy,
    I have started the thread while ago but no body seems to be replying on it , as Dan found the solution so thats why i posted on his thread.
    Below is the link to my Thread.
    e2e.ti.com/.../599853

    BR
    Ammar