How to Build & Run Linux on Kendryte K210 RISC-V NOMMU Processor

A few months ago, we wrote that Western Digital was working on Linux & BusyBox RISC-V NOMMU, and managed to boot a minimal Linux OS on Kendryte K210 powered Sipeed Maix Go board.

RISC-V NOMMU support was scheduled for Linux 5.5, and now that the new kernel has been released, Damien Le Moal has pushed the code allowing to build Linux and a busybox based roofs for RISC-V 64-bit NOMMU platforms using buildroot.

I could start the build following the instructions on Github, but it failed as a Linux 5.6 RC1 tarball was missing. But I noticed “Vowstart” picked up on Damien’s work, and wrote detailed instructions. So let’s try the build out using a machine running Ubuntu 18.04.

We’ll have to make sure dependencies are installed first:


Then we can retrieve the source code and do some preparations (e.g. extract Linux 5.6 RC1 tarball):


The next step is to build the toolchain. It will take a long while because there’s a lot of code to build and download from the Internet:


This ended successfully with:


We can now install the RISCV64 toolchain which will use for cross-compilation:


Next up is buildroot build for Kendryte K210 NOMMU processor:


The last step copies the file into $PROJ_ROOT/rootfs_k210 folder.

They also decided to build the Tiny C Compiler in order to be able to build code on the board itself. It’s not really necessary, as on such low-end hardware most people would likely prefer to cross-compile their code instead, but let’s go ahead anyway:


They also made a script to setup and copy k210 rootfs CPIO image into linux-kernel/k210.cpio.

We can now finally build the Linux 5.6-RC1 kernel:


I don’t have a Sipeed MAIX board on hand, so I have not tried that part, but you can flash the resulting image as follows assuming your board is connected over /dev/ttyUSB:


The first two lines are to add the current user to dialout group to get access to /dev/ttyUSB0 without having to be root. The third one installs kflash utility, followed by the command that does dump the image to the internal flash, and the last one is to get terminal access to the board.

That means you can now run Linux on low-cost RISC-V hardware such as the Sipeed MAIX Bit sold for around $14 and up. Note that’s technically uCLinux, you’d have to work with just 8MB RAM and handle stack overflow issues commonly experienced in processors without a memory management unit.

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 PayPal, become a Patron on Patreon, or buy review samples
Subscribe
Notify of
guest
24 Comments
oldest
newest most voted
Willy
Willy
7 months ago

Thanks for the tip, I might try it on my m5stickv device which I still do not use. It will still be useless but it could be fun.

dgp
dgp
7 months ago

I think the fun with nommu usually only lasts from seeing the kernel output scroll up to just after hitting enter at the busybox login prompt. After that it’s a type of cruel torture as it tries to pretend it’s something usable between the shell dying over and over, running out of memory, rebooting etc.

Willy
Willy
7 months ago

Having played with ELKS about 20 years ago just to see a Linux prompt on a tiny x86-based router, I know pretty well what you mean 🙂

DurandA
7 months ago

Are you aware of some legitimate use-cases of Linux on platforms without MMU with such limited memory? This is not trolling, I think this is really cool.

dgp
dgp
7 months ago

>a stable system until we realized >kernel panics were due to stack >overflows I thought the first thing anyone did was double the stack, check if the problem goes away and then forget about it until the stacks are so big the rest of the system no longer works.. You don’t really need an mmu to detect stack overflows though. With the cortex m’s almost useless mpu you can stick a no access region at the end of the stack to catch it or if you’re really in a bind get the stack somewhere where if it overflows it’ll trigger… Read more »

theguyuk
theguyuk
7 months ago

How did people cope in Z80 etc with no mmu, how did the world manage.

David Willmore
David Willmore
7 months ago

They ran toy operating systems on them and had no threat model?

theguyuk
theguyuk
7 months ago

Yeah right, CPM, forth, word proccessing, programing in machine code. Not todays toy programmers having their handheld by mummy .

William Barath
William Barath
6 months ago

The threat models existed. The key differences were 1: the (general) lack of remote access, and 2: shared machines almost always enjoyed some mutual trust between users. These days remote access and mutually-untrusting users are the pervasive expectations. Those operating systems had a broader attack surface once you take away the network. They didn’t have secure boot. They didn’t have a kernel enforcing local privileges. They didn’t have IO ports that were hardened to tampering. They didn’t have full disk encryption, memory encryption, TPMs, or even a concept of a root of trust. They survived without incident only because they… Read more »

dgp
dgp
7 months ago

>how did the world manage.

Memory protection is a lot less of an issue when your “OS” is in ROM, you basically have one “thread” that has less code than what it takes to render a button on a modern UI, your external data sources don’t go much beyond a hardwired keyboard, your concurrency issues are limited not shitting on the main program from interrupts.

theguyuk
theguyuk
7 months ago

Z80 had disk drives, modems, god those modems where slow, below 56kps. Also not forgetting the Apple and Comodore machine.

The IBM PCj was a 8088 business machine.

dgp
dgp
6 months ago

And you don’t remember that shit crashing all the time?

William Barath
William Barath
6 months ago

The Amiga, based on the Motorola 68k series, also had no MMU, and even on the few Amigas that did, they didn’t make use of them. How did we program them? We allocated a little extra stack either side of arrays and strings and filled them with 0’s, then we checked whether those 0’s had been overwritten, then we searched for the responsible code and fixed it. And a lot of the time the system heap manager was corrupt and caused a Guru Meditation, and we’d just reboot and try again. When I got to write in Turbo C++ under… Read more »

zoobab
7 months ago

TCC! Fabrice Bellard made once a demo of a Linux sources being compiled by TCC, and then booted a kernel out of it. Amazing.

William Barath
William Barath
6 months ago

TCC is also blindingly faster than GCC/LLVM/MSVC etc. It’s so fast that you can use it as a scripting engine for reasonably small projects, and that’s part of what makes it a great addon for this uCLinux installation, since all projects built on this tiny system are going to be small by definition, and this is literally orders of magnitude faster than microPython or mJS.

zoobab
7 months ago

Pre-openwrt wifi SOC ISL3893 was without mmu with ucdist, a nigthmare to have software compiling for it…

http://isl3893.wikidot.com/
http://isl3893.sf.net/

dgp
dgp
7 months ago

/me can’t believe there is something worse than old MIPS SoCs with 2.6 kernels

Claudio
Claudio
7 months ago

In the mmu-less era, we built communication gateways with ucLinux on Motorola 68328 (dragonball) processors. Nostalgia…

dgp
dgp
6 months ago

dragonball should still work in mainline if you want to try it.

William Barath
William Barath
6 months ago

@Jean-Luc Aufranc (CNXSoft): Correction – if you want to use the KPU then you only have access to 6MB of RAM, since 2MB is reserved for the KPU. Probably best to configure the kernel not to touch that memory since you’ll corrupt things if the KPU starts up. see section 3.4 of the K210 datasheet here: https://s3.cn-north-1.amazonaws.com.cn/dl.kendryte.com/documents/kendryte_datasheet_20181011163248_en.pdf I got the maix:bit and the maixduino kits with camera and LCD displays. There’s a bug in the camera library but it’s an easy fix, and so far I can’t get the MAIX’s ESP8266 WiSOC talking to the K210. My buddy wants to… Read more »

js0x0
js0x0
6 months ago

Thanks for the guide, the linked instructions had some parts that didn’t work. I pushed it down to my MAIX and… get a kernel panic! [ 0.265071] Freeing unused kernel memory: 1712K [ 0.268862] This architecture does not have kernel memory protection. [ 0.275274] Run /sbin/init as init process [ 0.279469] Run /etc/init as init process [ 0.283457] Run /bin/init as init process ————————[ 0.294233] unexpected interrupt cause 0x8000000000000009 [ 0.294244] ————[ cut here ]———— [ 0.304217] kernel BUG at arch/riscv/kernel/irq.c:43! [ 0.309252] Kernel BUG [#1] Still, this is much more successul than my previous hacking on this platform, so… Read more »

js0x0
js0x0
6 months ago

Just tried Damien’s prebuild kernel w/built-in cpio: much better
Means my earlier build probably has a broken rootfs, so at least it’s a simple fix.
[ 0.232785] Freeing unused kernel memory: 320K
[ 0.236490] This architecture does not have kernel memory protection.
[ 0.242906] Run /sbin/init as init process
[ 0.247103] Run /etc/init as init process
[ 0.251097] Run /bin/init as init process

—————————–
| Kendryte K210 NOMMU Linux |
—————————–
Mounting /proc
Starting shell

BusyBox v1.32.0.git (2020-02-12 17:51:45 JST) hush – the humble shell
Enter ‘help’ for a list of built-in commands.

/ #

Advertisements