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.

64K-Byte Shared SRAM

Other Parts Discussed in Thread: OMAP3530, OMAP-L137

How is this shared between the ARM and DSP?

Can this be memory mapped at all and how?

Can this be solely dedicated to the DSP?

  • What processor?  Please explain your second question some more.  If it's not already in the memory map then how would you use the memory at all?  Please specify the address range you are referring to.

  • Based on some of your prior posts I assume this is an OMAP3530 question? And that being the case the memory you refer to would be the internal SRAM at 0x40200000 of 64kB?

    hdp said:
    How is this shared between the ARM and DSP?

    Both the ARM and DSP are capible of initiating transfers on the internal bus, so it is shared by allowing both ARM and DSP access, it is literally imbedded in the physical memory map of both cores.

    hdp said:
    Can this be memory mapped at all and how?

    Assuming we are talking about the same memory, there is 64kB of internal SRAM located at 0x40200000 in the physical memory map, this could be remapped into virtual addresses using the MMU on both the ARM and DSP.

    hdp said:
    Can this be solely dedicated to the DSP?

    Sure, just dont access it from the ARM and you can dedicate the space to the DSP. However I am not sure if Linux is using this space anywhere (though I suspect it is not), and there is no way of solidly locking the memory to just the DSP to my knowledge, the ARM could always reconfigure its MMU to access the SRAM.

  • FWIW, I know of at least one ARM-side, OMAP3-based codec (not from TI) that is making use of this SRAM memory.  The use case in that environment was that CMEM was given that memory, and Codec Engine provided it to the codec when it requested it.

    It's unlikely that your system has this codec, but know that "some other users" have found that memory as well and may be using it if you're integrating a system with components from many vendors.

    Chris

  • For OMAP3530, is there a sample code snippet available in linux for accessing 64kB of internal SRAM located at 0x40200000 in the physical memory map, with the functionality of remapping to virtual addresses using the MMU on ARM-side along with read/write functionaility to this internal shared SRAM.

    Can you please point me towards the sample code either in the supplied CD along with the OMAp3530-EVM or in the linux source.

     

    Venkat

  • Although it would be possible to writte such software by including a kernel level driver to give user space applications access to this memory, it violates the Linux software architecture model.  In Linux, normally only kernel modules have access to physical memory and user space application only have access to virtual memory.  Unfortunately, I do not know of any such code snippet to point you to.

  • You can map the physical space into your user space and write a user level driver.  Here is some sample Linux code I used on the OMAP-L137 shared ram, just change the address:

    #include <stdio.h>

    #include <stdlib.h>

    #include <string.h>

    #include <sys/mman.h>

    #include <sys/stat.h>

    #include <fcntl.h>

    #define REG_AREA_SIZE 128 /* device register size */

    #define REG_OFFSET 0x80000000  /* physical address to map */

    /* physical address of device */

    int main (int argc, char **argv) {

     

    void *mem_ptr;

    /* de-reference for memory-mapped access */

    char *tmp_ptr;

    int fd;

    fd=open("/dev/mem",O_RDWR);

    /* open physical memory (must be root) */

    mem_ptr = mmap((void *)0x0,

    REG_AREA_SIZE, PROT_READ+PROT_WRITE,

    MAP_SHARED, fd, REG_OFFSET);

    /* actual call to mmap() */

    tmp_ptr = (char *)mem_ptr;

    strcpy(tmp_ptr, "Hello World");  /* write something for test purposes and then check DSP side with JTAG */

    printf("check dual port memory");

     

    return 0;

    }

  • Linux on OMAP3 uses the SRAM so you don't want to overwrite the routines in there.  Look at the files with SRAM in the name to see where the Linux code ends. These are usually in arch/arm/mach-omap2 and arch/arm/plat-omap. I don't have my Linux code handy to give you exact file names.

    Steve K.

  • For OMAP3530, is there a sample code snippet available in linux for the following: In our user-space application, memset is called so frequently on the mmap'ed buffer (from Internal SRAM) to fill-up with zero's. We would like to off-load the processor from doing this by using DMA. Is there a way to configure DMA operation from application with the destination as the mmap'ed buffer (from Internal SRAM) to be filled with zero's and the source as mmap'ed location from Internal SRAM (with the value of zero). We are also thinking of configuring DMA in the user-space application for copying the content of media file (like mp3, flv,,etc) to Internal SRAM for further decoding to speed-up the process. Can you please suggest us the best way of doing this with / with out implementing kernel module. Can you please point me towards the sample code either in the supplied CD along with the OMAP3530-EVM or in the linux source. Venkat