Just saw this SiFive board HiFive is retailing for $679, can you please comment if this is any good for toying around ? Specs look more than decent - almost desktop class computing.

https://www.crowdsupply.com/sifive/hifive-unmatched

I have a couple on order, and I've talked to one of the developers. It looks nice - PCIe, NVRAM SSDs, mini ITX format, 16GB RAM, more cores, etc - but not in the same price point or market segment as an SBC. We will likely buy a pile of them to do Fedora builds.

> We will likely buy a pile of them to do Fedora builds.

Do you expect a lot of things to break on RISCV?

Fedora have been shipping on RISC-V for about three years already. Last I saw, around 95% of packages work. The main exceptions have been thing that need some JIT that hasn't been ported yet -- gcc and llvm have been working for years.

https://fedoraproject.org/wiki/Architectures/RISC-V

Same for Debian, where the percentage of packages that build on RISC-V is second only to ppc64 out of the "minor" ISAs. https://buildd.debian.org/stats/graph-ports-week.png

Why would you want use these as build machines? It seems more efficient to just cross-compile on your fastest build machines. You get much faster CI feedback that way. Obviously you want to validate RISC-V code on native devices but using them as builders seems wasteful.

I'm genuinely curious why that's desirable. Maybe I just misunderstand your comment and you want the RISC-V boards for validation i.e. make sure you can self-host the distro even if in general releases are cross-compiled on your (I assume AMD64) build fleet.

I'm sure the Fedora builds aren't designed for cross compilation (which is far from trivial for most packages not designed for it). Also, man-power is the most precious resource so it would be a waste to spend time trying to cross-compile what could be built natively.

As long as you've got the target toolchain on the host, the code has no idea it's being cross compiled. If you've got the tooling set up it's a lot of setting of envars. It's not trivial but it's also not super difficult. A compiler running native on an architecture doesn't produce any different output than the same compiler doing a cross compilation.

Even if you wanted to run a native RISC-V build process, running it in QEMU on a much more powerful AMD64 system will get you the same results in a fraction of the time. This gets much faster feedback in the CI system.

The older HiFive Unleashed (1.5 GHz single-issue) builds things considerably faster on a per-core basis than qemu-system on current amd64 (or at least did in the Skylake generation). The dual-issue cores in the HiFive Unmatched should be around 50% faster.

amd64 machines do have the advantage that you can get them with 32 or 64 cores and hundreds of GB of RAM -- at a price, especially in power consumption.

The three year old HiFive Unleashed uses around 5W to 6W at the wall when building flat out, considerably less than the maybe 25W a quad core i7 or Ryzen will use, with lower performance running qemu-system.

The new HiFive Unmatched probably has the same or lower power consumption, at 50% higher performance.

Running qemu on a Pi 4 would use about the same power as the RISC-V chip but be waaaaaaay slower.

That's running qemu which is unnecessary for cross compiling. I'm not seeing any advantage to building on native silicon rather than cross compiling on existing machines AMD64 machines. Even with the power usage of the AMD64 chips being higher, the faster compilation speed will likely net less overall energy used for the builds.

I fully understand wanting native silicon to do development on and to work on some architecture specific branch. It's easy to just recompile your working copy locally. The original poster was talking about "build machines". I'm not seeing the utility as "build machines", especially if they have far less power than AMD64 machines.

There are many packages that compile some kind of tools and then run them to produce other things necessary for the build, possibly several layers deep.

In theory you can set up the build system to correctly know which things should be compiled native and which should be cross-compiled. Sometimes you even need native and cross-compiled versions of the same thing.

In practice, this is a capability that few people use and even if everything is set up correctly at some point most people contributing patches do not think about or test maintaining the ability to cross compile and it gets broken.

When you're building hundreds or thousands of packages for a distro such as Debian or Fedora this is a huge problem.

Building natively in a full system emulator or on real hardware is the only way, in practice.

Only for very simple systems. Many are complicated which produce artifacts that are executed to produce other artifacts (which are also compiled). As arbitrary binaries are executed during the build, and the correctness may depend on native execution, this is far from as trivial as you might think. Have you ever compiled Emacs (at least in its 18 version)?

Building under QEMU is obvious, however the native hardware is actually faster.

A Docker image with cross-compilation toolchain?

Other commenters have pointed out how tricky cross compiling can be. Debian has been making a lot of progress here, most thanks to Helmut Grohne it seems. http://crossqa.debian.net/ https://wiki.debian.org/DebianBootstrap (slightly out of date, but still useful)

Looks like you can get it from Mouser for $665 as well:

https://www.mouser.com/ProductDetail/SiFive/HF105-000?qs=zW3...

Found that link from this SiFive page:

https://www.sifive.com/boards/hifive-unmatched

This looks great, thanks!