• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 439 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.

OMAPL-137 D800K001 additional configuration

Marco Del Fiasco
Prodigy 110 points
Other Parts Discussed in Thread: TMS320C6474

I need to do additional configuration during the boot process of the OMAP L-137 related to L1P cache. I have placed a fast-code section inside L1P configured as SRAM. The problem is that the device defaults to L1P configuread as "all cache", so before code reaches the cache configuration routine I have the fast-code in L1P damaged by cache activity. The program works correctly if I could disable cache L1P on the boot process (now done via .gel file) and then re-enable it from the main program.

The question could be extended to similar problems as well: how can we do device configuration directly in the domain of the D800K001 bootloader? Is there a way to add hand-written configuration code that will be executed by the bootloader (before the main routine starts)? Thank you.

  • 0
    TI__Mastermind 24340 points

    Hi Marco,

    As the cache registers are memory mapped, you could include a section load command and change the value of the register. Please see:

    Using the D800K001 Bootloader

  • 0 in reply to Mariana
    TI__Guru*** 125430 points

    Marco,

    Even if you could get the boot ROM to configure L1P as SRAM instead of cache, it still would not be able to write your code into L1P SRAM.  You cannot use CPU for this activity.  It must be done with DMA.  So to reiterate, there are TWO problems related to this issue in the boot ROM:  1) cache configuration, and 2) need to use DMA for code placement.

    The way to work around this issue is to use load/run addresses.  The boot ROM will place your code at its load address (e.g. DDR2).  Then at run-time you can reconfigure L1P as SRAM and copy the routine to its run address (e.g. L1P SRAM).

    Brad

  • 0 in reply to Brad Griffis
    Prodigy 110 points

    Thank you Brad, this seems to be the right way: I tried using linker load/run sections together with table() directives and wrote a copy table processing routine using edma3. I've placed the load section in SDRAM and the run section in one half of L1P configured as RAM. The cache layout is configured in the main function before the copy-routine starts. Now I have another problem:

    If I place the run section in SDRAM the copy works and everything is fine, but if i place the run section inside L1P (as i have to do) I see that no code is copied by the edma3 from the load section to the run section. Since OMAP L-137 provides privilege-levels, I checked the L1P privilege registers but found no bad configuration. This is what I see with JTAG after edma transfer(s):

    all L1PMPPAxx = 0x0000FFFF

    all L1PMPLKx = 0x00000000

    L1PMPLKSTAT = 0x00000002 (one reserved bit is set but don't know what it is)

    L1PMPFAR = 0x00000000

     

    Why EDMA3 is not working from SDRAM to L1P RAM?

    Thank you.

     

  • 0 in reply to Marco Del Fiasco
    TI__Guru*** 125430 points

    Note that in the memory map listed in the data sheet the L1P has two addresses shown:  0x00E0_0000 and 0x11E0_0000.  Only the 0x11E0_0000 address is accessible by both CPU and EDMA.  Please verify that the destination address in your EDMA configuration is using the 0x11E0_0000 range or else the copy will fail.  I think this might be your error.

    Could you please provide me with the exact address where you are relocating your algorithm (as listed in the EDMA parameters) as well as the value of the L1PCFG register (0184 0020h)?

  • 0 in reply to Brad Griffis
    Prodigy 110 points

    You are right, there was an error in the MEMORY section regarding L1P location: it was set to 0x00E00000. But why in sprs563b.pdf section 3.5 the Memory Map Summary shows cache locations at multiple addresses?

    Thank you for your help.

  • 0 in reply to Marco Del Fiasco
    TI__Guru*** 125430 points

    That's a standard feature of the 64x+/674x core, i.e. we dual-map the internal memory.  The 0x00E0_0000 address is a "local" address accessibly only by the core.  The 0x11E0_0000 address is "global" and is accessible by anyone.  This feature makes more sense when you see a device like the TMS320C6474 which has 3 64x+ cores in it.  This features allows you to write code that can execute in parallel across all 3 cores and even though all 3 cores would be accessing the same address they would all be accessing their own local memory.  In that same scenario if one core wanted to access the memory of another core it should reference that core's global address.