HiFive Unmatched – A RISC-V Linux development platform | Hacker News Reader

HiFive Unmatched – A RISC-V Linux development platform

sifive.com

107 pointsvelmu115 comments

It's also a nice Haiku platform - https://discuss.haiku-os.org/t/my-progress-on-real-risc-v-ha...

However, the "HiFive Unmatched HW Reference Manual" mentioned on the SiFive web page (https://www.sifive.com/boards/hifive-unmatched) is still not available, so bare-metal programming (or porting other operating systems) requires lots of Linux code reading.

I have two (https://rwmj.wordpress.com/2021/05/27/hifive-unmatched/) so I guess ask me anything ...

Will RISCV have the same mess that ARM ecosystem has of not standardising or having a single BIOS or similar system... such that you have to compile a custom image for every board?

One thing PC has going for it, is that you can install one Linux distro into any PC board. This is not the same for ARM boards.

Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot).

The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv/riscv-platform-specs https://github.com/riscv-non-isa/riscv-sbi-doc)

I'm sure this mess could be avoided if instead of a doc only there would have a test suit exercising the implementation. This should be true for many foundations and their specs.

PC BIOS and UEFI are a mess as well. They are proprietary blobs guarded by Intel and alike. At least ARM had most bootloading open with uBoot, for example. Also PC firmware code on modern platforms is often bigger than Linux kernel. Hardly a good example. I sincerely hope RISC-V will avoid relying on UEFI and opt out for something more sensible.

Not really. Arm boards only work with uBoot because of a vast behind-the-scenes effort to integrate all the crappy forks and out of tree kernel drivers into Linux distros.

GPU resizable bar requires UEFI.

It has no hard requirement to be on UEFI rather it isn't compatible with legacy BIOS.

"Hard requirement" is a vague. At this moment in time no commercially available non-UEFI hardware exists to run GPUs supporting resizable bar.

There are solid open implementations of UEFI, one has actually been ported to the Pis and can boot Windows and Linux and so on.

Many PC UEFI builds from mega manufacturers are heavily customized, but a lot of them are also just based on TianoCore, including the modern RPi UEFI firmware builds. Nothing very strange about it. More specifically, the distinguishing thing here for RISC-V is the standardization of SBI, which will be a requirement for either UEFI or U-Boot to target it. U-Boot works on the million ARM devices it does today thanks to absurd effort from many people, not because ARM made it especially easy; with SBI in theory that can be made easier.

Aside from that people can argue whether UEFI is bloated and how their favorite is the perfect alternative, but as a user who would want to boot a RISC-V based desktop platform (and someone who has supported RISC-V, implemented their own designs, etc) I don't care and it doesn't matter; it actually does the job, and is a known quantity to aim for i.e. familiar and at least nominally understood by developers, users, and manufacturers. And I say that as someone who actually likes U-Boot and has patched it on a few occasions myself for my own targets.

> I don't care and it doesn't matter

you can not care, but it does matter

The complete lack of standardization of which ISA "extensions" each chip has means you will want a build targeting the chip you have, anyway.

This isn't true. The required extensions are specified in the Unix platform spec, and any additional extensions are detected and used at runtime (exactly how things work on x86 in fact).

There are Profiles specs and Platforms specs, that will be regularly updated. This means software has a fixed target on which it can depend.

Unpopular opinion: it will be much worse.

RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips used own solutions in some areas as a standard way of doing things was yet not available (e.g. memory protection).

So we have a hardware landscape with extreme fragmentation. If people cannot agree on the hardware, I have hard time seeing them agreeing on the firmware.

I don't think that's an unpopular opinion. It's more of an unfortunate truth.

I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :)

The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization."

Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box.

What specifically would be the comparable trigger for ARM or RISC-V?

You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs.

I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.

RISCV could end up being even worse if we ended up with a high performance fork of RV64

Why would that be worse?

All the issues ARM has but now with added ISA differences which may or may not be actually compliant with any standard let alone the one on the RISC-V website.

I don't believe the ISA dictates the implementation, so theoretically someone could implement the D extension to get 64-bit precision floating point in a more performant way than other implementations. If someone altered the ISA in order to get performance, I don't think you could accurately call it RISC-V anymore.

Sometimes ISAs restrict possible implementations so you can't implement faster designs.

There’s some plan for a common bootstrap and firmware interface. Personally though I think they should standardize on IEEE 1275 Open Firmware. It’s a standard, there are multiple good open source implementations with reasonable licenses, it’s lightweight, and it’s extremely flexible. Who needs the complexity of UEFI?

cryptsetup benchmark output :)

The output was quite large so I linked it here: https://gist.github.com/rwmjones/29b63bf20b10371ca9f1a56dac2...

The numbers are of course terrible because these chips don't perform very well and I guess also no one has tried to optimize this benchmark for RV.

Any sense how fast this chip is when running software optimized for it?

These are not fast at all, but it certainly helps to have an NVMe drive and 16G of RAM (a huge improvement over the older HiFive Unleashed boards). They're fine for packaging and general development work. I don't think we'll see software optimized for RISC-V until more extensions become available in hardware, especially the vector extension.

Indeed those are very low. However it might be related to lack of hardware acceleration extensions for encryption. I was hoping this machine had those.

Thank you.

RISC-V crypto extensions have just been opened up for public review: https://riscv.org/blog/2021/09/risc-v-cryptography-extension...

Yeah I was sort of expecting to have accelerated crypto, given the EAR export declaratioj I had to sign in order.l to buy this. If the CPU doesn't have any crypto implemented, what does? Some signature checking in the firmware?

The export agreement was a bit weird. No one will be using these to simulate their nuclear bombs on. As far as I'm aware there's no crypto hardware anywhere on them (no TPM etc.)

I've been thinking about getting one, but ultimately decided the price was not worth it, considering I'd probably hit a brick wall when trying to bring it up.

What convinced you to get not one but two of them? What do you run on it, was it hard to bring up the system?

hat convinced you to buy not one

I work some of the time on RISC-V and the hardware was paid for.

Does it have proprietary firmware?

The boot sequence is described in section 2.2 of this document: https://starfivetech.com/uploads/hifive-unmatched-sw-referen... And some more detail here: https://u-boot.readthedocs.io/en/stable/board/sifive/unleash...

The flow is something like: ZSPL -> uBoot SPL -> OpenSBI -> uBoot -> kernel

Everything is open source except (maybe?) ZSPL which I think is stored in ROM and just loads the SPL off the MMC card.

Thanks -- good to know. I think I'd seen that on the boot process but didn't know about what's involved.

OT, but I just wanted to say that your RedHat interview was interesting:

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

At £500+ it's not a realistic prospect I'm afraid. Maybe if there more affordable ones that becomes available then I definitely would want to take a look in-depth.

AFAIK, SiFives business is about selling their RISC-V cores and ASIC consulting services. RISC-V is still kind of new as far as hard silicon Linux-capable cores go. My understanding is that this thing is meant to serve as a dev kit for their U74 core and U740 SoC platform, provide hardware for interested-enough Linux kernel devs and distro maintainers, and serve as a real, up-for-sale RISC-V board with a real SoC, 'all the fixins', and no FPGA. That's to say it's not a board for people who'd otherwise buy a RasPI or slightly more expensive SBC -- It's closer to a proof of concept.

We’ve been through this here on HN. The board is designed around a chip that really wants to be a router. This is a bit expensive for a desktop workstation and will cater to people really determined to make this the year of the RISC-V desktop rather than the average developer, such as myself, who, while considering x86s disgusting, still buys them because they are cost-effective.

Why do you feel this is optimized as a router, are you mixing it up with the SolidRun HoneyComb ARM system ?

Oops... I think I did. Sorry.

Why is X86 disgusting?

Ugly ugly ugly ISA. We throw away a little bit of performance and a lot of power because of how weird and old it is.

It's a matter of taste, but x86 has a lot of historical cruft because it's been around long enough to see 16-bit, 32-bit, and 64-bit industry transitions. Off the top of my head, x86 memory segmentation and fragmentation between BIOS vs. UEFI and ACPI vs. the absence of device trees (AFAIK).

But it is kinda cool to run software that originally was built for the 8088 on an AMD Threadripper. But yes, I do agree the x86 architecture is fast losing its lustre.

Check out the Nezha D1 RISC-V SBC:

https://hackerboards.com/boards/nezha/

Not sure how easy they are to get ... but $99 is a great price.

One seller on AliExpress: https://www.aliexpress.com/wholesale?SearchText=sipeed+nezha

These are very slow with limited RAM. It's possible to run Linux but it won't be much fun.

Is 1GiB considered 'little RAM' these days for an embedded board?

Perhaps not for embedded, but it's being compared to a development board with 16 GB.

I actually thought the board above had only 512 MB, hence my comment, but even 1 GB is quite limiting. The HiFive Unleashed (previous SiFive board) has 8 GB and that is quite tight for some of the larger builds we do, or for doing parallel builds.

The bigger problem with the board above is the single core.

Why not cross-compile?

Distributions tend not to like cross-compiling, because it's not as flexible (how do you run test-programs?) and sometimes has bugs you don't have when native compiling.

I have an ARM board with 4 A53 cores with just 1GB of RAM. Despite these limitations I can successfully cross compile from my host. So yes, under circumstances memory might not be such a big issue.

That doesn't seem like an unreasonable price to me. Do you know of a cheaper alternative with the same performance?

Are there any good <$100 RISC-V dev boards out?

Good & $100, no. The volumes being produced make that impossible right now. But there are cheaper boards around. A summary can be found in the RISC-V Foundation board giveaway (https://www.cnx-software.com/2021/05/03/the-risc-v-foundatio...), but there exist more than that. Unfortunately the one we were hoping would come out about now - the BeagleV - just got cancelled.

It would be really cool if the Raspberry Pi Foundation could jump in.

What could they do though? Raspberry Pi only exists because there are hundreds of millions of Arm CPUs being built for phones and tablets, and a tiny fraction of these end up in SBCs. The sheer volume means each chip can be had for a few dollars. There is no such ecosystem for RISC-V yet. The largest known order was AllWinner/T-Head (reportedly 5 million through TSMC).

Build hundreds of millions of of RISC-V boards?

Hundreds of millions? 180 billion.

Ah damn. Would you say synthesising a RISC-V CPU on a FPGA dev board would qualify as an alternative?

FPGA dev boards aren't that cheap, particularly one that can synthesize a 64 bit multi-core RISC-V CPU (in fact, there is one that can do it and it costs nearly $3000). The other problem with synthesized CPUs is that the clock speeds are very slow, unless you pay a great deal of money for the FPGA.

They're a lot of fun though - I have PicoRV32 in a very low end Lattice FPGA which cost, like $30 I think? It can only run single C programs, not even an embedded kernel, but I love playing around with it.

Get a large fabric Xilinx FPGA from ebay, reball it and make a simple PCB with Altium auto routing with JTAG, SPI flash, some memory. And find a license for Vivado.

You may not need a new PCB, there are systems with a big FPGA [1] that could make a good host for a RISC-V design.

[1] https://news.ycombinator.com/item?id=21303446

That’s a Spartan 6 but you really want the larger fabric parts. If you go to Digikey they will quote starting at 20k, but on ebay a few hundred will do assuming you have a Vivado license capable of building a bitstream. It is possible to commandeer a board as in that post but often not worth the time vs just making your own. Rarely prototypes with only the power distribution and JTAG appear. Those are a bit easier. Like this https://www.ebay.com/itm/114784061306?hash=item1ab9a9c77a:g:...

That board looks like it might have been a prototype of a Fusion-io card. Compare:

https://commons.wikimedia.org/wiki/File:SanDisk_Fusion_ioMem...

It's basically useless for SoC development, though, as there's no memory on board, no I/Os other than PCIe, and no practical way to add any.

The GPIO is broken out all over the PCB for the NAND. It doesn’t get easier than that

[Edit: Crowd Supply,$25... Oops!] Pine64 has very nice $4 boards, equivalent to typical ESP microcontrollers. While not up to Linux, they are wholly adequate for several totally usable embedded RTOSes.

There are actual RISC-V-based ESPs for the typical price of $3-4.

https://www.espressif.com/en/products/socs/esp32-c3

It has been my impression that ESP SOCs are really just hard-configured FPGAs. Is this correct? (There doesn't seem to be anything wrong with that, except for possible clocking / reduced power state oddities as reported in the older ESP products. I would love to learn more details about that!)

No, I specifically meant development boards, not chips. They are not much more than a chip, though (a simple antenna, 32-48 pins, a crystal oscillator, a couple of LEDs, and a couple of buttons).

https://www.aliexpress.com/item/1005002783695684.html

I misremembered both supplier AND price! It was Pine64, and only US$4.

https://pine64.com/product/pinecone-bl602-evaluation-board/

The Ali Express boards look equally intriguing. And the price is right!

I'd go with the Pine64 board. I ordered some of these BL602 boards from aliexpress (not the ones above) a few months back and the documentation is abysmal and they seem to require a windows application to program them.

From looking around the 'net I _believe_ these will work through ESP-IDF, same as the old Xtensa-based ones. Basically just `idf.py flash` the project, and it should work. Mine are still on the way, I'm eager to try.

They're standard cell logic designs (so ASICs, but what you get from letting the tooling just create a chip from the HDL more or less) that haven't had a lot of work put into power management compared to similar chips like nrf5x. They're not hard configured FPGAs. Which makes sense, as their original target was as a SDIO WIFI chip for a much larger, power hungry system, not a standalone device.

For a limited-run dev board with the CPU, board, and that much RAM I'd say it's priced fairly appropriately.

Why not solder the SSDs and a GPU while at it?

So does it already have Swift support by now?

I know almost nothing about Swift except that it's some Apple-sponsored programming language, so I guess their main development thrust would be Arm. However as its implemented using LLVM, and LLVM has supported RISC-V for a very long time (at least since 2015/2016), there is hope that a volunteer port would not be too complicated.

You missed the joke.

https://www.sifive.com/blog/with-sifive-we-can-change-the-wo...

Given,

https://www.tensorflow.org/swift/guide/overview

This seems to be calling attention to Chris Lattner, creator of Swift, abandoning Apple for Google, and then abandoning Google for SiFive.

Swift might survive at Apple, but by the link appears already dead at Google.

Indeed, a project started at Google due to his arrival there, hence the jab at Swift being available in RISC-V due to the new position.

He went to Tesla first, by the way.

Guessing Swift didn't stick at Tesla either.

BTW, last I heard, Dave Abrahams, leader of the Swift std lib project had moved on to Google.

He is at Adobe now.

what GPUs are compatible with this?

My question is how would one determine which GPUs are compatible with this?

I guess any GPU that works on x8 PCIe gen 3 and can power itself from that or supply its own external power? (Datasheet says the fully loaded board is 150W btw.) You'd probably have to limit yourself to whatever has open source drivers for Linux.

I am running RX 570 with PCIe + 6-pin connector for the power. These works out-of-the-box due to open source drivers. Older Nvidia cards work too, but you would need to go with older cards as you need Nouveau driver. I believe someone recently used AMD RX 6700XT, which is a bit insane.

The bottleneck here is SoC, not the GPU. With HW decoding on the GPU I can play 4K 60fps trailers on Unmatched just fine.

AMD Radeon GPUs are known to work, provided you get one which has good Linux support. They need to have all open source bits because of course you cannot run x86 blobs on RISC-V, so for example Nvidia with the normal drivers would be impossible.

The getting started guide has a few specific model suggestions: https://starfivetech.com/uploads/hifive-unmatched-getting-st...

I have the Hifive Unmatched board with an AMD GPU and anything graphics related is extremely slow, to the point that launching and using a browser is unusably slow (I mostly use it via SSH). Might be related to the low amount of PCIe bandwidth available (AFAICT everything PCIe so both graphics and NVMe share a single x8 PCIe bus). Also there is a recent patch for the kernel that removes some unaligned memory accesses in copy_to/from_user which should speed things up, but I haven't tried the new kernel yet [1]

Nevertheless it is a useful board for testing software on RISC-V, e.g. I mostly use it to test the OCaml compiler and related programs on it.

[1] https://lore.kernel.org/lkml/mhng-423e8bdb-977e-4b99-a1bb-b8...

Nah, there is NO way PCIe bandwidth is to blame. x8 is a lot! My MACCHIATObin runs an RX 480 over gen2 x4 — with a 4K display Firefox WebRender is totally usable (actually the browser is CPU bound, just scrolling is 60fps consistently), SuperTuxKart gets into the 90fps range.

I find my enthusiasm for RISC-V materially reduced by its appalling lack of a base POPCOUNT instruction. Its lack makes my favorite optimizations annoyingly pessimal.

I understand that, someday, higher-end realizations will begin to ship with various "B" subsets implemented, but "portable" builds will tend to avoid relying on those for an appallingly long time after. (E.g. MSVC and Gcc still do not generate POPCNT instructions, on amd64, unless you specifically identify a post-2004 target.)

I will nonetheless be excited to learn of the first chip that does ship with the full raft of B instructions.

https://github.com/riscv/riscv-bitmanip/blob/main/bitmanip/_...

I cannot tell what this means.

It's a link to the proposal for popcount in the bitmanip extension.

I get that. But I said myself that the (optional!) B extension defines a popcount instruction. Does the linked page indicate anything further? Does it say RV64 chips are in fact required to implement the instruction? Or, what do the checkmarks indicate?

FWIW, RISC-V does have a invalid instruction trap mechanism that can be used to provide a software implementation of missing instructions. So at least if the platform provides a software implementation of the B instructions, user code can still use them (much more slowly, of course).

Emulated B extension instructions would be no better than a cruel joke: "Ha, you thought you were optimizing? Here, see how you like extra-super-slow, instead!"

Zba, Zbb, Zbc, Zbs (BitManip) have been approved by "Architecture Review" thus I assume they close to being ratified. Probably one of the first new extensions to be available for RISC-V.

Because it's not ratified the BitManip extensions are not listed in any RISC-V Profiles as supported (or required). Platforms specification is also not requiring it.

Note that the next Profiles will be for 2022, thus any extension ratified before that most likely will appear in a new profile (i.e. as supported, non-conflicting extension) in some set.

OK, so does the "RV64" checkmark on the page mean anything at all?

RV64 on that page refers to the fact the instruction can be implemented (as part of the B extension) on 64 bit RISC-V. RISC-V itself has a well-defined system of base ISA + extensions as explained in section 1.3 of the user specification, available from here: https://riscv.org/technical/specifications/

The B-extension, which likely all desktop class CPUs will have (and probably others too?) has most of the bit manipulation instructions.

There is also a vector extension, crypto extension and even a 128-bit computer (Q-extension)!

The bit manipulation extension was released as a draft for a public review.

See the thread here: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/YiK...

So, still just a draft. Public comment period ended before August... What is next? Is there any target release date?

I'm disappointed that zip and unzip are only available on RV32. It's great to be able to create Z-order indexes with a single instruction. I was surprised they had these and then disappointed they're on on RV32.

What does "only available on RV32" mean? Not proposed for smaller configurations?

IMO RISC-V is rather targeting ARM's niche than that of Intel/AMD, so custom builds will be a more common scenario than distributing binaries.

6.7 billion chips/quarter is "niche"?

niche the noun, not the adjective.

Could you give an example of how you'd use POPCOUNT in an optimization?

See puzzlegen.cc in https://github.com/ncm/nytm-spelling-bee/

Order of magnitude improvement.

BTW, the key line is #45, or line #42 in the Rust version.

Reply on news.ycombinator.com