Synchronizing earyl booted M4 FW with Linux:

[stm32mp1--Player]

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:

• cat /sys/class/remoteproc/remoteproc0/state outputs 'running'
• cat /sys/kernel/debug/remoteproc/remoteproc0/trace0 shows our debug outputs from the M4

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:

• cat /sys/class/remoteproc/remoteproc0/state outputs 'attached'
• /sys/kernel/debug/remoteproc/remoteproc0/trace0 doesnt exist
• cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table is empty
• /dev/ttyRPMSG0 is not loaded 

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.

[stm32mp1--Player · Accepted solution]

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 

[SScar.2]

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

[SScar.2]

Solved here!!! kinda.... 

https://community.st.com/t5/stm32-mpus-products/reallocation-of-sram-memory-to-stm32mp157a/td-p/194890 

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...