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

[HZhu.12]

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?

[HZhu.12]

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

[Olivier GALLIEN]

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 :

https://community.st.com/s/question/0D53W000012OLYLSA4/openamp-uboot-startup

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

Olivier