These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.
Most content on this site is licensed under the WTFPL, version 2 (details).
Questions? Praise? Blame? Feel free to contact me.
My old blog (pre-2006) is also still available.
See also my Mastodon page.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
(...), Arduino, AVR, BaRef, Blosxom, Book, Busy, C++, Charity, Debian, Electronics, Examination, Firefox, Flash, Framework, FreeBSD, Gnome, Hardware, Inter-Actief, IRC, JTAG, LARP, Layout, Linux, Madness, Mail, Math, MS-1013, Mutt, Nerd, Notebook, Optimization, Personal, Plugins, Protocol, QEMU, Random, Rant, Repair, S270, Sailing, Samba, Sanquin, Script, Sleep, Software, SSH, Study, Supermicro, Symbols, Tika, Travel, Trivia, USB, Windows, Work, X201, Xanthe, XBee
For a project (building a low-power LoRaWAN gateway to be solar powered) I am looking at simple and low-power linux boards. One board that I came across is the Milk-V Duo, which looks very promising. I have been playing around with it for just a few hours, and I like the board (and its SoC) very much already - for its size, price and open approach to documentation.
The board itself is a small (21x51mm) board in Raspberry Pi Pico form factor. It is very simple - essentially only a SoC and regulators. The SoC is the CV1800B by Sophgo, (a vendor I had never heard of until now, seems they were called CVITEK before). It is based on the RISC-V architecture, which is nice. It contains two RISC-V cores (one at 1Ghz and one at 700Mhz), as well as a small 8051 core for low-level tasks. The SoC has 64MB of integrated RAM.
The SoC supports the usual things - SPI, I²C, UART. There is also a CSI (camera) connector and some AI accelaration block, it seems the chip is targeted at the AI computer vision market (but I am ignoring that for my usecase). The SoC also has an ethernet controller and PHY integrated (but no ethernet connector, so you still need an external magjack to use it). My board has an SD card slot for booting, the specs suggest that there might also be a version that has on-board NAND flash instead of SD (cannot combine both, since they use the same pins).
There are two other variants - the Duo 256M with more RAM (board is identical except for 1 extra power supply, just uses a different SoC with more RAM) and the Duo S (in what looks like Rock Pi S form factor) which adds an ethernet and USB host port. I have not tested either of these and they use a different SoC series (SG200x) of the same chip vendor, so things I write might or might not be applicable to them (but the chips might actually be very similar internally, the CVx to SGx change seems to be related to the company merger, not necessarily technical differences).
The biggest (or at least most distinguishing) selling point, to me, is that both the chip and board manufacturers seem to be going for a very open approach. In particular:
Full datasheets for the SoC are available (the datasheets could be a bit more detailed, but I am under the impression that this is still a bit of a work-in-progress, not that there is a more detailed datasheet under NDA).
The tables (e.g. pinout tables) are not in the datasheet PDF, but separately distributed as a spreadsheet, which is super convenient.
For the the SG200x chips, the datasheet is created using reStructuredText (a text format a bit like markdown but more expressive), and the rst source files are available on github under a BSD license. This is really awesome: it makes contributions to the documentation very easy, and (if they structure things properly when more chips are added) could make it very easy to see what peripherals are the same or different between different chips.
Sophgo seems to be actively trying to get their chips supported by mainline linux (maybe by contributing code directly, or at least by supporting the community to do so), which should make it a lot easier to work with their chips in the future.
Other vendors often just drop a heavily customized and usually older kernel or BSP out there, sometimes updating it to newer versions but not always, and relying on other people to do the work of cleaning up the code and submitting it to linux.
The second core can be used as a microcontroller and Milk-V supports running FreeRTOS on it it, and provides an Arduino core for it (have not looked if it is any good yet). It seems the first core then remains active running Linux, providing a way to flash the secondary core through the primary core.
All this is based on fairly quick observations, so maybe things are not as open and nice and they seem to be at first glance, but it looks like something cool is going on here at least.
Other things I like about the board:
There are also some (potential) downsides that might complicate matters: - Only 64MB RAM is very limited. In practice, some RAM is used for peripherals (I think) too, the default buildroot image has something like half of the RAM available to Linux. Other images configure this differently so full RAM is available to the kernel (leaving 55M for userspace). See this forum topic for more details.
Low memory limits options - people have reported apt needs around 50M to work, which means it ends up using swap and is super slow.
The official Linux distribution from milk-v is a buildroot-built image, which means all software is built into the image directly, no package manager to install extra software afterwards.
The buildroot files are available, so it should be easy too build your own image with extra software, though I think this does mean compiling everything from source.
There does seem to be a lively community of people that are working on making other distributions work on these boards. In most cases this means building a custom kernel for this board (with milk-v/sophgo patches, often using buildroot) and combining it with existing RISC-V packages or a rootfs from these distributions. Sometimes with instructions or a script, sometimes someone just hand-edited an image to make it work.
Hopefully proper support can be added into the actual distributions as well, though a lot of distributions do not really have the machinery to create bootable images for specific boards (i.e. they only support building images for generic BIOS or EFI booting). One distribution that does have this is Armbian, but that is Debian/apt-based so probably needs more than 64MB RAM.
I have briefly tried the Alpine and Arch linux images that are available. Alpine is really tiny, but like the official buildroot image uses musl libc. This is nice and tiny, but not all software plays well with it (and in all cases I think software must be compiled specifically against musl). The main application I needed (The basicstation LoRaWAN forwarder) did not like being compiled against musl (and I did not feel like fixing that, especially since I am doubtful such changes would be merged upstream).
So I am hoping I can use the Arch image, which does use glibc and seems to run basicstation (at least it starts, I have not had the time to reallly set it up yet). Or maybe a Debian/Ubuntu/Armbian image after all - I have also ordered the 256M version (which was not in stock initially).
For an overview of various images created by the community, see this excellent overview page.
It is not entirely clear to me what bootloader is used and how the
devicetree is managed. On most single-board linux devices I know,
there is u-boot with a boot script, which can be configured to load
different devicetrees and overlays to allow configuring the hardware
(e.g. remapping pins as SPI or I²C pins). On the buildroot-image for
the Duo, I could find no evidence of any of this in /boot
, but
I did see u-boot being mentioned in some places, so maybe it is just
configured differently.
Even though the documentation is very open, some of it is a bit hard to find and spread around. Here's some places I found:
The USB datapins are available externally, but only on two pads that need pogopins or something like that to connect to them. Would have been more convenient if these had a proper pin header.
Some of the hardware setup is done with shell scripts that run on startup (for example the USB networking), some of which actually do raw register writes. This is probably something that will be fixed when kernel support improves, but can be fragile until then.
Sales are still quite limited - most of the suppliers linked from the manufacturer pages seem to be China-only, and I have not found the boards at any European webshop yet. I have now ordered from Arace Tech, a chinese webshop that ships internationally and worked well for me (except for to-be-expected long shipping times of a couple of weeks).
So, that was my first impression and thoughts. If I manage to get things running and use this board as part of my LoRaWAN gateway design, I'll probably post a followup with some more experiences. If you have used this board and have things to share, I'm happy to hear them!
Thanks for the overview, it is also a very helpful collection of links. I also ordered the Milk-V Duo 256, I will see what can be done with it at this stage. Have a nice day!
Would be cool to do a custom pcb using the same design