Meeting the players

Where does open source software come from? Who writes it? In particular, how does it relate to the key components of embedded development – the toolchain, bootloader, kernel, and basic utilities found in the root filesystem?

• Open source community: This, after all, is the engine that generates the software you are going to be using. The community is a loose alliance of developers many of whom are funded in some way by a non-profit organization, an academic institution, or a commercial company. They work together to further the aims of the various projects. There are many of them – some small, some large. Some that we will make use of are Linux itself, U-Boot, BusyBox, Buildroot, The Yocto Project, and the many projects under the GNU umbrella.
• CPU architects: These are the organizations that design the CPUs we use. The important ones here are Arm/Linaro (Arm Cortex-A), Intel (x86 and x86-64), SiFive (RISC-V), and IBM (PowerPC). They implement or at the very least influence support for the basic CPU architecture.
• SoC vendors: These include Broadcom, Intel, Microchip, NXP, Qualcomm, TI, and many others. They take the kernel and toolchain from the CPU architects and modify them to support their chips. They also create reference boards: designs that are used by the next level down to create development boards and working products.
• Board vendors and OEMs: These people take the reference designs from SoC vendors and build them into specific products like set-top boxes or cameras. They also create more general-purpose development boards such as those from Advantech and Kontron. An important category is the cheap Single-Board Computers (SBCs) such as BeagleBoard and Raspberry Pi, which have created their own ecosystems of software and hardware add-ons.
• Commercial Linux vendors: Companies such as Siemens, Timesys, and Wind River offer commercial Linux distributions that have undergone strict regulatory verification and validation across multiple industries (medical, automotive, aerospace, and so on).

These form a chain, with your project usually at the end, which means that you do not have a free choice of components. You cannot simply take the latest kernel from kernel.org, except in rare cases, because it does not have support for the chip or board that you are using.

This is an ongoing problem with embedded development. Ideally, the developers at each link in the chain would push their changes upstream but they don’t. Developers are under constant time pressure and getting patches accepted into the Linux kernel takes major effort. It is not uncommon to find a kernel that has many thousands of patches that are not merged. In addition, SoC vendors tend to actively develop open source components only for their latest chips, meaning that support for any chip more than a couple of years old will be frozen and not receive any updates.

The consequence is that most embedded designs are based on old versions of software. They do not receive security fixes, performance enhancements, or features that are in newer versions. Problems such as Heartbleed (a bug in the OpenSSL library) and Shellshock (a bug in the Bash shell) go unfixed.

What can you do about it? First, ask questions of your vendors (NXP, TI, and Xilinx to name just a few): what is their update policy, how often do they revise kernel versions, what is the current kernel version, what was the one before that, and what is their policy for merging changes upstream? Some vendors are making great strides in this direction. You should prefer their chips.

Secondly, you can take steps to make yourself more self-sufficient. The chapters in Part 1 explain the dependencies in more detail and show you where you can help yourself. Don’t just take the package offered to you by the SoC or board vendor and use it blindly without considering the alternatives.