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 - IPC RPMessage_send failed vring description address not consistent when annouce "MessageQ" service to the HOST

Hi TI expert,

I have an issue with the IPC communication between Linux and IPU1 (TI-RTOS on M4).
The issue is on RTOS side when I try to send the message to linux side (RPMessage_send) to annouce the MessageQ service to host.

After several day of debug it's seems that I have good alignment between the AMMU define in .cfg and the resource table entry based on messageQ example 2.
I'm able to start correctly the application form linux side, read the resource table and memories carveout and connect with CC on IPU1 to debug.

all seems align excepted the vring descriptor address that I get during vring_init function. As you can see below the vr->description address is correct regarding AMMU and resource table (0xA0000000)
but the address of the descriptor is inconsistent.

So this have as consequence that when I try to copy the message at this address in RPMessage_send function an exception is raised.


As you can see the vring address are consistent.

You find below my AMMU configuration as my resource table

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*********************** Small Pages *************************/
/* smallPages[0] & smallPages[1] are auto-programmed by h/w */
/* Overwrite smallPage[1] so that 16K is covered. H/w reset value configures
* only 4K */
AMMU.smallPages[1].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[1].logicalAddress = 0x40000000;
AMMU.smallPages[1].translatedAddress = 0x55080000;
AMMU.smallPages[1].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[1].size = AMMU.Small_16K;
/* L2RAM: 64K mapped using 4 smallPages(16K); cacheable; translated */
/* config small page[2] to map 16K VA 0x20000000 to PA 0x55020000 */
AMMU.smallPages[2].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[2].logicalAddress = 0x20000000;
AMMU.smallPages[2].translatedAddress = 0x55020000;
AMMU.smallPages[2].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[2].L1_writePolicy = AMMU.WritePolicy_WRITE_BACK;
AMMU.smallPages[2].L1_allocate = AMMU.AllocatePolicy_ALLOCATE;
AMMU.smallPages[2].L1_posted = AMMU.PostedPolicy_POSTED;
AMMU.smallPages[2].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#define VAYU_IPU_1
/* IPU Memory Map */
#define L4_DRA7XX_BASE 0x4A000000
/* L4_CFG & L4_WKUP */
#define L4_PERIPHERAL_L4CFG (L4_DRA7XX_BASE)
#define IPU_PERIPHERAL_L4CFG 0x6A000000
#define L4_PERIPHERAL_L4PER1 0x48000000
#define IPU_PERIPHERAL_L4PER1 0x68000000
#define L4_PERIPHERAL_L4PER2 0x48400000
#define IPU_PERIPHERAL_L4PER2 0x68400000
#define L4_PERIPHERAL_L4PER3 0x48800000
#define IPU_PERIPHERAL_L4PER3 0x68800000
#define L4_PERIPHERAL_L4EMU 0x54000000
#define IPU_PERIPHERAL_L4EMU 0x74000000
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

On linux side we can see that the resource table and carveout memories are correctly loaded

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
root@am5728-gen357a:~# cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table
Entry 0 is of type vdev
ID 7
Notify ID 0
Device features 0x1
Guest features 0x1
Config length 0x0
Status 0x7
Number of vrings 2
Reserved (should be zero) [0][0]
Vring 0
Device Address 0x60000000
Alignment 4096
Number of buffers 256
Notify ID 0
Physical Address 0x0
Vring 1
Device Address 0x60004000
Alignment 4096
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
root@am5728-gen357a:~# cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories
Carveout memory entry:
Name: vdev0vring0
Virtual address: 9dd8d14f
DMA address: 0x000000009d000000
Device address: 0x60000000
Length: 0x3000 Bytes
Carveout memory entry:
Name: vdev0vring1
Virtual address: 1b3fb2ee
DMA address: 0x000000009d004000
Device address: 0x60004000
Length: 0x3000 Bytes
Carveout memory entry:
Name: IPU_MEM_IPC_DATA
Virtual address: 21de72d3
DMA address: 0x000000009d100000
Device address: 0x9f000000
Length: 0x100000 Bytes
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

So my question are:
Why the vring->desrciptor->address seems to be not consistent ?
Who is in charge to fill the IIPU_MEM_RPMSG_VRING0 address with allocated buffer ?

Many thanks in advance

Quentin

  • Hello Quentin,

    Could you please let us know what SDK versions you are using for both RTOS and LInux?

    -Josue

  • Hi Josue,

    Thanks for the response.
    For the rtos side we are on processor_sdk_rtos_am57xx_06_03_02_08.
    On linux side we are working with linux-ti-staging-rt-5.10.168. .config - Linux/arm 5.10.168 Kernel Configuration. This dues to the fact that we have a specific board and application requirement.

    You find join the kernel module configuration that we have configured - perhaps you have an expert eye and highlight a module that is missed in VIRTIO or other - for info rpmsg-proto is enabled but perhaps something is loss....

    68520.config.txt

    On the linux side we have build exmaple, LAD and libraries thanks to make -f ipc-linux.mak config and the pdf document IPC_Install_Guide_Linux.pdf present into sdk IPC folder. We are able to run DRA7XX_linux_elf\ex02_messageq on the host by starting previously LAD deamon.

    Here is the log.txt for the LAD deamon when start app on host - application not stared on the IPU1

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    WARN: Client /tmp/LAD/312 has not yet opened, will retry
    [65.439971] FIFO /tmp/LAD/312 opened for writing
    [65.440063] sent response
    [65.440093] DONE
    [65.440124] Retrieving command...
    [65.441101] Sending response...
    [65.441131] Retrieving command...
    [65.441406] LAD_MULTIPROC_GETCONFIG: calling MultiProc_getConfig()...
    [65.441436] MultiProc_getConfig() - 5 procs
    [65.441467] # processors in cluster: 5
    [65.441497] cluster baseId: 0
    [65.441497] ProcId 0 - "HOST"
    [65.441528] ProcId 1 - "IPU2"
    [65.441558] ProcId 2 - "IPU1"
    [65.441558] ProcId 3 - "DSP2"
    [65.441589] ProcId 4 - "DSP1"
    [65.441619] status = 0
    [65.441650] DONE
    [65.441650] Sending response...
    [65.441711] Retrieving command...
    [65.442932] LAD_NAMESERVER_SETUP: calling NameServer_setup()...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    As mentionned in my previous post, when I start the .xem4 on IPU1, resource table seems to be coherent, memories carveout also and I have that log that inform about application is started as you can see here 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    [ 773.818817] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 7673056
    [ 773.818969] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
    [ 773.851257] remoteproc0#vdev0buffer: assigned reserved memory node ipu1-memory@9d000000
    [ 773.855072] virtio_rpmsg_bus virtio0: rpmsg host is online
    [ 773.855163] remoteproc0#vdev0buffer: registered virtio0 (type 7)
    [ 773.855163] remoteproc remoteproc0: remote processor 58820000.ipu is now up
    [ 774.126647] omap-rproc 58820000.ipu: received echo reply from 58820000.ipu
    [ 774.126861] omap-iommu 58882000.mmu: iommu fault: da 0x80389970 flags 0x0
    [ 774.126861] remoteproc remoteproc0: crash detected in 58820000.ipu: type mmufault
    [ 774.126892] omap-iommu 58882000.mmu: 58882000.mmu: errs:0x00000002 da:0x80389970 pgd:0x022db3db *pgd:px9d600002
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Thanks to CCS and as mentionned in my previous post, I was able to discovery that the MMU issue occurs on the memcpy in the RPMessage_send with dues to the vring->desc->addr that seems not consitent.

    It's why I try to understand from where is allocated this address, because all others like vring->desc are defined in resource table and translation defined with AMMU.

    Hope my explanation can help

    Thanks 

    Quentin

  • Hi Quentin,

    You cannot randomly mix and match an older RTOS SDK with a newer Linux SDK version. You are using a 6.3 SDK (would have been released with a 4.19 Linux kernel) with a 5.10 Linux kernel (8.2 Linux SDK).

    The Linux kernel remoteproc/rpmsg framework can change from LTS kernel to LTS kernel, and this requires the correct IPC 3.x version as well. The 5.10 Linux Kernel requires the IPC 3.51.00.00A release. So, please use the appropriate IPC version.

    Please see this response specifically on a different thread.

    regards

    Suman

  • Hi Suman,

    Thanks very much for the information after update to version IPC3.51.00.00A find here https://git.ti.com/cgit/ipc/ipcdev/ all works perfectly.
    In fact the only issue was the address of the vring that I have to define as below 

    Thanks for support.

    Regards,

    Quentin