• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 1462 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.

Accessing ARM Physical memory in DSP Tesla (OMAP4)

GregoireGentil
Expert 2330 points

Hello,

I have an application running on OMAP4 that grabs a frame from a video sensor in the Cortex-A9 through a standard v4l2 architecture. The frame is located in a contiguous memory. After some hacks, I have the physical address of this frame. dmesg gives:

cma: dma_alloc_from_contiguous(cma ed11a000, count 29, align 5)
cma: dma_alloc_from_contiguous(): returned c1113000
cma: dma_alloc_from_contiguous(cma ed11a000, count 29, align 5)
cma: dma_alloc_from_contiguous(): returned c1113400
cma: dma_alloc_from_contiguous(cma ed11a000, count 29, align 5)
cma: dma_alloc_from_contiguous(): returned c1113800
cma: dma_alloc_from_contiguous(cma ed11a000, count 29, align 5)
cma: dma_alloc_from_contiguous(): returned c1113c00
Physical address of v4l2 buffer #1/#4 is 0xab080000 (printk added by me)
Physical address of v4l2 buffer #2/#4 is 0xab0a0000 (printk added by me)
Physical address of v4l2 buffer #3/#4 is 0xab0c0000 (printk added by me)
Physical address of v4l2 buffer #4/#4 is 0xab0e0000 (printk added by me)

So the frame is located at 0xab080000 and I have managed to access it with devmem2 in Cortex-A9 user-space.

I would like to acces this frame in my DSP Tesla application which is linked through "tesla-syslink-2.00.09.29", but Tesla crashes:

omap-iommu omap-iommu.0: dsp: version 2.0
omap-iommu omap-iommu.0: iommu fault: da 0xab0803c0 flags 0x0
rproc remoteproc0: fatal error #1 detected in dsp_c0: error type mmufault
omap-iommu omap-iommu.0: dsp: errs:0x00000002 da:0xab0803c0 pgd:0xea0d2ac00
rproc remoteproc0: trying to recover dsp_c0

After some talks, I have the feeling that I need to modify the file TeslaAmmu.cfg but I'm not sure how to modify it and if it's the right file. Any help? Many thanks in advance.

/*
* ======== TeslaAmmu.cfg ========
*
* An example configuration script used by DSP sample applications.
*/

//////////////////////////////////////////////////////////////////////////////////////////////////////////////
A lot of config stuff
//////////////////////////////////////////////////////////////////////////////////////////////////////////////

/* IPC region: Large Page (512M); non-cacheable, posted */

/* config large page[3] to map 512MB VA 0xA0000000 to L3 0xBFFFFFFF */
AMMU.largePages[4].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[4].logicalAddress = 0xA0000000;
AMMU.largePages[4].size = AMMU.Large_512M;
AMMU.largePages[4].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[4].L1_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[4].L1_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[4].L1_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;
AMMU.largePages[4].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[4].L2_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[4].L2_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[4].L2_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;

  • 0
    TI__Mastermind 24525 points

    This is confidential code given to you under NDA. Please don't post it on a public forum.

  • 0 in reply to Mayank Mangla
    Expert 2330 points

    I didn't want to offend TI rules and I have edited the post to strip down the file content a little bit.

    This is not an excuse but you have much worse on Google and the same file for Ducati is available on a repository which is managed by TI employees:

    https://gitorious.org/ducati-syslink/ducati-syslink/source/8e2c149be04f4ee039301aa6875e3b31f162f95f:packages/ducati_cfg/DucatiAmmu.cfg

    Also, this post http://e2e.ti.com/support/embedded/bios/f/355/p/160345/584079.aspx publishes similar data.

    I could list many other similar links.

  • 0
    TI__Prodigy 10 points

    Have you checked to make sure that 0xA0000000 on the DSP will match up with 0xA0000000 on the ARM? I think the physical maps may be different too. 

  • 0 in reply to GregoireGentil
    TI__Guru** 112175 points

    The IPC portion of the code is public (ducati-syslink or sysbios-rpmsg) as from the links you have given and others on git.omapzoom.org or dev.omapzoom.org sites, but be careful about the other portions of the code that may have been delivered to you as one package (which is what Mayank might have hinted at). The current post is not an issue. 

  • 0
    TI__Guru** 112175 points

    OK, the main issue is that you are getting an MMU fault since the addresses 0xab0X0000 are not mapped into the L2 MMU of the DSP processor. The AMMU configuration that you have cited is merely setting the cache attributes for a range of 512MB starting at logical address 0xA0000000. The AMMU configuration applies the rules based on addresses as seen by the DSP processor, but it does not necessarily mean the actual DDR addresses. 

    It wasn't clear if you are using SysLink or RPMsg. You would have to map your buffers into the DSP address space by programming the appropriate L1/L2 page tables. Depending on the IPC stack, you might have to make some kernel changes if you are allocating the buffers dynamically. 

  • 0 in reply to Suman Anna
    Expert 2330 points

    Thanks Suman. It helps me to understand that this config file is not the right place to search. After more investigations, and without revealing the secrets of god, I found this file:

    ./build/tesla-syslink-2.00.09.29/src/ti/resources/rsc_table_dsp.h

    where the real mapping happens. I was therefore able to add a mapping for my specific region and this makes it work.

    My answers is the real answer but I marked yours as answer :-)

  • 0 in reply to GregoireGentil
    TI__Guru** 112175 points

    Glad you could move forward with your issue. Yes, the rsc_table_dsp.h gives out the memory mapping information to the remoteproc driver so that the driver can program the MMU appropriately. 

    That said, as I mentioned in the previous post, it depends on how you are allocating the memory for your buffers. If you are doing it at runtime and let the kernel give you memory, then ideally you also need to map the buffers into the MMU at runtime from the kernel side. If you are using a dedicated carveout set aside during kernel boot for your buffers, then the approach you used is fine, since the carveouts have a specific functionality. This is mainly from the perspective of achieving proper memory protection/sandboxing between the DSP and the Linux kernel memory.

    Btw, you might have received the entire package together  through NDA, but the IPC portion (all the code under tesla-syslink-2.00.09.29)  is from the following public project:

    http://git.omapzoom.org/?p=repo/sysbios-rpmsg.git

    There is an older wiki (based on 3.0 kernel and rpmsg-1.00 branch), but it might be useful for you for some of the design details.

    http://www.omappedia.org/wiki/Category:RPMsg