First steps with the Raspberry Pi

Posted on April 23, 2012


Yes, I was awake at 6am on the 29th of February and it was partially my fault that the element14 and RS components sites went down. I’m sorry.

It does mean that I now hold in my hands one of the first batch Raspberry Pi’s!

So what to expect right now?

First, if you too are an early adopter, congratulations! If this is your first time you’ve bought something like this with expectations that it will immediately do everything you think it might, I have to tell you a few truths about newly-minted low-budget hardware, and embedded devices (note, NONE of this is specific to the RasPi, but generally true about all very new and unseen devices):

  1. Start by expecting that nothing works and that you, or someone like you, will have to put the time and effort in to make it do what you want.
  2. Be supportive and congratulatory of anyone who improves that situation. For example, going from no sound through linux to a partially working ALSA driver is cause for celebration, not ‘WTF Boo SUCKS’
  3. More of guideline #1 – if you expect everything to work Out-Of-The-Box this early on, you will be disappointed.

So, what works?

Actually, given what I’ve just said, a truly surprising amount works just fine! There is already a wealth of documentation on the linux side of things on the wiki, several different distributions of linux to try, and even more impressive, the hardware all seems to be present, working to expectations and accessible (to an extent, but more on that later.)

HDMI video *and* audio output works, as well as composite video and the analogue 3.5mm audio out (with some potential for hot-swapping the two at a future date.) There is also a fully working and hardware-accelerated OpenGL ES 2.0 interface to build against, but you all probably know that from the countless Quake 3 demos that have been shown on the Pi in the past few months.

Ethernet and USB host functions seem to work quite well under normal load, and there are a wonderful set of working GPIO (General Purpose Input Output) pins on the board too! I won’t go into this too much, but suffice to say, that you know all those cool inputs and outputs an arduino has? They are technically GPIOs 🙂 The Pi has fewer of them than the arduino, but it certainly has enough to be exciting. It even has direct SPI and I²C connections and a serial UART (RS232 at 115200 baud) there!

“hello_pi” – accessing the hardware.

With the debian image from the Raspberry Pi downloads page, there is a selection of demonstration code samples, showing how to access the hardware directly in C within the directory ‘/opt/vc/src/hello_pi’ (also available to view/fork on github) The ‘video core’ hardware on the Pi comprises a number of components that can be accessed through an interface (an OpenMAX IL one) and much of the code here shows ways that you can access these parts:

  • hello_world‘ – the obligatory and traditional beginner’s piece of code. A simple C file and a suitable Makefile to compile it with. As with the other examples, all you need to do is run ‘make’ in the directory and it will compile the application. In these demos, the built program ends in ‘.bin’ Run them by typing ‘./hello_world.bin’ for example.
  • hello_video‘ – a demonstration C program to stream a 1080p H.264 file (a clip of Big Buck Bunny) to the video decoder component of the GPU core using the OpenMAX IL and display it over the current video out (eg HDMI). Note that this just uses the video decoder, and not any audio decoder, so there is no sound but it does show smooth and clear video output. As the lion’s share of the work is done by the GPU, the CPU barely does any work at all.
  • hello_triangle‘ – demo OpenGL ES 2.0 code. It’s much more than your typical ‘hello triangle’ demonstration as it shows a textured cube, rotating in fullscreen. This uses the provided OpenGL ES libraries which handle the hardware connection to the video core for you.
  • hello_audio‘ – an ‘alarming’ demo of how to send audio bytes directly to the audio out component of the video core. It’s quite alarming as it plays a siren sound at quite a solid volume through either the HDMI or 3.5mm audio jack depending. This uses OpenMAX IL directly and not any of the normal linux sound APIs like ALSA (more on this later.)

Whilst this is a wonderful way to introduce the hardware to hackers and developers like me, it doesn’t really replace good documentation on what the components can do. I have poked and played around with the system now and am reaching points where I have unanswered questions that I feel documentation on the hardware would help answer. For instance, I need to be able to ‘mute’ the sound output but continue playback at the correct speed/latency – is there a smart way to do this? Whilst some questions can be answered easily with time and experimentation, it would be quicker and cleaner just to answer them directly with specific documentation for this chip. (It is quite possible I am missing something with the OpenMAX IL 1.2 spec, but it’s a long PDF and very generic.)

How accessible is the hardware through the usual Linux media subsystems (ALSA/JACK/OSS, X server hw acceleration, etc)?

This, unfortunately, is where most of the work needs to be done BUT it’s all being done in the open. is the github account that owns the key repositories for the kernel, the firmware and some tools, including a tool required to turn a linux kernel into the bootable kernel.img that the Pi needs.

No hardware acceleration for X windows yet

Firstly, the most noticeable absence is hardware acceleration for X windows system (X11), the system that provides the basis for the graphical user interfaces on linux (and Unix). The Pi uses a framebuffer backend for X, and is unaccelerated. That means that, in simplified terms at least, if you want to move a window one pixel to the left, those bits of memory have to be rewritten completely on the buffer in a different location by the CPU.

One basic idea to speed this up would be to get the video core to do the work of creating the framebuffer rather than the CPU. If each window was stored as an image in the video core’s memory, and combined (composited) together to create the complete frame by the video core, then to move a window left by 1 pixel, you would pass the window’s reference with its new screen location to the core. This is a much better use of CPU resources and the desktop would feel far more responsive accordingly. (The example described here is based on XShm – there are far better mechanisms to employ now!)

There are a few different pushes to get accelerated X at the moment: some people are trying to get DirectFB working, others have suggested an OpenGL ES driver of some sort, blitting/flipping accelerated features and there are many more ideas still. This is certainly an area to watch (and perhaps contribute to!). I have no fixed opinion to which way will be the best, but there are a large enough group of people looking at this problem and I’m sure that a good solution will appear in the coming months. An alpha or beta-level driver may even appear before the second batch of Pi’s are sent out, who knows? It’s certain that the hardware is up to the task, it’s just down to how best to plumb it into X.

Linux Sound? ALSA – alpha level support.

Linux audio is not easy and its not simple to work with at the best of times. There is no straightforward stack to use and frankly, linux audio generally is a bit of a mess. A colleague whose technical opinion and skill I respect, upon hearing that I was looking at the source code of an ALSA hardware driver said “No! Don’t! Run for the hills! Don’t do it!”.

So, a few days after the first Raspberry Pi’s landed in people’s hands, they quietly announced an alpha-level ALSA driver! Wonderful and impressive, given the mess of the linux audio ecosystem. If you’ve browsed the github issues on the firmware repository, you might have noticed a number of tickets filed by me about this ALSA driver as there are a number of things to clear up in it. In fact, if you know anything about ALSA, then your help would be gratefully received! The key issue is that the hardware works fine and can be made to work, but plumbing this to ALSA is not complete, due to not understanding some of ALSA’s quirks, specifically to do with latency reckoning and delays. Please take a look! (files bcm2835* are the one’s to look at.) I am a novice at ALSA driver writing, but am trying to get this fixed or at least qualifying where and how the issues arise.

Even in the mess pictured above, it should be clear that ALSA is a key component to support. There is even ‘alsa-oss’ that provides OSS emulation via ALSA, so a working, reliable ALSA driver is an important component and I know is a high priority for everyone. Scratch, PyGame, Löve2D, Flash (and so Flixel, etc) and so on all can use ALSA as a means to make sound and sound can be a very engaging thing for someone learning to program to use. Some game designers, like Adam Atomic, argue strongly that good sound can “make all the difference in the world ” and can turn an mediocre interaction into a compelling experience that is remembered.

Most everything else works

  • OpenGL ES 2.0
  • USB 2.0 devices and storage
  • Ethernet
  • Video and audio out (HDMI and composite/3.5mm jack out)
  • GPIO pins
  • Linux

Word of Warning: Booting from SD cards

The Raspberry Pi has no BIOS; it boots by looking for a program called ‘start.elf’ that carries on the rest of the bootstrapping process and it only looks for this file in the first partition of the SD card and only if that partition is FAT32. Interfacing with the SD card at such a low-level, before anything has loaded, has certain limitations and certain assumptions were made about SD cards generally, based on the documentation of the SD card manufacturers.

However, the world of SD cards and their true specifications is a murky one indeed – it is not uncommon to compare two identically branded and specced cards from the same manufacturer and to find that the one bought a year ago is completely different to the one bought now. Certain brands also focus on a certain type of access, developing to improve the speeds of very large sequential file access (ie reading/writing raw photo images) at the complete expense of the speed of access to lots of different, small files.

The long and the short of it is that not all SD cards are created equally, and you can’t really guarantee that a given brand or even model of SD will be any good.

Combine this with the previous statement about the very limited bootloader above and you end up with a device that requires *decent* SD cards to boot up. There is a wiki page naming and in some cases, shaming makes and models of SD card that people have and have not been able to boot with. Bear in mind what I said before, and don’t be too surprised if you can’t boot the Pi with an old card you have, even if it is listed. It may have the same branding, but I doubt it is the same inside.

In summary

At this time (20 April 2012), this is a great device for anyone who wants to learn about compiling, embedded hardware, linux internals, subsystems and drivers, programming, servers, commandline, cross-compiling, building kernels, exploring electronics and control, kernel drivers, gdb, debugging, open source, repositories, distributions, network communication (ssh, etc), low-level I/O, GPIO, serial connections… in short, it’s a great thing for competent developers to stretch themselves working with.

It’s not something you can throw at an 8 year old and expect it to teach them Scratch and python programming. Yet. And it is a “Yet” as I expect that in the coming months, there will be a tailored setup of linux that will do exactly this. Just not now, but soon. This is *very* exciting to me.

It’s also not yet a low-cost, media centre that you can just plug in storage and have running. It’s pretty close but not quite there. Next week? maybe 🙂

There are so many exciting developments that as soon as I click ‘Publish’, I’ll probably need to update this post.

Posted in: Uncategorized