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.

AM5728: MMU fault in IPC between DSP and A15

Part Number: AM5728

Hello TI community,

I am trying to make use of TI IPC module (version 3.47.01) to communicate between A15 and DSP. On A15 a QNX 7.0 is running (I know, TI does not support QNX, but TI provides sources for IPC on QNX). Thus, my software based on the example ex41_forwardmsg for Linux.

At first, I compile the ipc sources for my QNX with the help of following command: <path_to_qnx>\qnx700\host\win64\x86_64\usr\bin\make.exe -f .\ipc-qnx.mak all

After a successful compiling, I added the binaries to my OS image so that I can call the ipc module on qnx. Further, I need a software for my slave core (DSP1) which has  - apart from sources - a memory map file (config.bld) and a resource table (rsc_table.h - based on ex41_forwardmsg/dsp1/rsc_table.h). I compared my custom resource table with this one from http://processors.wiki.ti.com/index.php/IPC_Resource_customTable - but I don't know, whether I understand the rsc table correctly.

My config.bld looks like:

var SR_0 = {
    name: "SR_0", space: "data", access: "RWX",
    base: 0xBFC00000, len: 0x00100000,
    comment: "SR#0 Memory (16 MB)"
};

Build.platformTable["ti.platforms.idkAM572X:dsp1"] = {
    externalMemoryMap: [
        [ "DSP1_CODE", {
            name: "DSP1_CODE", space: "code", access: "RWX",
            base: 0x90000000, len: 0x01000000,
            comment: "DSP1 Program Memory"
        }],
        [ "DSP1_DATA", {
            name: "DSP1_DATA", space: "data", access: "RW",
            base: 0x91000000, len: 0x05000000,
            comment: "DSP1 Data Memory"
        }],
        [ "DSP1_HEAP", {
            name: "DSP1_HEAP", space: "data", access: "RW",
            base: 0x96000000, len: 0x00300000,
            comment: "DSP1 Heap Memory"
        }],
        [ "DSP1_TRACE", {
            name: "DSP1_TRACE", space: "data", access: "RW",
            base: 0x9700000, len: 0x00060000,
            comment: "DSP1 Trace Memory"
        }],
        [ "EXC_DATA", {
            name: "EXC_DATA", space: "data", access: "RW",
            base: 0x97060000, len: 0x00010000,
            comment: ""
        }],
        [ "PM_DATA", {
            name: "PM_DATA", space: "data", access: "RW",
            base: 0x97070000, len: 0x00020000,
            comment: "Power Management"
        }],
        [ "SR_0", SR_0 ]
    ],
    codeMemory:  "DSP1_CODE",
    dataMemory:  "DSP1_DATA",
    stackMemory: "DSP1_DATA",
    l1DMode: "32k",
    l1PMode: "32k",
    l2Mode: "128k"
};

Regarding config.bld, I configure my resource table as follows (only a snippet):

#define DSP_MEM_TEXT            0x90000000
/* Co-locate alongside TILER region for easier flushing */
#define DSP_MEM_IOBUFS          0x8B000000
#define DSP_MEM_DATA            0x91000000
#define DSP_MEM_HEAP            0x96000000

#define DSP_MEM_IPC_DATA        0x99000000
#define DSP_MEM_IPC_VRING       0xA0000000
#define DSP_MEM_RPMSG_VRING0    0xA0000000
#define DSP_MEM_RPMSG_VRING1    0xA0004000
#define DSP_MEM_VRING_BUFS0     0xA0040000
#define DSP_MEM_VRING_BUFS1     0xA0080000

#define DSP_SR0_VIRT            0xBFC00000
#define DSP_SR0                 0xBFC00000

#define DSP_MEM_IPC_VRING_SIZE  SZ_1M
#define DSP_MEM_IPC_DATA_SIZE   SZ_1M
#define DSP_MEM_TEXT_SIZE       (SZ_1M * 16)
#define DSP_MEM_DATA_SIZE       (SZ_1M * 80)
#define DSP_MEM_HEAP_SIZE       (SZ_1M * 3)
#define DSP_MEM_IOBUFS_SIZE     (SZ_1M * 90)
#define DSP_SR0_SIZE            (SZ_1M * 1)

/*
 * Assign fixed RAM addresses to facilitate a fixed MMU table.
 */
/* See CMA BASE addresses in Linux side: arch/arm/mach-omap2/remoteproc.c */
#define PHYS_MEM_IPC_VRING      0x99000000

/* Need to be identical to that of IPU */
#define PHYS_MEM_IOBUFS         0xBA300000

...

    /* rpmsg vdev entry */
    {
        TYPE_VDEV, VIRTIO_ID_RPMSG, 0,
        RPMSG_DSP_C0_FEATURES, 0, 0, 0, 2, { 0, 0 },
        /* no config data */
    },
    /* the two vrings */
    { DSP_MEM_RPMSG_VRING0, 4096, DSP_RPMSG_VQ0_SIZE, 1, 0 },
    { DSP_MEM_RPMSG_VRING1, 4096, DSP_RPMSG_VQ1_SIZE, 2, 0 },

    {
        TYPE_CARVEOUT,
        DSP_MEM_TEXT, 0,
        DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
    },

    {
        TYPE_CARVEOUT,
        DSP_MEM_DATA, 0,
        DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    {
        TYPE_CARVEOUT,
        DSP_MEM_HEAP, 0,
        DSP_MEM_HEAP_SIZE, 0, 0, "DSP_MEM_HEAP",
    },

    {
        TYPE_CARVEOUT,
        DSP_MEM_IPC_DATA, 0,
        DSP_MEM_IPC_DATA_SIZE, 0, 0, "DSP_MEM_IPC_DATA",
    },

    {
        TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",
    },

    {
        TYPE_DEVMEM,
        DSP_MEM_IPC_VRING, PHYS_MEM_IPC_VRING,
        DSP_MEM_IPC_VRING_SIZE, 0, 0, "DSP_MEM_IPC_VRING",
    },

    {
        TYPE_DEVMEM,
        DSP_MEM_IOBUFS, PHYS_MEM_IOBUFS,
        DSP_MEM_IOBUFS_SIZE, 0, 0, "DSP_MEM_IOBUFS",
    },

...

    {
        TYPE_DEVMEM,
        DSP_PERIPHERAL_ISS, L3_PERIPHERAL_ISS,
        SZ_256K, 0, 0, "DSP_PERIPHERAL_ISS",
    },

    {
        TYPE_DEVMEM,
        DSP_SR0_VIRT, DSP_SR0,
        DSP_SR0_SIZE, 0, 0, "DSP_SR0",
    },

In my DSP1.cfg file, I added following lines:

var SysMin = xdc.useModule('ti.trace.SysMin');
Program.sectMap[".tracebuf"] = "DSP1_TRACE";
Program.sectMap[".errorbuf"] = "EXC_DATA";

/* Override the default resource table with my own */
var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true; 
Resource.loadSegment = "DSP1_CODE";

xdc.useModule('ti.sysbios.heaps.HeapBuf');
xdc.useModule('ti.sysbios.knl.Task');

xdc.global.SR0_cacheEnable = false;
xdc.global.procName = "DSP1";
var ipc_cfg = xdc.loadCapsule("../shared/ipc.cfg.xs");

xdc.useModule('ti.ipc.ipcmgr.IpcMgr');

/* Setup MessageQ transport */
var VirtioSetup = xdc.useModule('ti.ipc.transports.TransportRpmsgSetup');
/* Setup NameServer remote proxy */
var NsRemote = xdc.useModule("ti.ipc.namesrv.NameServerRemoteRpmsg");
BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');
BIOS.addUserStartupFunction('&IpcMgr_callIpcStart');

Before reporting my error log, I have the same problem with downloading my slave core app to IFS as described here: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/555459?AM572x-IPC-3-43-02-04-on-QNX-SDP-7-0-Beta. Have someone solved this problem?

Now, I can start ipc on QNX as follows:

ipc DSP1 /tmp/dsp1_app.out

I get the following print:

Starting IPC resource manager...
RscTable_process: RscTable version is [1]
RscTable_process: vring [256] @ [0xa0000000]
RscTable_process: vring [256] @ [0xa0004000]
RscTable_process: carveout [DSP_MEM_TEXT] @ da [0x90000000] pa [0x81000000] len [0x1000000]
RscTable_process: carveout [DSP_MEM_DATA] @ da [0x91000000] pa [0x82000000] len [0x5000000]
RscTable_process: carveout [DSP_MEM_HEAP] @ da [0x96000000] pa [0xfe700000] len [0x300000]
RscTable_process: carveout [DSP_MEM_IPC_DATA] @ da [0x9f000000] pa [0xfea00000] len [0x100000]
RscTable_process: trace [trace:dsp] @ da [0x09700000] len [0x8000]
RscTable_process: devmem [DSP_MEM_IPC_VRING] @ da [0xa0000000] pa [0xfe600000] len [0x100000]
RscTable_process: devmem [DSP_MEM_IOBUFS] @ da [0x8b000000] pa [0xba300000] len [0x5a00000]
RscTable_process: devmem [DSP_TILER_MODE_0_1] @ da [0x60000000] pa [0x60000000] len [0x10000000]
RscTable_process: devmem [DSP_TILER_MODE_2] @ da [0x70000000] pa [0x70000000] len [0x8000000]
RscTable_process: devmem [DSP_TILER_MODE_3] @ da [0x78000000] pa [0x78000000] len [0x8000000]
RscTable_process: devmem [DSP_PERIPHERAL_L4CFG] @ da [0x4a000000] pa [0x4a000000] len [0x1000000]
RscTable_process: devmem [DSP_PERIPHERAL_L4PER1] @ da [0x48000000] pa [0x48000000] len [0x200000]
RscTable_process: devmem [DSP_PERIPHERAL_L4PER2] @ da [0x48400000] pa [0x48400000] len [0x400000]
RscTable_process: devmem [DSP_PERIPHERAL_L4PER3] @ da [0x48800000] pa [0x48800000] len [0x800000]
RscTable_process: devmem [DSP_PERIPHERAL_L4EMU] @ da [0x54000000] pa [0x54000000] len [0x1000000]
RscTable_process: devmem [DSP_PERIPHERAL_DMM] @ da [0x4e000000] pa [0x4e000000] len [0x100000]
RscTable_process: devmem [Ø] @ da [0x00000013] pa [0x00000000] len [0x0]
RscTable_process: devmem [Ø] @ da [0x00000013] pa [0x00000000] len [0x0]
  Programming Dsp memory regions
=========================================
VA = [0x800000] of size [0x40000] at PA = [0x40800000]
VA = [0xe00000] of size [0x8000] at PA = [0x40e00000]
VA = [0xf00000] of size [0x8000] at PA = [0x40f00000]
VA = [0x90000000] of size [0x1000000] at PA = [0x81000000]
VA = [0x91000000] of size [0x5000000] at PA = [0x82000000]
VA = [0x96000000] of size [0x300000] at PA = [0xfe700000]
VA = [0x9f000000] of size [0x100000] at PA = [0xfea00000]
VA = [0xa0000000] of size [0x100000] at PA = [0xfe600000]
VA = [0x8b000000] of size [0x5a00000] at PA = [0xba300000]
VA = [0x60000000] of size [0x10000000] at PA = [0x60000000]
VA = [0x70000000] of size [0x8000000] at PA = [0x70000000]
VA = [0x78000000] of size [0x8000000] at PA = [0x78000000]
VA = [0x4a000000] of size [0x1000000] at PA = [0x4a000000]
VA = [0x48000000] of size [0x200000] at PA = [0x48000000]
VA = [0x48400000] of size [0x400000] at PA = [0x48400000]
VA = [0x48800000] of size [0x800000] at PA = [0x48800000]
VA = [0x54000000] of size [0x1000000] at PA = [0x54000000]
VA = [0x4e000000] of size [0x100000] at PA = [0x4e000000]

And in sys2log, I noticed the following MMU fault:

Jan 01 01:32:05.498                     ipc.311315                 slog*     0  DSP clock enabled:DSP_CLKSTCTRL = 0x102

Jan 01 01:32:05.498                     ipc.311315                 slog      0  DSP:RST2 released!

Jan 01 01:32:05.498                     ipc.311315                 slog      0  DSP:SYS_MMU_CONFIG MMU0 and MMU1 enabled!

Jan 01 01:32:05.640                     ipc.311315                 slog      0  *** benelli_mmu_init: phys_addr is invalid
        Error [0x0] at Line no: 821 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/vayu/vayudsp/VAYUDspEnabler.c

Jan 01 01:32:05.640                     ipc.311315                 slog      0  De-assert DSP RST1

Jan 01 01:32:05.640                     ipc.311315                 slog      0  DSP:RST1 released!

Jan 01 01:32:05.640                     ipc.311315                 slog      0  ****************** DSP-MMU0 Fault ******************
Jan 01 01:32:05.640                     ipc.311315                 slog      0  runSlave successful for core 4

Jan 01 01:32:05.640                     ipc.311315                 slog      0  ****    addr: 0x90033c00
Jan 01 01:32:05.640                     ipc.311315                 slog      0  ****    TRANSLATIONFAULT
Jan 01 01:32:05.640                     ipc.311315                 slog      0  **************************************************
Jan 01 01:32:05.640                     ipc.311315                 slog      0  ipc_error_cb: Received Error Callback for DSP1 : MMU Fault

Jan 01 01:32:05.640                     ipc.311315                 slog      0  ipc_error_cb: Scheduling recovery...
Jan 01 01:32:05.640                     ipc.311315                 slog      0  stopping DSP1
Jan 01 01:32:05.641                     ipc.311315                 slog      0  Assertion at Line no: 832 in C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c: (size != 0) : failed

 

Regarding map file of DSP app, section .vecs is stored at address 0x90033C00.

 

Does someone can help me to solve my problem and maybe to answer the following questions:

  • How can I interpret the following line of ipc output: carveout [DSP_MEM_TEXT] @ da [0x90000000] pa [0x81000000] len [0x1000000]?
    My dsp text section is stored at 0x90000000 (virtual) and physically at 81000000?
  • How do config.bld and resource table correlate with each other?
  • Which #defines in rsc table are important and application specific (virtual or physical), respectively?
    What about:
    • PHYS_MEM_IPC_VRING:
    • PHYS_MEM_IOBUFS / DSP_MEM_IOBUFS
    • DSP_MEM_IPC_DATA
    • DSP_MEM_TEXT

  • Which #define (memory address) in rsc table has to be identical with memory mapping in qnx?
  • (qnx  specific - maybe any TIer knows something about this ;-)): memory mapping in qnx is done with an "-r<addr>,<size>" argument, right? Which address and size has to be set here? Only for the shared memory region? 
    My current setting is: -r0x99000000,0x0F000000 (belonging to value of #PHYS_MEM_IPC_VRING)

Thanks a lot for your help.

Best regards

Thomas

  • Hi,

    I have notified the IPC experts. Note, that as you mentioned, QNX is not supported by TI, so I'm not sure that they can answer your questions.
  • okay, the last two lines of the ipc output are strange (because of memory address and name). If I delete the last two entries in resource table (I added these entries because of the example), I will get the following log:

    Jan 01 00:17:08.732                     ipc.213011                 slog*     0  ****************** DSP-MMU0 Fault ******************
    Jan 01 00:17:08.732                     ipc.213011                 slog      0  DSP clock enabled:DSP_CLKSTCTRL = 0x102

    Jan 01 00:17:08.732                     ipc.213011                 slog      0  ****    addr: 0x9a000000
    Jan 01 00:17:08.732                     ipc.213011                 slog      0  DSP Resets in not proper state! [0x0]

    Jan 01 00:17:08.732                     ipc.213011                 slog      0  ****    TRANSLATIONFAULT
    Jan 01 00:17:08.732                     ipc.213011                 slog      0  DSP:RST2 released!

    Jan 01 00:17:08.732                     ipc.213011                 slog      0  **************************************************
    Jan 01 00:17:08.732                     ipc.213011                 slog      0  DSP:SYS_MMU_CONFIG MMU0 and MMU1 enabled!

    Jan 01 00:17:08.874                     ipc.213011                 slog      0  De-assert DSP RST1

    Jan 01 00:17:08.874                     ipc.213011                 slog      0  DSP:RST1 released!

    Jan 01 00:17:08.875                     ipc.213011                 slog      0  runSlave successful for core 4

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  *** ProcMgr_translateAddr: Processor_translateAddr failed
            Error [0xfffffff3] at Line no: 2136 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/ProcMgr.c

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  *** ProcMgr_translateAddr: Failed to translate address!
            Error [0xfffffff3] at Line no: 2163 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/ProcMgr.c

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  *** init_ipc_trace_device: mmap_device_io failed
            Error [0xfffffff3] at Line no: 1029 in file C:/ti/ipc_3_47_01_00/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/syslink_main.c

    Jan 01 00:17:08.876                     ipc.213011                 slog      0  errno 22
    Jan 01 00:17:08.876                     ipc.213011                 slog      0  IPC: device init failed
    Jan 01 00:17:08.876                     ipc.213011                 slog      0  IPC: device init failed

    The next error is: VAYUDSPPROC_translate: srcAddr not found in slave address space.

  • Hi Thomas,

    TI IPC3.x package does provide QNX IPC tests as part of the IPC build. You can find information about them here:

    processors.wiki.ti.com/.../IPC_Install_Guide_QNX
    processors.wiki.ti.com/.../IPC_Install_Guide_QNX
    processors.wiki.ti.com/.../IPC_Install_Guide_QNX

    Additionally, standalone IPC QNX examples can be generated by following the instructions here:
    processors.wiki.ti.com/.../Examples
    processors.wiki.ti.com/.../IPC_Install_Guide_QNX

    Have you tried any of the IPC3.x tests/examples for QNX?

    Thanks,
    Angela
  • Hi Angela,

    thanks for your reply. I tried these examples on Friday. I get  some new output. After starting the slave core with "ipc DSP1 /tmp/server_dsp1.xe66", my slog seems to be okay because there are no errors:

    Jan 01 00:09:46.362                      ipc.81939                 slog*     0  DSP clock enabled:DSP_CLKSTCTRL = 0x102
    Jan 01 00:09:46.362                      ipc.81939                 slog      0  DSP:RST2 released!
    Jan 01 00:09:46.362                      ipc.81939                 slog      0  DSP:SYS_MMU_CONFIG MMU0 and MMU1 enabled!
    Jan 01 00:09:46.504                      ipc.81939                 slog      0  De-assert DSP RST1
    Jan 01 00:09:46.504                      ipc.81939                 slog      0  DSP:RST1 released!
    Jan 01 00:09:46.504                      ipc.81939                 slog      0  runSlave successful for core 4
    Jan 01 00:09:46.506                      ipc.81939                 slog      0  IPC resource manager started

     

     

    I still have some problems with the . My slave core hangs up after printing this:

    [      0.000] 19 Resource entries at 0x90000000
    [      0.000] [t=0x0004b355] xdc.runtime.Main: --> main:
    [      0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
    [      0.000] [t=0x000b462b] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
    [      0.000] [t=0x00101b35] xdc.runtime.Main: --> smain:
    [      0.000] [t=0x0011ec66] Server: Creating HeapBufMP...

    I think, there are some troubles with the creation of my heap buffer. I will now try to debug in more details and will response if some troubles are left.

    Best regards

    Thomas

  • Meanwhile, my IPC applications are running and communicating successfully. Now, I am trying to understand the details of my configuration, particular the resource table of the slave application. I'm not sure about the meaning of some macros. Can someone help?

    #define DSP_MEM_TEXT            0x90000000
    #define DSP_MEM_DATA            0x90100000
    #define DSP_MEM_HEAP            0x95200000
    #define DSP_MEM_IPC_DATA        0x9F000000
    
    /* Co-locate alongside TILER region for easier flushing */
    #define DSP_MEM_IOBUFS          0x80000000
    /* Need to be identical to that of IPU */
    #define PHYS_MEM_IOBUFS         0xBA300000
    
    
    #define DSP_MEM_IPC_VRING       0xA0000000
    /* This address is derived from current IPU & ION carveouts */
    #define PHYS_MEM_IPC_VRING      0x99000000
    
    #define DSP_SR0_VIRT            0xBFC00000
    #define DSP_SR0                 0xBFC00000

    1. Line 1 - 4 are virtual addresses for the carveouts of my slave core. These addresses have to be identical with the code/data/heap memory section in corresponding config.bld file, but the addresses can be selected arbitrary, right?
    2. Line 4: What about this address? Which data will be stored at this virtual address? I noticed the suffix IPC_DATA, but what is the difference between this address and the address in line 12/14 or 16/17?
    3. Line 7 - 14: These addresses are necessary for the MMU to map the physical address to a virtual address. The prefix DSP_MEM_* represents a virtual address for the slave core, PHYS_MEM_* macros represent the physical address in RAM. Which part of my configuration affects these addresses? Can I define these addresses arbitrary?
    4. Line 16 & 17: What about these addresses? This is a 1:1 mapping, right? This address must be identical with the reserved memory address in QNX (see here), right?

    Thanks for your help...

    Best regards

    Thomas

  • Hi Thomas,

    Glad to hear that your IPC applications are running and communicating successfully.

    Thomas N. said:

    Line 1 - 4 are virtual addresses for the carveouts of my slave core. These addresses have to be identical with the code/data/heap memory section in corresponding config.bld file, but the addresses can be selected arbitrary, right?

    Yes, these are virtual addresses can be moved from these default addresses selected in the default resource table. For more information on creating a custom resource table, see

    Thomas N. said:

    Line 4: What about this address? Which data will be stored at this virtual address? I noticed the suffix IPC_DATA, but what is the difference between this address and the address in line 12/14 or 16/17?

    This address is used by IPC for storing other IPC-related memory apart from the memory used for communication between cores. The trace buffer, error information, and some power management related data are placed here. In the IPC samples, you will see TRACE_BUF, EXC_DATA, and PM_DATA placed here.

    Thomas N. said:

    Line 7 - 14: These addresses are necessary for the MMU to map the physical address to a virtual address. The prefix DSP_MEM_* represents a virtual address for the slave core, PHYS_MEM_* macros represent the physical address in RAM. Which part of my configuration affects these addresses? Can I define these addresses arbitrary?

    The default resource table is given as an example, but these addresses can be modified to fit the needs of the application. When changing them, make sure to update your memory map as well to be in sync. Some information on changing memory maps can be found here

    Note that in QNX (versus Linux or Android) IPC, the physical address of the Vring listed in the resource table is not used when programming the MMU. The physical memory is allocated dynamically at loading of the remote core and the resource table is updated in memory by the IPC loading process. The previous link mentions this also.

    Thomas N. said:

    Line 16 & 17: What about these addresses? This is a 1:1 mapping, right? This address must be identical with the reserved memory address in QNX (see here), right?

    In this example, the mapping is 1:1, but that is not required. Yes, this address must be reserved memory from QNX.

    Thanks,

    Angela

  • Hello Angela,

    thank you for your support. Your detailed information resolved my issue.
  • Hi,

    After running the examples successfully, I try to create my own IPC application based on the examples (identical rsc table and config.bld).

    But when I start my application, I still get the same error as decribed before:

    VAYUDSPPROC_translate: srcAddr not found in slave address space

    What does it mean? Which source address is not found in address space? Why do I get this message? And how can I solve this problem?

    Here are my first analysis:

    I think, the IPC app tries to map the given virtual address to the defined physical address.

    In line 61: virtual address 0xa0000000 is mapped to physical address 0xbf000000. The index of current rsc table entry is 7. Thus, I think the remaining address entries (index 0-6) of the resource table fails since the error occurs a few times. But I can give no account of it.

    Can somebody help me to understand and solve this problem?

    Here is the full log (verbosity = 6):

    Starting IPC resource manager...
    RscTable_process: RscTable version is [1]
    RscTable_process: vring [256] @ [0xa0000000]
    RscTable_process: vring [256] @ [0xa0004000]
    RscTable_process: carveout [DSP_MEM_TEXT] @ da [0x90000000] pa [0xbf100000] len [0x100000]
    RscTable_process: carveout [DSP_MEM_DATA] @ da [0x90600000] pa [0xbf200000] len [0x600000]
    RscTable_process: carveout [DSP_MEM_HEAP] @ da [0x95600000] pa [0x90000000] len [0x5000000]
    RscTable_process: carveout [DSP_MEM_IPC_DATA] @ da [0x9f000000] pa [0xbf800000] len [0x100000]
    RscTable_process: trace [trace:dsp] @ da [0x9f000000] len [0x8000]
    RscTable_process: devmem [DSP_MEM_IPC_VRING] @ da [0xa0000000] pa [0xbf000000] len [0x100000]
    RscTable_process: devmem [DSP_MEM_IOBUFS] @ da [0x80000000] pa [0xba300000] len [0x5900000]
    RscTable_process: devmem [DSP_TILER_MODE_0_1] @ da [0x60000000] pa [0x60000000] len [0x10000000]
    RscTable_process: devmem [DSP_TILER_MODE_2] @ da [0x70000000] pa [0x70000000] len [0x8000000]
    RscTable_process: devmem [DSP_TILER_MODE_3] @ da [0x78000000] pa [0x78000000] len [0x8000000]
    RscTable_process: devmem [DSP_PERIPHERAL_L4CFG] @ da [0x4a000000] pa [0x4a000000] len [0x1000000]
    RscTable_process: devmem [DSP_PERIPHERAL_L4PER1] @ da [0x48000000] pa [0x48000000] len [0x200000]
    RscTable_process: devmem [DSP_PERIPHERAL_L4PER2] @ da [0x48400000] pa [0x48400000] len [0x400000]
    RscTable_process: devmem [DSP_PERIPHERAL_L4PER3] @ da [0x48800000] pa [0x48800000] len [0x800000]
    RscTable_process: devmem [DSP_PERIPHERAL_L4EMU] @ da [0x54000000] pa [0x54000000] len [0x1000000]
    RscTable_process: devmem [DSP_PERIPHERAL_DMM] @ da [0x4e000000] pa [0x4e000000] len [0x100000]
    RscTable_process: devmem [DSP_PERIPHERAL_ISS] @ da [0x52000000] pa [0x52000000] len [0x40000]
    RscTable_process: devmem [DSP_SR0] @ da [0xbfc00000] pa [0xbfc00000] len [0x100000]
    
    Jan 01 00:03:36.646                     ipc.139280                 slog*     0  resetSlave successful for core 4
    Jan 01 00:03:36.647                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.647                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.647                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.647                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:36.648                     ipc.139280                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.151                     ipc.180240                 slog*     0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c
    Jan 01 00:03:53.151                     ipc.180240                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c
    Jan 01 00:03:53.151                     ipc.180240                 slog      0  *** ElfLoaderTrgWrite_copy: Processor_translateAddr failed!
            Error [0x86a85001] at Line no: 518 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/loaders/Elf/Qnx/ElfLoader.c
    Jan 01 00:03:53.151                     ipc.180240                 slog      0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c
    Jan 01 00:03:53.151                     ipc.180240                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** ElfLoaderTrgWrite_copy: Processor_translateAddr failed!
            Error [0x86a85001] at Line no: 724 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/loaders/Elf/Qnx/ElfLoader.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** ElfLoaderTrgWrite_copy: Processor_translateAddr failed!
            Error [0x86a85001] at Line no: 518 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/loaders/Elf/Qnx/ElfLoader.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  *** ElfLoaderTrgWrite_copy: Processor_translateAddr failed!
            Error [0x86a85001] at Line no: 724 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/loaders/Elf/Qnx/ElfLoader.c
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  Processor_setState: Old state: 1, New state: 3
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  Processor_notify: New state: 3
    Jan 01 00:03:53.152                     ipc.180240                 slog      0  VAYUDSPPROC_translate: translated [7] srcAddr=0xa0000000 --> dstAddr=0xbf000000
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  VirtQueue_kick: Sending interrupt to proc 4 with payload 0x0
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** VAYUDSPPROC_translate: srcAddr not found in slave address space
            Error [0x86a85001] at Line no: 1777 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/family/common/vayu/vayudsp/VAYUDspProc.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** Processor_translateAddr: Processor address translation failed!
            Error [0x86a85001] at Line no: 690 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/Processor.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** ProcMgr_translateAddr: Processor_translateAddr failed
            Error [0xfffffff3] at Line no: 2136 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/ProcMgr.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** ProcMgr_translateAddr: Failed to translate address!
            Error [0xfffffff3] at Line no: 2163 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/procMgr/hlos/knl/ProcMgr.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** RscTable_update: Unable to get the Master PA for RscTable
            Error [0x86a87003] at Line no: 813 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/../../../../../ti/syslink/resources/RscTable.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  *** runSlave: Ipc_attach failed!
            Error [0x86a87003] at Line no: 226 in file C:/ti/ipc_3_47_01_00_TN/qnx/src/ipc3x_dev/ti/syslink/build/Qnx/resmgr/syslink_main.c
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.153                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.154                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  _ProcMgr_unmap check:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  VAYUDSPPROC_detach: Disabling Slave MMU ...
    Jan 01 00:03:53.155                     ipc.180240                 slog      0      VAYUDSPPROC_detach: Unmapping memory regions
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.155                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  Processor_setState: Old state: 3, New state: 0
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  Processor_notify: New state: 0
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.156                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.166                     ipc.180240                 slog      0  MultiProc_getName [DSP1]
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.167                     ipc.180240                 slog      0  MemoryOS_unmap:
    Jan 01 00:03:53.168                     ipc.180240                 slog      0  IPC: init failed

    Thanks a lot & best regards

    Thomas

  • HI Thomas,

    This error "srcAddr not found in slave address space" indicates that while doing a lookup of the physical address corresponding to a given remote core virtual address, no entry was found for the requested virtual address. This error is coming while loading the firmware. In this case "srcAddr" is coming from the firmware, and the "slave address space" is defined by the resource table.

    You can enable entry/exit traces by selecting the highest verbosity level (IPC_DEBUG_SLOG_LEVEL=7), and see what is the source address being translated when the failure occurs.

    Can you check your elf sections and make sure that each one is covered by a carveout in the resource table? You can use readelf or examine your generated xe66.map file. The resource table needs to define all memory that remote core needs to access. This includes memory for loading all the elf sections. You can look at the memory segment definitions and default resource table in the IPC examples for reference.

    Thanks,
    Angela
  • Hi Angela,

    thanks for your help. I solved the problem by comparing my memory mapping in map file (and config.bld respectively) with the resource table. The problem was the size of the data region in resource table which was not identical (too small) with the memory map in config.bld/map-file.

    Now, my slave app on DSP starts successfully (I can see some logs in sysmin).

    But one problem is still remaining. My remote app uses one of the PRU_ICSS Ports (J8 or J6 on idkAM5728). How can I access the PRU ports in my remote DSP app? I've added following lines to the resource table and increment the indexes (based on: http://processors.wiki.ti.com/index.php/IPC_Resource_customTable#New_TYPE_DEVMEM_entry):

    #define L3_PERIPHERAL_PRUSS     0x4B200000
    #define DSP_PERIPHERAL_PRUSS    0x6B200000
    
    #define L3_PRU_ICSS             0x4B200000
    #define DSP_PRU_ICSS            0x4B200000
    
    ...
    
        {
            TYPE_DEVMEM,
            IPU_PERIPHERAL_PRUSS, L3_PERIPHERAL_PRUSS,
            SZ_1M, 0, 0, "IPU_PERIPHERAL_PRUSS",
        },
    ...

    The given example based on IPU. Thus, I changed the prefix to DSP_. The address for DSP_PERIPHERAL_PRUSS (0x6B200000) is already busy by L3_TILER_MODE_0_1. If I change the address to another one (expect 0x4B200000), the IPC app prints the memory regions in an infinity loop (instead of one time) and does not return.

    1. What does this "infinity loop" mean? Why does this strange behavior happen?
    2. Is the physical address of PRU correct? Which virtual address is suitable for PRU in DSP? 

    Did I still make a mistake in rsc table / device tree?

    Thanks & best regards

    Thomas

  • HI Thomas,

    I'm glad to hear that you were able to solve the problem and you are able to load/start your DSP image. If this is a new issue relating to PRUSS access, can you please create a new thread?

    Without seeing logs, I'm not sure what "infinity loop" you are seeing, but it is possible that it is due to error recovery being repeatedly triggered. processors.wiki.ti.com/.../IPC_Slave_Error_Recovery

    When the IPC detects a fatal error from the remote core firmware (MMU fault, exception, watchdog timeout...), it will attempt to reload the firmware and start it again. You can disable error recovery as mentioned in processors.wiki.ti.com/.../IPC_Slave_Error_Recovery

    Thanks,
    Angela
  • Hi Angela,

    okay, my "infinity loop" was the recovery mode. If I disable it with the "-d" argument, it stops after the first try and I can look into the log. Thanks for your information.

    For my PRUSS access problem, I will open a new thread.

    Best regards

    Thomas