Showing results for 
Search instead for 
Did you mean: 

why M4 firmware been stopped by linux side access uart8@40019000 on STM32MP157C need confirmation of stm32-rproc would stop M4 firmware loaded by u-boot need confirmation on stm32-rproc has issue with kernel 5.10.10

Associate II

After linux bootup on STM32MP157C custom board with kernel build 5.4.31, I load and start M4 with remoteproc successfully, but every time when linux access uart8@40019000, M4 side firmware stopped, the two command i used to test is "echo 123 > /dev/ttySTM1" or "stty -F /dev/ttySTM1 -a", both command stopped the M4 firmware, and my M4 firmware is toggling a GPIO when it's running, so it's been confirmed by using logic analyzer.

Would anyone can tell me what's going on, and device tree dts file has been attached.

Another thing I observed is, if I load M4 firmware by u-boot, during linux side boot up, M4 firmware been stopped by some driver, I suspecting it's stopped when remoteproc driver been probed.

With kernel 5.10.10, the stm32-rproc driver failed to reset M4 and probe M4. would someone can confirm it?

Associate II

One more detail, that access other 4 uart port on my board, doesn't reset M4 firmware, but I cannot see the difference between them and UART8. On my board, they are:

uart8@40019000 -> ttySTM1

usart2@4000e000 -> ttySTM2

usart3@4000f000 -> ttySTM4

uart7@40018000 -> ttySTM7

uart5@40011000 -> ttySTM5

ST Employee

Hi @HZhu.12​ ,

To further investigate M4 stop by echo > Uart8 issue, can you please provide complete dmesg log from M4 start, up to stop by echo ?

Else for the issue you encounter with early boot with U-boot I think it may be worth to check it's not similar to this recently detected bug :

Check of VMA and LMA of you application using obdump + application of the provided patch in linker script will help to eliminate this assumption.


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.