2023-08-03 09:17 AM
Hello,
we want to implement Non-blocking method like in https://wiki.st.com/stm32mpu/wiki/How_to_start_the_coprocessor_from_the_bootloader
Our efforts searching documentation and reading discussions in the forum hadn´t resolve the situation.
We are using a devicetree genertated by the CubeMX tool for stm32mp157f-eval1.
When starting the Application in a booted linux system, it works as expected. The trace logs are available, and the /dev/ttyRPMSG0 virtual UART is loaded:
We can send dummy data to /dev/ttyRPMSG0 and get the echoed response
In our use case we need the M4 Application to start as early as possible, so we have configured u-boot SSBL to load the ELF file and start the M4 execution. We are then facing the problem that the software is started, but the linux kernel does not load the /dev/ttyRPMSG0 device:
we are modifying the kernel and u-boot devicetrees including:
&m4_rproc { st,auto-boot = <1>; };
the U-boot we are using is 2021.1 stm32mp1 rev 2
the boot script is boot.scr.uimg
Our main problem is that remoteproc state is attached, not running.
What are we missing?
best regards.
Solved! Go to Solution.
2023-08-09 08:21 AM
the problem was on SRAM memory and LMA and VMA overwritting.
.bss partition (which LMA is on SRAM1) wasoverflading SRAM2 because it was too much large.
Debug ideas taken from this post:
https://community.st.com/t5/stm32-mpu-products/openamp-u-boot-startup/td-p/212743
2023-08-09 08:21 AM
the problem was on SRAM memory and LMA and VMA overwritting.
.bss partition (which LMA is on SRAM1) wasoverflading SRAM2 because it was too much large.
Debug ideas taken from this post:
https://community.st.com/t5/stm32-mpu-products/openamp-u-boot-startup/td-p/212743
2024-08-01 03:22 AM
Hi there!
I'm in the same situation one year later... From your solution I couldn't implement what you're suggesting
Could you please explain what did you do to achieve the correct functionality of the fw synchronization?
Thank you so much
2024-08-29 08:55 AM
Solved here!!! kinda....
using this memory reallocation worked for me.
In a nutshell: Probably my M4 custom firmware was too big, and memory addresses wasn't working properly with u-boot remoteproc attaching process. Probably just increasing memory areas by hand in linker file and in dts without modify them would do the job with the same results.
NOTE: rpmsg, trace and resource table works fine now, the only issue is that the fw state is set to "attached" instead of "running", but it works so I think is fine...