The question of Why PiBox came up many times at the Denver Maker Faire and after stumbling across a multitude poor responses I realized I needed a better answer. Or maybe just an actual answer. A real description of what PiBox is instead of a series of fumbled mumbles about why I have no life. And yes, I’ve already written this once before. But I need to get back into blogging about PiBox and this was a good way to grease the rusted gears in my forehead.
The truth is simple: PiBox is my escape. I’m a nerd. A geek. A guy who, unlike everyone else, has known since he was 14 years old exactly what he was going to do for the rest of this life. I am a computer dork. And computer dorks, well, we dork with computers. We don’t play games. We don’t use smart phones. We build things. Out of hardware parts and bits and stuff. And software. Because hardware without software is a boat anchor, or at least used to be. Now hardware without software is a light switch. Or a really cheap TV. But software without hardware, well that’s different. That’s called imagination.
See, PiBox started life as a solution to a practical problem: how to build a custom software platform for some custom hardware. Except the definition of custom software platform was still evolving. This was about the time of PDAs. And the idea of building a custom software platform was really just forming with the OpenEmbedded project (which was known as something different back then, not that it matters). Custom really means targeted, as in for a specific device and probably for a specific purpose. And platform meant Linux, because who the hell builds a custom Windows platform on purpose?
The sum of the parts of a custom platform is more than the whole because it takes extra work just to get started on building those parts, like acquiring a toolchain. Toolchains are collections of software for compiling code, like Linux, into files we can stuff onto hardware. And don’t underestimate the requirements for stuffing the files onto hardware. We need bootloaders and firmware and programmers – no not people programmers, but tools for pushing files onto the hardware. There is a bunch of work that has to be done just to get started to do a bunch of other work of building a custom distribution.
Before PiBox I found the Linux From Scratch (LFS) site, which described how to make a custom Linux distribution. A Linux distribution is like a custom platform, but without a specific targeted hardware platform or even a defined use case (re: the reason you wanted to make the custom platform). LFS described, in book format, how to do everything to get a toolchain and compile Linux and the bits of pieces required to make your own Linux distribution. A Linux distribution is the combination of the Linux kernel and a root file system. A root file system is a collection of files that make up a set of core services such as device initialization and network configuration.
But LFS just described in book format the process of creating a custom Linux distribution. The tools to automate that process were left to the reader. Since there were many readers of LFS there were a few tools floating around that tried to implement it. The first tool I found was Dan Kegel’s Crosstool, a set of shell scripts, C programs and data files that automate toolchain development. A toolchain formed the backbone of scripts I wrote to build my own distribution. Crosstool and my own scripts sufficed for an initial project but was never a good general purpose solution. It was simply too specific to the hardware and project they targeted.
Time passed and others like me expanded on the ideas started by Dan and the LFS project. First, Yann Morin took up Dan’s banner and extended Crosstool into Crosstool-NG, the modern tool for building toolchains. Next I came across two projects targeted specifically at embedded projects: Busybox and Buildroot. Busybox provided a large set of common utilities needed in a root file system and linked into a single binary to reduce file size and memory use. Buildroot extended this to provide a wide variety of tools and applications. Together they provide just about everything you need for a custom Linux distribution. Toss in the Linux kernel and you’re just about there.
Just about. What’s missing is way to build all these bits in a uniform, easy to understand manner. The Linux kernel has a utility called kbuild, which allows a menu based configuration for choosing what drivers and services the kernel will include. Crosstool-NG, Busybox and Buildroot adopted that system so can also be configured using a menu system. Now you can build a custom Linux distribution using a menu system to pick and choose the bits you need. But a custom platform needs other things like bootloaders and firmware. Buildroot gets you most of the way there but these last two pieces can be their own problems.
PiBox takes Crosstool-NG, Busybox, Buildroot and Linux kernel projects and wraps them in a simple GNU Make environment, allowing easy configuration and an extensible framework for adding firmware, bootloaders and packaging tools. PiBox provides a generalized mechanism for building custom platforms from toolchains to bootloaders to the Linux kernel and root file system for any hardware platform.
But once you have this generalized platform you find you want to use it for something. That’s when PiBox began to separate into different vertical projects. The first was the media center, a set of small applications and configurations for basic media playback in a self-contained but network distributed setup used initially in my camper.
The media center was extended to include a consumer interface modeled on the Roku but written in C, GTK+ and Cairo (no web technologies required). This required defining a software stack modeled on the block diagrams for Android above the core PiBox custom platform . Libraries provide C APIs and user space applications are written primarily in C though eventually I added a simplistic web interface for distributed webcam viewing.
After the media center stabilized (there are still lots of ideas to be implemented, however) I moved to home automation with the Ironman project. This takes the media center UI and scales it to Nest-sized displays and adds a WiFi based closed network of sensors and controls. This is where the project stands now, with AES 128bit encryption working on a template Arduino control for light switches.
From here there are a plethora of directions that PiBox can go. There are many refactoring projects and UI updates to be made to the media center and many new features to be added to Ironman and the media center. Things are wide open because, as I said before…
…software is imaginiation.
Since PiBox started Buildroot has evolved it’s own version of building the complete Linux distribution. But I prefer PiBox because it makes it a little easier to rebuild parts of the whole distribution. And it includes the ability to get out-of-tree firmware along with with installation tools.