PiBox Platform

The PiBox Platform is a design goal: allow creation of a base system for a given hardware architecture on which applications can be built and run. The platform design separates the creation of a base system into multiple components: toolchains, bootloaders, firmware, kernel, initramfs, root file system and installation media. An implementation of the PiBox Platform provides a build system for each of these components while attempting to keep a common GNU Make target naming scheme. The use of a common target naming scheme makes use of the build system easier to understand, and thus encourages extension and customization.

Not every component of a PiBox Platform is necessary for every architecture. The main PiBox repository is a PiBox Platform implementation, re: a build system, for Raspberry Pis, but there are variations for other architectures such as Intel and the Rockchip RK3399. There have also been implementations for PowerPC and MIPS. The Raspberry Pi implementation provides component builds for a toolchain, firmware, kernel, initramfs, root file system and installation media. There is no bootloader build in this implementation because the Raspberry Pi bootloader is in the GPU (though a u-boot or other bootloader could be added if needed). In contrast, the Xeon implementation – the RK3399 implementation for a PinePhone Pro target device – can build multiple bootloaders along with the rest of the components.

There are other build systems that provide similar functionality. Yocto is popular among many hardware vendors. Buildroot, too, is highly popular and is, in fact, used by PiBox implementations to generate the root file system. So why use PiBox?

PiBox implementations separate configuration by component, externalize build directories from source and archives and, as mentioned earlier, provide a common GNU Make target naming scheme. More importantly, PiBox implementations are intended to be target specific. While a given PiBox implementation might support multiple devices, the intent is to support common devices like the Raspberry Pi family. More importantly, because the PiBox Platform is designed as an embedded solution the target devices are intended for specific purposes: video players, file servers, home automation, etc.

In contrast, Yocto divides build configuration based on yocto design, not by components. It’s much harder to find build configuration information under Yocto than under a PiBox implementation. Just trying to find the kernel source under a Yocto build (which is under the source directory and not separated from it) is quite a chore for the uninitiated. A kernel configuration under Yocto can contain many different files while PiBox keeps kernel configurations in a single file per target build. Yocto also lacks a menu-based configuration option for the various components.

Buildroot is much better than Yocto in most cases and, honestly, is a reasonable alternative to PiBox. When PiBox originated Buildroot lacked a toolchain build. Crosstool-NG is wrapped by PiBox implementation to create custom cross-toolchains. But more importantly PiBox separates the configuration and build processing of the system components making it easier to reproduce, rerun or clean builds by components. Because PiBox wraps Crosstool-NG and Buildroot, configuration for most components uses the common Kconfig menu system which greatly simplifies experimentation with alternative builds.

PiBox implementations generate a base system which, by itself, can be very useful. But the build is not targeted to a specific purpose because it lacks a UI and applications. By making the UI and applications installed packages PiBox implementations can be extended into PiBox Systems.