VirtIO problem on STM32MP157C-DK2

[Ljubica]

Hi! I am working with stm32mp157c-dk2 and trying to establish communication between m4 and a7 cores. I analyze standard examples for this purpose, namely OpenAMP_TTY_echo. VIRT_UART initialization is presented here for m4 core:

log_info("Virtual UART0 OpenAMP-rpmsg channel creation\r\n");
 if (VIRT_UART_Init(&huart0) != VIRT_UART_OK) {
   log_err("VIRT_UART_Init UART0 failed.\r\n");
   Error_Handler();
 }

 log_info("Virtual UART1 OpenAMP-rpmsg channel creation\r\n");
 if (VIRT_UART_Init(&huart1) != VIRT_UART_OK) {
   log_err("VIRT_UART_Init UART1 failed.\r\n");
   Error_Handler();
 }

 /*Need to register callback for message reception by channels*/
 if(VIRT_UART_RegisterCallback(&huart0, VIRT_UART_RXCPLT_CB_ID, VIRT_UART0_RxCpltCallback) != VIRT_UART_OK)
 {
  Error_Handler();
 }
 if(VIRT_UART_RegisterCallback(&huart1, VIRT_UART_RXCPLT_CB_ID, VIRT_UART1_RxCpltCallback) != VIRT_UART_OK)
 {
   Error_Handler();
 }

After flashing is issued:

[ 111.672943] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x0
[ 111.678249] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 111.685266] remoteproc0#vdev0buffer: registered virtio0 (type 7)
[ 111.690252] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x1
[ 111.696384] remoteproc remoteproc0: remote processor m4 is now up
[ 115.293405] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x0
[ 115.299594] virtio_rpmsg_bus virtio0: channel rpmsg-tty-channel:ffffffff:0 already exist
[ 115.307771] virtio_rpmsg_bus virtio0: rpmsg_create_channel failed
[ 115.313773] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x1
[ 115.321384] virtio_rpmsg_bus virtio0: channel rpmsg-tty-channel:ffffffff:1 already exist
[ 115.329519] virtio_rpmsg_bus virtio0: rpmsg_create_channel failed

And when viewing tty:

root@stm32mp1:~# ls /dev/tty*
/dev/tty /dev/tty2 /dev/tty31 /dev/tty43 /dev/tty55 /dev/ttySTM0
/dev/tty0 /dev/tty20 /dev/tty32 /dev/tty44 /dev/tty56 /dev/ttyp0
/dev/tty1 /dev/tty21 /dev/tty33 /dev/tty45 /dev/tty57 /dev/ttyp1
/dev/tty10 /dev/tty22 /dev/tty34 /dev/tty46 /dev/tty58 /dev/ttyp2
/dev/tty11 /dev/tty23 /dev/tty35 /dev/tty47 /dev/tty59 /dev/ttyp3
/dev/tty12 /dev/tty24 /dev/tty36 /dev/tty48 /dev/tty6 /dev/ttyp4
/dev/tty13 /dev/tty25 /dev/tty37 /dev/tty49 /dev/tty60 /dev/ttyp5
/dev/tty14 /dev/tty26 /dev/tty38 /dev/tty5 /dev/tty61 /dev/ttyp6
/dev/tty15 /dev/tty27 /dev/tty39 /dev/tty50 /dev/tty62 /dev/ttyp7
/dev/tty16 /dev/tty28 /dev/tty4 /dev/tty51 /dev/tty63
/dev/tty17 /dev/tty29 /dev/tty40 /dev/tty52 /dev/tty7
/dev/tty18 /dev/tty3 /dev/tty41 /dev/tty53 /dev/tty8
/dev/tty19 /dev/tty30 /dev/tty42 /dev/tty54 /dev/tty9

As You can see in /dev/tty* the /dev/ttyRPMSG0 port is not created on the A7 kernel side. Can you please tell me what step I am missing? Thanks in advance!

[Erwan SZYMANSKI]

Hello @Ljubica ,
Can you please give me the Cube_FW_package version that your are using, as well as the OpenSTLinux version that you use.

Do you use the Starter package to get the SW image ? 

Kind regards,
Erwan.

[Ljubica]

Thank you for reply, @Erwan SZYMANSKI ,
I am using STM32Cube_FW_MP1_V1.6.0 -> Projects -> STM32MP157C-DK2 -> Applications -> OpenAMP -> OpenAMP_TTY_echo with STM32MP1 OpenSTLinux 4.1.0 startup package.

[Erwan SZYMANSKI]

@Ljubica ,
Thanks or the confirmation, versions look aligned. Can you precise following point :

• Which hardware are you using ? STM32MP157C-DK2 board ? 
• Which method did you choose to start the coprocessor firmware ? If you tried an early start, can you also try to launch it at runtime, after the boot is completed on A7 side ? (using remoteproc utility, cf https://wiki.st.com/stm32mpu-ecosystem-v4/wiki/Linux_remoteproc_framework_overview#Remote_processor_boot_through_sysfs)

Kind regards,
Erwan.

[Ljubica]

@Erwan SZYMANSKI ,
The STM32MP157C-DK2 is being used, I was doing an early startup without specifying a new path. I'm not quite clear on how to flash without auto startup and how much of an impact it might have?

Kind regards,

Ljubica.

[Erwan SZYMANSKI]

@Ljubica ,
I have already seen people who have trouble with co-processor early startup. I just would like to confirm that it can work at runtime and that channels are well created. For this, on Linux side, you can use the link on the wiki I gave you to check if it works or not.

Second question concerning the use case. Do you need to do early work on M4 side ? What I want to highlight is that, if you do not need M4 cortex very early in the boot process, maybe the easier way is to start the M4 firmware (the Echo program here) only when Linux boot is finished.

Kind regards,
Erwan.