bsp: cvitek: fix cv18xx_aarch64 mnt init blocking

The aarch64 core of duo on the master cannot enter the
console interface. It can only print the RT flag and hold it.

Analysis: The latest commit that can work is ae6a328 ("Add
psoc62, 61 config"). This phenomenon will occur after adding
754c59a ("[Feature] DFS mount auto by kernel parameters").
The specific reason is that when aarch bsp enables the device
tree, the current u-boot will pass in bootargs, which contains
"root=/dev/mmcblk0p2 rootwait rw", which means that the
kernel is required to wait until the rootfs in /dev/mmcblk0p2
loaded successfully. However, the current aarch64 bsp default
does not implement sdmmc device mounting, causing the
 kernel file system mounting module (rootfs_mnt_init() of
components/drivers/core/mnt.c) to enter an infinite loop waiting.

Solution: At present, we do not plan to modify the startup
parameters of u-boot. The temporary solution adopted is to
create a pseudo /dev/mmcblk0p2 device during the board
initialization process, and then cancel the pseudo device
after mnt is completed. This allows the kernel boot to be
completed successfully.

Signed-off-by: Shicheng Chu <1468559561@qq.com>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
This commit is contained in:
Z8MAN8 2024-07-25 15:14:16 +08:00 committed by Meco Man
parent bde4817b9e
commit a1b01ee865
1 changed files with 40 additions and 0 deletions

View File

@ -81,6 +81,46 @@ void rt_hw_board_init(void)
{ {
rt_hw_common_setup(); rt_hw_common_setup();
} }
/*
* FIXME: This is a temporary workaround.
* When aarch bsp enables the device tree, the current u-boot will
* pass in bootargs, which contains "root=/dev/mmcblk0p2 rootwait rw",
* which means that the kernel is required to wait until the rootfs
* in /dev/mmcblk0p2 loaded successfully. However, the current aarch64 bsp
* default does not implement sdmmc device mounting, causing the kernel file
* system mounting module (rootfs_mnt_init() of components/drivers/core/mnt.c)
* to enter an infinite loop waiting.
* Solution: At present, we do not plan to modify the startup parameters
* of u-boot. The temporary solution adopted is to create a pseudo
* /dev/mmcblk0p2 device during the board initialization process, and
* then cancel the pseudo device after mnt is completed. This allows the
* kernel boot to be completed successfully.
*/
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);
#endif /* RT_USING_OFW */ #endif /* RT_USING_OFW */
static rt_ubase_t pinmux_base = RT_NULL; static rt_ubase_t pinmux_base = RT_NULL;