The Raspberry Pi: A Review

Even if the Raspberry Pi is under-powered for desktop work, I have only high regard for the stated goal of the design: an affordable platform for the next generation of hardware and software designers. Considering that the higher-end model is a mere US$35 (plus shipping, handling, and tariffs), the actual bang-for-the-buck is amazing.

The system and configuration

The main board of the Raspberry Pi Model B really is no larger than a credit card, except for the lack of rounded corners. The system-on-chip is a Broadcom BCM2835, which incorporates an ARM1176JZF-S CPU (including Thumb, Jazelle, vector FPU, and security extensions [but not Thumb2-ed.]). The on-board RAM is 256M for both video and the OS, attached to the SoC and therefore un-expandable. That may not sound like a lot of memory, but remember, early Linux could run quite comfortably in 16 megabytes. The design includes connectors for everything else, provided by you: SD card for booting and optional storage, a micro-USB connector for power, HDMI video/audio output, dual USB connectors for external devices, a camera connector, composite video output, a stereo jack for audio output, and a combination of UART and GPIO pins for connecting whatever hardware hacks you wish (including those which may fry the system!). If you want to go super-low-level, the board has space for a JTAG diagnostic connector, as well.

Having a runnable system requires only two components: power and an SD card with a suitable, bootable image. The RPi has no BIOS to validate the connected devices, store configuration settings, manage the boot process, etc. As soon as the system has power, the SoC is loading code from the SD card. Given that the on-board RAM is not yet enabled at this stage, the code is loaded into the L2 cache and run from there. Having the boot code on the SD card protects against permanently disabling (“bricking”) the device with a faulty software/firmware upgrade.

Customized system settings may be manipulated through the config.txt file in the boot partition. The contents of config.txt can adjust various clock speeds, voltages (but raising the voltage will void your warranty), and video parameters. The Linux kernel’s command line can be changed in the cmdline.txt file, also in the boot partition.

There are also options available to the hacker (outside config.txt) for the allocation of RAM to the OS and video. High performance video rendering, such as playing a digital video or Doom, requires more video memory, meaning less is available to the OS and its running programs. Ordinary system tinkering will probably not require this, but the RPi is designed for extraordinary ideas.

Testing it out

I am not a hardware hacker, despite my previous post. The closest I will ever be to a hardware hacker is owning a copy of Hennessy and Patterson’s Computer Architecture: A Quantitative Approach. My only hardware hacks have been reset buttons; anything greater than that, requires a mind greater than my own. I simply relish the challenge of making small systems work the way I want. Reading the online docs showed me I needed to buy a few things: a 5V micro-USB charger, and yet another SD card to add to my collection. I also picked up an HDMI cable, not realizing until later that I had a composite monitor that would work with the RPi.

I first wanted to familiarize myself with the Raspberry Pi, before I did any major hacking. I downloaded the Debian Squeeze image from the official RPi OS downloads, unpacked it, and copied it to an 8G SD card. When the RPi arrived (April 18th), I inserted the card, connected the HDMI cable and a small telly, hooked up a USB keyboard, and then plugged in the power. It booted up and let me log in. The device had survived shipping, from China to England to the USA.

The kernel is not stock Linux, as the Broadcom SoC is not yet supported by the mainline kernel. The patches and full source for Linux 3.1.9+ are available here for those who want to build a custom kernel. I’m keeping my fingers crossed that the patches will be merged into the 3.5 kernel.

The Debian Squeeze image has all the standard Debian administrative tools included, so “apt-get” and “aptitude” are fully functional. However, because the image’s partitions are so tight on space (less than 2 gigs), a wise first move will be to create another partition on the SD card, or on an external USB device, and copy the /usr directory to it, then mount it under /usr (or use a corresponding entry in /etc/fstab). Once it’s confirmed to be working well, the user/admin can shut down the system, put the SD card into another computer, and then delete the files under usr/ in the card’s root partition. This will free up space in the root partition, and allow more breathing room for packages that install into /usr.

The overall consistency that Debian brought to the new platform made a good impression on me. In the OS/360 tradition, the kernel hides the differences between platforms, and the programs mostly don’t know the particulars about the hardware. I was counting on this for my next adventure…

Loading Slackware

The kernel is the one piece of Pi (ha ha) that Slackware ARM doesn’t yet support. However, thanks to the Raspberry Pi’s SD card requirement, it was a fairly trivial matter to remove the card (after a shutdown, of course), copy off all its files into a temporary workspace on my desktop, then delete the files I didn’t want. Once I was left with only the boot partition and the kernel modules, I made a Slackware package of them for later use.

Leaving the SD card’s partitions alone, I formatted them, then mounted them in an orderly manner (/dev/sdX2 under /mnt, then /dev/sdX1 under /mnt/boot). I then installed my kernel package plus the other Slackware ARM packages outlined here. The trick for installation is to “export ROOT=/mnt” in Bash, a step the standard Slackware installer does. Installing the glibc* packages showed an error during the special post-install scripts, since the ARM “/bin/cp” binary is useless on an x86. I ignored this error and hoped for the best.

The stripped-down installation of Slackware ARM packages, plus the package containing the kernel from Debian Squeeze, was able to get the Raspberry Pi booted and on the network. Success! I decided that the RPi’s address would end in .18, the date it arrived in my hands, and its domain name would be “zacchaeus“, in keeping with my tradition of using Eastern Orthodox saints’ names. Rather than hard-coding the address into the configuration, I set it to use DHCP and configured my server accordingly. (The MAC address, used by the DHCP server, is part of the kernel’s command line, seen in cmdline.txt in the SD card’s first partition.)

Once the Raspberry Pi was connected to the network and working properly, the only special step I needed was to mount the NFS volume containing the Slackware ARM repository. Having the packages directly available made installation “by hand” much easier for me.

One drawback to using Slackware ARM on the Raspberry Pi, is that Slackware ARM doesn’t use on-board floating point (FP) hardware, opting instead for software emulation. Yes, the software-only approach makes Slackware ARM usable on systems without a built-in FP unit, but the stock 700 MHz clock leaves me yearning to wring all the native processing power I can from this system. Rebuilding standard C and math libraries takes considerably longer than building a Linux kernel, and on the Raspberry Pi the kernel already takes a long time. I don’t want to ponder how long it would take to rebuild the standard C library.

A “shortcoming” of the Raspberry Pi itself, is the lack of an on-board time source. Including one would have easily doubled the size of the circuit board, as well as the cost. The Slackware ARM startup scripts expect some sort of hardware clock to be available. Failing this, the kernel time proceeds from the start of the Unix epoch (12:00 AM UTC, January 1, 1970) unless the time is fetched from another source, perhaps NTP or provided manually by the root user.

These two negatives don’t seem like a big deal, but taken together, they leave me wondering if Slackware and the Raspberry Pi are a good fit. Over time, I could probably find other complaints. I expect to move away from Slackware ARM, to another distro (or OS) more suited to the Raspberry Pi’s design.

Impressions

Usability is not a design goal of the Raspberry Pi, and it shows in the delivered package: the unit arrived in a small box, inside a padded envelope with a single sheet of paper showing a web address. The stated long-term goal of the Raspberry Pi Foundation is to provide an affordable educational platform for the next generation of hardware designers. It’s expected that the user/hacker will find the RPi documentation, read the tutorials, browse code samples and hardware schematics, on his/her own.

Tomorrow’s computers

and peripherals won’t

design themselves.

Without even getting into the hardware hacking aspect of the Raspberry Pi, I can still muster excitement for its distilled design and scaled-back assumptions. The ARM instruction set architecture is “a thing of beauty” tracing its heritage to the early days of RISC. Given that ARM is currently the best-selling architecture (thanks to cell phones, tablets, and E-readers), it only makes sense to make an ARM-based experimentation platform available for the next generation of hackers. Tomorrow’s computers and peripherals won’t design themselves, so we need to develop the talent pool early. It’s one thing to design a spreadsheet, and quite another to design an autonomous low-orbit satellite.

I haven’t done much performance testing of the Raspberry Pi, for one simple reason: the sale price of the unit easily justifies whatever sub-par performance I might notice. After all, the RPi wasn’t designed for me, but rather, for kids, schools, and hardware tinkerers who sometimes melt their test units. From the software side, the lower spec of the system encourages efficient code. From the hardware side, the resulting lower cost of each unit also lowers the penalty for destructive design mistakes.

One aspect of the Raspberry Pi, having nothing to do with the hardware, is the community of enthusiasts that has rapidly grown up around it. The Raspberry Pi forums and the Embedded Linux RPi wiki pages have lively discussions, tutorials, and “what if?” and “how can I?” ideas tossed about. Many of the people engaging with the community are coming in “fresh,” with few prior restrictions of habit on their thinking. And, of course, the kids.

I applaud the Raspberry Pi Foundation for the outstanding job in bringing the Raspberry Pi to the masses, and I am happy to have made a purchase in their support.