Help on Interprocessor Communication STM32MP157F-DK2

[MSele.1]

Of the many things I have been struggling withmSTM32MP157F-DK2 throughout this summer, one of them is the interprocessor communication between A7 and M4. I want A7 to process data and send the refined result to M4 for further low level actions. As many users may agree, information in this wiki is scattered with many branches, and while following one topic you encounter references to many links that end up blowing you out if the device is new to you. I am one blown out that way.

I was reading this post https://wiki.st.com/stm32mpu/wiki/Coprocessor_resource_table and found that I have to have this code somewher in my M4 firware

which I managed (by trial and error) to add in my rsc_table.c as (note sure if that was correct)

 

Then found rhat I also have to add this code somewhere, but not sure where: whether it is in A7 Linux userland or in M4 firware. Played around many times for over 14 hours and got frustrated.

can anyone help me?

 

[ArnaudP]

Hello,

Did you have a look to existings IPC exemples provided in the stm32Cube distribution?

https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Applications/OpenAMP

These exemples should help you to understand the structure to implement in your Cortex-M4 firmware

And for your use case the RPMsg TTY example could be a good entry point:

https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo

[MSele.1]

Hello @ArnaudP​ 

I have compared my code to that of https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo and found that my project does not have the lock_resource.c which I assume to be created by STM32CubeMX but was not created in my project. All of the following openAMP files are identical

There are some differences between my main.c file and the one used in the example above. In my plan, I assumed that there will be only one virtual UART channel for sending data from A7 to M4, I did not think that I need a wake up channel, so my virtual UART declarations does not include virtual huart 1 

Then in the initialization, my code misses the whole of the following section; I don't know what it means

 

Instead, my code on that part reads as follows

 

At the end I enable M4 to start receiving data from A7 as follows

 

I your view, where do you think I mess up in my code? The A7 Userland application works by just writing the exchange data into dev/ttyRPMSG0 in a continuous loop as follows:

 

Please help ! Is it possible that my M4 firmware does not start automatically as I expect? I posted a question here Need help to make my programs start automatically on boot

[ArnaudP]

Hello @MSele.1​ 

Your status is not crystal clear for me so I propose to go by steps. could you give me the status on following steps?

Please connect your board to a PC terminal to have access to the board console.

1) check the state of the Cortex-M4

 root@stm32mp1~#  cat /sys/class/remoteproc/remoteproc0/state 

if the status is offline that's means that yourCortex-M4 firmware is not loaded and started

=> refer to this chapter to manually load it https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview#Remote_processor_boot_through_sysfs

2) check that the RPMsg TTY device exist

root@stm32mp1~#  ls dev/ttyRPMSG0

If it does not exist that means that something get wrong in your settings

else that means that everything seems ok for communication.

[MSele.1]

Hello @ArnaudP​  So far I was able to start the M4 firmware but I get a tty error bas shown below; any idea why? The code is exactly more or less like the tty_echo example

[ArnaudP]

Your rpmsg_tty.ko module seems outdated, you probably recompile your kernel with some additional patches without updating the associated kernel modules.

See https://wiki.st.com/stm32mpu/wiki/How_to_cross-compile_with_the_Developer_Package#Modifying_an_external_in-tree_Linux_kernel_module

Here is a tips to avoid to update modules each time you recompile the Linux kernel:

In your Linux kernel source directory

echo "" > .scmversion

Then recompile your kernel

[MSele.1]

The error does not want to go away even after recompiling and redeploying it. Here are the steps I want through. First I downloaded the latest version of en.SOURCES-kernel-stm32mp1-openstlinux-5-10-dunfell-mp1-21-03-31.tar.xz from https://wiki.stmicroelectronics.cn/stm32mpu/index.php?title=Modify,_rebuild_and_reload_the_Linux%C2%AE_kernel&diff=prev&oldid=77947 and stored it in a directory $HOME/ STM32MP15-Ecosystem-v3.0.0/Developer-Package

Then I followed the following sequence of Command line statements to compile and deploy the kernel; Can you take time go through them one by one so you can help[ me trouble shoot where I err.

PC $> source $HOME/STM32MP15-Ecosystem-v3.0.0/Developer-Package/SDK/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi
 
PC $> set | grep CROSS
 
PC $> cd $HOME/STM32MP15-Ecosystem-v3.0.0/Developer-Package
 
PC $> tar xvf en.SOURCES-kernel-stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31.tar.xz
 
PC $> cd $HOME/STM32MP15-Ecosystem-v3.0.0/Developer-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/linux-stm32mp-5.10.10-r0
 
PC $> tar xvf linux-5.10.10.tar.xz
 
PC $> cd $HOME/STM32MP15-Ecosystem-v3.0.0/Developer-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/linux-stm32mp-5.10.10-r0/linux-5.10.10
 
PC $>  for p in `ls -1 ../*.patch`; do patch -p1 < $p; done
 
PC $> echo "" > .scmversion 
 
PC $> mkdir -p ../build
 
PC $> mkdir -p ../build/install_artifact/
 
PC $> make ARCH=arm O="$PWD/../build" multi_v7_defconfig fragment*.config
 
PC $>  for f in `ls -1 ../fragment*.config`; do scripts/kconfig/merge_config.sh -m -r -O $PWD/../build $PWD/../build/.config $f; done
 
PC $>  yes '' | make ARCH=arm oldconfig O="$PWD/../build"
 
PC $>  make ARCH=arm multi_v7_defconfig fragment*.config
 
PC $>  for f in `ls -1 ../fragment*.config`; do scripts/kconfig/merge_config.sh -m -r .config $f; done
 
PC $>  yes '' | make ARCH=arm oldconfig
 
PC $>  make ARCH=arm mrproper
 
PC $>  make ARCH=arm uImage vmlinux dtbs LOADADDR=0xC2000040 O="$PWD/../build"
 
PC $>  make ARCH=arm modules O="$PWD/../build"
 
PC $>  make ARCH=arm INSTALL_MOD_PATH="$PWD/../build/install_artifact" modules_install O="$PWD/../build"
 
PC $> mkdir -p $PWD/../build/install_artifact/boot/
 
PC $>  cp $PWD/../build/arch/arm/boot/uImage $PWD/../build/install_artifact/boot/
 
PC $>  cp $PWD/../build/arch/arm/boot/dts/st*.dtb $PWD/../build/install_artifact/boot/
 
PC $> cd $HOME/STM32MP15-Ecosystem-v3.0.0/Developer-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/linux-stm32mp-5.10.10-r0/build/install_artifact/
 
(Check if there is and partition mpounted on /boot)
 
PC $> ssh root@192.168.1.14 df   
 
PC $> ssh root@192.168.1.14 mount  /dev/mmcblk0p4 /boot
 
PC $> scp -r  boot/* root@192.168.1.14:/boot/
 
PC $> ssh root@192.168.1.14 umount /boot
 
PC $> rm lib/modules/5.10.10/source lib/modules/5.10.10/build
 
PC $> find -name "*.ko" | xargs $STRIP --strip-debug --remove-section=.comment --remove-section=.note --preserve-dates
 
PC $> scp -r lib/modules/* root@192.168.1.14:/lib/modules/
 
PC $> ssh root@192.168.1.14 /sbin/depmod -a
 
PC $> ssh root@192.168.1.14 sync
 
PC $> ssh root@192.168.1.14 reboot

After uploading the Kernel, I modify the device tree by adding the one generated by STM32CubeMx. I can provide details of how I modify the device tree if you this that is where I err.

[ArnaudP]

Hello @MSele.1​ 

Thanks for the feedback.

I use similar command except that i do not do the "ssh root@192.168.1.14 /sbin/depmod -a"

Anyway To confirm (or invalidate) the hypothesis of a module compatibility issue, could change the rpmsg_tty driver mode from module to built-in, an retest?

make menuconfig

Thanks,

Arnaud

[MSele.1]

Thank you for the encouragement that I don't make errors in compiling and deploying the kernel. I just removed the whole system to reinstall afresh. However on applying fragments I get these error, which were never there before

wa@ubuntu:~/STM32MP15-Ecosystem-v3.0.0/Developer-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/linux-stm32mp-5.10.10-r0/linux-5.10.10$ for f in `ls -1 ../fragment*.config`; do scripts/kconfig/merge_config.sh -m -r .config $f; done
The base file '.config' does not exist.  Exit.
The base file '.config' does not exist.  Exit.
The base file '.config' does not exist.  Exit.

I guess I can go about those errors by repeating the reinstallation. However, I want to ask one question, which I suspect could be the reason.

I have a custom device tree generated by STM32CubeMx for my project, and I used information available at https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package

I recompile the device trees and create my custom TSV file that I use the STM32Programmer to to update U-boot, TA-F as well as the Kernel Device tree. Could that be the reason? Is there and clearer way of updating the device tree.

[ArnaudP]

The fact that you have an error message on the rpmsg_tty module indicates that the RPMsg communication has been well initiated. Indeed the Linux kernel received a first RPMsg from the Cortex-M4 firmware. At least from remoteproc node your Linux DT is correct.