Making a specific region of DDR3 uncacheable

ReinierC

Good day experts,

I am working on the C6657 DSP (TDMSEVM6657) and I am currently trying to define a certain region in DDR3 as non-cacheable.

First prize would be if I could completely disable caching on the MSMCSRAM, but it appears that the associated MAR registers (12-15) is read-only, so I guess that would not be possible? Am I correct in this respect?

Second prize would be to define a specific region in DDR3 and only make that region non-cacheable. It would like to put certain data buffers into this non-cacheable region, but I would still like the cache to be active for normal program code.

If I understand the guides correctly, disabling MAR128, would make the entire first 16 MB of DDR3 non-cacheable. This is undesirable as I only need about 2MB.

Can anyone please make a suggestion and provide some example code?

over 10 years ago

0 Chad Courtney over 10 years ago

TI__Mastermind 30825 points

#1 You can use MPAX (Memory Protection and Address eXtension) to re-map the MSMC SRAM to a different address space and then use the MAR for that address range.

#2 You can address smaller (16MB) sections, but if you need different granularity, you could use MPAX and remap a certain space.

#3 MAR 128 only address the first 16MB of DDR3. Typically I'd expect to see somewhere in the range of 1-4GB of DDR3 on a board. While you may only need 2MB, one would expect that you have a lot of extra space available and one could expect to block of say the last 16MB's out of the total space. You would still have 98.4375% of the DDR3 available. If you want you can put it at the end, ff you have 1GB, then you could use MAR 191 and start the space to be non-cached from 0xBF00 0000 - 0xBFFF FFFF. You still have the option of using MPAX. I believe there's sample code available in the CSL of the MCSDK.

Best Regards,
Chad

0 ReinierC over 10 years ago in reply to Chad Courtney

Expert 2425 points

Hi Chad,

Thank you for your reply.

I think I would be most interested in #1 by remapping MSMC SRAM by using MPAX.

I found an example in the MCSDK and adapted it as follow:

	volatile CSL_XmcRegs *xmc_regs = (volatile CSL_XmcRegs *)CSL_XMC_CONFIG_REGS;
	const unsigned int MAPPED_VIRTUAL_ADDRESS = 0x81000000;


    /* Define an MPAX segment in the virtual (CGEM) address space.
     * Map MSMC physical address to virtual address.
     * Configure all +rwx permissions.
     */

    /* Phy address base: 0x0C00 0000
     * Size: 1MB (0x13 according to encoding)
     * Virtual address: 0x8100 0000
     * Permission: 0xFF
     * MAR used: (0x8100 0000 >> 24) = 129
     */

    /* map using MPAX segment 2 registers */
	xmc_regs->XMPAX[2].XMPAXH = ((MAPPED_VIRTUAL_ADDRESS >> 12) << 12) | (0x13);

	xmc_regs->XMPAX[2].XMPAXL = ((0x0c000000 >> 12) << 8) | (0xFF);

	CACHE_disableCaching(129);

I just have a couple of questions:

1) Do I need to use the address 0x8100 0000 now instead of 0x0C000000 when referring to MSMC SRAM?

2) In the SYS/BIOS CFG script I am using the EVMC6657L package, which provides platform specific functionality of the EVM. In this package the MSMCSRAM section is of course still defined as 0x0C000000. Do I need to rebuild this package or should a rather define a new region which starts at 0x8100 0000?

3) In the latter case of 2), I guess I would have to use a different alias address as 0x8100 0000 as this overlaps the existing DDR memory section?

0 ReinierC over 10 years ago in reply to ReinierC

Expert 2425 points

Hi Chad,

On separate, but related note, I came across the following post:

This post actually addresses my original problem. When I use L2SRAM for my PING-PONG buffers in a EDMA transfer, the data is never actually transferred to the L2 buffers. This post mentions that for the case of EDMA I need to address the specific core, i.e. 0x10800000 instead of 0x00800000.

Let make this question 4):

4) How do I change this in SYS/BIOS to the correct L2 address using MPAX? Do I need to create a new platform? Can you please provide some code snippets?

Note: I am using the DATA_SECTION() pragma to statically create the buffers.

0 ReinierC over 10 years ago in reply to ReinierC

Expert 2425 points

Hi Chad,

I just wanted to follow up on the above questions I had. Did you have a chance to look at them?

I managed sort out 4), but I can't seem to find the official documentation concerning the local/global addressing of the core. Can you please advise?

0 ReinierC over 10 years ago in reply to ReinierC

Expert 2425 points

Hello guys,

Can anyone please assist me with the above questions?

0 Luca Nogarotto55 over 9 years ago in reply to ReinierC

Prodigy 160 points

Hi,

I was also looking into this and I'm now reporting my solution, hopefully useful to somebody else.

There are two MPAXs (mem protection & address extension) units in the C6657:

one into the C66 (described in SPRUGW0C chapter 7) to translate the addresses generated by the core(s). We are actually always passing through it, since the first two regions are pre-configured to access the address range 0x0C000000-0x80000000 and the address range 0x80000000-0xFFFFFFF. The configuration is simply done by setting the XMPAXH-XMPAXL registers with the address to translate and with the translation address, plus size and privileges.
one outside the C66x (described in SPRUGW7A chapter 2.2) to translate the addresses generated by the IPs into the chip (all the masters that are not a C66 core). This has two interfaces, SES (handles accesses to external DDR3 memory and memory-mapped registers inside the EMIF module) and SMS (handles accesses to MSMC SRAM).

In this particular case I understand you are using the C66 MPAX to remap the MSMCSRAM to another address space to be able to deactivate the cacheability. To do this, you only need to configure the XMPAXH-XMPAXL registers, as you've correctly done. The only thing I'd do differently is the permissions configuration, 0x3F instead of 0xFF, because of two not implemented bits. The mapped region overlap with the pre-defined region from the first sets of XMPAXH-XMPAXL registers, but that's is okay because higher numbered segments take precedence over lower numbered segments.

Done that, you can now access the MSMCSRAM using the mapped address 0x81000000. You can do this using a pointer:

uint32_t *var_mcmsram_not_cached = (uint32_t*)0x81000000; //pointer to the remapped MSMCSRAM
*var_mcmsram_not_cached = 0xC1A0; //access example

Or you can use the linker command file (you need to create a new one if your project includes the TI-RTOS) to define a memory region where you mapped the MSMCSRAM (if this overlap with the previously defined DDR3 address space, you first need to modify that):

MEMORY { VIRTUAL (RWX)   : org = 0x81000000, len = 0x100000}
SECTION { .virtual    >   VIRTUAL }

And finally in the C code:

#pragma DATA_SECTION (var_mcmsram_not_cached, ".virtual");
uint32_t var_mcmsram_not_cached;

Hope this is useful,

Luca Nogarotto

Processors

Processors forum

Making a specific region of DDR3 uncacheable