The other day we wrote about Getting Started with Embedded Linux on RISC-V in QEMU emulator and noted that Linux capable RISC-V hardware is currently fairly expensive.
We also mentioned there was work on porting uCLinux to Kendryte K210 RISC-V processor on boards such as Sipeed Maix board. The processor only comes with 8MB RAM, and does not feature an MMU (Memory Management Unit) so what you’d be able to do on the board would be limited, and for instance, a desktop environment is clearly impossible on the platform.
NOMMU support also requires some extra work, and in Linux 5.4 we saw only of the changes was “SiFive PLIC IRQ chip modifications, in preparation for M-mode Linux”.
The slide above is extracted from the “RISC-V NOMMU and M-Mode Linux” presentation by Damien Le Moal, Western Digital at the Linux Plumbers Conference 2019 last September. It explains M-mode support is better suited for NOMMU mode since more direct access to the hardware is possible, while S-mode is synonym with “have MMU”. The work on M-Mode also reduces RISC-V SBI (Supervisor Binary Interface) overhead and will benefit regular S-mode.
If we scroll to the end of the presentation we can also see a boot log showing Linux 5.1 booting to a minimal root file system with Busybox on Kendryte K210 powered Sipeed MAIX Go board with 6+2 MB RAM that sells for a little over $40 as part of a kit with camera and display.
The board will eventually be supported un mainline Linux too, as Linux 5.5 will add support for RISC-V NOMMU:
below is a series to support nommu mode on RISC-V. For now this series just works under qemu with the qemu-virt platform, but Damien has also been able to get kernel based on this tree with additional driver hacks to work on the Kendryte KD210, but that will take a while to cleanup and upstream.
A git tree is available here:
git://git.infradead.org/users/hch/riscv.git riscv-nommu.5
There are two new configuration options to enable support for RISC-V NOMMU: CONFIG_RISCV_M_MODE to switch between M-mode and S-mode, and CONFIG_RISCV_SBI to completely disable/enable SBI.
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.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
While this is cool and all mmu-less linux is horrible. IMHO getting a strong NuttX port would be much more useful. It looks like linux (from the user and from the driver model etc) but it has less of the problems with requiring tools that no one has touched in decades that barely work.
You might want to take a look at emcraft who do a uLinux based system on a variety of ARM Cortx devices. I’ve only run the STM32F4 version but that worked surprisingly well.
I used to have it running on a 68K based machine. It’s just too rough around the edges to bother with. If you want what Linux offers (a TCP/IP stack that isn’t a hack of lwip etc) you also probably want memory protection.
Actually it’s K210 instead of KD210, and the KD233 is the name of the official evaluation board.
Back in the LinuxAP days, we were running a 2.4 with iptables on 4MB RAM. I looked when this board was announced if it would have been possible to boot a linux on RISCV. I think I will pass and wait for the first cheap RISCV board to come, hopefully one day. I was expecting Western Digital to come out with Linux based RISCV chips, maybe some other chinese company will do it first.
Well, I’ve deployed “Internet gateways” in 1996/1997 made of recycled PCs equipped with 1.6 MB of RAM (640kB base + 1024 extension), with the rootfs on a floppy. It was kernel 1.2 with ipfwadm + pppd and dialup scripts to automatically set the link up on traffic, and worked great 😉
I used Coyote Linux back in the days, recycled 486 with ISA network cards. That was a revolution for people who wanted to share their internet connections https://en.wikipedia.org/wiki/Coyote_Linux
I ran zipslack with linux 1.0.6 + XFree86 X11R6 on a 386 with 4MB of RAM in 1994, with a 40MB MFM HDD that wasn’t a whole lot faster than a floppy, lol. It wasn’t pretty, but I got OLWM + Spider running decently, and I even got GEOS running in V86 mode on top of it, with the video BIOS initialized from the DOS emulation… that was tricky because I had a soundblaster but if it initialized it, it would overwrite kernel memory, so I had to prevent it setting up anything other than the yamaha synth chip, by lying about the interrupt for the DSP.
Why is this relevant? Well sure, the 386 had an MMU, but it was practically irrelevant because it was child’s play back then to escape protected mode, so the MMU didn’t provide any practical benefit other than ensuring that null pointer dereferences caused a segfault… which theoretically prevented OS crashes. But Win 3.1 was orders of magnitude more stable… why? Because MS chose not to protect the zero page, to avoid segfaults! Oi! So avoiding use of the MMU was a bonus in those Wild West days of protected mode, lol.
Too expensive same thing that killed RISC 1, 2, 3 and 4
for some reason i thought this already ran linux
Probably because the binaries were compiled with GCC… but GCC is used for a lot more than Linux kernel ABI binaries. There’s FreeRTOS and a couple other ultra-light kernels available. https://github.com/kendryte/kendryte-freertos-sdk
I’d love to see a NOMMU port of OpenWRT to K210 + ESP32 wifi module…
I looked at uClinux and uCdist in the past to port those to OpenWRT, but most of the packages would not compile at all: http://isl3893.wikidot.com/openwrt ISL3893 was uClinux based, in the era of pre-wrt54g.