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

OMAP54x DSP/L3 Access

michael clark
Intellectual 520 points

I'm working with the IPC 3.23 ex02_messageq example (OMAP54XX_linux_elf), and I could use some help on modifying this project to access L3 main memory (e.g. GPMC registers).

From "ex02_messageq/dsp/DspAmmu.cfg," the AMMU configuration seems to already support Q2-Q3 L3 access, which includes the GPMC address range (0x50000000-0x51FFFFFF) as shown below:

/* Peripheral regions: Large Page (512M); non-cacheable, posted */
/* config large page[1] to map 512MB VA 0x40000000 to L3 0x5FFFFFFF */
AMMU.largePages[1].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[1].logicalAddress = 0x40000000;
AMMU.largePages[1].size = AMMU.Large_512M;
AMMU.largePages[1].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[1].L1_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[1].L1_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[1].L1_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;
AMMU.largePages[1].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[1].L2_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[1].L2_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[1].L2_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;

I noticed that address translation is disabled for each page, which I'm assuming is ok for now. This should also imply that the DSP can access L3 directly using a physical address.

Based on what I see, the AMMU config doesn't need to be modified, and it's probably safe to assume the DSP's MMU is configured during BIOS initialization.

I'm not sure if the next step is required, but I added the GPMC register address range to the DSP's memory map. This was done by modifying "config.bld" as shown below:

Build.platformTable["ti.platforms.sdp5430:dsp"] = {
    externalMemoryMap: [
        [ "EXT_CODE", sdp5430_ExtMemMapDsp.EXT_CODE ],
        [ "EXT_DATA", sdp5430_ExtMemMapDsp.EXT_DATA ],
        [ "EXT_HEAP", sdp5430_ExtMemMapDsp.EXT_HEAP ],
        [ "TRACE_BUF", sdp5430_ExtMemMapDsp.TRACE_BUF ],
        [ "EXC_DATA", sdp5430_ExtMemMapDsp.EXC_DATA ],
        [ "PM_DATA", sdp5430_ExtMemMapDsp.PM_DATA ],
        [ "GPMC_REG", {
            name: "GPMC_REG",
            base: 0x50000000,
            len:  0x02000000,
            space: "data",
			access: "RW" }
        ],
    ],
    codeMemory:  "EXT_CODE",
    dataMemory:  "EXT_DATA",
    stackMemory: "EXT_DATA",
};

At this point, I think I'm done, so I update the DSP with the following code snippet to access the GPMC revision address:

#define GPMC_REVISION_PTR     ((volatile uint32*) (0x50000000))
unsigned int val = *BASE_PTR;

which results in the following error while booting the kernel (Linux):

[    6.180908]  remoteproc0: Booting fw image tesla-dsp.xe64T, size 5860016
[    6.201049] omap-iommu omap-iommu.0: mmu_dsp: version 2.0
[    6.223510]  remoteproc0: remote processor dsp is now up
[    6.268402] omap-iommu omap-iommu.0: iommu fault: da 0x50000000 flags 0x0
[    6.268432]  remoteproc0: crash detected in dsp: type mmufault
[    6.268432] omap-iommu omap-iommu.0: mmu_dsp: errs:0x00000002 da:0x50000000 pgd:0xecfb9400 *pgd:px00000000
[    6.269683] omap-rproc omap-rproc.0: received echo reply from dsp
[    6.269744]  remoteproc0: handling crash #1 in dsp
[    6.269744]  remoteproc0: recovering dsp
[    6.272186] ------------[ cut here ]------------
[    6.272186] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x13c/0x17c()
[    6.272186] L3 custom error: MASTER:MPU TARGET:L4CFG

I'm obviously missing something here, and would appreciate any assistance.

Thanks!

  • 0
    Intellectual 520 points

    Looks like I spoke to soon. The AMMU comments were a bit confusing:

    /* Peripheral regions: Large Page (512M); non-cacheable, posted */
/* config large page[1] to map 512MB VA 0x40000000 to L3 0x5FFFFFFF */

    This page is only 512MB, which does not overlap the GPMC register address (0x50000000). I added a new large page and everything is working as expected.




  • 0 in reply to michael clark
    Intellectual 520 points

    When I try to access the GPMC_REVISION register @ 0x50000000, it always return's 0x0. From the Linux kernel source, I'm expecting 0x20, as displayed during bootup (e.g. 2.0).

    I inserted the following large page in my AMMU configuration:

    /* GPMC region: Large Page (512M); non-cacheable, posted */
/* config large page[2] to map 512MB VA/DA 0x50000000 */
AMMU.largePages[2].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[2].logicalAddress = 0x50000000;
AMMU.largePages[2].size = AMMU.Large_512M;
AMMU.largePages[2].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[2].L1_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[2].L1_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[2].L1_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;
AMMU.largePages[2].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[2].L2_posted = AMMU.PostedPolicy_POSTED;
AMMU.largePages[2].L2_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.largePages[2].L2_writePolicy = AMMU.WritePolicy_WRITE_THROUGH;

    and source:

    #define	GPMC_REVISION_MAJOR(l)		((l >> 4) & 0xf)
#define	GPMC_REVISION_MINOR(l)		(l & 0xf)
uint32 val = *((volatile uint32*)(0x50000000));
Log_print1(Diags_INFO, "GPMC Revision ID: %x", val );
Log_print2(Diags_INFO, "GPMC Revision ID: %d.%d", GPMC_REVISION_MAJOR(val),  GPMC_REVISION_MINOR(val) );

    I also tried to reset the GPMC and write/read to a CONFIG register, and zero is always returned.

    Any ideas?

  • 0 in reply to michael clark
    TI__Genius 12865 points

    Hi Michael,

    A virtual address is first translated by the AMMU, then by the IOMMU. The first is configured using the .cfg file that you are looking at. The second is programmed by the Linux loader when it loads the DSP. The mapping for the IOMMU is specified in the default resource table in <IPC_INSTALL_DIR>/packages/ti/ipc/remoteproc/rsc_table_omap5_dsp.h.

    I do not see the 0x50000000 range being mapped in the resource table, so you will need to add an entry to translate it (a straight translation would do). This page talks about how to override the default resource table with your own customized one:

    http://processors.wiki.ti.com/index.php/IPC_Resource_customTable

    I think your entry would look something similar to this:

    #define DSP_GPMC 0x50000000

    #define L4_GPMC 0x50000000

    ...

        {
            TYPE_DEVMEM,
            DSP_GPMC, L4_GPMC,
            SZ_1M, 0, 0, "DSP_GPMC", // Assuming you want to map 1M starting at 0x50000000 to 0x50000000 in physical memory
        },

    Best regards,

    -Vincent

  • 0 in reply to Vincent W.
    Intellectual 520 points

    Thanks Vincent!

    I did manage to figure all this out, but I was not aware that I could set a flag for a custom table. I just modified "rsc_table_omap5_dsp.h" from the IPC package, but that's about to be fixed.