打个笔记，SDK版本V1.0.8。
1.编译RTOS固件，以Duo256M为例
source device/milkv-duo256m/boardconfig.sh
source build/milkvsetup.sh
defconfig cv1812cp_milkv_duo256m_sd
clean_uboot
build_uboot
编译完后可以在install/[config]下找到编译好的fip.bin
Nice tutorial! Thank you!
Do you need to
after each change in code, or build_uboot is enough?
Have you managed to launch the blink using FreeRTOS? (Mine doesn’t work for some reason) How do I check if FreeRTOS is actually running?
Thank you for your reply,
In my test it confirm worked
But the SDK defaults to disabling RTOS，and the demo of blink has some wrong need to modify.
If you want to enable RTOS on DUO-256M, you need add config “CONFIG_ENABLE_FREERTOS=y” to /build/boards/cv181x/cv1812cp_milkv_duo256m_sd/cv1812cp_milkv_duo256m_sd_defconfig
If you want run blink in RTOS, you need alter define in /freertos/cvitek/task/comm/src/riscv64/milkv_duo_io.h:
#define GPIO2 0x05021000
#define GPIO_SWPORTA_DR 0x000
#define GPIO_SWPORTA_DDR 0x004
alter code /freertos/cvitek/task/comm/src/riscv64/milkv_duo_io.c: 24----->2
Then, you can find the log starting with “RT:”, if the demo of mailbox worked, the blue LED will blinked.
Thanks a lot!
It’s a bit weird, but a couple of days ago I had some troubles compiling the whole thing (the same error as here make: *** [Makefile:604: br-rootfs-pack] Error 2 Error: Build board milkv-duo failed! · Issue #62 · milkv-duo/duo-buildroot-sdk · GitHub). Later I tried compiling just the FreeRTOS part (according to your instructions in the original post) - and it compiled just fine! So, is there a way to start the second (FreeRTOS) core from the linux one, without reflashing the entire ISO?
The SG2002 datasheet maybe useful for you, reference Part5–>SOFT_CPU_RSTN, I had not test, but I guess it’s useful.
I try to use devmem write the reg to reset the RTOS core, but the firmware seems not changed.
The fip.bin seems loaded on fsbl stage, if we want start the second core from linux, we may need to find a way to reload the bin to memory.
I wonder, which core you tried to reset 
In the datasheet, they are core0, core1, core2 and core3 (without explaining which is which), meanwhile, it has two C906 cores, one ARM core, one 8051 core and one TPU core? (5 cores altogether?)
Btw, thank you for pointing on the right GPIO register! (I thought, PWR_GPIO is controlled by GPIO3, but it was RTCSYS_GPIO). However, yesterday I managed to blink from terminal using devmem and IOBLK_GRTC_REG_PWR_GPIO2 register.
The same ambiguity is with PWM. The datasheet states, it has four PWM channels. But according to the pinout, the same PWR_GPIO2 (the LED one) is PWM10. The pinmux also suggests that it can be configured as PWM10 (i checked it both through pinmux and devmem FMUX_GPIO_REG_IOCTRL_PWR_GPIO2), but when trying to setup PWM with wiringX, it complained, that was not a PWM pin (could be, that was old toolchain supplied with duo-examples though). However, I couldn’t find registers responsible for PWM10 in the datasheet…
As for now, I’m struggling with compiling it altogether from Docker (strange ‘permission denied’ errors with chmod on some newly created files in the buildroot - I am out of ideas what’s wrong with it)
I’m happy that my note useful for you.
I tried to reset cpucore0-3, but it doesn’t work. In my experiment, the cpusys2 for RTOS core, cpusys1 for linux, cpusys0 maybe for Arm.
I haven’t used PWM and Docker before, but I suggest you build the SDK in Ubuntu, I set a virtual machine to build the SDK, and it have a good work.
yep! I just installed linux mint on my old imac, and it has successfully finished building the firmware in somewhat 40 minutes (core2duo 2009) (while on my late 2011 mbp with Quad-Core Intel Core i7 it took more than hour in Docker environment).
Interestingly, it started blinking immediately after I power it up - the FreeRTOS loads instantly! However, I still don’t see any logs in dmesg - probably, it’s logging to some uart…
Very interesting tutorial, I tried to upload de fw on a milk-v duo but it doesn’t seem to update even after following theses instructions. Any ideia on what might be missing?
If I compile the whole image it works and the new RTOS fw runs, but only this way.
I believe, after you make the whole thing work, you can just follow this tutorial to build a working freertos image (at least I managed to build it from docker, and i can confirm that it works fine).
but remember, I am using duo-256 (there are some differences).
besides, I’ve seen the following instruction (for the original duo board):
The SDK’s default configuration file, freertos/cvitek/kernel/include/riscv64/FreeRTOSConfig.h, enables configUSE_TICK_HOOK but does not implement the hook callback. Modify the configuration to disable this macro.
# define configUSE_TICK_HOOK 0
in my case, i reverted everything back and it worked just fine.
Nvm I could build, but instead of using build_uboot I used build_all. Then the same as your tutorial. Thanks man!
I’ve sent a pull request, Remoteproc fix by kinsamanka · Pull Request #75 · milkv-duo/duo-buildroot-sdk · GitHub, that allows dynamic firmware loading on the secondary processor.
With this patch applied, use the following commands to run:
# copy firmware to /lib/firmware dir:
scp -O duo-buildroot-sdk/freertos/cvitek/install/bin/cvirtos.elf root@<duo ip>:/lib/firmware
# stop existing firmware
echo stop > /sys/class/remoteproc/remoteproc0/state
# change firmware name
echo cvirtos.elf > /sys/class/remoteproc/remoteproc0/firmware
# start
echo start > /sys/class/remoteproc/remoteproc0/state