AnsweredAssumed Answered

iMX8QXP MEK RPMSG communication with M4 image built from 2.5.2 SDK

Question asked by Emanuel Achimescu on Aug 13, 2019
Latest reply on Aug 13, 2019 by CarlosCasillas

Hello,

 

I am using an iMX8QXP MEK rev B0 board and have to start the communication between the M4 and A35 cores.

I've started with the multicore examples provided in the FreeRTOS SDK from NXP.

 

My current setup is the following:

Silicon revision: B0

FreeRTOS v2.5.2 got from the sdk put together on https://mcuxpresso.nxp.com

I didn't change the build parameters, I compiled using gcc  by exporting the ARMGCC_DIR with the crosscompiler path and running the build_debug.sh script included in the sdk.

 

The goal is to build the rpmsg_lite_pingpong_rtos_linux from the multicore examples available in the SDK.

 

From the IMX8 yocto project, I've built my own u-boot and kernel and did all the steps to create a boot image using mk-image utility and including all the sfcw, ahab container, bl31 and so on images in a fit image.

 

I'm stopping the boot process in u-boot, loading the m4 core 0 image using:

 

$ fatload mmc 1:1 0x80280000 m4_image.bin

$ dcache flush

$ bootaux 0x80280000 0

 

On the serial console of the m4 core, I get the

 

RPMSG Ping-Pong FreeRTOS RTOS API Demo...

RPMSG Share Base Addr is 0x90000000

 

then I boot the Linux on the A core and load the imx_rpmsg_pingpong.ko module, but nothing happens.

 

With the same environment (u-boot, kernel, ko) but an m4 image obtained from the yocto project  imx8qx_m4_TCM_rpmsg_lite_pingpong_rtos_linux_remote.bin prebuilt by NXP, then I get the following correct behavior:

 

 

RPMSG Ping-Pong FreeRTOS RTOS API Demo...

RPMSG Share Base Addr is 0x90000000

/* Here I boot the A35 core */

Link is up!

Nameservice announce sent.

/* Here I am loading the imx_rpmsg_pingpong.ko on the linux side */

Waiting for ping...

Sending pong...

Waiting for ping...

Sending pong...

....

 

The expected behavior.

 

This points to the fact that my build of the m4 image is not completely ok.

In the FreeRTOS demo, the point where it hangs is

    while (!rpmsg_lite_is_link_up(my_rpmsg))
        ;

in main_remote.c

 

Thanks

Outcomes