A couple questions about Milk-V Duo boards

[SiliconWizard]

Interested in evaluating the CPU they use. I haven't ordered boards yet.

Does anyone know:
- How the C906 core compares to say a Cortex-M7 (namely the main C906 core @1GHz vs a iMXRT10xx @600MHz, for instance)?
- The approximate current draw under typical load, and any "sleep" mode it may have?
- Whether it's possible (probably) but, most of all, documented, to program the main core baremetal (no Linux)? If so, is there any documentation out there? (I've seen the typical setup was Linux on the main core and some RTOS on the second core, I'd like to use both cores baremetal).

Thanks!

[brucehoult]

On my primes benchmark:

Code: [Select]

//    27.196 sec Teensy 4.0 Cortex M7 @ 960 MHz        228 bytes  26.1 billion clocks
//    27.480 sec HiFive Unleashed RISCV U54 @ 1.45 GHz 228 bytes  39.8 billion clocks
//    30.420 sec Pi3 Cortex A53 @ 1.2 GHz T32          204 bytes  36.5 billion clocks
//    36.652 sec Allwinner D1 C906 RV64 @ 1.008 GHz    224 bytes  36.9 billion clocks
//    39.840 sec HiFive Unl RISCV U54 @ 1.0 GHz        228 bytes  39.8 billion clocks
//    43.516 sec Teensy 4.0 Cortex M7 @ 600 MHz        228 bytes  26.1 billion clocks
//    47.910 sec Pi2 Cortex A7 @ 900 MHz T32           204 bytes  42.1 billion clocks
//    48.206 sec Zynq-7010 Cortex A9 @ 650MHz          248 bytes  31.3 billion clocks

The D1 is not the same chip as the Duo but it's the same core at the same speed, and this benchmark runs entirely in cache.

> The approximate current draw under typical load, and any "sleep" mode it may have?

See:



In the comments:

Without SD card: 15mA

Booting: 80-114mA, average about 90.

Idle after boot: 62mA

> Whether it's possible (probably) but, most of all, documented, to program the main core baremetal (no Linux)?

Sure. The UBoot is, after all, open source, so you can either use that to launch your own code (replacing OpenSBI) or else simply hack on the UBoot SPL. The biggest task will be initing the DDR2 RAM, but the code is there.

[SiliconWizard]

Thanks! So, in terms of pure performance, at least from your benchmark, the C906 looks way behind a Cortex-M7 at the same clock freq, but not too far between a M7 @600MHz and C906@1GHz.

In terms of power draw, the "missing" info is whether it has any kind of sleep mode, which you can go to and resume from, either when running Linux, or baremetal.
62mA on "idle" is not bad for a CPU @1GHz, but the ability to put it in some standby mode drawing much less, and from which it could get out of within maybe less than 1s, would be nice. I haven't found the info so far and may have to order boards and figure it out myself.

[brucehoult]

Thanks! So, in terms of pure performance, at least from your benchmark, the C906 looks way behind a Cortex-M7 at the same clock freq

Sure. The M7 is a pretty good dual-issue uarch -- better than A7, A9, A53, maybe close to A55. And running from SRAM not DRAM helps too. The C906 is purely single-issue, in order.

Note that the Duo has massively more RAM with 64 MB (and 256 MB and 512 MB models just becoming available for only a few dollars more)

[SiliconWizard]

Yep. The amount of RAM can be pretty interesting. Using a Cortex-M7, you rarely have access to anything else than PSRAM if you want more than the internal RAM, which is slow and limited to 8MB/chip (at least for the QSPI ones), or maybe SDRAM for some MCUs?

The Duo's with 256MB and over are slightly different beasts as I've seen, they include an ARM core on top of the 2 RISC-V cores. I haven't figured out yet how all 3 can work together.

[brucehoult]

I think you have to choose one or the other at boot time, but I don't know.

Also see:

https://github.com/orangecms/sg_boot "loader for CVItek/Sophgo SoCs (CV1800B, SG200x)"

He said today initial stuff is working and asked for collaborators.

https://t.me/riscv/1/20904

https://t.me/riscv/1/20913

[brucehoult]

More progress today:

"Daniel aka CyReVolt 🐢: Transferring code to the CVITek 1800B worked with my tool. There was no output on the UART though. I'll see if the SRAM address is different, which isn't described in the manual. UART0 seems to have the same base address per the manual."

"plat/cv180x/include/platform_def.h
296:    #define VC_RAM_BASE 0x3BC00000 // Shadow_vc_mem"

"Daniel aka CyReVolt 🐢: aha aha - 0x3BC00000 - neither "VC RAM" nor that address is mentioned in the manual"

"Daniel aka CyReVolt 🐢: THAT WORKS! VROOM VROOM! 🥳"

"I have now successfully run my own code on
- Duo (CV1800B)
- Duo 256M (SG2002)
- Duo S (SG2000)

The CV1800B has its SRAM at a different base address.
UART0 is mapped to the same address for all three."

His "own code" is written in Rust. Blergh for some people, ++ for others :-)

A note on chip names and companies ... Sophgo bought Cvitech a year or two ago, so CV1800B and SG200* share lineage.  Also, a well informed Chinese person on Telegram said a couple of days ago that Sophgo and Radxa are parts of the same company, or fall under the same umbrella company (Bitmain?). I just found this repo, which lends support to this: https://github.com/radxa/bm-bootloader-arm64

[SiliconWizard]

I ordered a couple boards and dug into the SDK and datasheet to figure out the details and possibly how to use it "baremetal".

The SDK repo: https://github.com/milkv-duo/duo-buildroot-sdk
Datasheets & schematics: https://github.com/milkv-duo/duo-files

This post which gave a starting point: https://forum.sophgo.com/t/use-opensbi-to-boot-your-own-operating-system/340

I was able to build the FSBL with mainline GCC 14.1, but that took quite a few changes in various files, so I suggest sticking to the toolchain they provide (which unfortunately is based on GCC 8 ), unless you are brave enough. It takes a while.
Note that recent GCC now includes the T-head extensions in mainline, I guess with GCC 8 this was patched: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html
The T-head extensions are described here: https://github.com/T-head-Semi/thead-extension-spec/tree/master

So with that info and the datasheet, I should be able to write baremetal stuff. I should receive the boards in a week or so, I'll see how it goes.

The second core should also be freely usable, as far as I got it, they share the same resources, and apart from the fact it doesn't have the vector extension and runs at 700MHz max "only", it's pretty much the same core. In the SDK distribution with Linux on the first core and FreeRTOS on the second, they reserve the upper 768KB of DRAM for the second core, but I think there shouldn't be any problem sharing RAM differently when going baremetal. All this looks pretty cool.

There's even a third core, 8051-based, but which can run at up to 300 MHz. Not sure I'll bother with that for now, but it's also described in the datasheet.

Also, it should be able to boot from eMMC or even from a SPI flash chip. Not sure yet how you'd program the flash chips though, at least initially. Probably before assembly? Haven't gotten into all details about the ROM bootloader. It's not documented in details, just a few sentences.

[Nominal Animal]

Do keep us informed about your experiences; I for one am very interested, and might go the same way.

The main use case for myself is, once again, as an intelligent controller for small displays to use with headless SBCs ("IoT"'y servers) and routers and switches (non-technical human interface for status reporting).

You see, if the interface is slow or sluggish, the nontechnical folks just don't trust it.  It it is slick with small animations (my favourite one is having Tux, my mascot and shown as my avatar, roll its eyes in different directions when booting or checking out something), they seem to trust it much better.

I am intelligent enough to not try and convince them otherwise, since the technology is here to do the job their way.  I just need to learn enough to make the software needed for the job.

In the Milk-V Duo case, I might even run a simple network server (tracking which machines are connected and how) on the Linux side, and the display driver on the RTOS side.  Typical display sizes I use are 320×240 and 480×320, mostly IPS panels from BuyDisplay/EastRising; I don't want the expensive HDMI stuff here.  The simple Linux network server would make it easy to add support for e.g. some ESP32's with temperature and humidity sensors to measure otherwise hard-to-reach nooks and crannies in a big rural house, for example.  It's just that I'm finding it difficult to find/get SD cards I can trust, so would prefer eMMC or something more durable.

[SiliconWizard]

I will. I'll have to confirm with actual tests, of course, but so far I think there should be no problem using this chip as a MCU on steroids.
The only thing that lacks documentation - that I could find - is the TPU, if you're at all interested in using that at a low level as some kind of "general-purpose" accelerator.

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0. That bites as there are a number of actual chips on the market that have implemented rvv 0.7.1 and they are now "let down" by the toolchains - you'd have to stick to a pretty old version, and find it. This has been discussed already a couple years ago (found discussions about it with Bruce), so this is not a new problem. From what I know, so far, very few actual, available chips implement rvv 1.0. There is the newer K230 which apparently does, but I haven't had all that great experience with Kendryte in terms of support (with the K210), so I would personally shy away from Kendryte at this point.

Of course, the chip is perfectly usable without the vector extension. Alternatively, one can either find a version of binutils that supports rvv 0.7.1 and just use 'as' for assembly code which uses rvv and still use a recent and mainline GCC/binutils for the rest. Or implement your own assembler.

Regarding displays, yes, note that the CV1800B doesn't support any video output, only input. But of course you can drive TFT panels which have a SPI controller. Note that the chip doesn't have any kind of "parallel"/FSMC interface, so you either have SPI, UART or SDIO. (It has 2 SDIO controllers, one is used by the SD card, but I'm thinking of using the second for communicating with a FPGA. You can otherwise use it to connect another flash chip, SD card or even modules with a SDIO interface such as some WiFi modules.)

Yes in your case, going "baremetal" may not be the most efficient approach: using the provided Linux on the main core and FreeRTOS on the second will work, and it's readily supported.
For using eMMC, from what I gathered, the board has a footprint (not populated) for a Flash chip that can be used instead of a SD card - note that the pins are routed in parallel, so it's either one or the other, they share the same SDIO controller. And you'd need a eMMC chip with a SDIO interface, from what I got. They give a list of supported chips in the following file: duo-files/duo/hardware/CV1800B-Flash-Support-List.pdf
As I said, I don't know yet how you can flash it this way, as one can't solder a Flash chip and boot from a SD card at the same time. Either you'd have to flash the chip beforehand with an external programmer, or maybe there's a USB mode in the bootloader that I don't know how to use yet. Something to figure out.

[brucehoult]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

You can choose which version you want using command line -march.

Even better, if you write RVV code using the C intrinsic function interface then the same source code can be compiled to either 0.7.1 or 1.0.

The only missing feature is auto-vectorisation doesn't support 0.7.1.

That bites as there are a number of actual chips on the market that have implemented rvv 0.7.1

Yes, literally billions of chips shipped according to THead, and on Linux-capable boards priced as low as $5 (such as the Duo, but also Pine64 ox64 and Sipeed M1s (BL808 chip) both of which also have 64 MB RAM.

0.7.1 is, obviously, not quite as good as 1.0, otherwise we wasted 2 1/2 years of committee time between those releases, but it's still a darned good vector ISA, and better than SIMD ISAs. Probably as good as Arm's SVE.

Meanwhile, what's the cheapest thing you can get SVE (spec published in 2016) or SVE2 (2019) in? No SBC that I know of -- not the RK3588, for example. High end phones only.

and they are now "let down" by the toolchains - you'd have to stick to a pretty old version, and find it. This has been discussed already a couple years ago (found discussions about it with Bruce)

Not a problem, I've had the relevant GCC/binutils snapshot at https://github.com/brucehoult/riscv-gnu-toolchain even since the first C906 boards came out in 2021.

But now you can simply use current GCC.

From what I know, so far, very few actual, available chips implement rvv 1.0. There is the newer K230 which apparently does

K230 was the first, with the CanMV-K230 board released back in October. It's got two cores with the larger (1.6 GHz, dual issue C908) one supporting RVV 1.0. There are a couple of annoyances with it, the big one being that it's only got 0.5 GB RAM, the small one that the vendor OS runs Linux on the small (non RVV) core reserving the big core for microcontroller/realtime use. 3rd parties had figured out how to run Linux on the big core, with RVV enabled.

https://code.videolan.org/Courmisch/k230-boot/

See also this excellent video which demos running RVV 1.0 code on the CanMV-K230:

youtube.com/watch?v=Ozj_xU0rSyY

The BananaPi BPI-F3 started getting delivered to customers in the last month. It has 8 dual-issue cores running at 1.6 GHz (and reportedly better than Arm A55 or SiFive U74) each with RVV 1.0. Also the price is good at $63 for a board with 2 GB RAM or $75 for a board with 4 GB RAM.

https://www.aliexpress.us/item/1005006921744822.html

The problem is I don't regard 4 GB as enough for an 8 core system. The SoC supports 16 GB RAM, which would be great, but boards with this are not (yet) available.

There are a couple of faster boards coming up using SiFive P550 cores. They will be comparable to RK3588 boards except they DON'T have RVV.

Late in the year the SG2380 boards with 16 SiFive P670 cores with RVV 1.0 should appear. Those are OoO with roughly Arm A78 performance, including around 2.5 GHz clock for the P cores. That should make a really usable PC, getting up into early i7 territory I think.

Of course, the chip is perfectly usable without the vector extension. Alternatively, one can either find a version of binutils that supports rvv 0.7.1 and just use 'as' for assembly code which uses rvv and still use a recent and mainline GCC/binutils for the rest. Or implement your own assembler.

Yup. Been doing that for years.

But now just use the current GCC version, 14.1.

[SiliconWizard]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

Ah thanks! Didn't realize that was what the XTHeadVector implemented. Great. I'm using GCC 14.1 now, so that's all good. Solved.

[brucehoult]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

Ah thanks! Didn't realize that was what the XTHeadVector implemented. Great. I'm using GCC 14.1 now, so that's all good. Solved.

There are a couple of minor differences:

- XTHeadVector doesn't include the "ediv" feature from 0.7.1 (which was optional and C906/C910 don't implement)

- XTHeadVector adds the "vlenb" CSR (vector register length in bytes), which was not in the 0.7.1 spec.

I think that's it!

[SiliconWizard]

I should have received the boards almost a week ago, but the package got stuck at a transit facility for an unknown reason. Annoying.