I imagine a conversation like this:

"Bob, people hate power supplies. They're big, chunky, hot, and they don't fit on power strips. Design me a computer that doesn't need an external power supply."

Six months later: "Bob, you fool! This is a power supply that doesn't need a computer! What idiot will buy this?"

So what do you get for your one hundred dollars American (approximately seventy pounds in real money)?

First impressions are good; inside the packaging is a neat magnetic gift box, which the actual device inside. This is an utterly generic white plastic box that's so white label there's even an empty space on top to apply your own branding. Ports and cooling slots are obviously arranged to suit the geometry of the PCB inside. It's not going to win awards for style, but let's face it, it's a development kit; you're lucky you don't get it in a bag. But it's solid, well built, and well designed, which is what matters. You can unplug the nasty two-prong power adaptor to reveal a perfectly normal figure-of-eight socket underneath; US cable included. Four rubber feet, which hide the access screws to open it up, stop it skittering around when it's not fastened to the wall. The internal power supply is a smart one and will cope with any reasonable range of voltages.

However, nobody cares about the outside. It's the inside that counts, and what's inside is an ARMv5 system-on-a-chip microcontroller running at 1.2GHz with 512MB of RAM and 512MB of fast flash. (The board design, by the way, goes by the splendid name of the Feroceon-KW. Rowr!) This talks to the outside world via one USB2 port, one Gigabit Ethernet port, an SDIO slot (which supports SDHC), and a USB slave port that's used for debugging. Oh, and two LEDs. The flash is preloaded with a working kernel and a stock minimum installation of Ubuntu Jaunty Jackalope for ARM.

The slave port is used for JTAG debugging and the serial console. Again, Marvell score points for practicality; development kit serial ports are usually horrible non-standard TTL-voltage things. The SheevaPlug's approach makes life vastly simpler. All you need to do is to load the right driver, feed the device power, and you get a console.

Want more details? The processor is a Kirkwood MV88F6281, an ARM926EJ-S compatible, with 16kB of instruction cache and 16kB of data cache. It supports Thumb and Jazelle extensions, and has some nice DSP-like features. Martin Michlmayr, of course, has some nice pictures of the inside.

cpuinfo.txt 482 bytes

The raw /proc/cpuinfo output.

dmesg.txt 6 kB

The boot log.


Technical reference information follows: while instructions are supplied for installing the Windows serial driver, they assume that Linux users know what they're doing. While you don't need to install any additional drivers, you need to use the following intuitive command to load and configure it:

modprobe ftdi_sio vendor=0x9e88 product=0x9e8f
...and then use your favourite serial terminal emulator to connect to /dev/ttyUSB1 at 115200 8n1. (Tip: don't use minicom, it's shite. gtkterm appears to be the least bad Linux terminal emulator around.)

You'll see the u-boot menu scroll by and then be presented with a login prompt. Log in as root using the default password of nosoup4u. Change this immediately.

At this point you'll probably want to configure the device before playing. If it was like mine, the clock was set to 1927, so connect it to a working internet and do:

mkdir -p /var/cache/apt/archives/partial
apt-get update
apt-get install ntpdate

Next you'll probably want to do an apt-get upgrade; the preload seems to be a bit old.


Assuming your SheevaPlug is like mine you'll eventually become aware that there are a few problems.

The preloaded Jaunty image is not, in fact, in particularly good shape. The most obvious issue is that it uses the JFFS2 file system, which while a perfectly decent file system for small flash devices, is not a good choice for large ones. This may cause your device to hang on startup for several minutes. It hasn't crashed; it's scanning the file system. It's a known issue.

In addition, JFFS doesn't support writable mmap(). Guess what apt uses to maintain its database? Right. So /var/cache/apt on the SheevaPlug is actually a tmpfs volume, which stores all its data in RAM. But this doesn't get populated at boot time, so apt still doesn't work until you use the mkdir instruction described in the setup instructions above.

Oh, yes; there also aren't any kernel modules installed, which means you're out of luck if you want a feature that's not built into the supplied kernel. Like JFS, or Bluetooth.

These aren't particularly serious issues. Most users of the SheevaPlug will almost immediately blow away the installed operating system and replace it with something like Debian or SlugOS. But it's something that you should be aware of if you're evaluating the SheevaPlug.

(I've also noticed that occasionally pdflush will start using 100% of the CPU for no apparent reason --- I suspect this is related to JFFS2.)


So how fast is it?

On the console it feels... kinda weird. This seems to be because the performance characteristics are rather different to a desktop PC's. It's mostly very snappy but some operations will be rather slower than you expect. I'm putting this down to JFFS2, which is very hard to benchmark (as it's not backed by a simple block device). The SD card reader slot maxes out at about 8MB/s on a class 4 SDHC card, which is reasonable; the USB port runs at in excess of 14MB/s (which is the maximum transfer speed of my test device).

But what you're really after are benchmarks.

Here's the results of running nbench on both the SheevaPlug and pyanfar, my existing server; pyanfar is a 1.6GHz AMD Athlon.

SheevaPlug pyanfar
Memory 3.3 9.6
Integer 4.6 11
Float 0.36 17

(Compiled with -O3 only. The SheevaPlug would be happier with -Os, as its tiny instruction cache would prefer smaller code; the Athlon would be happier with -funroll-loops, because its huge instruction cache would prefer larger code. I went with the defaults.)

The numbers are indexed against a theoretical AMD K6 processor running at 266MHz. nbench is a descendant of BYTE Magazine's venerable BYTEmark benchmarking suite, and while it's still a synthetic benchmark and therefore not representative of real life, it's still interesting.

(Why does the floating point performance suck? Because the SheevaPlug's processor has no floating point unit, and it's therefore emulated. As nobody is likely to want to do anything on the SheevaPlug that requires float, I'm not terribly bothered.)

So, disregarding float, the SheevaPlug appears to be about a third and half as fast as a proper, if slightly old, desktop PC. That's not bad for a glorified power adaptor. In fact, if I go and look at the nbench itemized results page, I can find a AMD Athlon at 1GHz that's almost exactly as fast. Oh, and what's this? Is that an UltraSparc III that's being soundly beaten by the SheevaPlug? Yes. Yes it is.

nbench-sheevaplug.txt 1 kB

The raw nbench results for the SheevaPlug.

nbench-athlon.txt 1 kB

The raw nbench results for pyanfar, my 1.6GHz AMD Athlon server.

Interestingly, just for fun I tried building nbench on the SheevaPlug in Thumb mode. Thumb is an alternative instruction set provided on most ARMs these days, using instructions that are only 16 bits wide as opposed to the 32-bit instructions in the traditional ARM architecture. Thumb code is slower, but much denser, and is intended for embedded devices. These got results of 3.2 for memory, 4.1 for integer, and 0.34 for float --- still slower than 32-bit code, but not much. What's happening here is that even though the individual instructions are slower, we can fit more of them into the cache. If Marvell ever produce one of these with a reasonable amount of cache, it'll fly.


So, plug computing. Is it the wave of the future?

Right now? No. Plug computing is marketing bullshit. Apart from anything else, the SheevaPlug may be small, but it's not that small, and would be rather unhappy hanging from a power socket, particularly the US kind which aren't known for their mechanical stability. It also gets rather warm.

On the other hand, I do believe that what we're seeing with the SheevaPlug is the first generation of a new kind of computer --- small and cheap. This is probably the first mass-market ARM that's fast enough to compete with desktop PCs on their own terms. And they're only going to get better. Okay, the SheevaPlug has about the same performance as a PC of a decade ago, but at a tiny fraction of the price. Machines like this open up the ability to deliver a usefully large amount of CPU power in a very small space for a tiny price. $100! I know people who spend more than that on lunch!

It's not perfect. It could be improved in so many ways: more cache, more USB ports, more Ethernet, wireless, Bluetooth, external SATA, power level monitoring... and, in fact, when you look at the dmesg output you realise that drivers for all these actually exist. The Feroceon board can be trivially expanded to 1GB of RAM. It's already got two Ethernet ports; only one is populated. There's a hardware crypto engine. There's a sound chip. There's a hardware XOR engine that can be used for RAID acceleration.

It's very obvious that the SheevaPlug is precisely what it is, a development kit, a simple-as-possible computer built around the basic hardware design intended to be shipped to developers as rapidly as possible so they can play with the hardware. It's a tribute to Marvell that despite having so few peripherals it's still so powerful --- this little box is going to drive my house, and save me quite a lot of money for electricity bills.

I predict that in short order we're going to see a huge wave of new products, all based around this hardware, and probably just simple mods of the Feroceon-KW board in the SheevaPlug. It's already an ideal NAS, for example. And all it needs is one more Ethernet port to become the most sought after Linux-based router since the WRT54GL.

Now. If I'm going to put this on my home network, I'm going to need a name...