|
Deprecated
|
Design
Table Of Contents
Project Goals
Every project needs an primary goal, that thing that provides the measure for "We did it!" The primary goal for PiBox is an easily extensible lightweight embedded software platform for a battery powered Raspberry Pi using well defined hardware accessories This primary goal is very simplistic unless you look at the alternative software distributions currently used for the Raspberry Pi. Most are not designed to reduce daemon services by default. This means they run daemons the embedded platform may not need and can therefore reduce run time for a battery powered device. PiBox allows customization of the boot process to eliminate unwanted services. Additionally, few of these distributions run solely out of memory. Many perform continuous updates (logging, for example) to the primary storage device for the Raspberry Pi - the SD card. Performing many writes to an SD card will decrease its life span. Just deleting files from the SD card will not help as a delete requires deleting more than just the one file (and then rewriting data that wasn't deleted) due to the way SD cards are designed. PiBox is designed to move all repeating write operations off the SD card and into a file system in memory. This has the added benefit of allowing PiBox to be powered off mid-stream, as it were, with no damage to applications or data. Applications that require persistant storage will have to manage that data themselves. The base OS assumes all writes have been completed before poweroff. PiBox also places no constraints on the UI. A default UI is provided that provides minimalistic desktop support. However, this can be easily changed to any UI running either under an X.org server or the frame buffer directly. Support exists for a variety of X.org window managers including the Matchbox UI that originally formed the basis of many PDAs and hand held devices. All current PiBox systems are based on Matchbox. The goal of defining hardware accessories is achieved by specifying components that are commonly needed in projects based on the Raspberry Pi. This includes USB dongles for Wifi, keyboards and mice. Specifications for battery power are left to individual projects extending the PiBox Development Platform. To achieve these goals PiBox provides an easy to use build system that wraps other build systems such as the Linux Kernel and Busybox/Buildroot. The PiBox build system provides common target naming simplifying editing configurations, building, re-building after changes and packaging. A common skeleton is provided that is easy to modify and allows extending the base platform for specific applications. Finally, the build system will generate all the packages and supporting files needed to install the system to an SD card and boot the Raspberry Pi. This includes a staging tree that can be used to cross compile application-specific components into opkg-formatted packages. Specific Goals
Enough of the philosophy. Down to brass tacks. This is what PiBox supports now.
Power-up time is subjective based on the start and end points of the measurement. Assume start time is the time the kernel starts since a Raspberry Pi's firmware doesn't take more than a second to load the Linux kernel. The stop time is the point where the user can access the system, be that a login prompt, a graphical terminal or a consumer-grade user interface. 10-second power-up is possible with a modified init process but without applications, in other words, on the PiBox Development Platform only. System V Init is used initially but later migrated to application specific boot processes while systemd will be avoided due to its overhead and complexity (it solves problems that don't exist within the design goals of PiBox). The most complex PiBox system, the Media System, has a boot time of approximately 20 seconds, most of which is due to wifi configuration and starting of the X server. The user interface presents a launcher application which takes less than a second to start on Raspberry Pi 3's.
Easily accomplished with a USB dongle. Additionally, versions of the Pi (Zero W and Model 3) offer embedded wifi.
Most video display devices these days offer HDMI input and all Raspberry Pi's provide HDMI interfaces. PiBox does not utilize the DSI interface at this time but research into its use is ongoing.
Easily supported by the Raspberry Pi using upstream supported drivers in the Linux kernel and ALSA user space audio tools.
Direct control of PiBox is via keyboard and mouse, including the official Raspberry Pi touchscreens, but not via IR controllers. IR adds a level of complexity that is no longer needed in modern devices. Applications can utilize wifi or bluetooth networking for controlling user interfaces using smartphones and similar devices.
The default UI in the PiBox Development Platform is BlackBox, a very lightweight X window manager without desktop environment overhead. This serves as a simple interface for initial development of application environments. The Matchbox window manager is also included to support a stacked window environment suited to handheld and consumer devices. Matchbox is the default window manager in all current PiBox systems. The Build Software
The PiBox build software is the collection of software and tools that are used to generate PiBox systems. The PiBox build software consists of the following high level components.
The cross toolchain provides a compilation environment that can be used on a build system that is not the target platform. This means you can build the software on your desktop system but run it on the Rasberry Pi. The advantage to a cross toolchain is that the build host can be a much more powerful system - more memory, more CPU cores, faster disk I/O, etc. This speeds development time for both the PiBox Development Platform (or anything derived from it) as well as applications. The cross toolchain also includes debugging utilities that are packaged with opkg, a Debian-like package management system for embedded platforms. PiBox uses the Crosstool-NG package to create the cross toolchain. Boot loaders are required to get the board to properly find and start the Linux kernel as well as initiate various hardware components. The Raspberry Pi uses the GPU to perform boot loader operations and a binary blob is provided for this purpose. Additional boot loader capabilities may be added through the use of a second stage bootloader such as Das U-Boot if required. PiBox does not use a second state boot loader at this time. The Linux kernel is used to provide operating system services. The majority of hardware support in the Linux Kernel comes from the Raspberry Pi repositories on GitHub. This includes user space support for OpenGL. The initial ramdisk is a very small file system designed to be embedded in or loaded by the Linux kernel to provide early boot time processing before the real root file system can be accessed. PiBox uses the BusyBox package to generate an initial ramdisk, whose purpose is to setup the overlay and squashfs features required to access the real root file system. The root file system provides a core set of utilities, libraries and configuration files required to run a variety of applications. The root file system includes a minimalist set of GNU utilities to access hardware such as USB and the SD card, provide boot processing and additional components required in support of both Linux kernel configuration and higher level software configuration and control. PiBox uses the Buildroot package to create the root file system. X.org provides the graphical interface for a default desktop component, menus and window management. X.org is required to support many off-the-shelf applications that rely on widget sets such as GTK+ an Qt. However, accelerated graphics are handled through OpenGL until such time as a 2D hardware accelerated X.org driver becomes stable. OpenGL will provide a common interface to hardware accelerated graphics. Wayland is not targeted for support under PiBox because it has no added value for current use cases. Hardware accelerated video decoding for formats such as H.264 comes from the Broadcom BCM2835's GPU component. Kernel drivers and user space libraries allow for accelerated video playback of a variety of video formats. A custom network configuration tool, PiBox Network Config and the associated libpnc library, is included in the PiBox Development Platform, making it available to any system based on that system. The libpnc library is a simplified wrapper around Debian-style network configuration, wpa_supplicant, hostapd and various other configuration files. It allows easy configuration of a system that does not require speciailized ethernet or wifi settings. The PiBox Development Platform also provides the libpibox library with a collection of features such as touchscreen management, logging, Raspberry Pi config file parsing and editing, JSON reading and writing, and PiBox display abstraction. The PiBox Software Stack
For developers who wish to create systems based on PiBox, it helps to see what the software stack looks like. While some of this stack is represented by the previously discussed build system, must of this stack is found in the various PiBox based build systems.
The PiBox stack starts with a layer of 3rd party software at the OS layer, most of which comes from one GitHub repository or another. These provide basic support for the Raspberry Pi but could just as easily provide support for other hardware. It also provides the custom Linux distribution through the use of Buildroot and BusyBox, which provide a basic set of utilities. This layer, plus the pnc (PiBox Network Config) application and libpnc (which is generated as part of the pnc build), provide the PiBox Development Platform. Just above this layer are additional third party tools for networking. While these tools are included in the development platform their configuration varies on the use case for higher layer software. Above this are the configuration files for various components, from hardware support to networking to the UI to a stock web server (sans content). Again, these are stock configurations that are often updated the specific use cases. One of the most interesting of these is the custom mdev device handling, specifically with respect to USB devices which is really the only consumer-grade expansion bus available on the Raspberry Pi (SPI and i2c are more likely used by developers of third party hardware). The next layer contains two custom libraries, libpnc and libpibox, which are part of the development platform. The former is the network configuration library mentioned earlier. The latter provides a set of utility functions for applications such as touch screen support, debugging and Raspberry Pi bootloader configuration. At this point, everything higher in the stack is installed as a separate opkg package. A set of packages are used to customize the UI. The psplash package is a simple boot logo for miot, the overriding idea of My IoT which greets uses of any supported PiBox based system. The pmsui package provides a GTK+-based theme wrapping the Matchbox window stacked window manager. The stacked window manager implements one of the design intents for applications: only one application runs at a time and is the only application visible. This attempts (but doesn’t quite manage) to follow the principles found at suckless.org. The appmgr package is a daemon that handles starting and stopping apps under the X.org server. This app has no UI and it’s primary duty is to start and keep running the launcher as well as start apps requested by the launcher and manage them as children. The launcher is a package that displays icons for the available apps and handles app selection through either an input device or a touchscreen. The launcher is modeled after launchers available on smartphones or, more accurately, the Roku interface. The backbone of the software stack is piboxd, a daemon responsible for message passing between apps. Think of this as a really bad dbus implementation, but for the sake of trying to keep the suckless philosophy as much as possible. It also doesn’t handle network port proxy. It’s just a message passing interface. It also happens to handle performing actions that non-privileged apps cannot such as network configuration. All of these layers provide the services required for applications to do something useful under PiBox. The top layer in the above diagram shows the many apps created using these services, including a few dependent third party packages like the Raspberry Pi omxplayer. Together, these form the structures of the multiple PiBox systems: the media system, the kiosk, and IronMan home automation for example. And they show the potential for the many new systems that are possible. The stack will continue to grow for PiBox, providing services that are yet unrequested. But the goals will remain the same: keep them simple, keep them small and then tie them together. It’s the Unix way. And it still makes sense. New to embedded? This high level and not very detailed description is essentially the way any software platform is built. See the Android and Maemo stacks for comparison. Those are more detailed specifications, but since PiBox is not (yet) supplying an API for development there is little need for a more complex structure. Modularity
The system allows for adding external applications using the opkg format. This will allow for future integration of an application-specific App Store interface that allows users to add applications to their system, possibly through the use of external USB storage. The rules regarding use of apps are defined by PiBox application environments. The PiBox Development Platform does not define or implement any application use rules other than making available the opkg package management system. Data Storage
The PiBox Development Platform is not intended to be used to store content. USB connected storage may be added and is supported but user data storage is not part of the PiBox design. Configuration files that need to be saved between system power cycles are stored on the SD card in the mmcblk0p3 partition. Configuration files that are recreated on each boot are stored in a temporary file system in memory. Read/write use of the SD card is limited to allow it to survive for long periods without replacement. |
