写了一个stm32mp157的m4程序，需要在uboot阶段就去启动这个程序，现在存在两个问题。
1、程序内包含了双核通信的部分，因此这部分的初始化肯定是要等到linux系统内核初始化完成之后才可能成功。在uboot阶段进行初始化的话会导致程序一直在下面的printf处死循环，即使linux内核初始化完成了也无法跳出。
但是关闭m4程序后，重新开始m4程序则不会出现卡死在循环的问题，因此我修改了一下这部分内容，判断失败不会再次死循环转而跳到main函数的开头，相当于重新执行main函数，发现问题依然存在。请问有什么解决办法吗。
void rproc_virtio_wait_remote_ready(struct virtio_device *vdev)
{
    uint8_t status;

    /*
     * No status available for slave. As Master has not to wait
     * slave action, we can return. Behavior should be updated
     * in future if a slave status is added.
     */
    if (vdev->role == VIRTIO_DEV_MASTER)
        return;

    while (1) {
        printf("wait rproc_virtio_wait_remote_ready\r\n ");
        status = rproc_virtio_get_status(vdev);
        if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
            return;
        metal_cpu_yield();
    }
}
2、m4程序中使用了spi+dma的方式去进行数据的传输 ，发现uboot启动m4程序之后，再一段时间内触发了spi的中断回调函数，但是内核初始化之后，就不再触发spi的中断回调了。去除dma后单纯spi传输则并没有出现此问题。推测为a7内设备树初始化时将dma再次初始化了一遍导致spi+dma传输出现了问题。附件为a7和ide程序内Linux的设备树。请问应该如何修改

有两种方式，可以等待也可以不等待。

https://wiki.st.com/stm32mpu/wiki/How_to_start_the_coprocessor_from_the_bootloader#Synchronizing_the_remote_firmware_with_Linux

• Blocking method: the firmware is blocked on MX_OPENAMP_Init call (by the rproc_virtio_wait_remote_ready function) until the Linux kernel is ready to communicate (update of the vdev status in the resource table).
• Non-blocking method: when it is ready to communicate, the Linux kernel generates an interrupt towards the Arm Cortex-M4 core using the IPCC peripheral. This interrupt can be used by the Arm Cortex-M4 firmware to initialize the OpenAMP middleware and start the RPMsg protocol.
  

Allonli 发表于 2023-1-11 10:27
有两种方式，可以等待也可以不等待。

https://wiki.st.com/stm32mpu/wiki/How_to_start_the_coprocessor_f ...

我在内核设备树里添加了st,auto-boot=<1>;但是还是会一直卡在rproc_virtio_wait_remote_ready函数这，
MX_IPCC_Init();这里一直就是通的。