Purpose-Built Wind River Linux Distribution
Create and Customize Your Linux
As processing power increases each year, so does the number of embedded devices. According to a 2022 forecast from The Brainy Insights, the global embedded systems market is expected to grow at a compound annual growth rate of 5.7% by 2028.
Although some applications require a real-time operating system, using an RTOS comes with several challenges, including cost of development, time-to-market, memory management, security, hardware compatibility, and compliance.
Wind River® Linux, an open source, embedded Linux development platform, provides a supported solution that addresses many of these difficulties while greatly accelerating time-to-market. As a leading contributor to the Yocto Project and other open source communities, Wind River has helped customers deliver embedded solutions across a variety of industries and applications (aerospace and defense, automotive, industrial, medical, telecom) for more than 40 years. And it does this by providing designers with a toolset to create their own purpose-built Linux systems.
The Wind River Linux Binary Distribution
Previously, Wind River Linux was only available in a source-based distribution builder (known as Wind River Linux) that allows embedded developers to build an entire Linux operating system from source for complete customizability. While powerful, that approach has a high learning curve and may not be best choice for development of all embedded solutions. In contrast, the Wind River Linux binary distribution (Wind River Linux Distro) can be used to create and customize your own Linux image in just a few minutes.
OSTree Benefits and Purpose
OSTree performs atomic upgrades of complete file system trees (such as Git). It can do so with incremental updates, rollback, deterministic updates, complete image replacement, and with or without an A/B partition scheme. This makes it well suited for CI/CD. Figure 2 shows a disk view of OSTree updates.
Micro-start images (ustart.img) are used in the distribution process. The default image includes a compressed version of an installer as well as initramfs, boot loader, kernel, and an OSTree repository; a custom image would just have the boot loader and a network connection to bring over everything else. This process provides a flexible install with fresh file systems and the ability to factory-reset corrupt devices to their original install state. And if a user were to rebuild the binary distribution, they could install directly from a network (and use a network for PXE/Net UEFI/U-Boot) as well as alternate disk layouts (use A/B partitions, add additional partitions, and encrypt rootfs and data using a TPM stored key).
When you customize your image, /etc and /var are persistent by default unless a factory reset or factory upgrade is performed, but a user can use ostree admin unlock to temporarily unlock. And, by default, ustart.img does not enable a console, but this can easily be enabled.
While the initial image lies within Docker Hub, the binary distribution container base (which is roughly 36 MB compressed) contains a package manager and is built from the exact same package feed as the released OS. There’s also an option for a smaller reference (only 5 MB), but you must build from source Wind River Linux distribution and select the OPKG Package Manager to build the container base.
The Linux Assembly Tool and a Lego Brick Analogy
The LAT can be used to perform a number of tasks to help manage images, build and publish RPM packages (from any files, including third-party content), generate images from feeds for specific hardware, create customized initramfs boot loaders and custom deployment actions, and generate updated SDKs.
Think of LAT as a set of plastic toy construction blocks, like Legos. But instead of building toys, you’re assembling software into an embedded solution. The build system creates “bricks,” or apps/libs/packages, which provide each of the Lego pieces (artifacts). Building an RPM may consist of starting with external content or materials (such as glue, plastic, etc.) and then using the LAT genrpm (3-D printer, in this case) to produce custom packages (or Lego bricks, in this analogy). Building a boot loader (appsdk geninitramfs) would essentially build the floor or foundation for these bricks. And while building the containers (appsdk gencontainer) creates rooms or houses on top of this foundation, building the SDK (appsdk gensdk) packages everything up into a kit — sort of like a prepackaged Lego kit.
