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.

DSP cache configuration on OMAP-L138

Other Parts Discussed in Thread: OMAP-L138

Hi,

Can anyone check if the following is correct and sufficient for setting up the DSP on OMAP-L138 to cache the DDR2?

/* setup MAR bits to enable cache for DDR2 */
CacheEnableMAR((unsigned int)DDR2_ADDR, DDR2_SIZE);
/* Enable Cache */
CacheEnable(L1PCFG_L1PMODE_32K | L1DCFG_L1DMODE_32K | L2CFG_L2MODE_256K);

Do I have to add this line? What is the purpose of it?

CacheWBInv((unsigned int)DDR2_ADDR, DDR2_SIZE);

If I want to use only half of the L2 as cache? Do I just do this? And then the top half of the L2 (from 0x11820000) become RAM?

/* setup MAR bits to enable cache for DDR2 */
CacheEnableMAR((unsigned int)DDR2_ADDR, DDR2_SIZE);
/* Enable Cache */
CacheEnable(L1PCFG_L1PMODE_32K | L1DCFG_L1DMODE_32K | L2CFG_L2MODE_128K);

I wish the StarterWare documentation is more detailed and complete.

Thanks

  • Hi Liz,

    YOur cache configuration looks fine.

    Reg. cacheWbInv - Writes back and invalidates the specified range of memory. When you perform a writeback, the contents of the cache lines are written to lower-level memory. When you invalidate a cache line, its contents are discarded. All lines within the range are written back to the source memory and then invalidated in all caches.

  • When should I use cacheWbInv? Or I don't have to at all.

  • How do I achieve this (from bios tcf) in starterware

    /**
     *  The following statements will enable the MAR bit for MAR 128.
     *  (MAR 192 to MAR 223 are enabled by default).
     *  This will make the memory ranges (0x8000 0000 - 0x8001 FFFF) and
     *  (0xC000 0000 - 0xDFFF FFFF) cacheable.
     */
    bios.GBL.C64PLUSCONFIGURE = 1;
    bios.GBL.C64PLUSMAR128to159 = 0x00000001;

  • It seemed every time I tried to enable half of the L2RAM, my program crashes mysteriously. Please have a look if I am doing it right.

    in the cmd file:

    MEMORY {
       CACHE_L2    : origin = 0x11820000,  len = 0x20000
       CACHE_L1P   : origin = 0x11e00000,  len = 0x8000
       CACHE_L1D   : origin = 0x11f00000,  len = 0x8000
       DDR2        : origin = 0xc3e00000,  len = 0x100000
       L2RAM       : origin = 0x11800000,  len = 0x20000
       L3_CBA_BOOT : origin = 0x80000000,  len = 0x80
       L3_CBA_RAM  : origin = 0x80000080,  len = 0x1EF00
       L3_CBA_LINK : origin = 0x8001F000,  len = 0x1000
    }

    In the C file, app crash if like this, works but slow when I removed the highlighted part.

    #define DDR2_ADDR (void *)0xc3e00000
    #define DDR2_SIZE (unsigned int)0x100000

    {
        /* setup MAR bits to enable cache for DDR2 */
        CacheEnableMAR((unsigned int)DDR2_ADDR, DDR2_SIZE);
        /* Enable Cache */
        CacheEnable(L1PCFG_L1PMODE_32K | L1DCFG_L1DMODE_32K | L2CFG_L2MODE_128K);
    }


  • You have probably unearthed this by now, but there is an error in the starterware cache enable functions.  The end result is the wrong setting for L2 caused by the L1 setting, and you step on the memory at execution.  Try manually configuring the cache, and it will be fine.  

  • Great find.

    Added one more to my long list of TI software bugs.