Confirmed with milkv, only the sd card version is sold
by default for duo in the market. The spi pins are
provided through stamp holes, so that users can solder
the corresponding components on their baseboard during
secondary development.
In order to simplify maintenance work, the mainline
will only support the sd-card version and no longer
support spinor/spinand.
Updated config files the same in this patch.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
duo is a real hardware, no need for virtio.
Disable RT_USING_VIRTIO and update configuration to latest.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Move the combine.sh to under cv18xx_aarch64, so we can
run this script the same as scons and no need to change
cwd.
Rename the folder boot to prebuild just becuase all the
files under boot are prebuild binaries.
Move the prebuilt fip.bin to under prebuild/milkv-duo256m
because it's only for 256.
Update combine.sh accordingly and output fip.bin to the output
folder where we create fip.bin/boot.sd as other bsp.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
For bsp/cvitek, all drivers related files are moved to the directory
bsp/cvitek/drivers, so the drivers_path_prefix processing in the
SConstruct of the three bsp projects can be simplified.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
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>
When compiling CV18xx_arch64, have a error:
can not find "rt_fdt_commit_memregion_early"
Analysis: b785ef9 ("[libcpu][aarch64]memory setup using memblock ")
no longer support "rt_fdt_commit_memregion_early", become use
"rt_memblock_reserve_memory"
Solution: Refer to the bsp/qemu-virt64-aarch64/drivers/board.c
delete "rt_fdt_commit_memregion_early"
Signed-off-by: Shicheng Chu <1468559561@qq.com>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
When compiling CV18xx_arch64, there are the following errors:
1. missing soc type for aarch64
2. uart device objects defined but not used
Analysis: a63c07f ("bsp: cvitek: new design for pinmux") and
114e143("bsp:cvitek: add pinmux for uart"), CV18xx_arch64 is not
considered.
Solution: Refer to the cv18xx_riscv format to add the corresponding
chip type SOC_Type_SG2002, as well as the corresponding macro
for the serial port pins and interrupts
Signed-off-by: Shicheng Chu <1468559561@qq.com>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
