• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1376 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: IPC- Experiments on Loading IPU1 firmware (dra7-ipu1-fw.xem4) image through linux Kernel

Gokul Kujulva
Genius 4465 points
Other Parts Discussed in Thread: TEST2

Tool/software: TI-RTOS

Hi all,

we are trying few experiments in IPC -source for memory map and resource table handling in vision-SDK.
we did few changes in the default IPC -source code for IPU1 and it is not working.
Please find the files in the attachment.

Command to Build xem4 image:
make -f ipc-bios.mak all


Changes

1. package.bld (packages/ti/ipc/tests/package.bld)

var evmDRA7XX_ExtMemMapIpu1 = {
EXT_CODE: {
name: "EXT_CODE",
base: 0x80000000,
len: 0x000fc000,
space: "code",
access: "RWX"
},
EXT_DATA: {
name: "EXT_DATA",
base: 0x80100000,
len: 0x00200000,
space: "data",
access: "RW"
},
EXT_HEAP: {
name: "EXT_HEAP",
base: 0x80300000,
len: 0x00300000,
space: "data",
access: "RW"
},
TRACE_BUF: {
name: "TRACE_BUF",
base: 0x9F000000,
len: 0x00060000,
space: "data",
access: "RW"
},
EXC_DATA: {
name: "EXC_DATA",
base: 0x9F060000,
len: 0x00010000,
space: "data",
access: "RW"
},
PM_DATA: {
name: "PM_DATA",
base: 0x9F070000,
len: 0x00020000,
space: "data",
access: "RWX" /* should this have execute perm? */
}
};

2 corresponding changes in rsc_table_vayu_ipu.h (packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h )
#define IPU_MEM_TEXT 0x80000000
#define IPU_MEM_DATA 0x80100000

Logs:


[ 221.120682] remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 4461564
[ 221.128210] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
[ 221.140064] remoteproc0: bad phdr da 0x0 mem 0xe0
[ 221.145112] remoteproc0: Failed to load program segments: -22
[ 221.155310] remoteproc0: rproc_boot() failed -22
[ 221.160279] virtio_rpmsg_bus: probe of virtio0 failed with error -22

Is it necessary to start the EXT_CODE from addrss 0x00004000?


Regards,
Gokul

test2.zip

  • 0
    TI__Mastermind 42515 points
    Hi Gokul,

    I have forwarded your question to IPC experts.

    Regards,
    Yordan
  • 0
    TI__Expert 3640 points

    Hi Gokul,

    EXT_CODE is not required from address 0x00004000; it may be moved. But, regardless of EXT_CODE location, a few segments still get placed starting at 0x0. You can see these in your shared map file or with readelf:

    SEGMENT ALLOCATION MAP

    run origin load origin length init length attrs members
    ---------- ----------- ---------- ----------- ----- -------
    00000000 00000000 000000e0 000000e0 r-x
    00000000 00000000 000000e0 000000e0 r-x .ducatiPowerBoot
    00000400 00000400 00000140 00000140 r--
    00000400 00000400 00000140 00000140 r-- .resetVecs
    00003000 00003000 0000044c 0000044c rw-
    00003000 00003000 0000044c 0000044c rw- .resource_table

    So, you do still need an entry in the resource table that starts from 0x0 and covers these above highlighted segments so that the Linux can load them. The modification to the resource table IPU_MEM_TEXT address removed the resource table TYPE_CARVEOUT entry for address 0x0, and so the Linux remoteproc was unable to load the segments. Each TYPE_CARVEOUT entry tells the remoteproc to allocate memory from the CMA pool and map it to the specified virtual address. These are for the ELF sections that are placed in those virtual addresses.

    You will need to add another TYPE_CARVEOUT entry to cover the above addresses in the resource table for loading to succeed.

    The following link gives some information on the resource table for your reference:

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

    Thanks,

    Angela