Question on OMAP-L137 memory utilization

There is a nice discussion of the DaVinci EVM (DM6446) memory map from a SW standpoint here:

http://tiexpressdsp.com/index.php/Changing_the_DVEVM_memory_map

But I have not seen an equivalent SW memory map or the OMAP-L137 which is probably simpler (i.e. you could start with the HW memory map from the datasheet and add Linux, eDMALLD, BIOS, etc.)

Hello Joe,

Thanks for your feedback. Looking at my UBOOT bootargs the mem parameter is set to 32M which I assume is 32 Mbyte.

How does one figure out what physical address space is being used as the base address for that 32M?

Thanks!

Richard

It is the first 32M of the memory for Linux.

If you are using DSPLink please also see:

http://tiexpressdsp.com/index.php/Changing_DSPLink_Memory_Map

Hello Mariana

I am developing an application which is based on the "message" sample app which uses DSPLINK to pass messages between the ARM and DSP cores.

The program is running fine and here is a snapshot of my DSP memory map. According to this map it appears that the DSP is using memory in the first 32Mbytes which according to the tech manual for the EVM board starts at 0xC000 0000 and runs to 0xD000 0000. Could you elaborate on your earlier statement as something doesn't seem right if linux owns the first 32M. That is to say if linux owns the first 32M then I would have expected to see that the DSP is then required to stay out of that area and only use memory after 0xD000 0000. Thanks for your help.

Richard

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  IRAM                  11808000   00008000  000063e0  00001c20  RWIX
  CACHE_L2              11838000   00008000  00000000  00008000  RWIX
  CACHE_L1P             11e00000   00008000  00000000  00008000  RWIX
  CACHE_L1D             11f00000   00008000  00000000  00008000  RWIX
  L3_CBA_RAM            80000000   00020000  00000000  00020000  RWIX
  RESET_VECTOR          c3e00000   00000080  00000000  00000080  RWIX
  SDRAM                 c3e00080   000fff80  000300dd  000cfea3  RWIX
  DSPLINKMEM            c3f00000   00030000  00000000  00030000  RWIX

Richard Bagdazian said:

 

I made an error in my memory bounds the below is corrected.

 

Hello Mariana

 

I am developing an application which is based on the "message" sample app which uses DSPLINK to pass messages between the ARM and DSP cores.

The program is running fine and here is a snapshot of my DSP memory map. According to this map it appears that the DSP is using memory in the first 32Mbytes which according to the tech manual for the EVM board starts at 0xC000 0000 and runs to 0xDFFF FFFF. Could you elaborate on your earlier statement as something doesn't seem right if linux owns the first 32M. That is to say if linux owns the first 32M then I would have expected to see that the DSP is then required to stay out of that area and only use memory after 0xD000 0000. Thanks for your help.

Richard

 

 

 

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  IRAM                  11808000   00008000  000063e0  00001c20  RWIX
  CACHE_L2              11838000   00008000  00000000  00008000  RWIX
  CACHE_L1P             11e00000   00008000  00000000  00008000  RWIX
  CACHE_L1D             11f00000   00008000  00000000  00008000  RWIX
  L3_CBA_RAM            80000000   00020000  00000000  00020000  RWIX
  RESET_VECTOR          c3e00000   00000080  00000000  00000080  RWIX
  SDRAM                 c3e00080   000fff80  000300dd  000cfea3  RWIX
  DSPLINKMEM            c3f00000   00030000  00000000  00030000  RWIX

Hi Richard,

You can see that the DSP does not even map the beginning of the SDRAM (from 0xC000 0000 to 0xC3E0 0000) , meaning that it will not put DSP program in the first 62MB (0x03E0 0000) of the SDRAM, so it is safe for the ARM to use the first 32Mbytes of the SDRAM.

fyi, even it the technical ref show the address range from 0xC000 0000 to 0xDFFF FFFF, the SDRAM on the board has only 64Mbytes, so the real address range is from 0xC000 0000 to 0xC400 0000 as 0x400 0000 = 64MB

As just another data point, the memory map used by Codec Engine's examples - which use DSP Link underneath - are here:

http://tiexpressdsp.com/index.php/Codec_Engine_Examples_Memory_Map

One [optional] additional thing that memory map shows is the reservation for CMEM of physically contiguous buffers that can be used to send across processors.

Chris

Thanks Mariana and Chris for your help on this.

The CMEM segment  provides me with just what I was looking for to ship a big chunk of data across processors with zero overhead.

So it's save to send data into that segment and write custom code on both sides of the fence to deal with it, particular to my application?

Is CMEM API supported in the montevista linux distro by default for the OMAP-L137?

Thanks

Richard

Richard,

Than you it is better to use Codec Engine (that uses DSPLink underneath) instead of stand alone DSPLINK of the message example that you mentioned.

If you want to go the Codec Engine route, please see:

http://tiexpressdsp.com/index.php/Getting_started_with_IUNIVERSAL

The only case that you should not use Codec Engine is if you plan on using DSP drivers. If the DSP is only used to run algorithms (DSP does not touch the peripherals directly), than the Codec engine is a very good option.

I wouldn't state as strongly as Mariana that you _need_ to use Codec Engine...  :)   but depending on your use case, you may find value in considering it.  Codec Engine will handle the tricky cache maintenance and address translation associated with passing buffers across processors.  And note that the link Mariana provided helps reflect that CE can support 'algorithms', not just 'codecs'.

It has some limitations - like it leaves all I/O processing to the application, so if you want to use DSP-side drivers, you have to use "something else" (like DSP Link) to get your processed data buffers from one processor to the other.  But for many use cases it can simplify your application and system resource management.  With a little more detail, we might be able to make a recommendation "to CE or not to CE".  :)

To your question, yes, you can use CMEM without Codec Engine, and it has been ported to recent Linux releases.  CMEM is part of the larger "Linux Utils" product, latest releases are available here - http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html

Chris

Indeed you do not need to use CE in order to use CMEM - I edited my previous post. You can use it stand alone.

Thanks for the correction Chris.

Thank you Mariana and Chris,

This was very helpful. I'm just going to use the mem directly and handle the data management on the DSP side via a custom support api that I plan to develop. It will be more lightweight and suited to my immediate requirements.

Thanks again for your support!

Richard