In the vast majority of cases, running a Linux-based operating system involves a pretty powerful processor with a lot of memory on hand, and perhaps most importantly, a memory management unit, or MMU. This is a piece of hardware which manages virtual memory, seamlessly giving each process its own memory sandbox in which it shouldn’t be able to rain on its neighbours’ parade. If there’s no MMU all is not lost though, and [Uros Popovic] gives us a complete guide to building the MMU-less μClinux on a RISC-V microcontroller.
The result is something of a Linux-from-scratch for this platform and kernel flavour, but it’s so much more than that aside from its step-by-step explanation. It’s probable that most of us have heard something of μClinux but have little direct knowledge of it, and he leads us through its workings as well as its limitations. As examples, standard ELF binaries aren’t suitable for these systems, and programmers need to use memory-safe techniques.
Whether or not any of you will run with this guide and build a tiny MMU-less Linux system, anything which expands our knowledge on the subject has to be a good thing. it’s not the first time we’ve seen a RISC-V microcontroller turned to this task, with a nifty trick to get round the limitations of a particular architecture.
For those of us who remember the Motorola 68000 microprocessor, it’s likely that a sizeable quantity of those memories will come in the form of a cream or grey box with a Commodore, Atari, or Apple logo on it These machines were the affordable creative workstations of their day, and under the hood were a tour de force of custom silicon and clever hardware design. We might, therefore, be excused for an association between 68000 based computers and complexity, but in reality, they are as straightforward to interface as the rest of the crop of late-1970s silicon. We can see it in [Matt Sarnoff]’s 68k-nano, about as simple a 68000-based single-board computer as it’s possible to get.
But for all its simplicity, this board is no slouch. It packs a megabyte of RAM, 64k of ROM, a 16550 UART, and an IDE interface for a CompactFlash card. There is also provision for a real-time clock module, through an interesting bit-banged SPI interface from the 16550’s control lines. There appears also to be a 50-pin expansion header.
Software-wise there is a ROM monitor that provides test and housekeeping functions, and which loads an executable from the card plugged into the IDE interface if there is one. This feature makes the board especially interesting, as it opens up the possibility of running a μClinux or similar kernel for a more fully-featured operating system.
The 68k doesn’t receive the attention here that some of its 8-bit contemporaries do, but it still appears from time to time. We’ve certainly featured at least one other 68000-based SBC in the past.
Thanks [Anton] for the tip.
[Mike] has been filling up a rather intense wiki entry outlining how to run uClinux on a DE0-nano FPGA board. This is an inexpensive dev board that will run you somewhere between $80 and $100. Right off the bat he goes into a hefty list of the reasons that this is a foolish activity. To name a few: Once you’ve complete the build the device will be tethered for reboot. This board doesn’t have Ethernet hardware and TCP/IP is one of the beast features of the uClinux kernel. And the FPGA tools are closed-source, which doesn’t often mesh with the ideals of Linux developers. But we still like to see what it really takes to get these large-scope firmware builds to compile and load correctly.
After his preamble you’ll find three main chunks. The first deals with setting up the toolchain on Fedora 14. From there, he installs packages necessary for cross-compiling, pulls down the source packages, and gets to work. Once the kernel is compiled and running on the FPGA [Mike] goes on to show you how to build out a simple hardware add-on in the form of a couple of LEDs connected to extra FPGA pins. The final portion of the wiki details rolling support for toggling the LEDs into the software distribution.
[Linux4Nano] over at the [Gna! repositories] have just finalized a breakthrough for their bootloaderproject. Because the iPod Nano 2G has a hardware encryption chip, it could previously not be flashed with a custom firmware. By digging around in some assembly code (and working their magic) the team was able to get Linux onto the 2G, develop drivers for its peripherals (screen, clickwheel and serial interface are a few), and put all of that code into a package convenient to install by the end user. If you’ve ever considered installing uClinux (the ported distro) on your Nano, the [Linux4Nano] team have made the iLoader an easy place to start.
Update: Closer inspection yields that the iLoader is not yet able to load uClinux onto a 2G because it has not been ported. However, it can reload it with other custom firmware which is still a solid breakthrough.