RISC-V is getting more and more popular, but if you want to run Linux on actual hardware it’s currently fairly expensive since you either need to rely on HiFive Unleashed SBC ($999), or expensive FPGAs.
Another solution is running Linux RISC-V via QEMU emulator, and I showed how to do this using BBL (Berkeley Boot Loader), Linux 4.14, and busybear rootfs. If you check the comments section of that earlier post you could also try out Fedora RISC-V images in QEMU.
Bootlin has now published a presentation showing how to run embedded Linux on RISC-V in QEMU with many of the same components as in the previous instructions, but with a more up-to-date Linux kernel (5.4), and using Buildroot to build everything from scratch including the toolchain, BBL, the Linux kernel, and a Busybox based root file system.
They explain each step in detail in the 45-page presentation to allow you to customize your final firmware to your requirements for example for choosing between glibc, uClibc or musl C libraries. They also link to some video playing the command to run for example to configure buildroot as shown below.
It’s always good to get started with QEMU to make yourself familiar with some of the potential pitfalls before low-cost hardware to play with RISC-V Linux come to market. You may not have to wait too long however, as based on a comment, some Kendryte K210 based boards such as
Longgan Nano ($5) or Maixduino ($24 kit with camera and display), may get a uClinux port soon enough. uClinux is a version a Linux that works on hardware without MMU (memory management unit), and it can be a bit more complicated to debug notably due to kernel panics caused by stack overflows.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
If they want the architecture to succeed, they’d better partner up with some company to get sensible affordable hardware into the hands of people. $1000 for a board is a joke, and no thanks, not bending over backwards with QEMU just to learn your arch, if you don’t care about users to try meeting them even halfway, then users will not care about you and will just stay with ARM and ARM64 instead, which are here right now, cheap and work.
This is such a weird position to take. Intel and AMD sell individual Core i9 and ThreadRipper consumer chips for well over $1000 just for the CPU chip and enthusiasts love them. Those aren’t even computers until you add a lot more stuff to them. Perhaps, also, you are not familiar with dev boards from other companies, such as ARM? Their A53 and A72 Juno dev board is $10,000. https://www.digikey.com/product-detail/en/arm/V2M-JUNO-0317D/V2M-JUNO-0317D-ND/7400345 These boards are what processor IP companies such as SiFive and ARM provide to chip and product manufacturers to prototype their things to go into cars or TVs or mobile… Read more »
$1000 is nothing for a company that’s really interested in using RISC-V in a product. Hell if you want to try out some little Analog Devices thing the evaluation board for an 8 or 16 pin chip can be hundreds of dollars.
SBCs and other maker grade stuff like Arduino hasn’t really done much for semiconductor vendors aside from some cheap PR. In the future when people that grew up on the maker stuff are running the industry maybe it’ll be different but right now its a drop in the ocean.
Longan Nano is NOT based on Kendryte K210 and there is no chance to run any kind of Linux on it.
Running even a smallest Linux on K210 makes no sense as it simply was not designed for that purpose.
Linux 5.4 got M-mode support for RISC-V (that’s for non-MMU processors)
Uhh .. that’s not what that page says. It says an interrupt controller had support added “in preparation for” M-mode Linux. That doesn’t mean M-mode Linux is done.
Also, the 32 KB of RAM in the Longan Nano won’t be enough to run M-mode Linux, and the 8 MB in the Kendryte K210 is likely to be insufficient or extremely marginal too.
Does anybody know if there is a docker image with in it a running QEMU-RISC-V environment. That would be easier, IMHO
I worked on it for OpenWRT port, but the RISC-V port is still not released.
But none of the examples works for me.