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

RTOS/TMDXIDK5728: Resource table conflict for DSP2

netrover
Intellectual 850 points
Part Number: TMDXIDK5728
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

There appears to be something else configuring the resource table for DSP2 trying to use a custom resource table.

DSP1 works after installing it on the target idkAM5728 board. However DSP2 will not install. These messages are shown after the command use to install DSP2,

-----------------------------------------------

cd /lib/firmware

rm dra7-dsp2-fw.xe66

ln -s /lib/firmware/ipc/ipcm/server_dsp2_mod8.xe66 dra7-dsp2-fw.xe66

cd /sys/bus/platform/drivers/omap-rproc

echo 41000000.dsp > unbind

[24952.221267] omap_hwmod: mmu1_dsp2: _wait_target_disable failed
[24952.234417] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[24952.240308]  remoteproc3: stopped remote processor 41000000.dsp
[24952.247751]  remoteproc3: releasing 41000000.dsp

echo 41000000.dsp > bind

[24999.808025] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[24999.815857]  remoteproc3: 41000000.dsp is available
[24999.820767]  remoteproc3: Note: remoteproc is still under development and considered experimental.
[24999.829767]  remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[24999.847427]  remoteproc3: powering up 41000000.dsp
root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# [24999.852682]  remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 4236204
[24999.871654] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[24999.877553] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[24999.883584] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
[24999.892308] omap-rproc 41000000.dsp: dma_alloc_coherent err: 2097152
[24999.898695]  remoteproc3: Failed to process resources: -12
[24999.912976] omap_hwmod: mmu1_dsp2: _wait_target_disable failed
[24999.925941] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[24999.931827]  remoteproc3: rproc_boot() failed -12
[24999.936586] virtio_rpmsg_bus: probe of virtio3 failed with error -12
[24999.942978]  remoteproc3: registered virtio3 (type 7)

-----------------------------------------------

The custom resource table is slightly different between DSP1 and DSP2, because DSP2 has 8 MBytes reserved for it while DSP1 has 56 MBytes. The following resource table entries are for DSP1 and DSP2,

DSP1:

#define DSP_MEM_IPC_VRING_SIZE  SZ_1M
#define DSP_MEM_IPC_DATA_SIZE   SZ_1M
#define DSP_MEM_TEXT_SIZE       (SZ_1M * 4)
#define DSP_MEM_DATA_SIZE       (SZ_1M * 48)
#define DSP_MEM_HEAP_SIZE       (SZ_1M * 3)
#define DSP_MEM_IOBUFS_SIZE     (SZ_1M * 90)

DSP2:

#define DSP_MEM_IPC_VRING_SIZE  SZ_1M
#define DSP_MEM_IPC_DATA_SIZE   SZ_1M
#define DSP_MEM_TEXT_SIZE       (SZ_1M * 1)
#define DSP_MEM_DATA_SIZE       (SZ_1M * 5)
#define DSP_MEM_HEAP_SIZE       (SZ_1M * 2)
#define DSP_MEM_IOBUFS_SIZE     (SZ_1M * 90)

The .map files for each are as follows,

DSP1:

OUTPUT FILE NAME:   <bin/release/server_dsp1.xe66>
ENTRY POINT SYMBOL: "ti_sysbios_family_c64p_Hwi0"  address: 95023000


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2SRAM                00800000   00040000  00000000  00040000  RW X
  OCMC_RAM1             40300000   00080000  00000000  00080000  RW X
  OCMC_RAM2             40400000   00100000  00000000  00100000  RW X
  OCMC_RAM3             40500000   00100000  00000000  00100000  RW X
  EXT_CODE              95000000   00400000  0002316c  003dce94  RW X
  EXT_DATA              95400000   03000000  00072ab2  02f8d54e  RW  
  EXT_HEAP              98400000   00300000  00000000  00300000  RW  
  TRACE_BUF             9f000000   00060000  00008004  00057ffc  RW  
  EXC_DATA              9f060000   00010000  00000200  0000fe00  RW  
  PM_DATA               9f070000   00020000  00000000  00020000  RW X
  CMEM                  a0000000   0c000000  00000000  0c000000  RW  

DSP2:

OUTPUT FILE NAME:   <bin/release/server_dsp2.xe66>
ENTRY POINT SYMBOL: "ti_sysbios_family_c64p_Hwi0"  address: 95023000


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2SRAM                00800000   00040000  00000000  00040000  RW X
  OCMC_RAM1             40300000   00080000  00000000  00080000  RW X
  OCMC_RAM2             40400000   00100000  00000000  00100000  RW X
  OCMC_RAM3             40500000   00100000  00000000  00100000  RW X
  EXT_CODE              95000000   00400000  00022f70  003dd090  RW X
  EXT_DATA              95400000   03000000  00072a96  02f8d56a  RW  
  EXT_HEAP              98400000   00300000  00000000  00300000  RW  
  TRACE_BUF             9f000000   00060000  00008004  00057ffc  RW  
  EXC_DATA              9f060000   00010000  00000200  0000fe00  RW  
  PM_DATA               9f070000   00020000  00000000  00020000  RW X
  CMEM                  a0000000   0c000000  00000000  0c000000  RW  

As you can see EXT_CODE, EXT_DATA, and EXT_HEAP lengths match exactly between the two, which total too large for the DSP2 reserved memory.

CMEM is also being used.

In the DSP2 MainDsp2.c program the absolute path to the resource table is entered to try to avoid maybe using the wrong one, as follows,

#include "/home/user01/ti/ipc_3_44_00_00/examples/DRA7XX_linux_elf/ex02_messageq/dsp2/rsc_table_dsp.h"

and the following lines are included in DSP2.cfg to override the default resource table,

var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true;

Does anyone know what is happening?

Thanks

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 850 points
    Hello,
    I was able to figure this out, though a few questions remain.
    An additional file needs to have its EXT_CODE, EXT_DATA, and EXT_HEAP data lengths match that being allocated in the custom resource table. In the example IPC programs for ex01_messageq in the shared folder the file, config.bld, was allocating memory that was showing in the .map file for DSP1 and DSP2. Those were,

    EXT_CODE 95000000 00400000 00022f70 003dd090 RW X
    EXT_DATA 95400000 03000000 00072a96 02f8d56a RW
    EXT_HEAP 98400000 00300000 00000000 00300000 RW

    Because config.bld assigns the same table entries to DSP2 that are for DSP1 as follows,

    Build.platformTable["ti.platforms.evmDRA7XX:dsp2"] =
    Build.platformTable["ti.platforms.evmDRA7XX:dsp1"];

    I used a smaller amount of DDR for EXT_DATA, since DSP2 only has 8 MB reserved in the memory carve out. CMEM memory map information was also added to config.bld.
    That is what I initially did to get the example also work with DSP1 and DSP2. config.bld can be modified to let DSP1 use more of its reserved memory space. And of course the carve out can also be modified.

    So config.bld should be mentioned more in documentation that shows how to customize the resource table and where it looks like the linked memory map is allocated.
    Also, I did not see exactly where config.bld is being referenced in the make files, so I still do not know how to use outside of the example compile directory structure.
    Thanks