• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 483 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.

Can OMAP-L138 boot loader access DSP Cache?

john filo
Intellectual 260 points
Other Parts Discussed in Thread: OMAP-L138, SYSBIOS, TMS320C6748

Does the bootloader on the OMAP-L138 have access to DSP cache?  I have a app that is using SYSBIOS on both the ARM and DSP side.  The DSP side is using the Power module to go into DEEPSLEEP mode, so portions of the SW must be linked into one of the on-chip memories.   When I link the DSP app into L3 everything works as expected but when I link the DSP side into L2 or L1 the DSP doesn't initialize properly (it never reaches our "main()").  When linked into L2 or L1, I can load the app from the emulator and everything works fine.  But when trying to boot from flash the app fails to load.  Given that the boot loader runs on the ARM my assumption is that it doesn't have access to the DSP's L2 or L1 cache.  

  • 0
    Intellectual 260 points

    One other thing that surprised me; after running into this problem I looked more closely at the bootloader docs and saw this:

    The ROM bootloader itself uses 16 KB of Shared RAM starting from 0x80000000 for multiple purposes. This memory should not be used by any initialized section of the user application.

    In my particular app, the ARM portion is starting at 0x80000000 so now I'm surprised that things behave correctly when running out of L3.  Am I just getting lucky?

  • 0
    Expert 1950 points

    Yes, it can.

    See memory map on p24 of sprs586h : ARM has access to all memory. Requires only that the DSP program is linked with L1x, L2 in the 0x1xxxxxx address range (not the 0x0xxxxxx range of page 22).

  • 0 in reply to Jakez
    Intellectual 260 points

    Thanks for the Info.  I was using 0x11800000.  Now I just have to figure out why my app starts up when I link the DSP portion at 0x8001c000 but doesn't start when I link at 0x11800000.  I wasn't aware that the Cache was also available via 0x00800000.  Any idea why the Cache is available from two different address ranges?

  • 0 in reply to john filo
    Expert 1950 points

    Hello,

    This is only my opinion:

    When using multicore C67+ DSPs, each core can access its local RAM at the same address (ie all cores can run the same program with local data for exemple), but RAM loading at boot or memory-sharing between cores requires a common address range, hence the dual ranges provided. Of course, the OMAP-L138 or the TMS320C6748 use only one DSP core, but the same common architecture is used.