The inevitable YOCTO
When dealing with customizing embedded solutions, Yocto is the one word that simply cannot be ignored. In this article we aim to explain what the Yocto Project does, why it’s needed, and how it can be applied when working with an FPGA/ARM platform such as the Xilinx Zynq.
What is YOCTO
“It’s not an embedded Linux distribution – it creates a custom one for you”
The Yocto Project is an open platform that provides templates, tools and methods to help in making custom Linux based systems for embedded products. It combines BitBake and OpenEmbedded to create specialized Linux distributions. Using the Yocto tools, the process of setting up a Board Support Package (BSP) gets tidier and more modular than attempting to keep track of the large amounts of third party source code manually. This process used to be different for each hardware platform, while Yocto aims to be a generic, supplier independent solution.
A modular approach
Yocto splits large software modules into layers, such as distro, BSP and software layers. Hardware manufacturers typically provide a BSP layer for their products, complete with drivers and kernel configuration. The embedded specialist then adds a custom layer that inherits the hardware layer, adding and removing components to fit the end product. User level software is kept in one or several separate layers. If the developers do a good job separating the layers, they behave like building blocks, and can be switched on and off depending on hardware, customer requirements and version varieties. Due to this modularization, the Linux kernel and software can be kept up to date through the product life-cycle without depending on the hardware manufacturer.
Yocto can fetch, build, configure and install all software used on an embedded product, such as the kernel, bootloader, root file system, driver modules and device trees. It uses recipes to describe how these steps are performed. Recipes can be inherited from other layers and appended. A layer can contain configurations for several different hardware platforms, separated into “machines”. Machine configurations are part of a BSP layer that are board-specific. Typically, bootloader, Linux kernel configuration, device trees and boot parameters must be customized to fit the targeted board. Machine configurations can set build variables and select non-default recipes to be used for building e.g. the Linux kernel, to customize the resulting product. Which machine to build for is chosen before the build process is initiated.
Living with licenses
When using open source software, developers are often faced with the trouble of keeping track of licenses. Accidental use of the wrong license can lead to costly trials and trouble. Each Yocto recipe has to specify which license the software shall use, and the build process fails should the recipe apply open source code within a closed software module. Yocto keeps track of all licenses, not only during development, but throughout the products life-cycle.
Fetching and branching
Being developed simultaneously by several different parties, the different flavors of Yocto and subsequent layers have to be split into branches in Git. Most BSP layers will only work with OpenEmbedded-Core of the same branch. Xilinx, for instance, uses the Dora or Daisy branches, while other suppliers have their own branches. Fetching the correct branch for all components and keeping track of which branches will work together is a part of the Yocto based development process.
Yocto Linux and the Xilinx Zynq platform
Xilinx is one of many vendor companies that provide a Yocto layer targeting their products. The meta-xilinx layer adds on top poky and open-embedded meta layers to provide Yocto support for Xilinx’ Zynq and Microblaze architectures, along with machine configurations for some of their development boards. Once you have made Bitbake aware of your layers you can target different Xilinx boards by simply setting a variable in your local configuration file which tells Yocto which machine configuration to use.
Device trees are used to provide the Linux kernel with information on the hardware it is running on. It is a convenient way to use the same kernel on slightly different hardware configurations. For the Zynq platform the standard kernel is compiled with drivers for all of th PS/SoC peripherals, common board components and some drivers for Xilinx FPGA IPs. The device tree will make the kernel aware of which components are present and how they are configured so that drivers are loaded and initialized correctly. Also board components can be described. Be describing the topology of i2c buses, including switches and node addresses, Linux will be able to reach and configure each node in the i2c network (provided the drivers are compiled in the kernel).
When the time comes to deviate from the standard configurations and recipes provided by a vendor you create your own Yocto layer on top of your vendors’. You then inherit all of their functionality but you are free to add your own customizations. In this layer you typically maintain your custom device trees, kernel configurations, patches, drivers, machine configurations etc. This approach makes it easy to maintain your BSP layer and transition from a vendors’ evaluation board to your custom built board.
Yocto and Data Respons
Data Respons has seen that their early adoption of Yocto is bearing fruits, as an increasing number of hardware manufacturers drop their own tools for the Yocto Project. Having a deeper understanding of the many parameters and branches of the platform has proven essential to keep up with the rising demands for high product to market speeds. Specialists at Data Respons are currently also working to set up a full configuration management system, version tracking each component from top to toe in Linux based embedded systems.
Getting a full overview of all the parameters and possibilities in Yocto is a daunting task, but once it is done, it can be applied to a large number of other hardware platforms.