STM32
直播中

哥儿

9年用户 991经验值
擅长:嵌入式技术
私信 关注
[问答]

stm32mp157在uboot阶段启动m4程序存在的问题求解

写了一个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_readyrn ");
        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的设备树。请问应该如何修改

回帖(1)

mintsy

2024-3-21 16:49:49
问题分析:
根据问题描述,你的STM32MP157 M4程序在u-boot阶段启动的时候会卡在循环处,而如果关闭M4程序后重新启动则不会卡住。你已经尝试过修改代码以重新执行main函数,但问题依然存在。

解决方法:
1. 确保在u-boot阶段,等待Linux内核初始化完成之后再启动M4程序。可以在u-boot启动脚本中添加相关的等待时间,以确保Linux内核初始化已完成。例如,你可以在u-boot启动脚本中添加类似下面的代码,等待2秒钟后再启动M4程序:
```
sleep 2
run m4boot
```

2. 检查和确认你的双核通信部分的初始化是否正确,并且在启动M4程序之前已经完成。确保在M4程序运行时,双核通信的相关资源已经初始化完毕。

3. 在代码中添加更多的调试信息,以便定位问题所在。比如可以在循环的前后添加打印语句,以及在出现问题时打印相关的信息,以便找出问题的根本原因。

4. 如果问题仍然存在,可以在初始化双核通信部分的代码中添加超时机制,如果在一定时间内还没有初始化成功,则跳过初始化,直接启动M4程序。但这不是一个理想的解决方法,仅仅是一种权宜之计,具体要根据实际情况来决定是否采用这种方法。

希望这些解决方法能够帮助到你解决问题。
举报

更多回帖

发帖
×
20
完善资料,
赚取积分