Alternatives to imx_rpmsg_tty/rpsmg_lite?

[Troglobyte]

We are using the imx8mpevk development board.  We would like to implement rpmsg with multiple endpoints such that our linux processes can communicate with each endpoint through a unique device (tty or ???) to our M7 FreeRTOS application.

I am referring to the following post...

https://community.nxp.com/t5/i-MX-Processors/Multiple-endpoints-using-RPMsg-RTOS-Layer/m-p/1008744

It appears that there are limitations to implementing multiple endpoints using imx_rpmsg_tty/rpmsg_lite.  Does the limitation lie in the imx_rpmsg_tty driver or rpmsg_lite (on Freertos)? (or both?)

If the limitation is in the imx_rpmsg_tty driver exclusively, can we use the rpmsg_char driver with rpmsg_lite (on Freertos) to implement multiple endpoints?

Regards

Rich

[Troglobyte]

Thanks Edward - this is exactly what I was looking for!

Rich

[kef2 · Accepted solution]

Hi 

Regarding rpmsg_char driver. It can't coexist with other RPMSG devices. Its idea is nice. One communication channel is usually not enough, at least one streaming channel + one control channel to pass settings - is more desired. 

As I see, rpmsg_char driver usurpers all RPMSG virtual devices, so that other drivers like imx_rpmsg_tty,  gpio_imx_rpmsg, etc  are unable to see any more alive devices on Cortex-M, all virtual devices turn into rpmsg_char control devices. Either rpmsg_char is enabled in kernel config and is the only way to use RPMSG, or you disable rpmsg_char in kernel config and may use different RPMSG drivers for different purposes.

imx_rpmsg driver supports up to 8 virtual devices (#define in the driver, could be more). So it is basically just the matter of proper device tree and additional rpmsg_lite_remote_init() and rpmsg_ns_announce() calls on Cortex-M to create second or more imx_rpmsg_tty instances.

Regarding DT, vring size is hardcoded in imx_rpmsg driver. (If you wonder where, look for "+ 0x8000" string in imx_rpmsg.c. It would be better to use bigger vrings for more demanding channels, less for others. But at least it's working and working quite well.) One device uses 64k  of shared memory, next virtual device uses next 64k of memory and so on. Number of virtual devices is vdev-nums = <N> property of RPMSG in DT. Vrings memory sized N*64k should be reserved, as well specified as reg = <> property of RPMSG in DT. Each rpmsg_lite_remote_init() call on Cortex-M should specify right addr argument matching specific piece of shared vring memory. Say you have 3 devices, vdev-nums=<3>, vring memory starts at 0x80000000, vring memory size - 0x30000. So one call to rpmsg_lite_remote_init should use addr=0x80000000, second call - 0x80010000, 3rd - 0x80020000.

Oh, one more thing, imx_rpmsg_tty driver detects only up to 3 devices. There are 3 different announcement strings listed in driver rpmsg_driver_tty_id_table struct. Only those listed there and announced by Cortex-M will be detected as /dev/ttyRPMSG devices. 

Hope this helps

Edward

[Troglobyte]

Ok...want to start with the existing rpmsg_char driver.  I see the .c file in the kernel source.

I have been trying to build the rpmsg_char driver using bitbake menuconfig but don't see that specific driver in the list?  We are using 5.4.70-2.3.0...Is it available in a newer kernel version?

Thanks

T

[igorpadykov]

that driver is not included in M7 MCUXpresso SDK so one will have to port it himself,

New releases can be obtained in https://mcuxpresso.nxp.com/en/welcome

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

For help with porting drivers nxp has special service : https://contact.nxp.com/new-prof-svcs-sw-tech

Best regards
igor

[igorpadykov]

Hi Rich

one can consider

 

 

>can we use the rpmsg_char driver with rpmsg_lite (on Freertos) to implement multiple endpoints?

yes, also one can develop their own RPMsg-like protocols between cores using
rpmsg_char driver, rpmsg_lite as examples.

Best regards
igor