we plan to implement a project with means of the Colibri VF61 dual core communication via MCC2. Due to the fact that the original Linux Kernel 3.13 shipped with TRW65 (from TimeSys) is quite obsolete we would prefer to use the actual Linux kernel 4.1 from Toradex. On the M4 side we would like to use MQX (4.2.0), for the inter-core communication MCC2 shall be used. I have read the article about “MQX on the Cortex-M4 of a Colibri VF61” but unfortunately this example does not address MCC2 inter-core communication.
Have anyone experience with implementing MCC2 in Toradex Linux Kernel 4.1 and MQX?
Any doubts that this may be a hard way to get it work, especially on the Linux side due to a lot of changes from Kernel 3.13 to 4.1?
Another question which MCC and kernel has Toradex used in their example in article “Ping-Pong Example Between Linux and eCos RTOS on Colibri VF61”? Does the MCC implementation of that Linux image will also work with MQX?
Any help will be appreciated,
Currently our Kernel implements MCCv1 only. We considered using MCCv2, however decided against it for the following reasons:
- The implementation of Freescale exports the MCC API only within the kernel and exposed a standard TTY interface (see http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/char/imx_amp/imx_mcc_tty.c?h=imx_3.14.52_1.1.0_ga) whereas the implementation of Timesys is somehow a mix and match of the Timesys implementation and the MCCv1 implementation (still having ioctrl/using libmcc, while being implemented as a TTY char device?! linux-timesys/imx_mcc_tty.c at 3.13_vybrid · Timesys/linux-timesys · GitHub).
- Since MCCv2 still exports the API to userspace, there is still userspace library required. Up until recently that library was only available under the GPL v2 license (Timesys/Freescale just recently changed that, so that argument actually no longer holds true)/
- Newer Freescale designs, e.g. the upcoming i.MX7 is going to use rpmsg (see http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rpmsg/imx_rpmsg_tty.c?h=imx_3.14.38_6ul7d_beta)
Therefor we decided not to adopt MCCv2. However, I think it should be viable to forward-port the MCCv2 implement with a reasonable amount of effort. We currently exploring to implement rpmsg for Vybrid which looks like the more future proof solution.
The MCCv1 implementation we use is ABI compatible with MQX, hence the Ping-Pong Example works also with MQX (I think it was 4.1.2 which implements the MCCv1 API).
Hi @stefan.agner this means that if I need communication between A5 (Linux 4.1 from Toradex ) and M4 (Freescale MQX) the version of MQX can not be 4.2. Is this correct?
@danieloak, that is right. I think the differences between MCCv1 and MCCv2 are really minimal. The underlying protocol might even be the same, so maybe it just works by incrementing the version number on Linux side. Otherwise, probably diffing the differences in the MCC implementation between MQX 4.1.2 and 4.2 and backport MCCv1 to MQX 4.2 might be work as well.
We’re running MQX 4.2.0 with a backported MCCv1, so it is definitely possible.
Can you share the project or provide instructions on how to backport MCC v1 to MQX 4.2.0?
I don’t currently have a form which I can distribute to you. I basically took an MQX version with MCCv1 and copied the MCC folder into MQX 4.2.0. Stefan may still have a copy of the work I did for it.
I do the following steps to backport MCC.
- Duplicate and rename mcc folder to mcc_v1
- Replace .c and .h files with the MCC 1 files
- Change the compilation scripts to generate mcc_v1 archive file.
The only change in source code that I need to do is rename the interrupt vector number from INT_CPU_to_CPU_int0 to GIC_CPU_to_CPU_int0.
Tomorrow I will test the backport but I think it will work.
Sorry for the late answer, I just uploaded a Version I got from @nbarrett some months back to our server:
Hi @stefan.agner thank you for your explanation and the provided download. In reference to your tarball MQX-4.2.0_with_MCC_backported_1.2.tar.gz the pingpong example is working fine with VF61 Toradex Linux Image 2.5 (Kernel 4.1).
I started from mcc_v1.2. Symlinked it with mcc.
Did the code change as you.
Found that post-build was failing. Needed to add:
cd mcc/source/include/mqx && ln -s …/mcc_config.h.
(Strange, the post-build script is identical to mcc 2.1…)
with v1 you loose the nocopy part of API