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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

1,374 Views
daharingwitekio
Contributor III

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!

0 Kudos
4 Replies

1,327 Views
JosephAtNXP
NXP TechSupport
NXP TechSupport

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

0 Kudos

1,295 Views
daharingwitekio
Contributor III

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.

0 Kudos

1,216 Views
JosephAtNXP
NXP TechSupport
NXP TechSupport

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

1,276 Views
jackie2
Contributor III

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. 

Tags (1)
0 Kudos