Duo 256M is a small board powered by SOPHGO SG2002 multi-architecture Arm/RISC-V/8051 SoC with 256MB of on-chip RAM and a 1 TOPS NPU, a microSD card for storage, a camera connector, a USB-C port for power and programming, and two headers for GPIO expansion.
We covered the SOPHGO SG2002 (and SG2000) Arm+RISC-V+8051 AI SoC earlier this month saying a couple of boards were expected very soon. We’ve already covered Sipeed LicheeRV Nano with optional Ethernet or WiFi 6, and now we’ll look at the Duo 256M designed by Milk-V Technology in more detail since it’s available now.
Duo 256M specifications:
- SoC – SOPHGO SG2002
- Main core – 1GHz 64-bit RISC-V C906 or Arm Cortex-A53 core (selectable)
- Minor core – 700MHz 64-bit RISC-V C906 core
- Low-power core – 25 to 300MHz 8051 MCU core
- NPU – 1 TOPS INT8, supports BF16
- Integrated 256MB DDR3 (SiP)
- Storage
- MicroSD card slot
- 32Gbit NAND flash (CSNP32GCR01)
- Camera Interface – 4-lane MIPI CSI input connector
- Audio – Built-in microphone
- Networking – Support for 100Mbps Ethernet via adapter connected to 5x I/O pins
- USB – 1x USB Type-C port for power and programming
- Expansion – 2x 20-pin 2.54 pitch headers with access to GPIO, PWM, I2C, SPI, UART, JTAG, ADC, Audio, Arm/RISC-V switch signal
- Misc – Power LED
- Power Supply – 5V via USB-C port
- Dimensions – 51 x 21mm
You’ll find hardware documentation – including schematics, PCB layout, and datasheets – on GitHub. Instructions to getting started with buildroot (Linux 5.10 + FreeRTOS), the TDL SDK leveraging the NPU for computer vision workloads (e.g. face detection, face tracking, license plate recognition, gesture detection, etc…), and various code samples for GPIO and other features on the documentation website.
The Duo 256M board can be purchased for $7.99 plus shipping on Arace Tech. If you are interested in building your own board based on SG2000 or SG2002, samples of the chips can be purchased for respectively $6 and $5 each in packs of 5 pieces ($30 and $25).
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Such solutions are getting increasingly interesting. @dgp’s dream has come true,now you have Linux in a device the size of an arduino nano, and with 4 times more RAM than before. The board’s form factor makes it easy to solder on another PCB thanks to the castellated pins, like is usually done for ESP32. I think we’d need to see a tiny board with more compact pins like we’re seeing with the ESP series (e.g. the PSF85B) in order to let adopters make their own boards without having to deal with too fine PCB routing nor too small pitch soldering. This stuff is really opening a lot of possibilities. I’m tempted to buy one again, even though I have not yet received the LicheeRV nano 🙂
Another good point is that these boards already have partial support in mainline since 6.7: uart & gpio for now (and only the 64MB version).
Interesting, indeed. Hopefully the work goes forward. Adding a bit more ram should only be a dt fix, right?
This looks really good. You even get a 300mhz 8051 🙂
Some silicone real estate i could imagine being put to better use…
You know how tiny an 8051 and 6K of SRAM is in a modern process? It’s probably stuffed into otherwise unused space between other existing functions. 🙂 I’m no 8051 fan, but the area is beyond trivial.
The 8051 is probably there for deep sleep. If you don’t have something that can run code the things you can check to work out if you should boot up the main CPU are very trivial so you end up booting most of the system to check something and go back to sleep.
A small 8 bit core is perfect for waiting for a wake up signal, checking if you really want to wake up or not by poking around.
I agree, similar to the ESP32 ULP.
We live in exciting times for microcontrollers, but it seems to be this is a weird product, a Frankenstein of a SoC with three different architectures. If this was April 1st, I’d be thinking it was a joke. Am I mistaken? Mixing cores is not new in larger CPUs and even mixing architectures as I think Intel’s CPUs carry out used to carry a non-x86 core for the ME stuff? But still, this seems unusual in microcontrollers. Apart from it being awesome that someone can do this, can someone point out real life advantages of such an approach? Seems to me a logical approach is to combine different size cores of the same architecture (which you do see more and more)?
See around this comment about potential benefits of such a FrankenSoC: https://www.cnx-software.com/2024/02/07/sophgo-sg2000-sg2002-ai-soc-features-risc-v-arm-8051-cores-android-linux-freertos/#comment-615467
As much as I don’t like to see wasted silicon, this chip isn’t as much of an abomination as it seems–or it is, but for different reasons.
The three cores are all different enough that you would need different environments to develop for them anyway–the SG2000 already had an 64 bit RV core with MMU (suitable for a paging OS) with a slower 64 bit RV core with just a basic memory protection unit (not suitable for a paging OS), and a third core with an MSC51 architecture. You wouldn’t use the same compiler for the two 64 bit RV cores and the rest of your tooling and libraries would be different because one would be built for glibc and the other likely not–and the 8051 is just straight up PITA.
So, moving the ‘main’ RV core from RV64 to ARM64 really doesn’t mess up an already nightmare inducing development environment all that much. You’re still going to use a different compiler and libraries for the two 64 bit cores.
Which all just goes to say that development for these chips (if you try to use all of it) is a train wreck. The new chip isn’t a worse train wreck, just a slightly different kind of one.
Oh, and I’ve yet to see an example of how to run code on the 8051 from Linux.
With all that said, their out of the box Linux experience is the best I’ve run into in a board like this! You write an image to an SD card, plug it in and power it from a PC via USB-C. It appears as an RNDIS network interface. Then you just ssh to the board and you’re in. That’s up there with DJP’s breadbee with the micro-USB power/serial setup, but nicer since it’s a full up network connection, but worse since it’s RNDIS.
Getting ethernet working was super simple as well. The SoC has a 10/100 PHY built in, so you just need a jack with magnetics connected to the 5 pins on the end of the board and you’re good to go. The software change to activate ethernet was simple as well–something that I can’t say for the Ox64 nor the Sipeed M1S(dock). Neither of them has working ethernet yet, IIRC. They have a built in 10/100 MAC on the chip and require an external RGMII PHY. (1.8v for the Ox64 and 3.3V for the M1S)
On Arace Tech they also offer a USB/Ethernet IO board for 5$. I’ve not had the opportunity to test as I apparently order the Duo board without the headers and haven’t taken the time to solder them on!
I picked up some of their boards on Ali and they work quite well. I also cut up an old 10/100 PCI ethernet board to steal its magnetics and that also worked–once I reversed the pinout of the darn magnetics…
So, yes, ethernet works just fine on there.
I’ve never heard of RNDIS. Would this work as straightforward on a machine running Ubuntu? (seems it’s some MS thing)
> but worse since it’s RNDIS
Trying to understand the drawback 🙂
> RNDIS. Would this work as straightforward on a machine running Ubuntu?
Ubuntu running on the machine you connect to the board or running on the latter?
For the 1st scenario it should work OOTB, the other way around (enabling USB gadget mode on the OTG port of a board which involves switching the port from host to device mode and loading g_ether driver) can sometimes be tricky. Personal experience with smelly Allwinner BSP kernel here and Raspberries there.
RNDIS is a very old Microsoft standard for networking attachment. Its biggest problems are *it’s old* and *its Microsoft*. That said, it’s widely supported. I don’t ever use Ubuntu, but the device showed up immediately on Debian and Fedora as a network device and was trivial to bring up the network connection. It was hardly any harder than installing a terminal program, chaning the groups/permissions on the USB serial device process that boards with serial over USB use. *And* it allowed a full network connection–so multiple ssh connections, routable connection to the outside world, scp, etc. That’s a clear step up from a simple serial console login.
Thank you for that detailed explanation! Very useful 🙂
To my surprise my Samsung phone exposes some rndis when tethering
Works fine out of the box with Ubuntu and FreeBSD. You’ll need to set “sysctl net.ipv4.ip_forward=1;” in Ubuntu to enable fowarding between USB0 and wlo0 (or whatever your main network port is) and add a route, but it is surprisingly fast.
Has anyone tested the ARM core on these chips (2000 and 2002)? And any benchmarks comparing the C906 and A53?
The official builds seem to be RISCV only. I still don’t understand the purpose of a selectable core, why would anyone choose the RISCV option?
I’ve been trying to find out how to run code on the 8051 for as long as I’ve had the boards and I haven’t found anything on their wiki or their forum. The question has been asked, just not answered. 🙁