Rpmsg_pinpong on M4 core of VF61

In the supplied example rpmsg_pingpong for M4 core of VF61 (available from [freertos-toradex.git - FreeRTOS for the Cortex M4 core of Heterogeneous Multicore modules]]1 branch colibri-vf61-m4-freertos-v8) rpmsg driver is init as REMOTE calling rpmsg_init().
Digging down in this function, _create_endpoint() is called with parameter addr == RPMSG_ADDR_ANY.
This calls rpmsg_get_address() where bitmap is set to 0x00000000.
In this way get_first_zero_bit() (line 704 of rpmsg_core.c) returns 0 and line 707 addr = tmp32 + i + 1; /*This is strange*/ is executed.
This breaks the for() loop returning 1 and so _create_endpoint() fails with status = RPMSG_ERR_DEV_ADDR;.

This is what I see when I compile the example rpmsg_pingpong with Keil DS-5/DS-MDK.
Is this an expected behavior?
Could you double check it, please?

Do you have any news on this topic?

The rpmsg core implementation comes from Open Asymmetric Multi Processing (OpenAMP) framework project. To be honest we only ever ported the same for Vybrid and have not looked into the internal details of OpenAMP itself, which is the topic you are enquiring into. The expected behavior of each of the core internal functions is something we do not have information on at the moment.

Do the rpmsg examples not work as intended?

No, it doesn’t work as expected if you compile it from sources under Keil Ds-% or DS-MDK.
I’m going to investigate deeply but I need few days

Do the precompiled binaries from here work?

@sanchayan.tx, sorry for the delayed answer.
Yes, the precompiled binaries either downloaded from here or included in Toradex CE libraries 2.0-20170524 works as expected.
But, as I said, if I rebuild the bin from the source code (downloaded from here) using Keil DS-5 or DS-MDK it fails with the error I described in my first post.
I can’t verify that rebuilding with GCC it works properly, since I don’t have a working system with GCC.
I can import GCC toolchain in DS-MDK, but I need your help setting up the proper linker files.

@raja.tx Can you please look into this?

@vix,
We followed GCC compiler setup to build rpmsg_pingpong firmware on Windows 7.
Moreover, your issue related to the compiler. Could you please try GCC and let us know the update.
We don’t have experience on DS-MDK and Keil DS-5.

I imported ARM Embedded toolchains 4.9 2015 Q3 update (suggested here) into Keil DS-MDK.
I setup the settings for GCC 4.9.3 Compiler, Assembler and Linker based on what I find in CMakeLists.txt (supplied with the example).
For assembler I see

# DEBUG ASM FLAGS
SET(CMAKE_ASM_FLAGS_DEBUG "${CMAKE_ASM_FLAGS_DEBUG} -g  -mcpu=cortex-m4  -mfloat-abi=hard  -mfpu=fpv4-sp-d16  -mthumb  -Wall  -fno-common  -ffunction-sections  -fdata-sections  -ffreestanding  -fno-builtin  -Os  -mapcs  -std=gnu99")

but when I compile, I get the error

arm-none-eabi-as.exe: unrecognized option `-no-common'

Don’t you have this problem while compiling under Linux?

Moreover I found this info for -fno-common flag (for GCC compiler, not assembler)

-fno-common

In C code, this option controls the placement of global variables
defined without an initializer, known
as tentative definitions in the C
standard. Tentative definitions are
distinct from declarations of a
variable with the extern keyword,
which do not allocate storage.

Unix C compilers have traditionally allocated storage for
uninitialized global variables in a
common block. This allows the linker
to resolve all tentative definitions
of the same variable in different
compilation units to the same object,
or to a non-tentative definition. This
is the behavior specified by -fcommon,
and is the default for GCC on most
targets. On the other hand, this
behavior is not required by ISO C, and
on some targets may carry a speed or
code size penalty on variable
references.

The -fno-common option specifies that the compiler should instead place
uninitialized global variables in the
data section of the object file. This
inhibits the merging of tentative
definitions by the linker so you get a
multiple-definition error if the same
variable is defined in more than one
compilation unit. Compiling with
-fno-common is useful on targets for which it provides better performance,
or if you wish to verify that the
program will work on other systems
that always treat uninitialized
variable definitions this way.
and so I suspect this flag can be related to different behavior when I compile the sources with a different compiler (ARM Compiler 5).

@raja.tx, if I follow GCC compiler setup on my Windows 7 machine, what does “put the contents in C:\MinGW\bin” mean?
Should I install GNU ARM Embedded Toolchain into C:\MinGW\bin?

Running build_all.bat (no build.bat exists) I get the error
Please set ARMGCC_DIR in environment variables

@vix,
yes, install in C:\MinGW\bin. If it is zip file, extract in that path.

@raja.tx, to be 100% sure the exact steps are:

  • download the zip package of GNU ARM Embedded Toolchain and extract the content in C:\MinGW\bin

Could you confirm this?

@sanchayan.tx, I see that Open Asymmetric Multi Processing (OpenAMP) framework project changed based on what you supply with your FreeRTOS porting.
rpms_core.c file changed too, and line addr = tmp32 + i + 1; /*This is strange*/ is not present anymore.
Could you doulbe check, and verify if OpenAMP supplied with your samples needs to be updated based on original github project?

I did it, but (as I wrote), running build_all.bat I get the error

cmake -DCMAKE_TOOLCHAIN_FILE="../../../../../../tools/cmake_toolchain_files/armgcc.cmake" -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug  .
CMake Error at G:/WorkInProgress/N130/VF61_M4/freertos-toradex/tools/cmake_toolchain_files/armgcc.cmake:23 (MESSAGE):
  ***Please set ARMGCC_DIR in envionment variables***
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.8/Modules CMakeDetermineSystem.cmake:85 (include)
  CMakeLists.txt

The OpenAMP implementation was taken from the iMX7 FreeRTOS work done by NXP. We did not integrate from upstream. Looking into the current github branch, it seems it is the same way for iMX7 as well now. Does changing it fix the issue for you? Note that the WinCE rpmsg implementation also uses OpenAMP while the Linux stack is completely different. It is possible that OpenAMP WinCE master + OpenAMP FreeRTOS remote has some corner cases not observed while using Linux. I work on Linux side of things. @raja.tx Can you please verify this with WinCE and check if we need to update OpenAMP side of things for Vybrid?

@sanchayan.tx, I’m a little bit confused: in your first message you wrote

The rpmsg core implementation comes
from Open Asymmetric Multi Processing
(OpenAMP) framework project. To be
honest we only ever ported the same
for Vybrid and have not looked into
the internal details of OpenAMP itself

and I checked that the file rpms_core.c in the head of that repository is different from what I find in Toradex repository for VF61 (not iMX7).
Then you wrote

The OpenAMP implementation was taken
from the iMX7 FreeRTOS work done by
NXP. We did not integrate from
upstream.

What do you mean with this sentence?

In can be that WinCE is different from Linux, but the most important thing is that I work with Vybrid VF61 and not iMX7.
I din’t try to patch rpmsg_core.c because the file in Toradex repository for VF61 is really different from those in OpenAMP repository.
So it’s not clear for me where did you take the OpenAMP implementation.

I need help from you (who originally ported it to Vybrid) and from @raja.tx to clarify and (if needed) fix this porting.

Thanks in advance

By porting I meant the platform specific part of Vybrid required to make rpmsg work which is here. The rest of core OpenAMP stack comes from the older NXP iMX7 FreeRTOS branch.

I understand, but I notice that rpmsg_core.c file in Toradex repository is different in branch colibri-vf61-m4-freertos-v8 and colibri-imx7-m4-freertos-v8.
Maybe the file in vf61 branch must be updated as the one in imx7 branch.
I’m going to test this and I let you know.
In the meanwhile, can you check this too?

Patching rpmsg_core.c as it is in colibri-imx7-m4-freertos-v8 branch is not enough, because the patch depends on other files.
Looking to the commit logs in Toradex repository I see that rpmsg module was originally the same in vf61 and imx7 branches (on January 2016).
Afterwards, @stefan.tx modified this module in imx7 branch, but vf61 hasn’t been modified.
I suspect the same patch is needed for vf61 too (since both vf61 and imx7 have a Cortex-M4 core).
Maybe @stefan.tx can clarify this (and update the branch, if needed).

Please set these two environment variables(My Computer → Properties → Advanced System settings → Environment variables).
ARMGCC_DIR=C:\MinGW\bin
PATH=C:\MinGW\bin
and try to build.