Follow and star our public account for exciting content
Doing Linux system development mainly revolves around the root filesystem, as uboot and kernel are generally provided by the manufacturer, and the peripherals also have official drivers available for porting, making the development work relatively minimal. The most challenging aspect of building the root filesystem is ensuring version compatibility and completeness. This is because the root filesystem involves many requirements, libraries, source files, etc., along with version requirements, making it not easy.
The most troublesome libraries when constructing the root filesystem include OpenGL, Java, Qt, tslib, OpenVG, Python, SQLite, etc. Below, I will introduce several different construction methods, outlining the materials and tools, the process, and the output.
Yocto is a common tool for building root filesystems. Of course, uboot and kernel can also be built together, but most people only need the root filesystem. Many SoC manufacturers, such as NXP, have joined the Yocto project to produce Yocto versions of SDKs. This is not ideal as SoC users prefer each chip to have a separate SDK provided, which they can configure and compile. The materials and tools required for Yocto construction include a computer with high memory, frequency, and disk space, as well as an Ubuntu environment and repo, git environments, and a Yocto package provided by the SoC manufacturer. The process involves downloading, configuring the build, and compiling, which can take several hours depending on the computer's performance. The output includes a cross-compilation toolchain, binary uboot and kernel, and most importantly, the root filesystem containing various required libraries.
Buildroot is also a common method provided by SoC manufacturers for SDKs, such as Rockchip and STM32MP. Buildroot's configuration and compilation are relatively simple, and the process is not complicated, resembling the configuration and compilation process of the kernel. The compilation speed is also relatively fast; once you obtain the SDK from the vendor, compiling is not difficult.
Busybox is only used to build the root filesystem, but it only includes some basic components like shell and telnet. The compilation process is similar to compiling the kernel, starting with make menuconfig, then configuring and finally compiling. When constructing the root filesystem, I believe it is better to have more than less. Many people feel that flash resources are limited and not suitable for including so many libraries, but since you chose to use Linux, you should not approach it with an MCU mindset. If resources are truly constrained, you should use RTOS instead of considering Linux. Because missing one or two libraries can prevent applications from running, having to rebuild the root filesystem is very painful.
Additionally, porting Android is not as difficult as many imagine. Generally, SoCs that can run Android will have an official public SDK released. The difficulty with Android lies in deep customization and application development; the porting itself is easier than with Linux.
Comparison of Buildroot and Yocto
Comparison Content:
(1) Embedded Build System
The goal is to build a complete, customized embedded Linux system
Including root filesystem, toolchain, kernel, bootloader
(2) Starting from source code
(3) Using cross-compilation toolchain
(4) Very active maintenance and development engineering
(5) Widely used in the industry
(6) Documentation and training courses available
(7) Free software
Buildroot's General Principles
(1) Focus on simplification
(2) Easy to use, easy to understand, easy to extend
(3) Handle special cases through extension scripts rather than modifying Buildroot itself
(4) Use existing technologies/languages: kconfig, make (worth investing time to learn)
(5) Defaults to small
(6) Purpose-agnostic
(7) Open community, no vendor, bureaucratic/company management
Yocto's General Principles
(1) Supports major CPU architectures
OpenEmbedded: only qemu
Yocto Project: adds support for a small number of machines
(2) Only provides core methods, using layers to support more packages and machines
(3) Customer changes should be in a separate layer
(4) Multipurpose build system: as flexible as possible to handle more use cases
(5) Open community, but the project is overseen by the Yocto Project Advisory Board initiated by corporate sponsors
(6) OpenEmbedded is an independent community-driven project.
Buildroot Output
(1) Primarily root filesystem images
Also includes: toolchain, kernel image, bootloader, etc.
(2) Supports various formats: ext2/3/4, ubifs, iso9600, etc.
(3) No binary packages, no package management system
Some refer to it as a firmware generator
Updates through packages are not possible
Updating requires a complete system update, like Android
Partial updates are considered harmful
Yocto Output
(1) Builds distributions, the main output is a package feed
Package management system is optional
Loading and updating parts of the system is possible
(2) By installing some packages, it can also produce root filesystem images. Supports ext2/3/4, ubifs, iso9600, etc., and also supports VM images: vmdk, vdi, qcow2
(3) Ultimately, image classes or tools, wic can be used to build disk images
(4) When generating images, an SDK can also be generated to allow application developers to compile and test their applications (without integrating into the build). However, the SDK must match the image.
Buildroot Configuration
(1) Uses kconfig like the Linux kernel
(2) Simple {menu, x, n, g} configuration interface
(3) The entire configuration is saved in a file .config/defconfig
(4) Defines various aspects of the system: architecture, kernel version/kernel configuration, bootloader, user-space packages, etc.
(5) make menuconfig, make
(6) Build a generic system for different machines: handled separately
A tool can build defconfig from fragments
Feasible, but not super simple
Each machine builds completely independently
Yocto Configuration
(1) Configuration is divided into several parts:
Distribution configuration (package configuration, toolchain and libc selection...)
Machine Configuration (defines architecture, CPU features, BSP)
Image recipe (what packages to install on target)
Local configuration (distribution and default machine selection, how many threads to use during compilation, whether to delete build artifacts)
(2) Necessary to collect the layers to be used and declare them.
(3) Allows building the same image for different machines, or building different distributions or images for the same machine.
Buildroot Layers
(1) No concept of layers
(2) All packages are maintained in the official repository
(3) Add BR2_EXTERNAL
Allows storage of package definitions, configurations, and other manual files
A BR2_EXTERNAL
Typically used for proprietary/customized packages and configurations
Only adds packages, does not override packages in buildroot
Yocto Layers
(1) Layer mechanism allows modification and addition of new packages or images
(2) Clear separation between core build system, BSP, and custom modifications
(3) Third parties provide their layers for BSP or a method to handle specialized applications
(4) Layers need to be compatible and use the same OE branch base
(5) Be cautious of layer quality, checks are not systemic
(6) OpenEmbedded Metadata Index lists available layers, recipes, machines: http://layers.openembedded.org/layerindex/
(7) Additionally, there is a powerful override mechanism that can adjust recipe variables based on machine or distribution
Buildroot/Yocto Toolchain
Same functionalities:
(1) Build your own toolchain based on gcc, C libraries (glibc, uClibc, musl)
(2) Use external toolchain, easier for Buildroot as this feature is built-in, for Yocto, only fully supported in additional vendor layers.
Buildroot New Package
Involves three files: Config.in, xxx.mk, xxx.hash
Yocto New Package
Involves one file: xxx.bb
Buildroot: Complexity
(1) Designed for simplicity
(2) For core, each suggested feature is analyzed based on utility/complexity ratio
(3) Core logic is entirely written using make, with less than 1000 lines of code containing 230 lines of comments: indeed easy to understand what, why, how; almost as simple as a shell script that sequentially downloads, extracts, builds, and installs software.
(4) Documentation is very thorough, with many resources available
(5) An hour-long talk is enough to describe all internal implementations (ELCE 2014)
(6) Typical feedback on IRC: from Yocto, very surprised at how simple it is to use. This is the first thing that makes me difficult.
Yocto Project: Complexity
(1) There is a bit of a steep learning curve
(2) The core is bitbake, a separate project written in python (60k lines of code)
(3) A set of class definitions for common tasks
(4) Recipes use a bitbake-specific language, a mix of python and shell
(5) Logs and debugging help understand what each task does
(6) Detailed documentation, but there are many different configuration variables
(7) It is not always easy to understand best practices (for example, Poky cannot be used in production, distro/image modifications should not be done in local.conf, deleting tmp/)
(8) People still feel confused about some terms (Yocto Project, Poky, OpenEmbedded, bitbake)
Buildroot Packages
(1) 1800+ packages
(2) Graphics: X.org, Wayland, Qt4/Qt5, Gtk2/Gtk3, EFL
(3) Multimedia: Gstreamer 0.10/1.x, ffmpeg, Kodi, OpenGL
(4) Languages: Python2/3, PHP, Lua, Perl, Erlang, Mono, Ruby, Node.js
(5) Networking: Apache, Samba, Dovecot, Exim, CUPS, lots of servers/tools
(6) Init systems: Busybox (default), initsysv, systemd
(7) No support for a toolchain on the target
Yocto Project Packages
(1) Several thousand recipes: for oe-core, meta-openembedded, meta-qt5 about 2200. More than 8400 can be known through Metadata Index
(2) Most are similar to Buildroot
(3) More languages: Java, Go, Rust, Smalltalk
(4) There is still a working layer for Qt3
(5) meta-virtualization (Docker, KVM, LXC, Xen) and meta-openstack layers
Buildroot Dependency Method
(1) Minimal dependencies, if a feature can be turned off, it is off by default
(2) Many automatic dependencies, for example, if you enable OpenSSL, it will automatically gain SSL support from other enabled packages that can provide SSL support
(3) Default to effortlessly getting a small root filesystem
Yocto Project Dependency Method
(1) Package configuration at the distribution level
Enabling OpenSSL will turn it on for all packages, but can turn it off for some packages, conversely, can enable some features for selected packages.
(2) Can be modified at the machine level, but should be avoided
(3) Each recipe can define its own default feature set, with a robust default configuration.
Buildroot Updates/Security
(1) Releases every three months, two months of development, one month of stability
(2) Releases include package version updates: security updates and major updates
(3) Core architecture may also potentially change
(4) No LTS version, requires handling on your own
(5) A script is being provided to assess unresolved CVEs (Common Vulnerabilities & Exposures) in a given Buildroot configuration
Yocto Project Updates/Security
(1) Releases every six months, once in April, once in October
(2) Planning and roadmap can be understood through wiki: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status
(3) Contains four milestones in the three months between M1 and the final release
(4) At least the previous and current releases have designated maintainers who obtain security and important fixes, but no recipe updates
(5) Old versions are maintained by the community
Buildroot Detecting Configuration Changes
(1) Buildroot is not very intelligent
(2) When modifying configurations, it does not attempt to detect what needs to be rebuilt
(3) Once a package is built, Buildroot will not rebuild it unless forced
(4) Major configuration changes require a full rebuild
(5) Minor configuration changes may not require a full rebuild
(6) One configuration, one build; configurations cannot be shared
Yocto Project Detecting Configuration Changes
(1) Bitbake maintains a shared State Cache that allows incremental builds
(2) It detects task input modifications by creating checksums of inputs
(3) This cache can be shared across all builds, builds are faster for similar machines
(4) Can be shared across hosts, such as a nightly server and a development machine, greatly speeding up full builds
Buildroot: Architecture Support
(1) Supports many architectures
(2) ARM (64), MIPS, PowerPC (64), x86/x86-64
(3) Also supports many more specialized architectures: Xtensa, Blackfin, ARC, m68k, SPARC, Microblaze, NIOSII; ARM noMMU, especially ARMv7-M
(4) Architecture vendors provide assistance: MIPS from Imagination Technologies, PowerPC64 from IBM, ARC from Synopsys, Blackfin from Analog Devices
Yocto Project: Architecture Support
(1) In core, ARM, MIPS, PowerPC, X86, and their 64-bit series
(2) Separate layers: Microblaze, NIOSII
(3) Typically, chip manufacturers maintain their own BSP layer: meta-intel, meta-altera (ARM & NIOSII), meta-atmel, meta-fsl, meta-ti, meta-xilinx ...
(4) Community provides: meta-rockchip, meta-sunxi
Buildroot: Minimal Build
The minimal build takes 15 minutes and 25 seconds, image size 2.2MB
Yocto Project: Minimal Build
The minimal build takes 50 minutes and 47 seconds, image size 4.9MB. If there is an existing sstate-cache, it takes 1 minute and 21 seconds.
License
(1) Both can create a list of licenses used
(2) Both can detect license changes
(3) Yocto project can exclude GPLv3
Choosing Between Buildroot & Yocto
Buildroot
(1) Very specialized CPU architecture
(2) Very small rootfs < 8M
(3) Not much requirement on engineers
(4) Does not support various machines or similar systems
(5) No need for package/system updates
(6) Small systems
Yocto
(1) Not a very specialized CPU architecture, not a very small rootfs, requires experienced engineers.
(2) Not a very specialized CPU architecture, not a very small rootfs, requires experienced engineers. Supports several similar systems
(3) Not a very specialized CPU architecture, not a very small rootfs, requires experienced engineers. Requires package and partial system updates
(4) Not a very specialized CPU architecture, not a very small rootfs, requires experienced engineers. Very large systems
Copyright Statement: This article is sourced from the internet, freely conveying knowledge, and the copyright belongs to the original author. If there are copyright issues, please contact me for deletion.
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
Follow my WeChat public account, reply "Join Group" to join the technical exchange group according to the rules.
Click "Read the original" for more sharing, welcome to share, collect, like, and view.
