i.MX8M Plus RPMsg Device Tree Entries (Cortex-M7/A53) with imx_rpmsg_tty driver

[daharingwitekio]

Hi, I'm trying to use the RPMsg functionality on the IMX8MP between the Cortex-A53 & M7. More specifically, right now I'm trying to use it with the example `imx_rpmsg_tty` driver to have a simple character device interface between them. I've read through some documents I found and used the example device tree `arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts` as my base. But I've had a hard time finding documentation for the RPMsg node itself and I wanted to ask a list of questions. Also please forgive me because I'm still kind of new to BSP development.

First, here is the device tree I've created (it's a modified/trimmed version of the example DTS with rpmsg node added):

#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/gpio/gpio.h>

/*
 * ATTENTION: M7 may use IPs/peripherals including:
 * ECSPI0/ECSPI2, FLEXCAN, GPIO1/GPIO5, GPT1, I2C3, I2S3, UARTs,
 * PWM4, SDMA1/SDMA2, and more. Any peripheral used by the cortex M7
 * must be disabled in the device tree and must be added to domain 1
 * in the U-Boot device tree.
 */

/ {
    // This is for RPMsg. Specifically, at least for the imx_rpmsg_tty driver
    rpmsg: rpmsg {
        compatible = "fsl,imx8mq-rpmsg";
        reg = <0x0 0x55000000 0x0 0x80000>;
        memory-region = <&vdevbuffer>;
        vdev-nums = <1>;
        /* up to now, the following channels are used in imx rpmsg
            * - tx1/rx1: messages channel.
            * - general interrupt1: remote proc finish re-init rpmsg stack
            *   when A core is partition reset.
            */
        mbox-names = "tx", "rx", "rxdb";
        mboxes = <&mu 0 1
                  &mu 1 1
                  &mu 3 1>;
        status = "okay";
    };

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

        // M7 TCM instruction memory
        // Linux/Cortex-A physically can't access this area of memory
        m7_itcm: m7@0x7E0000 {
            no-map;
            reg = <0 0x7E0000 0 0x20000>;
        };

        // M7 TCM data memory
        // Linux/Cortex-A physically can't access this area of memory
        m7_dtcm: m7@0x800000 {
            no-map;
            reg = <0 0x800000 0 0x20000>;
        };

        // M7 RAM
        // This is used if the Cortex-M is booted from RAM
        m7_reserved: m7@0x80000000 {
            no-map;
            reg = <0 0x80000000 0 0x1000000>;
        };

        // IMX Remote Proc; tx buffer 32KiB
        vdev0vring0: vdev0vring0@55000000 {
            compatible = "shared-dma-pool";
            reg = <0 0x55000000 0 0x8000>;
            no-map;
        };

        // IMX Remote Proc; rx buffer 32KiB
        vdev0vring1: vdev0vring1@55008000 {
            compatible = "shared-dma-pool";
            reg = <0 0x55008000 0 0x8000>;
            no-map;
        };

        rsc_table: rsc-table@550ff000 {
            reg = <0 0x550ff000 0 0x1000>;
            no-map;
        };

        /* RPMsg buffer; this is 64KiB which is 32KiB for the
         * TX and RX buffers each. The start address is defined
         * as the `VDEV0_VRING_BASE` define in the Cortex M7 code.
         */
        vdevbuffer: vdevbuffer@55400000 {
            compatible = "shared-dma-pool";
            reg = <0 0x55400000 0 0x100000>;
            no-map;
        };
    };

    // IMX remote proc
    imx8mp-cm7 {
        compatible = "fsl,imx8mp-cm7";
        rsc-da = <0x55000000>;
        clocks = <&clk IMX8MP_CLK_M7_DIV>;
        fsl,startup-delay-ms = <500>;

        mbox-names = "tx", "rx", "rxdb";
        mboxes = <&mu 0 1
                  &mu 1 1
                  &mu 3 1>;

        memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
        status = "okay";
    };
};

Oh, one more note; I'm booting the Cortex-M7 from TCM and am not using remote proc to start/stop/hotload it. Also, my kernel is v5.15.

So my questions about this are as follows:

1. Is the `imx8mp-cm7` node needed if I'm using the imx_rpmsg_tty driver and am not using remote proc? From what I can tell, it doesn't seem needed
2. Is there a good example provided somewhere for the `rpmsg` node? I found this node somewhere but I can't remember where but I don't think it was an official source (and there's no rpmsg node in the example DTS)
3. Should the `vdevbuffer` reference be there in the `imx8mp-cm7`? From my understanding of how it works the answer is no, but it's like that in the example DTS.
   
   • If it should stay, is the overlap with `rpmsg` also using `vdevbuffer` an issue? Same question with the reg value `55000000`
4. I added memory reservations for the TCM memory but this isn't in the example either. Is it needed/good practice to include it? I know that the Cortex A53 (at least what I read) cannot access the TCM area of memory physically anyway.
5. Is there anything blaringly wrong that you see?

Any help/comments are appreciated!

[JosephAtNXP]

Hi,

Thank you for your interest in NXP Semiconductor products.

You could refer to the code in that version, that I understood that you have previously checked on.

Or the bindings example, also for that branch.

I think that can help, have you tried the hello world and rpmsg.dts on an EVK?

Thanks for the attention,

Regards

[daharingwitekio]

Ah, you're right about the bindings example. That's where I found it! However, I should clarify that there doesn't seem to be an example DTS where the imx_rpmsg_tty driver (in conjunction with existing RPMsg Cortex-M example code) works without me manually adding the rpmsg node that you see in my DTS (it doesn't exist in the imx8mp-evk-rpmsg.dts).

The code you linked (which is the imx8mp-evk-rpmsg.dts) I mentioned in my original post (but didn't provide a link to). That DTS is what I derived mine from (I stripped out the stuff I don't need and added the rpmsg node which wasn't in the example dts).

I should clarify that what I have works as is. If I remove the RPMsg node, then the imx_rpmsg_tty driver is unable to connect to the Cortex-M when running the RPMsg example code on the Cortex-M which would be expected.

However, my other questions (1,3 & 4) still remain. I should note that for question 1 that I observed that if I remove the imx8mp-cm7 node, RPMsg with the imx_rpmsg_tty seems to work as expected (assuming the RPMsg node is there as in my example). Which leads to my question #1.

[JosephAtNXP]

Hi,

I have talked with a colleague and this' his advice:

1. As said before, only if you want to monitor the cortex-M during Linux operation.

3. vdev should stay as they are the tx and rx buffer, its size depends on your app size.

4. Varies from your app, also. It's a good practice to either allocate the code in TCM as in the first two child nodes, as is, allocating it in RAM.

Thanks

[jackie2]

If you don't not need start/stop M core under Linux.

You don't have to use the RPROC framework(remote proc).

AN5317.pdf (nxp.com.cn)

You need remote proc framework, you need everything in the dts.