Milk-V Mars: RISC-V credit card size SBC | Hacker News Reader

Milk-V Mars: RISC-V credit card size SBC

milkv.io

112 pointsvmoore76 comments

This is definitely not the first RISC-V SBC at this size (the Sipeed Nezha SBC[0] launched over two years ago based on the Allwinner D1, and the ARIES FIVEBerry[1] launched almost a month ago based on the Renesas RZ/Five). It's not even the first SBC with that specific SoC, as StarFive (the company behind the JH7110 SoC used by this SBC) launched the VisionFive 2 SBC[2] on KickStarter back in September, and Pine64 had the STAR64 since last year as well.

As for PoE support, the presence of the 4-pin header on the board suggests that it's optional, and requires the help of something like the PoE+ HAT[3], same as on the VisionFive 2 and the RPi.

[0] https://www.indiegogo.com/projects/nezha-your-first-64bit-ri...

[1] https://www.aries-embedded.com/evaluation-kit/cpu/rzfive-ren...

[2] https://www.starfivetech.com/en/site/boards

[3] https://www.raspberrypi.com/products/poe-plus-hat/

If you want to talk about customers actually receiving stuff, rather than announcements or taking preorders, then the timing is:

- Nezha: late June / early July 2021

- VisionFive 2: February 2023

- Star64: May 2023

The PineTab-V also uses the JH7110. It was supposed to ship late May at the same time as the (very similar) A55-based PineTab2, but according to the company they found something they wanted to fix before shipping. Hopefully soon! My VF2 that arrived in February was supposed to have been in November, and the Star64 was scheduled to ship in December, so slips of a few months are just in the nature of the industry, especially at this time.

No argument there, though I'm not sure why you feel that the delivery date is the relevant metric in the context of the Milk-V Mars which has only been announced and isn't even available for preorder yet.

Because the delay between announcement or order-taking and receiving the thing can be highly variable, and having it in my hands and being able to use it is what is important to me.

The biggest delays are usually with a new SoC. Once the SoC is available, building yet one more circuit board is usually a pretty straightforward exercise, at least for the competent.

How does it boot?

Or is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board.

I'm not certain, but I think that's what opensbi is for: https://github.com/riscv-software-src/opensbi

I don't know about interrupts/device tree/etc. but at least for the boot process itself, UEFI/EDK2 was ported to RISC-V. (I actually learned this because I was looking up information about the Windows PE format and was surprised to see relocations support for RISC-V; they needed to add support for it to the PE specification since PE is the native binary format of UEFI!)

UEFI/EDK2 has been demoed with the JH7110 on VisionFive2.

It's not quite complete yet (e.g. lacks drivers for hdmi display and usb), but it boots Linux.

The simpler u-boot SPL --> opensbi --> u-boot flow is mature, and patches have been submitted upstream.

UEFI has also been ported to ARM, yet we still have all kinds of issues booting ARM boards with generic images.

Yep, it's not the full story. For ARM, the standard for that is SystemReady.

UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by some RISC-V platforms, and there's PLIC and APLIC for interrupts. Undoubtedly there are more things that I'm not thinking of, but I think that's a good start, as those are two things that were in fact NOT standard on many ARM SBCs.

That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?

Good question; I hope they choose the path of standards early on, but it's not clear yet. I wonder if there's a genuine cost-cutting reason to not implement standards like ACPI. I believe SiFive was involved in the ACPI-on-RISC-V work, so that's probably a good sign. But honestly? I think we'll just have to wait and see.

Yes, and already done. For UEFI specifically, there's a relevant spec[0].

0. https://github.com/riscv-non-isa/riscv-uefi/releases

Oh, those technologies have already become non-niche? So if I survey the world of RISC-V SBCs, I will find that they can all pretty much just boot the same generic RV64 Linux distro images?

No?

AIUI Sifive's most recent board and VisionFive2 have working EDK2 UEFI.

VF2's is early (boots Linux, but only from mmc. No NVMe, USB or display yet), but being worked on by StarFive themselves.

In the future, with OS-A Platform spec, you can expect RISC-V computers to be no different than PCs from a user perspective.

Under the hood, the platform is modern, and carries none of the legacy x86 PCs do. The scope of standardization is also broader: It's not just interrupts, timers or memory map, but also things like the interfaces for Watchdogs, GPIOs are being standardized.

>is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board.

No. Instead, RISC-V standardized the boot process early on, avoiding that situation.

That wasn’t actually true on the boards I’ve tried, MangoPi MQ-Pro being the most recent. Look here for more details: https://linux-sunxi.org/Allwinner_Nezha Maybe if it had a “standard” U-Boot flashed onto a SPI chip you could standardize the process, but then you can do the same with ARM (this is what TowBoot does), so RISC-V is not a benefit in this instance.

Things are still in a rapid development phase, especially for the new boards in the last four months (VF2, Star64, LicheePi4A), figuring out what things are actually necessary. The aim is definitely to get a board-specific (but standard interface) uboot and SBI in SPI flash on each board, and then have a single kernel + root FS image (for each distro) that can run on anything.

One obstacle is that some people are resisting upstreaming support for the THead C906 and C910 cores "non standard" physical memory attributes and vector implementation into the toolchain and kernel. Both those things were 2 1/2 years away from standardisation in mid 2019 when THead designed their cores, and it takes 3 1/2 to 4 years to get a new core into cheap mass production SoCs and on to boards, so they really could not have done better (other than to simply not implement that kind of feature at all).

How did they handle implementation differences between SoCs? Do all RISC-V SoC have exact same memory maps and SFR behaviors?

There are memory map and SFR differences. I bet it's similar to how Linux on Arm/PowerPC/MIPS handle it with device trees.

Device trees indeed.

Note that newer SBCs have efforts implementing UEFI spec[0], and RISC-V is working on OS-A Platform spec[1], which further reduces basic peripheral and memory map differences.

0. https://github.com/riscv-non-isa/riscv-uefi/releases

1. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0].

0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

there are so many SBCs these days.

if you use them for hobby projects, many of them are fine.

if you ever want to convert your project to something commercial, I would still consider raspberry pi and beaglebone instead based on software maturity and community support and their ecosystem at large.

I really like NXP's i.MX6/8/9 chips, I wish there are some i.MX SBCs as popular as RPi and Beagles, for both hobby and commercial applications.

I would tend to agree, but the supply limitations of the Pis has made me re-think that. I've heard with commercial agreements you can sometimes get Pis easier, but for launching a new product I'd be terrified that my growth would be hampered/limited by availability of the Pi

I have had zero problems getting pis for the past 3 years, but we generally pre-buy supply in bulk (500+)

Out of curiosity, what is the channel for making a purchase like this? I am in that ballpark in terms of supply for CM4s.

We use Insight.

I feel like there are ton of SBC designs out there. Many are still in Kickstarter/Launch phase. Others are sold-out. And the few that aren't sold out are selling for much higher than their reference price.

>if you ever want to convert your project to something commercial

Surely at that point you would just treat the SBC as a reference design and fab your own boards?

A lot of commercial projects based on SBCs are relatively niche. It's very common to see things like lighting controllers, hobbyist stuff, etc, that's in the run size of 500 at the very most, basically be a raspberry pi with a custom hat in a custom plastic case. That can sustain a medium sized business.

Designing and fabbing your own boards doesn't always make sense until you're on a version 2, or 3.

use CM4 modules with your own carrier board makes sense when you're building 500+.

I read somewhere if you're building more than 10,000 devices, it's better to design the whole PCB board on your own. Before that volume, using SOM modules for time to market could be more reasonable.

10.000 probably isn't even enough to get Broadcom to reply to your emails. Good luck getting your hands on the required documentation, let alone the actual chips!

true,never liked Broadcom myself,wish RPi picked some different cpu from companies that are more open source friendly.

I wonder how that compares to Expressif.

> if you ever want to convert your project to something commercial, I would still consider raspberry pi and beaglebone

Last time I checked, Broadcom forced you to integrate their compute modules into your product because there was no way they would sell their CPUs alone, no matter how many of them one would be willing to buy. That is not normal in the industrial world. As an example, the Allwinner H3 used in a lot of boards is $5 each for 1000+ pieces at Alibaba, or $10 at Olimex in the EU in single quantity. It's also well documented. https://linux-sunxi.org/H3

Things may be different with the RP2040, which is a very interesting part, but that chip has nothing in common, except the name, with the ones running the bigger Linux capable Raspberries.

I will just use SOM modules from RPi for products, carrier board is relatively easy to design

Also, depending on your designs, certifications may already be taken care of for WiFi, BT, etc by integrating it on the module.

It depends on your definition of "normal". A lot of high-end chips are completely unavailable on the open market, with manufacturers often not even willing to publish a product brief - let alone a datasheet. Try finding a Displayport MST hub chip, for example!

Things are indeed very different for the RP2040. They are widely available in both small and large quantities, and have excellent documentation publicly available. Alas, they are not SoCs!

> I wish there are some i.MX SBC

You can buy a Toradex, Variscite or PHYTEC module and pop a binary distro like Debian in there very easily.

Disclosure: I work for one of the companies above.

I wish those SOM vendors can produce smaller and cheaper carrier boards with their popular SOM installed, basically becomes a SBC with SOM, so I can start with them before buying more SOMs down the road.

RPi did the right way in my opinion: its (cheap) SBC format gains attention widely, then it started to sell its own SOM in large volumes.

We (as an industry) do produce some smaller SoMs. Long are gone the days of gigantic EVKs with a thousand interfaces, but it's costly compared to RPi, because of scale and all the certifications we make our hardware go through.

>if you ever want to convert your project to something commercial, I would still consider raspberry pi and beaglebone instead based on software maturity and community support and their ecosystem at large.

Seconding this for the Beaglebone Black (including the Industrial variant). FreeBSD support and onboard Ethernet set it apart from some alternatives.

There are quite a few manufacturers who offer NXP ARM SoC based modules. Variscite, Compulab, and SolidRun just to name a few.

I love the PoE support! I wish more SBCs and even nuc/nuc-clones would start adding support! It’s nice being able to consolidate power supplies/deploying to places where only ethernet is present (which anyone can deploy legally unlike AC wires)

although not ideal, external gigabit POE splitters are ~10 euros

This is super cool! It has a little bit of everything I'd want in a small project board - PoE, mini PCIe, RPi case compatibility, lots of RAM.

OpenBSD has some support for the StarFive chip, so perhaps this device could run OpenBSD in the future:

https://www.openbsd.org/riscv64.html

Quite excited by this whole line up, the Pioneer ( https://milkv.io/pioneer ) looks interesting too.

I really hope they can pull this all off. I've ordered a couple of the MlikV-Duos should arrive in the next week or so, let's see how things go!

Thickest credit card I've ever seen!

Yes, I am quite disappointed because I thought from the headline that it would actually fit in my wallet.

It's not available to purchase. I have yet to see affordable and consistant RISCV hardware availability just breadcrumbs leading to preorders or coming soon or something that costs 500$

has video, usb & ethernet. missing price & benchmarks, though

Isn't it JH7110 like VisionFive2?

That board shipped in February. There's plenty about it.

I have one. On release a few benchmarks were made, but be careful that driver improvements and newer GCC versions (it shipped with a Debian built with a really old GCC) have improved performance dramatically since then.

Firefox and Chrome have also gained JS JIT, which makes web browsing fast.

Apparently not recently discussed here:

https://news.ycombinator.com/item?id=36377439

Different board, same company

This MILK-V reposts are getting terious. Three new RISC-V boards, competing with forms of mATX (Pioneer), Pi Zero (Duo), and Pi (Mars). Pioneer[0][1][2][5], Duo [2][3][7][8], Mars [4][5][6] (and now this)

Thanks for the links!

I wonder what graphics chip this is using?

Looks to be Imagination BXE-4-32 GPU, courtesy of https://www.cnx-software.com/2022/08/29/starfive-jh7110-risc... .

Overkill for my keyboard controller, but finally I get 40 GPIOs with native RV64.

You'd get better latency out of an ESP32-S2 or even a CH569 MCU.

But here, I get RV64. Want to write the firmware "once" in 64bits, not 32bits.

Is this available in India? I'd buy but won't risk the customs dance.

What happens with customs if you buy something like this?

45% tax usually. sometimes it gets lost in the customs office or they refuse entry to the product.

The cores still lack bitmanip/clz/ctz/clmul. :(

AIUI they got Zba and Zbb.

I expect next batch of cores to be full RVA22+V.

Yup, and in boards at this price point and performance level (quad 1.5 GHz) or better in probably 2026.

JH7110 has Zba, Zbb. So not clmul, but yes clz, popcount, etc.

How does this thing stack up against the Pine64's Ox64?

The linked system uses the same SoC as the Pine64 STAR64, so it will be a lot faster than a Pine64 Ox64, the Milk-V Duo is similar to the Ox64.

Is it available? No.

Coming soon...

All SBCs are useless to me...

How am I supposed to encode vp8 in real time with them?

Not every machine is suited to every usecase. It might not be useful to you for the one specific use you've picked, but it's still useful to a lot of people.

All desktop computers are useless to me...

How am I supposed to fit one in my pocket?

Build a kubernetes cluster out of them and deploy pods which would encode one frame at a time. Then you just need to map-reduce. Easy!

Reply on news.ycombinator.com