• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 557 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.

Letting the ARM use the DSP L2 RAM for code space

Nick Robertson
Intellectual 420 points
Other Parts Discussed in Thread: OMAPL138

I'm trying an experiment where the DSP will not be active and the ARM will have it's .bss section loaded to the DSP L2 RAM (0x11800000 or 0x00800000) . I thought I could do this since the OMAPL138 data sheet states that the ARM has access to the DSP internal memories. However, it's not working. I've tried it in the debugger with the ARM GEL file both enabling and disabling the DSP PSC register.  Is the DSP somehow configuring L2 RAM to be cache? I've also noticed that while the .map file appears to place the .bss in the correct memory section, a review of the Intel-hex file does not show anything being placed in the DSP L2 RAM.

Any advice on how to configure the OMAP to allow this mapping is appreciated.

  • 0
    TI__Expert 3425 points

    Nick,

    Can you please provide more details when you say that its not working. ".bss" section corresponds to uninitialized global variables/arrays, so the output file will not have any area/data assigned to the ".bss" section. If DSP is powered on properly, the DSP memories should be accessible from ARM.

    Can you also check if the virtual memory configuration in ARM memory controller  and memory protection unit is properly configured.

    Thanks,
    Gaurav

  • 0 in reply to Gaurav Agarwal
    Intellectual 420 points

    Hi Gaurav, thanks for the reply.

    From a build standpoint, here's what I'm doing now. Via the linker.cmd file, I'm placing the .bss section in shared RAM (0x80000000) and I'm now placing a module from the .text section (let's call it foo.obj) into the DSP L2 RAM (0x11800000) so that it in part looks like this:

    .bss > SHARED_RAM

    .special: { FOO.obj (.text) } > DSPL2RAM

    It builds and links fine, with no warnings or errors. The .map file shows the sections being placed where I expect them to be placed.

    By not working, I mean this: I connect to the target and load the code through the debugger. I can view memory at location 0x11800000 and it looks like I expect. The DSP has been woke up via the GEL file at this point. So when I hit 'Run' on the debugger, I get a critical error window that pops up stating:

    Error:
    Error 0xE0002024/-173
    Error during: Register, Execution, Control,
    Error generated by SD scan controller module

    If i reset everything and rebuild so that FOO.obj is mapped back into shared RAM or DDR, everything works great again. I've also tried this with FOO.obj mapped to 0x00800000.

    As to your queries about the virtual memory configuration and MMU's in the ARM:

    1. Where is the virtual memory configuration located? I'm using the OMAP L138 datasheet and there is no real reference to this. A straight answer or reference to an appropriate document would be helpful

    2. The MMU

         MMU1 (0x01E14000): revid: 0x4E814901;  Configuration: 0x0006C001; the rest of the entries are all 0x00000000

         MMU2 (0x01E14300): All entries are 0.

    Thanks in advance

  • 0 in reply to Nick Robertson
    Intellectual 420 points

    A further bit of information:

    I remapped and rebuilt my code so that it is all resident in DDR and Shared RAM. I then added code to write and then read back a test value from memory location 0x11800000. This works fine. I can stop the debugger and verify that my test value is being written to the DSP's L2 RAM, and I can read it back. In my mind this lends credence to the thought that the MMU is blocking execute access but not read/write. However I've read in sprugm7d that MMU1 is concerned with shared RAM access and MMU2 is concerned with DDR access. Do they control DSP L2 RAM access as well? And as a side question, where can I access the MMUs in the debugger? The list of registers does not explicitly show these, at least as far as I can tell.

  • 0
    TI__Guru 62975 points

    Nick,

    Be careful when using memory address 0x00800000.  Both 0x11800000 and 0x00800000 point to the same physical memory, but 0x00800000 is only accessible through the DSP.

    Also, I am under the impression that the L2 memory space is not cache-able by the ARM so that may be another clue.

    -Tommy