4 Tools for building embedded Linux systems-turn

Transferred from: 4 Tools for building embedded Linux systems

Linux was deployed to a wider range of devices than Linus Torvalds in his dorm. The shocking support for a variety of chips allows Linux to be used on large and small devices: from IBM's jumbo machines to tiny devices that are not as large as the ports they connect to, and devices of all sizes. It is used in large enterprise data centers, Internet infrastructure equipment and personal development systems. It also provides power for consumer electronics, mobile phones and many IoT devices.

When building Linux software for desktops and enterprise-class devices, developers often use desktop distributions on their build machines, such as Ubuntu, to be as similar to the deployed machine as possible. Tools such as VirtualBox and Docker make development, testing, and production environments better aligned.

What is an embedded system?

Wikipedia defines an embedded system as: "Computer systems with special functions in larger mechanical or electrical systems are often accompanied by real-time computational limitations." ”

I think it's easy to say that embedded systems are computers that most people don't think are computers. Its main function is to be a device, not considered a general-purpose computing platform.

The development environment for embedded system programming is often very different from the test and production environment. They may use different chip architectures, software stacks, or even operating systems. Development workflows are very different for embedded developers than for desktop and WEB developers. Typically, its built-in output will contain the entire software image of the target device, including the kernel, device drivers, libraries, and application software (and sometimes boot loader).

In this article, I'll take a glance at four common ways to build embedded Linux systems. I'll explain how each product works and provide enough information to help the reader determine which tool to use for the design. I'm not going to teach you how to use any of them; once you've narrowed down your selection, there's plenty of in-depth online learning resources. There is no choice for all situations, and I would like to provide enough detail to guide your decision.

1. Yocto

The Yocto project is defined as an open source collaboration project that provides templates, tools, and methods to help you create customized Linux-based systems for embedded products, regardless of the hardware architecture. "It is a collection of recipes, configuration values, and dependencies for creating custom Linux runtime images that can be tailored to your specific needs."

Full disclosure: Most of my work on embedded Linux is focused on the Yocto project, and my understanding and prejudice to the system may be obvious.

Yocto uses openembedded as its building system. Technically, these two are independent projects; However, in practice, users do not need to know the difference, and project names are often used interchangeably.

The output of the Yocto project is broadly composed of three parts:

• Target runtime binaries: These include boot loader, kernel, kernel module, root file system image. and any other auxiliary files required to deploy Linux to the target platform.
• For: This is a collection of packages that can be installed on the target. You can choose the package format (for example, Deb, RPM, IPK) as needed. Some of these may be pre-installed in the target runtime binaries, but you can build packages for installation to deployed systems.
• Target SDK: These are the collections of libraries and header files for the software installed on the target platform. Application developers use them when building code to ensure that they are linked to the appropriate libraries

Advantages

The Yocto project has been widely used in the industry and has been supported by many influential companies. In addition, it has a large and vibrant developer community and ecosystem. The combination of open source enthusiasts and corporate sponsors helps drive the Yocto project.

There are many options to get Yocto support. If you want to do it yourself, there are books and other training materials. If you want to gain expertise, there are many engineers with Yocto experience. And many business organizations can provide Yocto-based Turnkey products or service-based implementations and customizations for your designs.

The Yocto project can easily be extended through layers, and the layer may be published independently to add additional functionality, or a platform that is not available for project publishing, or for saving system-specific custom functionality. Layers can be added to your configuration to add unique features that are not specifically included in the market version, for example, the "Meta-browser" layer contains a list of Web browsers that can be easily built for your system. Because they are maintained independently, tiers can be released at different times (depending on the development speed of the layer), rather than in the standard Yocto release.

Yocto can be said to be the broadest device support in any of the ways discussed in this article. Thanks to the support of many semiconductor and board manufacturers, Yocto is likely to be able to support any target platform you choose. The main version of the Yocto branch supports only a few boards (to achieve a reasonable test and release cycle), but the standard operating mode is to use an external motherboard support layer.

Finally, Yocto is very flexible and customizable. Customizations to your particular application can be stored in a layer for encapsulation and isolation, typically storing feature-layer customizations as part of the layer itself, which can apply the same settings to multiple system configurations at the same time. Yocto also provides a well-defined layer precedence and coverage feature. This allows you to define the order in which the layers apply and search for metadata. It also allows you to override the settings for layers with higher priority, for example, many of the custom features of an existing manifest are preserved.

Disadvantages

The biggest drawback of the Yocto project is the steep learning curve. Learning the system and really understanding the system takes a lot of time and effort. Depending on your needs, this may be too much to invest in technology and capabilities that are not important to your application. In this case, working with a commercial supplier can be a good choice.

The development time and resources of the Yocto project are quite high. There are quite a few packages that need to be built, including the toolchain, the kernel, and all target runtime components. Development workstations for Yocto developers are often large systems. It is not recommended to use a small notebook computer. This can be mitigated by using a cloud-based build server provided by many providers. In addition, Yocto has a built-in caching mechanism that allows it to reuse previously built components when it determines that the parameters used to build a particular package do not change.

Suggestions

Using the Yocto project for your next embedded Linux design is a powerful choice. In the options described here, it is the most widely applicable regardless of your target use case. Extensive industry support, active community and extensive platform support make it a good choice for designers.

2. BuildRoot

The BuildRoot project is defined as "a simple, efficient and easy-to-use tool for building embedded Linux systems through cross-compilation." "It has many of the same goals as the Yocto project, but it focuses on simplicity and simplicity. In general, BuildRoot disables all optional compile-time settings for all packages (with some notable exceptions), resulting in a system that is as small as possible. System designers need to enable the settings that apply to a given device.

BuildRoot builds all components from source code, but does not support managed by target packages. Therefore, it is sometimes called a firmware generator, because the image is mostly fixed at build time. The application can update the target file system, but there is no mechanism to install the new package into the running system.

The BuildRoot output consists mainly of three parts:

• The root file system image and any other auxiliary files required to deploy Linux to the target platform
• Cores for target hardware, boot loader and kernel modules
• Tool chain used to build all the target binaries.

Advantages

BuildRoot's focus on simplicity means that, in general, it is easier to learn than Yocto. The core build system is written with make and is short enough for developers to understand the entire system, while scaling to meet the needs of embedded Linux developers. The BuildRoot core typically handles only common use cases, but it can be extended through scripting.

The BuildRoot system is configured using common Makefile and Kconfig languages. Kconfig is developed by the Linux kernel community and is widely used in open source projects, making it familiar to many developers.

Due to disabling design targets for all optional build-time settings, buildroot typically generates the smallest possible image with an out-of-the-box configuration. In general, build time and build host resources will be smaller than the size of the Yocto project.

Disadvantages

The focus on simplicity and the minimization of enabled builds means that you may need to perform a number of customizations to configure the BuildRoot build for your application. In addition, all configuration options are stored in a single file, which means that if you have multiple hardware platforms, you need to make each custom change for each platform.

Any changes to the system configuration file will require all of the packages to be rebuilt. Compared to Yocto, this problem is solved by the smallest image size and build time, but may cause the build time to be too long when you adjust the configuration.

The intermediate package state cache is not enabled by default and is not as thorough as the Yocto implementation. This means that although the first build may be shorter than the equivalent Yocto build, subsequent builds may require rebuilding many components.

Suggestions

For most applications, using BuildRoot for the next embedded Linux design is a good choice. If your design requires multiple hardware types or other differences, but due to the complexity of synchronizing multiple configurations, you may need to reconsider, but for a system consisting of a single setup, BuildRoot may be right for you.

3. Openwrt/lede

The OpenWRT project began developing custom firmware for consumer routers. Many of the low-cost routers offered by your local retailer can run Linux systems, but may not be available out of the box. The manufacturers of these routers may not be able to provide frequent updates to address new threats, and even if they do, it is difficult and error-prone to install a mechanism for updating mirroring. The OpenWRT project generates updated firmware images for many devices that have been discarded by their manufacturers, enabling these devices to rejuvenate.

The main deliverables of the OpenWRT project are binary images that can be used for a large number of commercial devices. It has a network-accessible package repository that allows device end users to add new software to their systems. The OpenWRT build system is a generic build system that allows developers to create custom versions to meet their own needs and add new packages, but their primary focus is on target binaries.

Advantages

If you are looking for a replacement firmware for a commercial device, the OpenWRT should be in your list of options. It is well maintained and can protect you from issues that cannot be resolved by the manufacturer's firmware. You can also add additional features to make your device more useful.

If your embedded design is focused on the web, OpenWRT is a good choice. The Web application is the primary use case for OpenWRT, and you may find many available packages.

Disadvantages

OpenWRT has a lot of limitations on your design (compared to Yocto and BuildRoot). If these decisions do not meet your design goals, you may need to make a lot of changes.

Allowing package-based updates to be allowed on deployed devices is difficult to manage. By definition, this results in a different software load than your QA team tests. In addition, it is difficult to ensure that most of the Package manager's atomic installation, as well as the wrong power cycle, may leave your device in an unpredictable state.

Suggestions

OpenWRT is a good choice for hobbyist projects or commercial hardware reuse. It is also a good choice for Web applications. If you need to make a lot of customizations from the default settings, you might prefer BuildRoot or Yocto.

4. Desktop distribution

A common way to design an embedded Linux system is to start with a desktop release, such as Debian or Red Hat, and remove unwanted components until the installed image meets the footprint of the target device. This is a popular Raspbian distribution method for the Raspberry Pi platform.

Advantages

The main advantage of this approach is familiarity. In general, embedded Linux developers are also desktop Linux users and are proficient in their choice distributions. Using a similar environment on the target may allow developers to get started faster. Depending on the distribution selected, many other tools can be installed using standard packaging tools such as apt and Yum.

You can connect the monitor and keyboard to the target device and do all the development directly there. For developers unfamiliar with embedded space, this could be a more familiar environment, without the need to configure and use tricky cross-development platform settings.

The number of packages available for most desktop distributions is typically greater than the number of available packages for embedded-specific builders discussed earlier. Because of the larger user base and the wider use case, you may be able to find all the run-time packages required by your application that are already built and ready for use.

Disadvantages

It may be slow to target the platform as your primary development environment. Running the compiler tool is a resource-intensive operation, depending on how much code you build, which can seriously hinder your performance.

In addition to some exceptions, desktop distributions are not designed for low-resource systems and may be difficult to fully crop the target image. Similarly, a preset workflow in a desktop environment is not ideal for most embedded designs. It is difficult to obtain a reproducible environment in this way. Adding and removing packages manually is error-prone. This can be scripted using a release-specific tool, such as a debootstrap based on a Debian system. To further improve reproducibility, you can use configuration management tools such as CFEngine (my employer Mender.io complete disclosure of this tool). However, you are still under the control of the distribution provider, and they will update the packages to meet their needs, not your needs.

Suggestions

Use this method with caution for products that you intend to market. This is a good model for enthusiast applications, but this approach is likely to be problematic for products that need support. While you may be able to get started faster, in the long run, you may spend your time and effort.

Other considerations

This discussion focuses on the functionality of the build system, but often there are non-functional requirements that may affect your decision. If you have selected an on-chip system (SoC) or board, your choice is likely to be determined by the vendor. If your vendor provides a board support package (BSP) for a particular system, it typically saves a considerable amount of time, but study the quality of the BSP to avoid problems later in the development cycle.

If your budget allows, you may want to consider using a commercial vendor for the target operating system. Some companies offer proven and supported configurations for many of the options discussed here, and unless you have expertise in embedded Linux build systems, this is a good choice to focus on your core competencies.

As an alternative, you might consider doing business training for your developers. This may be cheaper than a commercial operating system vendor and can make you more self-sufficient. This is a learning curve that quickly finds the basics of building systems you choose.

Finally, you may already have some experience with one or more systems. If your engineers are biased, when you make a decision, it's definitely worth considering.

Summarize

There are many options for building embedded Linux systems, each with advantages and disadvantages. It is important to prioritize this part of the design because the cost of switching the system is very high in the later process. In addition to these options, there are new systems in development. Hopefully this discussion will provide some background for evaluating the new system (and the systems mentioned here) and help you make a solid decision for the next project.

Via:https://opensource.com/article/18/6/embedded-linux-build-tools

Drew Moseley topic: lujun9972 Translator: Lhrchina proofreading: Wxy

4 Tools for building embedded Linux systems-turn