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
My Raspberry Pi, wired to a Commodore Amiga monitor. The future, and the past, connected.
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.
I Am, Therefore I Think 
Nice informative review. You have not wasted the readers time by contrasting the device against all manner of factors that are beyond the foundation’s clearly stated goals.
Embedded systems are funny little computers. You do not use, develop, and engineer with embedded systems the same way you would on a workstation or server. I suggest reading the Embedded Linux Primer. It’s an excellent read whether you’re into embedded systems or not.
Good review! In terms of core functionality, I felt you reviewed the system pretty well. The first software steps are going to be the most interesting to 99% of the population using this. My only real worry is the use of the Broadcom chip, which defeats the educational hardware aspect, and may cripple the linux capabilities in the future. One can only hope that Broadcom opens up the chip/drivers, or the OSS community solves it themselves…
Two more things:
1. When you say:
___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.___
Not quite that bad. For basic timekeeping, an RTC can be found for 40 students.
Raspberry Pi is the next evolution in education. Just as amazing are projects like gumstix ( http://www.gumstix.com/ ) and Arduino. Each service a niche, and together create a blooming eco-system. I’m really excited to see where this release takes us!
>After all, the RPi wasn’t designed for me, but rather, for kids, schools, and hardware tinkerers who >sometimes melt their test units.
Finally, someone who gets it.
Look, we all want a cheap computer to put in the garage or workshop but you have 50-120$ boards for that.
I am less worried-curious about the specs than how they are going to do the learning thing.
Its nice if you have a parent or teacher to help a child but success to me would be a kid whose cool uncle buys him a Pi and the the kid can on HIS OWN follow a guide or tutorial/videos and learn on his own.
That would be amazing because not every parent has geek knowledge.
Naming computers after Eastern Orthodox saints is one of the more awesome schemata I’ve seen. :)
it isn’t like I’ll ever run out of names. :-)
Hello
I would like to ask about permission for article [raspberry pi: a review] reprint
in my noncommercial electronic magazine. Of course i will add full information about author in my e-zine. Please send answer in the comments [or directly on email], because i have no account on wordpress :/. Thank You in advance.
(gus3 says: request approved, replied in private, email removed from this comment for security)
Just for the sake of perfection ;)
“I needed to buy a few things: a 3.3V micro-USB charger”
should say
“I needed to buy a few things: a 5V micro-USB charger”
Right you are; I corrected my mistake in the article.
The CPU takes 3.3V, but the main power rails need 5V.
If it’s going to really gain any major traction in its target market, I imagine somebody at some point is going to have to develop an introductory-level curriculum that uses it. (I don’t mean introductory in the sense of being for people who have never used a computer, but introductory in the sense of being for people who have never worked with embedded systems before, other than as an end user.) To some extent, individual teachers may be able to develop their own, but it would be a lot more attractive to schools if there were something extant to work with in that regard.
The holy grail, I suppose, would be to design the curriculum so that the student, over the course of a semester, could proceed from basics like getting a working bootable system as you’ve outlined here, to using it for three or so different projects where the embedded nature and small size of the system are significant to the success of the project — say, for example, a hand-held digital jukebox, a remote-control vehicle, and a wearable system that monitors heart rate or some such — all with the same core system. The tricky part about designing such a curriculum would be to keep the auxiliary costs (for the other needed hardware) low. A remote-control vehicle for example might require too many expensive components, so that project might have to be replaced with something that could be done more affordably and yet would still appeal, at least somewhat, to the students.
The timing of the RPi’s release to market was fortuitious, making it available to kids for summer projects. The softwares available for it are a good start, but turning kids loose with their own ideas of what it could do is the whole point of the RPi. This article is a good demonstration of what I mean.
There is also an “introductory” book on the RPi mentioned here (with a not-so-introductory version on the way), so there is already work on a formal academic approach.
Nice article, thanks
I’ve choosen the Arch Linux ARM as the OS for my RPi. So far, it works exactly the same as the x86_64 one, plus vfp=hard activated by default -:) My Linpack benchmark is slightly above the standard rev. B and default 700 MHz clock; see my blog
I bought the RPi to upgrade my asm knowledge to ARM. talking about Schools, beside engineers ones, which kids is targeted by the RPi : the FB generation !