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.
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.
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 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!)
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.
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?
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).
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.
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.
> 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.
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 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
>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.
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!
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.
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.
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)
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$
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.
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)
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.
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/