My Raspberry Pi configuration: serial cable w/ +5V, ethernet cable and no micro usb power
The Raspberry Pi boot process is fairly complex and, as far as I know, closed source. Apparently the GPU boots first, then jumps to the boot code on the SD card which eventually runs the binary file provided by the user. By default the bootloader looks for the kernel.img binary, however alternative file paths can be specified by editing config.txt. Typically the binary is some sort of Linux kernel; in the case of bare metal development it’s either custom code or another loader stage.
To get started with developing for the Pi hardware it is sufficient to simply replace kernel.img on the SD card with a compiled binary. This requires the tedious reflashing approach described above, however, so I looked for a different solution in my setup.
At first I used U-Boot and ran my code by transferring it to the Pi via TFTP. This approach worked well, however U-Boot was too bulky for my liking. I eventually found a GitHub project called Etherboot that loads the binary using a lightweight client/server model. The project isn’t very polished (and not actively maintained), however I’ve had a lot of success using it to load code. It’s also quite compact, so I plan to add some features when I have the time. Needless to say, Etherboot requires the Pi to be connected to a router via an Ethernet cable.
The other major component in my Pi development setup is an Adafruit USB to Serial cable. The cable connects the RX/TX pins on Pi to a USB port on my laptop, which can then be used with a terminal emulator like GTK Term or GNU Screen to talk to the hardware. One of the other nice features of the cable is that it provides a +5V lead that can be connected to the appropriate pin on the Pi. This can be used in place of a micro USB power source, which reduces the number of cables needed.
To make use of the cable, the Raspberry Pi needs to send and receive bytes over a UART port. The low level samples David Welch has on GitHub provide working examples of communicating over the UARTs on the Pi.
One other nice feature that’s lacking from the stock Raspberry Pi hardware is a reset switch. It’s apparently easy to solder one on though, since the hardware has the appropriate connectors. I haven’t done this myself as I don’t have a soldering iron, however I did try bridging the connection with a jumper clip and it does indeed reset the board.
The context switcher work!
The current milestone for the CS 452 project is a working context switcher and the ability to create and schedule additional processes. As such, I wrote a simple implementation on my Raspberry Pi today that switches between a kernel and two different user processes. Some of the context switch code came from my CS 452 partner Rollen — he spent some yesterday working on the hardware in the lab.
I used input from the UART to determine which user process to run, as well asprovides useful debugging output (stack pointers, PC, PSR, etc). The user processes themselves simply blink the LED at different rates depending on the state of some of the variables on the process stacks. The code isn’t very polished, but it was a nice reintroduction to ARM assembly.
The next item I’d like to complete is to write some generic Makefiles to build the same code for the school hardware and Raspberry Pi. Some of the functionality, such as the UARTs and LEDs, is platform specific and will need to be pulled out, but much of the code should be portable.