If you want to skip the stuff below just read this as ‘I am impressed with it and took some pictures of my ‘retail’ unit’.
That in itself is not overly remarkable but the Raspberry Pi foundation managed to keep one little trick up their sleeve. It’s well priced coming in at around the £25 for the basic ‘Model A’ and £35 for the ‘Model B’ (The ‘Model B’ giving you a highly useful Ethernet port, driven off USB, and extra USB host port). Neither model features a connector for a serial console but it is put out on the GPIO header at 3.3v so easy enough to convert if you need it (like I do ). There is also an abundance of other I/O to play with on the headers.
Considering you get 256MB of RAM mounted over a Broadcom BCM2835 ARMv6 SoC (more commonly used in things like STB’s and media streamers from people like Roku) and access to a beefy, admittedly closed source, GPU/video decoder it is pretty damm impressive and rather hard to complain. Ok, some might say an v7 ARM core would not have hurt and more of this and that but if your going down that road you are completely missing the point of this little budget device. Just pay a little more and get something like a BeagleBone or it’s big brother the BeagleBoard-XM to hack on and enjoy it (I already enjoy hacking on them).
This neatly brings me on to my interest in the Raspberry Pi. It’s low end by todays ARM standards, but it’s still got a hell of a lot of power to play with, cheap, quirky (another way of saying full of interesting features that may blow up in your face ) and with a little luck it will bring out that wonderful streak of madness in people.
Hopefully it will become ubiquitous in the lower end of this market and bring in more and more hobbyist developers, hardware hackers and students. Take a few of these devices and mix with a liberal helping of Arduino’s and you have some awesome options for cheap experimentation.
All that makes this a pretty appealing platform to hack on and fits well with the other stuff I like to mess about with.
Hardware pictures (click for larger jpeg’s):
Here are a few random pictures of the ‘early release’ retail model B unit the Raspberry Pi foundation have kindly provided me for some hacking (the logoed shipping label on the package was cute by the way). Rather than overly comment on the workings (the specs are well known) I’ll just provide some soft-core hardware p0rn pictures and comment on the physical build.
Not a huge amount say on this but I’ll note that it is nicely built, soldering seems precise and of good quality and no diff joints I can see. There is no solder in the test points (handy), most connectors are well attached and there is a only a little flex in the board.
The HDMI port does seem a lot more fragile than I would like and it’s a tight fit but I guess the cost of battening connectors would push the board outside its price envelope and consume board space, just don’t yank cables out or it will end in tears.
All in all, it seems a lot like the earlier boards in respect of the build and layout and that’s quite a good thing just remember the price constraints when considering that.
A big concern I have is how well these will last uncased but I understand the educational units are cased (Raspberry Pi, please make sure that case provides some battening for connectors) and that is surely going be be where the boards see most abuse. In fairness the uncased concern could be levelled at any of the development boards I have.
I know the foundation is going for a model that will see several manufacturers turning out boards under license but as long as they all hit this quality level or get above it I can’t envisage that many build problems as long as people are gentle with them and understand what they are buying.
After all that fluff lets move on to what I actually plan to use this device for…
As the hardware is at the lower end proper optimisation is highly important to get the most out of the device and this is where OpenEmbedded comes into the mix. I have put together an OpenEmbedded-Core based BSP layer for the Raspberry Pi A and B hardware that ensures every package built for the machine is tuned for both the ARMv6 architecture and the ARM 1176jzf-s core. This was actually fairly easy to get going bar the time consuming mess that is the usual platform specific quirks, hacks and munges. However as the OpenPandora has used OpenEmbedded/Angstrom since its inception (and has it’s own set of quirks) I should be pretty familiar with it by now .
Currently the layer it has a number of rough edges but the basics. kernel, bootloader and supporting bits and bobs are building and if you so desire it can be used to (almost, needs a small fix) create you a pre-configured SD card image file (currently setup for a 4GB > SD card) with the kernel and bootloaders on a vFAT partition and the RootFS on EXT4 all ready to write onto an SD and boot the unit.
Some more work is needed to clean up the recipes, fix a few bits and currently there is no support for the GPU libraries (coming as soon as I clean up some of the more obvious hacks and get confirmation of licence and redistribution terms). But you can already use this layer to boot an Angstrom (my OE based distribution of choice) console image or some of the more interesting image flavours (Xfce/E17 etc.) up on actual hardware.
Just don’t expect everything to work yet, ok, being honest don’t expect a lot to work yet!
Building OpenEmbedded/Angstrom packages for the RaspberryPi
If your interested in trying this (and assuming your familiar with OpenEmbedded-Core and have a build setup) you can just add the meta-raspberrypi layer (firstname.lastname@example.org:djwillis/meta-raspberrypi.git) to your build setup and use MACHINE = "raspberrypi" in your local.conf.
If you have never tried building an operating system from scratch using OpenEmbedded/Angstrom you can find a really good guide on the Angstrom site. With a few little tweaks you can get a build going in no time (just be prepaired to use a LOT of disk space and waiting many hours for it all to build, not to mention having to deal with the odd snags that come along).
Following the above guide if you change:
This will ensure you grab a fork of the setup scripts with the RaspberryPi layer already added.
Then if you proceed to use ‘raspberrypi’ as the machine you should be off the starting blocks and on the journey to getting something built.
What happens next?
Once things have settled down a little and the GPU libraries are all working my aim is to get the meta-raspberrypi layer into a state that can be included by default in the upstream Angstrom distribution. That would bring lots of nice benefits like ARMv6 and RaspberryPi optimised software feeds and use of the Angstrom online image builder to put RaspberryPi images together.
I’ll also find a way, if I can, to distribute images all setup with binaries for the GPU and ready to go. People can then grab it and write to an SD just like other distributions.
It would be great to get some input into this as it is just something I have been hacking on in my (limited) free time for a while, if anyone wants to help with this work this please fork and send over pull requests.