RT-Thread项目：CV18XX AArch64 BSP启动失败问题分析与解决

问题背景

在RT-Thread操作系统的master分支中，针对CV18XX AArch64架构的板级支持包(BSP)出现了一个启动问题。当系统启动时，只能打印出RT-Thread的标志信息后就停止响应，无法进入控制台界面。这个问题影响了基于CV18XX芯片的开发板（如Milk-V Duo）的正常使用。

问题定位

通过代码二分查找(bisect)发现，该问题出现在提交754c59a411（"[Feature] DFS mount auto by kernel parameters"）之后。深入分析发现，系统在启动过程中卡在了components/drivers/core/mnt.c文件中的rootfs_mnt_init()函数里。

具体卡死的位置是在一个等待设备初始化的循环中：

for (; rootdelay || rootwait; --timeout)
{
    if (!rootwait && timeout == 0)
    {
        LOG_E("Wait for /dev/%s init time out", dev);
        break;
    }

    if (rt_device_find(dev))
    {
        break;
    }

    rt_thread_mdelay(1);
}

根本原因

进一步分析发现，问题的根源在于：

1. Bootloader通过设备树传递的启动参数中包含rootwait标志
2. 系统会等待指定的设备(/dev/mmcblk0p2)被创建
3. 由于当前BSP中尚未实现对应的MMC设备驱动，导致系统无限等待

启动参数示例如下：

root=/dev/mmcblk0p2 rootwait rw console=ttyS0,115200 earlycon=sbi riscv.fwsz=0x80000 loglevel=9

解决方案

考虑到当前BSP的实现状态和开发进度，我们提供了两种解决方案：

临时解决方案

对于需要快速恢复系统功能的开发者，可以创建一个伪设备来绕过等待逻辑：

#include <rtthread.h>
#include <rtdevice.h>

static struct rt_device *pseudo_mmcblk;

static int pseudo_mmcblk_setup(void)
{
    pseudo_mmcblk = rt_calloc(1, sizeof(*pseudo_mmcblk));
    RT_ASSERT(pseudo_mmcblk != RT_NULL);
    
    pseudo_mmcblk->type = RT_Device_Class_Graphic;
    return (int)rt_device_register(pseudo_mmcblk, "/dev/mmcblk0p2", RT_DEVICE_FLAG_DEACTIVATE);
}
INIT_BOARD_EXPORT(pseudo_mmcblk_setup);

static int pseudo_mmcblk_remove(void)
{
    if (pseudo_mmcblk)
    {
        return (int)rt_device_unregister(pseudo_mmcblk);
    }
    return 0;
}
INIT_FS_EXPORT(pseudo_mmcblk_remove);

长期解决方案

从系统设计角度，建议采取以下改进措施：

1. 修改Bootloader的启动参数，使其符合RT-Thread的设备命名规范，例如：

   root=sd0p0 rootfstype=elm rootwait rw
   

2. 完善BSP中的MMC/SD卡驱动实现，确保能够正确识别和处理存储设备

3. 在设备树中明确指定文件系统类型(rootfstype)

技术启示

这个问题揭示了RT-Thread设备树和启动参数处理机制中的几个重要方面：

1. 启动参数(rootwait/rootdelay)对系统启动流程的影响
2. 设备命名规范在不同系统间的差异
3. 设备驱动初始化与文件系统挂载的时序关系

开发者在使用RT-Thread时应当注意：

• 确保启动参数与BSP实现相匹配
• 了解RT-Thread特有的设备命名规则
• 在移植过程中注意设备驱动与文件系统的依赖关系

总结

通过本次问题分析，我们不仅解决了CV18XX AArch64 BSP的启动问题，还深入理解了RT-Thread的启动流程和设备管理机制。这为后续的BSP开发和系统移植提供了宝贵的经验。开发者可以根据实际需求选择临时解决方案或长期解决方案，确保系统能够正常启动和运行。