OpenPower Firmware Stack

The OpenPower server platform comprises one or more Power8 processors, the latest of the IBM PowerPC family, and some kind of management controller to power on and monitor the state of the main processor(s). This post provides an overview of the different bits of open source firmware that are used to take the machine from power on all the way through to running your operating system.

Tyan Palmetto Motherboard

The Tyan GN70-BP010 is the first OpenPower machine to ship. Known also by its codename Palmetto, it contains a single Power8 processor and an Aspeed AST2400 ARM System on Chip which we refer to as the Baseboard Management Controller (BMC). The BMC is a typical embedded ARM system: u-boot, Linux kernel and stripped down userspace. This firmware is built by OpenPower Foundation member AMI.

P8 Boot

The BMC and the Power8 share a common memory mapped interface, called the LPC bus. This is the interface over which the Power8 accesses boot firmware, as well as boot time configuration, from a SPI attached PNOR flash, and speaks to the BMC’s IPMI stack over the BT interface.

Hostboot Starting

When it comes to starting the Power8 the BMC wiggles a pin to kick the SBE (Self Boot Engine) into gear. This tiny processor in the Power8 loads the first stage firmware, called Hostboot, from PNOR and configures one of the Power8 threads to execute it from L3 cache. Hostboot is responsible for bringing up the internal buses in the Power8, as well as the rest of the cores, SDRAM memory, and another on-CPU microcontroller called the OCC (On Chip Controller).

P8 Boot Flow

When Hostboot is finished the procedures it loads a payload from the PNOR. This payload is the second stage firmware, known as Skiboot. Skiboot synchronises the timebase between all the CPU threads, brings up the PCIe buses, communicates with the management controller, and provides the runtime OPAL (Open Power Abstraction Layer) interface for the operating system to call into. Skiboot is also responsible for loading the next stage bootloader, which in this case is a Linux kernel and root file system that provide the Petitboot loader environment.

Skiboot Starting

Petitboot Starting

Petitboot is a bootloader that discovers all the disks and network devices in the system, and presents a menu for the user to select which OS to run. Petiboot looks for PXE configuration information, as well as parsing Grub configuration files found on local disks. Petitboot reads configration information from the NVRAM partition on the PNOR, which means it can be configured to boot from a specific network interface, hard drive, or even not boot at all and wait for user input. Once the boot OS has been selected, Petitboot uses the Linux kexec functionality to jump into the host kernel.

Petitboot Menu

FreeDV on Android

This blog post presents the content from my 2013 presentation Droids that talk: Pairing Codec2 and Android, where I presented some background on radio theory, and followed by a discussion of the software components required to run Codec2 and Fdmdv2 on Android, via a USB sound card.


Codec2 a digital voice codec for communication below 2400 bits per second, developed by local voice codec guru David Rowe. It is fully open – free software, as in both beer and speech sense. He as also created a modem designed for carrying Codec2 over HF channels, called Fdmdv2. David and his co-contributors have combined Codec2 and Fdmdv2 to create FreeDV, a free software digital voice application for communicating over HF radio using your Linux, Mac or PC.



In addition to my FOSS hobbies, I’ve been getting involved in amateur radio these past few years. This began with meeting Mark in the final year of my degree, moved into my time spent playing with balloons as part of Project Horus, and now has continued with FreeDV.

Mark and Joel at 2011

Modern Communication

As technology progresses, more complex systems can be built and understood with the tools we have. Sophisticated DSP and SDR are within the reach of the attendee skill set. DSP is digital signal processing; a field that moves signal processing from physical circuits to software that runs on a computer. It is relatively new, as it was only in the 80s that digital logic became fast enough to run the software in real time. SDR is software defined radio, where DSP techniques are applied to the building of radios. The following information describes the building blocks for using DSP and SDR to implement a digital voice over radio system.

Radio Theory

Radio Block Diagram

In studying for my Engineering degree, I learnt a bit about how radios work. Of interest for FreeDV is the use of a direct conversion receiver  Put simply, this kind of receiver uses the difference between a local oscillator and an amplified incoming HF signal to produce an image of the HF signal at baseband. Once amplified this baseband signal is suited for capture by a sound card, in order to be decoded and tuned using Software Defined Radio techniques. Using these simple building blocks a DSB receiver can be constructed for receiving FreeDV or SSB analog voice over the air.
Radio Frequency

Such a radio is described in my building a double sideband receiver blog post. The completed radio is show below, with the major stages compared to the block diagram above.

Radio Block Overlay


Now that the HF signal present in the computer and ready to be processed, the software must be designed. The codec and modem is implemented in C; in order to save effort in re-implementing in Java and staying up to date with changes, it was decided to use the C libraries directly, and interface them with the Java’s foreign function interface; Java Native Interface. The Android team provide a cross complier for the supported applications called the Native Development Kit (NDK).

Android Audio Input

Android handsets have a connector for microphones, however, they are not suitable as a line-in in the same way as a PC sound input, as the connector pins vary between phone manufacturers  as does the specification for the impedance between pins in order to detect the microphone. Instead, it was decided to use a USB Audio Class (UAC) soundcard device digitise the baseband radio signal.

Android runs the Linux kernel, however, unlike a desktop Linux operating system, it does not include a driver for supporting UAC devices. A user space driver for supporting the UAC device was written, using the c libusb library. This sets up an isochronous transfer from the appropriate descriptor to get 16-bit PCM audio at 48kHz delivered to a callback. The configuration is currently hardcoded for the TI PCM2900C device; this will be made generic in time.

Another complication that Android brings is the security architecture  An application can only access a USB device if it has requested permission through the USB host API. This is only provided on Android 3.1 (API 12), which means pre-4.0 devices are not supported. This compromise is acceptable, as in general older devices lack the CPU cycles to run the application. A modified version of libusb that requests permission on open, and is buildable by the Android NDK toolchain, can be found on github. Thanks to Роман Донченко for releasing this work!

Android Integration

FreeDV Android Software

The C code is all built using the NDK build system. Each component is built as a separate shared library, with the JNI code initialising each of the modules below it and registering handles for the appropriate Java callback functions. The USB callback receives the sound samples from the radio, and calls into a processing loop that is shared with the FreeDV desktop software. When enough samples to decode an entire frame, this loop uses the modem to decode a frame, which itself passes the bits to the codec if the modem is in sync.

The modem depends on the quality of the HF channel; when the demodulation side of the modem cannot sync, no data can be recovered.  Synchronisation state, as well as estimates of the timing and frequency offset of the recovered signal is passed to the Java side of the app to be displayed. When the modem is in sync, the decoded phase information is also passed to Java so it can be plotted in a scatter plot. This plot allows the user to adjust their radio’s output levels to ensure a good spread, as well as observe the effects of interference on the received data.

Android Graphing

In Android, there are no built-in widgets for drawing graphs of any kind. There does exist a library called GraphView, which provides various types of classes. As I had familiarity with the line graph class, I used this for the timing and frequency offset graphs. This required hacking GraphView a fair bit, as it did not at the time support the graphing of real-time data (since then it has gained this functionality).

joel_preso_3I decided to write my own scatter graph class, in order to learn about drawing on Android. It inherits from View, with data collected as it comes from the modem into a LinkedList of fixed size, and invalidate() is called so that the system knows to re-draw the graph when the UI thread is ready. The onDraw() call finds the largest points, scales and filters them, and draws circles for each point to a Canvas. It was easy enough to do drawing in Android by following the basic shape drawing tutorial, despite appearing complex when reading about it. I was worried about performance; should I be scaling the points when inserted, so they don’t happen when drawing? Or does that mean that I would be iterating over the list to update the scale more than once between onDraws, and therefore do unnecessary work? These are still good questions to answer, but for now, it Just Works.

Native Code Optimisation

The native code is built with -O2 -ffast-math flags for speed, as well as NEON support enabled through the NDK’s mechanism. There were optimisations provided to the codec2 mailing list some time ago, including using the float instead of double precision variant of the maths functions, and I incorporated some of these in the copy of the FreeDV software I used. It is not clear if these performance optimisations are necessary in order for real-time performance; some benchmarking is required. For now the NEON support means that the application will not run on all platforms, as there is no run-time detection performed.


In the near future, I plan to add a waterfall display of the received spectrum, and allow tuning within this range. I will also add support for generic USB Audio Class devices, as well as analog input for those who have line-in ability on their Android devices.

The source code can be found on Github. Please download, compile, code-review, hack, and test. Any feedback is welcome.

Thanks to David and Mark for your help with all of the hacking, both hardware and software, to Kristina for your help in preparing my talk and taking the photos of me presenting that I’ve used on this blog post.


Building a double sideband reciever

David, Mark and I sat down one weekend to build a direct-conversion double-sideband (DSB) radio receiver.

Direct-conversion indicates that the desired signal is mixed directly down to baseband using a local oscillator (LO), with no intermediate steps. Double-sideband means that signals above and below our local oscillator frequency are superimposed on each other and output at baseband. Because of this, a DSB receiver can be used as an AM receiver, though we were only using it to receive single-sideband communications.

The design we chose to build was based on the Porta 40, from the November 2012 edition of Amateur Radio Australia by Peter VK3YE. The schematic for the circuit is not online, but an explanation is on YouTube and a similar design is the DC40. The components for the design could be purchased from a local electronics store, which made it attractive for fast prototyping and experimentation. As we couldn’t obtain 7.2MHz resonators quickly, we used 7.158MHz crystals. This limited our tuning range, but this was acceptable for our purposes.


With the parts in hand I built it up on some blank PCB material, starting with the local oscillator. While I built the LO Mark wound the transformers that were required for the mixers. We tested the LO with David’s old HP oscilloscope and found it resonating at 7.143MHz, close enough to the 7.158MHz we were expecting.


The pre-amp was pretty straight forward, with the exception of a mistake in the published schematic where the Zener diode was drawn with reversed polarity.

Pre-amp testing

Next up was the mixer. The hardest part of building this part was remembering which of the three windings had to go where. I recommend using different coloured wire for the windings, which reduces confusion and allows the design to be checked before powering on.


Finally the audio amp was built, and we tested the entire setup by connecting to the antenna on a pole, and the output to the soundcard on Mark’s laptop. Using some SDR software (Spectravue), we were able to tune to a SSB voice transmission right at the edge of our 24kHz of bandwidth provided by the soundcard. Not only had the design worked first time, but we were about to hear two operators from Victoria having a conversation using the SDR software!



Aside from using it as a single frequency analog voice receiver I plan to use this radio as a downconverter to demonstrate a SDR based implementation of FreeDV of Android.

Thanks to Peter VK3YE for publishing his design, and to David VK5DGR and Mark VK5QI for their help building and testing the radio.