openamp_rsc_table App in imx7d-pico (M4-Side name in Zephyr=pico_pi_m4) I cant see /dev/ttyRPMSG

[neuberfran]

Hi,

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table#id6

I stay trying this since last month in my imx7d-pico (m4 side) Zephyr upstream board is pico_pi_m4 using mailbox=mub

I can run Remoteproc and zephyr on this device but without resource table, vrings and RPMsg: https://www.youtube.com/watch?v=NFyEJXIpq4E

Now I stay trying openamp_rsc_table based on this link below: https://github.com/zephyrproject-rtos/zephyr/pull/60455

I can go up and run everything but the channel and /dev/ttyRPMSG are not created

cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories

Carveout memory entry:
    Name: vdev0vring0
    Virtual address: 7938acbc
    DMA address: 0x90000000
    Device address: 0x90000000
    Length: 0x8000 Bytes

Carveout memory entry:
    Name: vdev0vring1
    Virtual address: 3a612924
    DMA address: 0x90008000
    Device address: 0x90008000
    Length: 0x8000 Bytes

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 0x90000000
    Alignment 16
    Number of buffers 8
    Notify ID 0
    Physical Address 0x0

  Vring 1
    Device Address 0x90008000
    Alignment 16
    Number of buffers 8
    Notify ID 1
    Physical Address 0x0

pico_pi_m4.overlay

/ {
    chosen {
        /*
         * shared memory reserved for the inter-processor communication
         */
        zephyr,ipc_shm = &ocramfake;
        zephyr,ipc = &mub;
    };

    ocramfake: memory@90000000  {
        compatible = "mmio-sram";
        reg = <0x90000000  0x110000>;
    };
};

&mub {
    status = "okay";
};

In linux Yocto A7 Side imx7d-pico-pi-qca-m4.dts (file):

/*
 * Copyright 2018 TechNexion Ltd.
 *
 * Author: Tapani Utriainen <tapani@technexion.com>
 *         Richard Hu <richard.hu@technexion.com>
 *         Ray Chang <ray.chang@technexion.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 */

 #include "imx7d-pico-pi-qca.dts"

 / {
     memory {
         linux,usable-memory = <0x80000000 0x1ff00000>;
     };

     reserved-memory {
         #address-cells = <1>;
         #size-cells = <1>;
         ranges;

         //  mailbox_reserved: vrings0@30ab0000  {
        //    reg = <0x30ab0000 0x10000>;
        //    no-map;
        //  };

        m4_reserved: m4@90000000 {
           reg = <0x90000000 0x100000>;
           no-map;
         };        

        vdev0vring0: vdev0vring0@90000000 {
            compatible = "shared-dma-pool";
//            compatible = "shared-dma-pool";
            reg = <0x90000000  0x8000>;
            no-map;
        };

        vdev0vring1: vdev0vring1@90008000 {
            compatible = "shared-dma-pool";
//            compatible = "shared-dma-pool";
            reg = <0x90008000  0x8000>;
            no-map;
        };

        // rsc_table: rsc_table@900ff000 {
        //  reg = <0x900ff000  0x1000>;
        //  no-map;
        // };

        vdev0buffer: vdev0buffer@90010000 {
            compatible = "shared-dma-pool";
            reg = <0x90010000 0x80000>;
            no-map;
        };

        //  cm4tcmcode: cm4tcmcode@0x7f8000 {
        //      compatible = "shared-dma-pool";
        //      reg = <0x007f8000 0x8000>;
        //      no-map;
        //  };

        //  cm4sramcode: cm4sramcode@0x900000 {
        //      compatible = "shared-dma-pool";
        //      reg = <0x00900000 0x40000>;
        //      no-map;
        //  };
     };

     imx7d-cm4 {
         compatible = "fsl,imx7d-cm4";
         clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
//         fsl,auto-boot;
         mbox-names = "tx0", "rx0", "rxdb0";
         mboxes = <&mub 0 1
              &mub 1 1
              &mub 3 1>;
  //         memory-region = <&rpmsg_vrings>, <&cm4tcmcode>, <&cm4sramcode>;
        memory-region = <&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>;
        //, <&cm4tcmcode>;
        fsl,rproc-auto-boot = <1>;
        fsl,rproc-fw-name="zephyr_openamp_rsc_table.elf";
        syscon = <&src>;
        status = "okay"; 
     };

     m4_tcm: tcml@007f8000 {
         compatible = "fsl, m4_tcml";
         reg = <0x007f8000 0x8000>;
     };

     gpio-leds {
         status = "disabled";
     };
 };

 &adc1 {
     status = "disabled";
 };

 &adc2 {
     status = "disabled";
 };

 &gpt3 {
     status = "disabled";
 };

 &gpt4 {
     status = "disabled";
 };

 &ocram {
     reg = <0x00901000 0xf000>;
 };

 &rpmsg{
     vdev-nums = <1>;
     memory-region = <&vdev0buffer>;
//     memory-region = <&vdev0vring0>, <&vdev0vring1>, <&vdevbuffer>, <&cm4tcmcode>, <&cm4sramcode>;
     reg = <0x9fff0000 0x10000>;
     status = "okay";   // Tava disabled
 };

 &uart6 {
     status = "disabled";
 };

 &mub {
     status = "okay";
 };

 &wdog3{
     status = "disabled";
 };

Why I can`t see vdev0buffer in result of the cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories And cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table commands?

Why when I change MAX_RPMSG_NUM_BUFS and MAX_RPMSG_BUF_SIZE from 512 to 256 in virtio_rpmsg_bus.c (file in rpmsg/drivers in my linux kernel), nothing change in Number of buffers 8 in my resource_table?

Edited:

Change CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=8 to CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=512 in prj.conf. But not solved.

CONFIG_KERNEL_BIN_NAME="zephyr_openamp_rsc_table"
CONFIG_PRINTK=n
CONFIG_IPM=y
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024
CONFIG_OPENAMP=y
CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=32
CONFIG_OPENAMP_RSC_TABLE=y
CONFIG_OPENAMP_MASTER=n

[neuberfran]

@jlh-makeen I'm already suspecting that my vrings may not be 0x1000 but rather 0x8000. So I don't know if I have enough (remaining) memory for the vdevbuffer and what the vdevbuffer would look like. Could you tell me? https://community.toradex.com/t/verdin-mini-rpmsg-lite-increase-buffer-size/18356/5 https://community.nxp.com/t5/i-MX-Processors/Changing-RPMsg-Buffer-Size/m-p/1221466/highlight/true#M168448

[jlh-makeen]

@jlh-makeen I'm already suspecting that my vrings may not be 0x1000 but rather 0x8000. So I don't know if I have enough (remaining) memory for the vdevbuffer and what the vdevbuffer would look like. Could you tell me? https://community.toradex.com/t/verdin-mini-rpmsg-lite-increase-buffer-size/18356/5 https://community.nxp.com/t5/i-MX-Processors/Changing-RPMsg-Buffer-Size/m-p/1221466/highlight/true#M168448

@neuberfran

In order to get rpmsg to work, we had to update to kernel 5.16 to have the official tty-rpmsg and rpmsgctrl drivers. Then in the DT, we have defined 0x1000 size for the VRING0 and VRING1 and 0x8000 for the vdevbuffer all in DDR memory.

When rproc cannot allocate the memory you request (512 bytes * CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF)

For 0x8000 you can go up to CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=32 buffers You will get error -62 when kicking the virtio when remoteproc. If you get -62 you need to reduce the number of buffers or increase the memory size for the vdevbuffer.

Our particular setup:

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 0xbfff0000
    Alignment 16
    Number of buffers 32
    Notify ID 0
    Physical Address 0x0

  Vring 1
    Device Address 0xbfff1000
    Alignment 16
    Number of buffers 32
    Notify ID 1
    Physical Address 0x0

When our app starts we created 3 tty endpoints:

[ 8883.780211] remoteproc remoteproc0: powering up imx-rproc
[ 8883.807068] remoteproc remoteproc0: Booting fw image zephyr_pnet_ipm.elf, size 2223228
[ 8883.814115] remoteproc remoteproc0: no SP or PC loaded into M4 bootrom vector. Core will not start!
[ 8883.823367]  remoteproc0#vdev0buffer: assigned reserved memory node vdev0buffer0@bfff2000
[ 8883.835930]  remoteproc0#vdev0buffer: registered virtio0 (type 7)
[ 8883.849667] remoteproc remoteproc0: remote processor imx-rproc is now up
[ 8883.862012] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 8883.862321] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x400
[ 8883.880476] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x401
[ 8883.892294] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x402

In our case we needed the linker script to start the M4 boot-vector as I mention in this discussion:

https://github.com/zephyrproject-rtos/zephyr/discussions/71617

I'll provide a PR for the bootvector when I have time.

Regarding the if your kernel doesn't have the rpmsg-tty driver but instead the: when creating the endpoint for imx-rpmsg-tty driver you need the endpoint name: "rpmsg-virtual-tty-channel"

// As defined  in the linux kernel imx-rpmsg-tty
static struct rpmsg_device_id rpmsg_driver_tty_id_table[] = {
    { .name = "rpmsg-virtual-tty-channel-1" },
    { .name = "rpmsg-virtual-tty-channel" },
    { .name = "rpmsg-openamp-demo-channel" },
    { },
};

You also need to use mbox id 0 as mentionned before in the Linux DT.

[neuberfran]

@jlh-makeen

After I chage zephyr,flash (to)= &ocram_code; (from &tcml_code) messages from zephyr_openamp_rsc_table.bin no longer appear on the zephyr side Question: Do I need to start zephyr_openamp_rsc_table.bin in Uboot at 0x7f8000 or 0x900000?

## No elf image at address 0x007f8000
## Starting auxiliary core stack = 0x200020B0, pc = 0x00900CE9...
baseboard is pi
lmb_dump_all:
 memory.cnt  = 0x1
 memory[0]  [0x80000000-0xbfffffff], 0x40000000 bytes flags: 0
 reserved.cnt  = 0x1
 reserved[0]    [0xbcd5d858-0xbfffffff], 0x032a27a8 bytes flags: 0

[neuberfran]

@jlh-makeen

readelf -S zephyr_openamp_rsc_table.elf 
Há 31 cabeçalhos de secção, começando no desvio 0xa14b4:

Cabeçalho de Seções:
  [Nr] Nome Fora do Tipo de Endereço ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] rom_start         PROGBITS        00180000 000114 00023c 00 WAX  0   0  4
  [ 2] text              PROGBITS        00901000 000350 00455c 00  AX  0   0  4
  [ 3] .ARM.exidx        ARM_EXIDX       0090555c 0048ac 000008 00  AL  2   0  4
  [ 4] initlevel         PROGBITS        00905564 0048b4 000040 00   A  0   0  4
  [ 5] device_area       PROGBITS        009055a4 0048f4 000028 00   A  0   0  4
  [ 6] sw_isr_table      PROGBITS        009055cc 00491c 0003f8 00  WA  0   0  4
  [ 7] tbss              NOBITS          009059c4 004d14 000004 00 WAT  0   0  4
  [ 8] rodata            PROGBITS        009059c4 004d14 0009c0 00   A  0   0  4
  [ 9] .ramfunc          PROGBITS        20000000 005858 000000 00   W  0   0  1
  [10] datas             PROGBITS        20000000 0056d4 0000e0 00  WA  0   0  4
  [11] device_states     PROGBITS        200000e0 0057b4 000004 00  WA  0   0  1
  [12] k_heap_area       PROGBITS        200000e4 0057b8 000014 00  WA  0   0  4
  [13] k_sem_area        PROGBITS        200000f8 0057cc 000030 00  WA  0   0  4
  [14] bss               NOBITS          20000128 005858 000442 00  WA  0   0  8
  [15] noinit            NOBITS          20000570 005858 001f4c 00  WA  0   0  8
  [16] .comment          PROGBITS        00000000 005858 000020 01  MS  0   0  1
  [17] .debug_aranges    PROGBITS        00000000 005878 001298 00      0   0  8
  [18] .debug_info       PROGBITS        00000000 006b10 048893 00      0   0  1
  [19] .debug_abbrev     PROGBITS        00000000 04f3a3 00a53b 00      0   0  1
  [20] .debug_line       PROGBITS        00000000 0598de 017ab0 00      0   0  1
  [21] .debug_frame      PROGBITS        00000000 071390 002c24 00      0   0  4
  [22] .debug_str        PROGBITS        00000000 073fb4 0099a6 01  MS  0   0  1
  [23] .debug_loc        PROGBITS        00000000 07d95a 015d1f 00      0   0  1
  [24] .debug_ranges     PROGBITS        00000000 093680 0035f8 00      0   0  8
  [25] .ARM.attributes   ARM_ATTRIBUTES  00000000 096c78 000032 00      0   0  1
  [26] .last_section     PROGBITS        009064ac 0057fc 000004 00   A  0   0  1
  [27] .resource_table   PROGBITS        009064b0 005800 000058 00  WA  0   0  4
  [28] .symtab           SYMTAB          00000000 096cac 005ca0 10     29 787  4
  [29] .strtab           STRTAB          00000000 09c94c 004a2a 00      0   0  1
  [30] .shstrtab         STRTAB          00000000 0a1376 00013c 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required)
```, G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), y (purecode), p (processor specific)

[neuberfran]

@jlh-makeen

I carried out several tests today, but unfortunately still without success.

[neuberfran]

@jlh-makeen Hello. Firstly, I want to congratulate you for being able to upload /dev/ttyRPMSG using Remoteproc/Linux-UserSpace/Zephyr Upstream on your imx7d device (even though it only has 1gb)

For my part, I haven't managed it yet and I would like you (if possible) to clarify my doubts using the photos below:

1) Do you change something in NS announcement in the RPMSG on Linux?

2) Is there a possibility that I can be successful using Linux 5.15? If so, what changes should I make?

3) Can I use &tcml_code in zephyr,flash ?

[jlh-makeen]

@jlh-makeen Hello. Firstly, I want to congratulate you for being able to upload /dev/ttyRPMSG using Remoteproc/Linux-UserSpace/Zephyr Upstream on your imx7d device (even though it only has 1gb)

For my part, I haven't managed it yet and I would like you (if possible) to clarify my doubts using the photos below:

1. Do you change something in NS announcement in the RPMSG on Linux?
2. Is there a possibility that I can be successful using Linux 5.15? If so, what changes should I make?
3. Can I use &tcml_code in zephyr,flash ?

@neuberfran

There is no need to modify the Linux driver, at least in Linux 5.16.

We have only been able to successfully have ttyRPMSG on Linux 5.16 (and newer should work too)

You need PR #71684 in order to have the zephyr.elf file place the rom_start region (aka boot vector) into the OCRAM_S in order to be able to boot the M4 core using tcml_code memory.

There is a trick where you can get the M4 to boot by using ocram_s by changing the definition in the DT for ocram_s_code from address to the alias 0x00000000, this way the rproc driver is going to properly load the zephyr.elf file and boot-vectors at the right place. This will also be a valid addresssing for the M4 core as address space 0x00180000 for OCRAM_S code is aliased at 0x00000000.

I do not have the ressources and time to try it with linux 5.15, we need people from NXP or your vendor to support us here. As I explained linux 5.15 doesn't include the generic "tty-rpmsg" driver but instead the "imx-tty-rpmsg" which uses different rpmsg-endpoint names.

As of now, people have been very silent on the subject.

[neuberfran]

@jlh-makeen I can do echo "test2" > /dev/ttyRPMSG0 and led light red blink in cp2102 UART-USB adapter in USB1 (by m4 side) But nothing appear in USB1 m4 side

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 0x9ff00000
    Alignment 16
    Number of buffers 16
    Notify ID 0
    Physical Address 0x0

  Vring 1
    Device Address 0x9ff01000
    Alignment 16
    Number of buffers 16
    Notify ID 1
    Physical Address 0x0

cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories
Carveout memory entry:
    Name: vdevbuffer
    Virtual address: 61161a75
    DMA address: 0x9ff02000
    Device address: 0x9ff02000
    Length: 0xfe000 Bytes

Carveout memory entry:
    Name: vdev0vring0
    Virtual address: c79cef80
    DMA address: 0x9ff00000
    Device address: 0x9ff00000
    Length: 0x1000 Bytes

Carveout memory entry:
    Name: vdev0vring1
    Virtual address: 49beba9f
    DMA address: 0x9ff01000
    Device address: 0x9ff01000
    Length: 0x1000 Bytes

Carveout memory entry:
    Name: cm4tcmcode
    Virtual address: f8f35095
    DMA address: 0x007f8000
    Device address: 0x7f8000
    Length: 0x8000 Bytes

Carveout memory entry:
    Name: cm4sramcode
    Virtual address: 0aa07789
    DMA address: 0x00900000
    Device address: 0x900000
    Length: 0x40000 Bytes

[jlh-makeen]

@neuberfran
Looks like you are very close to the goal in fact your Linux kernel is now receiving the RPMSG name service annoucements message and it is creating the proper channels rpmsg-tty and rpmsg-client-sample.

Does /dev/ttyRPMSG0 show up by itself in the /dev directory ?

Because I can see the dmesg output it not showing that the rpmsg-tty driver was probed by the annoucement on channel rpmsg-tty / 0x401.

Did you manage to update to Linux 5.16 or are you still on 5.15 ?

If on 5.15, you probably don't have the rpmsg-tty driver but rather the imx_rpmsg_tty driver instead. If that's the case, need to replace "rpmsg-tty" on the Zephyr side for the rpmsg endpoint name to the same as imx_rpmsg_tty driver instead "rpmsg-virtual-tty-channel".

See the endpoint names here: https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/rpmsg/imx_rpmsg_tty.c#L211-L216

Change is done here: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/ipc/openamp_rsc_table/src/main_remote.c#L290

I haven't tested on kernel 5.15 and cannot test it for you.

Make sure you also enable the LOGGING framework in Zephyr to see all the messages coming on the M4 side as it doesn't use PRINTK the print statements in openamp_rsc_table example.

[neuberfran]

@jlh-makeen

Yes, I use kernel 5.16 now, Yes, I have /dev/ttyRPMSG now

So I'm trying two approaches:

1) First with your PR-71684 in order to have the zephyr.elf file place the rom_start region

In this case the resulting zephyr.bin became very large (511m) (i don't know why).

1,1) I even tried to approach your approach (that is, using PR) and uploading zephyr.elf only in sysfs (echo start) in Userspace, but I got error -62 and I can't upload rproc that way, unfortunately.

2) In the second approach, I got a smaller zephyr.bin and had better success (as shown in the print screen in the last post)

I could be wrong, but this concludes that I have to use zephyr.bin(Uboot starts) and zephyr.elf(rproc starts) in this project on a mandatory basis. Otherwise I may have error -62

Now comes the issue that Linux (TX part of Linux) is not sending messages (**RPMsg/OpenAMP messages) to the Zephyr

** You can see in the window on the right side of the last photo (print screen) I posted that (despite CONFIG_PRINTK=n and CONFIG_LOG_PRINTK=n) some messages already arrive in m4, but not the main ones about RPMsg and OpenAMP, type test in echo "test" > /dev/ttyRPMSG0

What I've already tried to resolve: 1) Change CONFIG_PRINTK=n and CONFIG_LOG_PRINTK=n to CONFIG_PRINTK=y and CONFIG_LOG_PRINTK=y (Not solved) 2) Change vdev0vring0 and vdev0vring1 to vdevvring0 and vdevvring1, in Linux DT (Not solved) 3) Number of buffers 32 4)

printk("\r\nOpenAMP[remote] Linux tty ccc1.2 started\r\n");            

        if (tty_msg.len) {
            LOG_INF("ipc_service_open_instance() 14 failure");
            snprintk(tx_buff, 13, "TTY 0x%04x: ", tty_ept.addr);
            memcpy(&tx_buff[12], tty_msg.data, tty_msg.len);
            LOG_INF("ipc_service_open_instance() 15 failure");
            rpmsg_send(&tty_ept, tx_buff, tty_msg.len + 13);
            rpmsg_release_rx_buffer(&tty_ept, tty_msg.data);
            LOG_INF("ipc_service_open_instance() 16 failure");
        }
        printk("\r\nOpenAMP[remote] Linux tty ccc3 started\r\n"); 

OpenAMP[remote] Linux sample client ccc10 started                               
OpenAMP Linux sample client responder ended                                     

OpenAMP[remote] Linux task ccc21 started                                        

OpenAMP[remote] Linux task ccc20 started                                        

OpenAMP[remote] Linux tty ccc1.2 started                                        
I: ipc_service_open_instance() 14 failure                                       
I: ipc_service_open_instance() 15 failure                                       
I: ipc_service_open_instance() 16 failure                                       

OpenAMP[remote] Linux tty ccc3 started                                          

OpenAMP[remote] Linux tty ccc1.1 started  

Please, give-me your main_remote.c and your prj.conf generic and your_board.conf

[jlh-makeen]

@neuberfran

Let me try to be as clear as possible.

We have a custom carrier board using the cl-som-imx7d from Compulab so some changes might not be necessary on your board:

~/zephyrproject/zephyr/boards/makeen$ tree
.
├── index.rst
└── makeen_gw
    ├── board.yml
    ├── doc
    │   ├── dw_makeen_imx7d_m4.png
    │   └── index.rst
    ├── Kconfig.defconfig
    ├── Kconfig.makeen_gw
    ├── makeen_gw_mcimx7d_m4_defconfig
    ├── makeen_gw_mcimx7d_m4.dts
    ├── makeen_gw-pinctrl.dtsi
    └── makeen_gw.yaml

2 directories, 10 files

~/zephyrproject/zephyr/boards/makeen$ cat makeen_gw/makeen_gw_mcimx7d_m4_defconfig 
#
# Copyright (c) 2024, MAKEEN Energy
#
# SPDX-License-Identifier: Apache-2.0
#

CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_CONSOLE=y
CONFIG_XIP=y
CONFIG_PINCTRL=y
CONFIG_GPIO_HOGS=y

In the Zephyr DT I have &mub set to status = "okay"

Regarding the project I can build the native example from samples/subsys/ipc/openamp_rsc_table using this board config:

Create boards/makeen_gw_mcimx7d_m4.conf in samples/subsys/ipc/openamp_rsc_table:

CONFIG_IPM=y
CONFIG_IPM_IMX_MAX_DATA_SIZE_4=y
CONFIG_OPENAMP_WITH_DCACHE=y
CONFIG_PLATFORM_SPECIFIC_INIT=n
CONFIG_OPENAMP=y
CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=32
CONFIG_OPENAMP_RSC_TABLE=y
CONFIG_OPENAMP_MASTER=n

Before Building you must use my ROMSTART_REGION relocation PR in order to have the correct boot-vector placement for Linux RPROC. You don't need the BIN files anymore, only ELF file.

Then on your Linux board create the following boot_m4.sh script:

#!/bin/bash

fw=$1

cp $fw /lib/firmware

echo stop > /sys/class/remoteproc/remoteproc0/state
echo $fw > /sys/class/remoteproc/remoteproc0/firmware
echo start > /sys/class/remoteproc/remoteproc0/state

Don't forget to chmod +x boot_m4.sh

Build :

cd ~/zephyrproject/zephyr/samples/subsys/ipc/openamp_rsc_table
west build -p always -b makeen_gw/mcimx7d/m4

Then SCP the zephyr_openamp_rsc_table.elf file and boot_m4.sh to your home directory of the linux board:

Then call the script:

su root
./boot_m4.sh zephyr_openamp_rsc_table.elf && dmesg

It should output the following:

[ 1529.626593] remoteproc remoteproc0: stopped remote processor imx-rproc
[ 1529.637142] remoteproc remoteproc0: powering up imx-rproc
[ 1529.645231] remoteproc remoteproc0: Booting fw image zephyr_openamp_rsc_table.elf, size 1282424
[ 1529.661279]  remoteproc0#vdev0buffer: assigned reserved memory node vdev0buffer0@bfff2000
[ 1529.718327] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 1529.718981] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x400
[ 1529.722666]  remoteproc0#vdev0buffer: registered virtio0 (type 7)
[ 1529.730217] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x401
[ 1529.741235] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x402
[ 1529.741946] remoteproc remoteproc0: remote processor imx-rproc is now up

Now I have 2 /dev/ttyRPMSG0 and /dev/ttyRPMSG1 showing up if you are using the latest openamp_rsc_table sample that enables the SHELL and SHELL_RPMSG_BACKEND.

To use the shell you can use your TTY terminal of choice like minicom:

su root
minicom -D /dev/ttyRPMSG0

Then press CTRL+C a few times to trigger the shell prompt: You should see ipc:~$, then you can type kernel version to see that you are currently running Zephyr on the M4 !

Welcome to minicom 2.8

OPTIONS: I18n
Compiled on Jan  1 2021, 17:45:55.
Port /dev/ttyRPMSG0, 06:09:54

Press CTRL-A Z for help on special keys

ipc:~$ kernel version
Zephyr version 3.6.99
ipc:~$

You can also use /dev/ttyRPMSG1 to see the regular TTY echo of the sample when you send data to the tty

Welcome to minicom 2.8

OPTIONS: I18n
Compiled on Jan  1 2021, 17:45:55.
Port /dev/ttyRPMSG1, 06:10:44

Press CTRL-A Z for help on special keys

TTY 0x0402: eTTY 0x0402: eTTY 0x0402: eTTY 0x0402: e

Be aware that the sample uses approximately 48kB of CODE memory so I think you must run the code from OCRAM, but RAM usage is approx 20kB and can fit on any of TCM/OCRAM_S/DDR

[171/171] Linking C executable zephyr/zephyr_openamp_rsc_table.elf
Memory region         Used Size  Region Size  %age Used
 ROMSTART_REGION:         572 B         1 KB     55.86%
           FLASH:       48304 B       128 KB     36.85%

I hope this helps.

[neuberfran]

@jlh-makeen Tks. But I don't want open /dev/ttyRPMSG0 in minicom or picocom. I want: 1) open Linux a7 side in picocom usb0 2) open Zephyr m4 side in minicom usb1 3) Execute rproc sysfs in linux and in linux -> echo "test" > /dev/ttyRPMSG0. 4) At that moment I would see the word test next to the Zephyr (in usb1 minicom window) Note: 1) All that remains to be done is resolve this issue at the moment 4) 2) I try LOG_INF("TTY 0x%04x: ", tty_ept.addr); Result is: TTY 0x401 3) Nothing to tty_ept.addr, Why

if (tty_msg.len) {
            LOG_INF("ipc_service_open_instance() 14 failure");
            snprintf(tx_buff, 13, "TTY 0x%04x: ", tty_ept.addr);
            memcpy(&tx_buff[12], tty_msg.data, tty_msg.len);
            LOG_INF("ipc_service_open_instance() 15 failure");
            rpmsg_send(&tty_ept, tx_buff, tty_msg.len + 13);
            rpmsg_release_rx_buffer(&tty_ept, tty_msg.data);
            LOG_INF("ipc_service_open_instance() 16 failure");
        }

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.1.3/zephyr/samples/subsys/ipc/openamp_rsc_table/README.html

[jlh-makeen]

@jlh-makeen Tks. But I don't want open /dev/ttyRPMSG0 in minicom or picocom. I want:

1. open Linux a7 side in picocom usb0
2. open Zephyr m4 side in minicom usb1
3. Execute rproc sysfs in linux and in linux -> echo "test" > /dev/ttyRPMSG0.
4. At that moment I would see the word test next to the Zephyr (in usb1 minicom window) Note: 1) All that remains to be done is resolve this issue at the moment 4)
5. I try LOG_INF("TTY 0x%04x: ", tty_ept.addr); Result is: TTY 0x401
6. Nothing to tty_ept.addr, Why

if (tty_msg.len) {
            LOG_INF("ipc_service_open_instance() 14 failure");
            snprintf(tx_buff, 13, "TTY 0x%04x: ", tty_ept.addr);
            memcpy(&tx_buff[12], tty_msg.data, tty_msg.len);
            LOG_INF("ipc_service_open_instance() 15 failure");
            rpmsg_send(&tty_ept, tx_buff, tty_msg.len + 13);
            rpmsg_release_rx_buffer(&tty_ept, tty_msg.data);
            LOG_INF("ipc_service_open_instance() 16 failure");
        }

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.1.3/zephyr/samples/subsys/ipc/openamp_rsc_table/README.html

Congrats ! I can see in your screenshot here that the Zephyr TTY side has successfully received the message from the Linux and sent the Echo back to Linux ! See the TTY 0x0401: Hello Zephyr so it is working perfectly now !

You don't see anything from your LOG_INF because you have not enabled CONFIG_LOG=y.

Try to add a printk statement instead, like this:

if (tty_msg.len) {
  printk("Linux rx message %*.s\n", tty_msg.len, tty_msg.data);
  snprintf(tx_buff, 13, "TTY 0x%04x: ", tty_ept.addr);
  memcpy(&tx_buff[12], tty_msg.data, tty_msg.len);
  rpmsg_send(&tty_ept, tx_buff, tty_msg.len + 13);
  rpmsg_release_rx_buffer(&tty_ept, tty_msg.data);
}

When you receive a message from Linux, you'll the message content appear in the Zephyr console.

Now it is implementation details you will have to care about by yourself, now that /dev/ttyRPMSG shows in Linux and the RPMSG sample works on your platform I think we should close the issue as it's resolved.

If you encounter application specific requests, feel free to report to the documentation or open a new issue for the new subject.

[neuberfran]

@jlh-makeen Unfortunately, I still couldn't get echo test > /dev/ttyRPMSG0 to appear in the other window

I am one of the first interested parties to close this topic.

I thought that adding the printk you suggested would solve it (it was the only thing I hadn't tried yet). But unfortunately not yet

if (tty_msg.len) {
            printk("Linux rx message %*.s\n", tty_msg.len, tty_msg.data);
            LOG_INF("ipc_service_open_instance() 14 failure");
            snprintf(tx_buff, 13, "TTY 0x%04x: ", tty_ept.addr);
            memcpy(&tx_buff[12], tty_msg.data, tty_msg.len);
            LOG_INF("ipc_service_open_instance() 15 failure");
            rpmsg_send(&tty_ept, tx_buff, tty_msg.len + 13);
            rpmsg_release_rx_buffer(&tty_ept, tty_msg.data);
            LOG_INF("ipc_service_open_instance() 16 failure");
        }

prj.conf

CONFIG_KERNEL_BIN_NAME="zephyr_openamp_rsc_table"
CONFIG_PRINTK=y
CONFIG_LOG=y 
CONFIG_LOG_DEFAULT_LEVEL=0
CONFIG_LOG_MODE_MINIMAL=y
CONFIG_IPM=y
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024
CONFIG_OPENAMP=y
CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=32
CONFIG_OPENAMP_RSC_TABLE=y
CONFIG_OPENAMP_MASTER=n
CONFIG_PLATFORM_SPECIFIC_INIT=n
#CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# CONFIG_LOG=y
# CONFIG_LOG_BACKEND_UART=y
# CONFIG_SERIAL=y

# CONFIG_IPC_SERVICE=ys
# CONFIG_PRINTK=y 
# CONFIG_LOG=y # required to allocate virtqueues 
# #CONFIG_HEAP_MEM_POOL_SIZE=2048
# CONFIG_IPC_SERVICE_LOG_LEVEL_INF=y 

pico_pi_m4.conf

CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_CONSOLE=y
CONFIG_LOG_PRINTK=y
CONFIG_IPM_IMX_MAX_DATA_SIZE_16=n
CONFIG_IPM_IMX_MAX_DATA_SIZE_4=y
CONFIG_OPENAMP_WITH_DCACHE=y

# CONFIG_IPM=y--> Interrupt-based inter-processor mailboxes
# CONFIG_IPM_IMX=y--> Your IPM driver here for Renesas R-Car
# CONFIG_OPENAMP=y--> Enable OpenAMP IPC library
# CONFIG_OPENAMP_SLAVE=y --> Virtqueue are initialized by the host (Linux)
# CONFIG_OPENAMP_RSC_TABLE=y

This is Correct Result When Everything Works Ok

5.2 openamp_rsc_table application in Page=12

AN13970.pdf

[neuberfran]

@jlh-makeen

Pls Can you perform these procedures below? 1) open Linux a7 side in picocom usb0 2) open Zephyr m4 side in minicom usb1 3) Execute rproc sysfs in linux and in linux write echo "test" > /dev/ttyRPMSG0. 4) Please let me know if you can see the message test or openamp_rsc_table: platform_ipm_callback: platform_ipm_callback: msg received from mb 0 in m4 side window

[jlh-makeen]

It is weird that printk doesn't display the message can you print the size of the message too ?

printk("Linux rx message [%d] %*.s\n", tty_msg.len, tty_msg.len, tty_msg.data);

[neuberfran]

@jlh-makeen

Linux rx message [5]

[neuberfran]

@jlh-makeen???????

[jlh-makeen]

@jlh-makeen

Linux rx message [5]

You succesfully received the "test\n" string so it is working, the length of the message is 5 :)

You don't see the message because I made a mistake with the printk: I swapped the . in the printk statement. printk("Linux rx message [%d] %.s\n", tty_msg.len, tty_msg.len, tty_msg.data);

See the test here:

[neuberfran]

@jlh-makeen Tks. With printk("Linux rx message [%d] %.*s\n", tty_msg.len, tty_msg.len, tty_msg.data); (Without mistakes) I have sucess

Other things I changed (in main remote.c) to have the messages shown in the screenshot below:

1) LOG_MODULE_REGISTER(openamp_rsc_table, LOG_LEVEL_DBG); to LOG_MODULE_REGISTER(openamp_rsc_table, LOG_LEVEL_INF);

2) All LOG_DBG from main_remote.c to LOG_INF

3) Now I have I: mailbox_notify: msg received and I: platform_ipm_callback: msg received from mb 0 and I: mailbox_notify: msg received

[neuberfran]

https://www.youtube.com/watch?v=V06RC2G_3M8

[jlh-makeen]

https://www.youtube.com/watch?v=V06RC2G_3M8

Excellent, here we are finally 👍

Regarding the LOG framework, the default level is INF that's why you had to change the module default level, but you could also have changed the default log level in prj.conf:

#set default level to 4
CONFIG_LOG_DEFAULT_LEVEL=4

Refer to the logging doc: https://docs.zephyrproject.org/latest/services/logging/index.html https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_DEFAULT_LEVEL