Western Digital Made RISC-V Linux & BusyBox Boot on Sipeed Maix Go Board

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”.

Click to Enlarge

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.

Click to Enlarge

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.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

12 Replies to “Western Digital Made RISC-V Linux & BusyBox Boot on Sipeed Maix Go Board”

  1. 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.

    1. 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.

      1. 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.

  2. 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.

    1. 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 😉

    2. 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.

Leave a Reply

Your email address will not be published.