Having decided that I wanted to embark on a bare-metal adventure, I thought it best that I prepare myself a bit. Ideas are already buzzing around in my head about what and how I might approach this problem, but to start with I think that following in someone else’s footsteps might be a good idea.

A look around.the web threw up several references to some tutorials from Cambridge University covering bare-metal operating system programming for the Raspberry Pi in assembler. Just what I need.

I followed the starting instructions, flashed a SD card with a compatible file system, installed the yagarto toolchain, entered the code from their first tutorial, and after a minor bit of typo fixing, unplugging and SD-card swapping I have control of the tiny green “OK” LED conveniently visible through the slots in the ModMyPi case. It’s hard to overstate how this feels. Sure it’s not my own code, but it’s a real working example of controlling the Pi with no dependency on a mysterious operating system, just a couple of handfuls of assembler instructions. It feels as if anything is possible now!

Flushed with success I pressed on with the rest of the OK series of tutorials. I like the explanation of the eabi, and the way it demystifies the interface between C/C++ and native code. I also like the little side journeys into how and why things work as they do.

I will admit that keeping my eye on the details of the assembler listings has become a bit tedious, though. By OK03 I had given up even trying to think through the challenges and write my own code. The compile, build, unplug, move card copy, move card, plug in, state at little LED cycle just seems so cumbersome that it does not feel easy to try stuff and iterate until it works. I’m also really feeling the lack of any other output. My knee-jerk reaction when faced with a piece of software which does not seem to be doing what I expect is to instrument it- add some output at strategic places to find out what is actually happening inside the black box. This process feels like just poking at the black box with a stick.

All went reasonably well until OK05. Here I hit a problem. I started by gluing the code together from the source snippets on the page, as had worked for the earlier exercises. Nothing. I tried a few changes and tweaks, all to no avail. Eventually I gave up and downloaded the “answers” and did the run-around with cards and cables again. Still no luck. I tried a few things and double checked everything, but no. It simply didn’t work.

At this point I felt a bit stumped. The code and the description seemed both compatible and reasonable. But they did not work. So I looked around the web. It took me a while but eventually I found an answer.

It seems that there are two versions of the Raspberry Pi boards, with two slightly different bootloaders. The difference is subtle, and effects the way data sections in the image file are accessed. I have the newer of the two, and the tuturial was written for the older one. Given this, there are two ways to get the code to work. The first is to tell the system to boot using the old process, by editing the file config.txt on the SD card to add a line

kernel_old=1

This is not recommended, though, as the new boot process is considered generally better.

A more appropriate solution is to add the code base address to the data symbol when accessing it.. The original code in the tutorial to load the morse code data gives:

ldr ptrn,=pattern
ldr ptrn,[ptrn]

To make it work, add in the offset 8000:

ldr ptrn,=pattern
add ptrn,ptrn,#0x8000
ldr ptrn,[ptrn]

I’m glad I got to this point, ironic though it is that the tutorial example which doesn’t work is the one which is supposed to flash SOS and call for help!

From tomorrow I will be travelling to visit family and away for a few days. My plan is to do a lot of thinking and designing and come back ready to build on what I have achieved with some of my own ideas. There not much point progressing on to the next few Baking Pi tutorials, as I have neither a screen nor a keyboard connected. I have ordered a few extra bits of hardware, though, which might help with the input and output problems.