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.

K2H EVM - DDR3 usage with 'MPM' module

Other Parts Discussed in Thread: TMS320C6678

Hi all,

I am using XTCIEVMK2X EVM. 

Developing environment is: CCS ver  5.4.0.00091; MCSDK Packages: 3_00_01_12

Bootmode:  ARM SPI Little Endian mode.

For K2H EVM, we want to download the DSP image through ARM with the help of 'MPM' module. So,  we are using DDR3 from start address 0xA0000000 and a length of 512 MB.

In DSP linker cmd file, DSP memory map using DDR3 external address starting from 0xA000 0000 to 0xBFFF FFFF.

Through MPAX (Memory Protection and Extension), DSP can map 32-bit address to 36-bit physical address space. But we are using  ARM SPI boot mode and 'mpmcl' commands, now by default  Linux (ARM) manages (up to 2GB memory) mapping from 32-bit address to 36-bit address,  so we are not configuring any xmc table again from DSP side. 

With single core i.e. core 0, we are able to work with DDR3 memory as required.  No issues with single core and we are trying to extend it to other cores.

Now while implementing for other cores, we are observing memory conflict issues across two cores (core 0 and core 1) in the usage of DDR3.

Memory conflict issue means some of the variables updated in core 0 are reflecting in core 1 . We are expecting these variables should be initialized with zeros and should be update in core 1 as per code.

Both cores are accessing the DDR3 region from 0xB200 0000 to 0xB300 0000.

Can you please provide the answers for below questions ?

1. We are not using MPAX / XMC tables, so how DDR3 memory can be sharable among different cores ?

2. How can I divide DDR3 region (from 0xA000 0000 to 0xBFFF FFFF) as CACHEABLE or NONCACHEABLE / SHARED or PRIVATE blocks ?

 

Thanks in advance.

Best regards,

Rajanikanth.

  • Hi Rajanikanth,

    I am working on your query. I will post my suggestions shortly.

    Thank you for your patience.

  • Hi,

    1. From my understanding, It  supports only 32-bit address, and it can support 36-bit address through configuration of MPAX inside MSMC.  Please refer MSMC UG for more detail. 

    MSMC UG: http://www.ti.com/lit/spruhj6

    2. You can divide using the MAR functions. Please refer the CorePac user guide for more detail.(Section 4)

    CorePac UG: http://www.ti.com/lit/sprugw0

    1. Are you able to run the MPM examples provided in MCSDK successfully?

    2. What are all the files you have modified and what changes you have made? Please provide the detail.

    3. We would recommend you to use the latest MCSDK for development.

    Thank you.

  • Hi Rajasekaran,

    Thanks for the information.

    Please find below answers:

    1. Are you able to run the MPM examples provided in MCSDK successfully?

    3. We would recommend you to use the latest MCSDK for development.

    RK: I am using MCSDK 3_00_01_12 and it seems in this version there are no  MPM examples provided.

    I am referring to below path for examples:

    C:\ti\pdk_keystone2_3_00_01_12\packages\exampleProjects 

    I will check in latest MCSDK. But in the said MPM examples, can I get the usage for my below question:

    How can I divide DDR3 region (from 0xA000 0000 to 0xBFFF FFFF) as CACHEABLE or NONCACHEABLE / SHARED or PRIVATE blocks ?

    2. What are all the files you have modified and what changes you have made? Please provide the detail.

    RK: Earlier on Shannon platform (TMS320C6678), we used MAR registers, MPAX / XMC tables but now on K2H, we are using  ARM SPI boot mode and 'mpmcl' commands, so by default  Linux (ARM) manages (up to 2GB memory) mapping from 32-bit address to 36-bit address,  so for this reason, we are not configuring any xmc tables/MAR again from DSP side.

    For this we have disabled xmc tables/MAR usage from 'hardware configuration' file.

    Note: With ARM SPI boot mode, if we still use xmc tables/MAR from DSP side then we observed the corruption in program memory. So, we disabled xmc tables/MAR usage from DSP side.

    Also we changed DSP linker cmd file. Earlier we used  DDR3 external address starting from 0x8000 0000. But now using start address from 0xA000 0000 to 0xBFFF FFFF.

    In ARM SPI mode, by default  Linux (ARM) manages mapping from 32-bit address to 36-bit address.  Is there any way to stop this management by Linux so that we can use xmc tables/MAR again from DSP side.

    What would be the solution to my current problem ?  Please suggest.

    Thanks in advance.

    Thanks and Regards,

    Rajanikanth.

  • Hi Rajasekaran,

    Can you please provide answers for the mentioned problem ?  This is a critical situation for us.

    Thanks in advance.

     

    Thanks and Regards,

    Rajanikanth.

  • Hi RK,

    1. The MPM configures the memory 0xA0000000 - 0xBFFFFC00 as shared memory across all the DSP cores and MPM uses 0xBFFFFC00 - 0xBFFFFFFF as scratch memory. (Please refer the /etc/mpm/mpm_config.json file)

    2. The MPM does not do MPAX mapping for local to global addresses. So the MPAX support needs to be handled by application.

    The only solution would be to use MPAX to avoid conflict or programmer should manage the addresses for data write. 

    http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Developing_System_Mgmt#Multiple_Processor_Manager

    Thank you.

  • Dear Rajanikanth.

    If I understand your problem correctly, indeed you are right. If you use the same build for multiple DSP cores, and a private variable is defined in a shared memory (DDR or MSMC shared memory) then multiple cores will over-write each other.

     

    I can suggest two possible solutions:

    1. 1.       Keep the message area in share memory and move private variables to local L2 of each core. L2 size in keystone II is 1M
    2. 2.       If you need to store some private variables in DDR then I would define 8 (or whatever the number of DSP cores you want to use) memories in the RTSC platform in addition to a shared DDR memory.  That is, in the RTSC platform I will define DDR memory, DDR1, DDR2 and so on and so forth. (If you do not use RTSC you define the memories in linker command file), and then use different linker command file to distribute the private variables differently in each private memory. (That is, the first linker command file will put the sections in DDR1, the second in DDR2 and so on). Next I would build 8 different build configurations to build 8 different out files, and load all of them to the Linux, and load different out file for each DSP core.

     

    Does it solve your issue?  If you need more information let me know

     

    Bets regards

     

     

    Ran

  • Hi Ran & Rajasekaran,

    Thanks a lot for your suggestions.

    Ran, For testing purpose, I have implemented your 1st suggestion by keeping private variables (some of channels memory) in local L2 memory and its working. But to achieve more channel density, we have to use external memory too. To implement your 2nd suggestion is not feasible due to some certain contexts.

    Rajasekaran, we see only solution to this problem to use MPAX. I have gone through the link:

    http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Developing_System_Mgmt#Multiple_Processor_Manager

    But didn't get complete information.

    Is there any example where MPAX / XMC / MAR implemented ? Please suggest.

    Also, can you please clarify the below query:

    For example, each channel occupies 0x4000 bytes of memory. I want to use external memory from 0xB000_0000 address.

    Suppose, If I use 10 channels memory (0x28000 = 0x4000 *10) from address 0xB000_0000 to 0xB002_8000 and If I implement MPAX , then these 10 channels memory would work as private memory for each core, similar to local L2 memory ?

    Please provide answer to this query.

     

    Thanks in advance.

    Best regards,

    Rajanikanth.

  • Hi

     

    Using private memory in DDR is explained in a document that I have written

     

    Read it and tell me if it makes sense

     

    Ran3108.DSP_PrivateMemoryExample.docx

     

     

  • Hi Ran,

    Thanks a lot for the very well explained document.

    Our project is not RTSC based and we are not using any cfg file, but we are using a linker command file.

    From your document, I can understand that 'per channel data' which would be a private area and need to define it in the linker command file. We need to allocate DDR regions as shared memory / private memory through linker command file.

    To configure MPAX registers, the method mentioned in the document is for RTSC based project. Can you please provide an example where MPAX configuration implemented for
    non RTSC based project?

    Do I also need to do changes in  /etc/mpm/mpm_config.json file ?

    Thanks in advance.

    Thanks & Best regards,
    Rajanikanth.

  • For NON_RTSC projects, I do it using a special gel file (and I do development in CCS)

    Look at the standard gel file at the function xmc_setup() and change it based on the MPAX registers that you want to change and the core number

    Now, in the real world, this is part of the boot process.  Each core has to modify its own MPAX registers before c_init.  There are more than one way of doing it, but I have not done it myself.

     

    Remember that if you want to use EDMA (or any other non-core data mover) you need to change the MPAX registers of the Teranet.

    And about the mpm_config, you must garantee that the Linux will not use the same memory that any of the cores uses, so teh reserve area must be taken into considerations (I think)

     

    Ran