Building Qt with Buildroot for Linux and Development Boards

# 1 | Building Qt with Buildroot for the File System

[1] Unzip the file

kali@ubuntu:~/Desktop/Buildroot$ tar zxvf buildroot-2024.02.tar.gz

# 1.1 | Configure Buildroot

Enter the buildroot-2024.04 directory. Enter the command below to install the libraries needed for the graphical menu. If already installed, no need to install again.

sudo apt-get install libncurses5-dev

Open the configuration menu, enter the command below, as shown in the figure.

kali@ubuntu:~/Desktop/Buildroot$ cd buildroot-2024.02/
kali@ubuntu:~/Desktop/Buildroot/buildroot-2024.02$ make menuconfig

The main event begins

# 1.2 | Configure Target options

First configure the Target options option, the items to configure and their corresponding content are as follows (the content to select follows the “=” sign!):

[1] Select Target options

[2] Select Target Architecture ARM (little endian)

ARM architecture is a widely used processor architecture in mobile devices, embedded systems, and various fields including embedded Linux. In ARM architecture, there are two byte orders, little endian and big endian. These two byte orders determine the arrangement of data in memory.

In little endian, the low-order byte of data is stored at the starting address, and the high-order byte is stored at the ending address. For example, for a four-byte data <span>0x04030201</span>, in little endian, it will be stored in memory as follows:

Address: 0x00  0x01  0x02  0x03
Data:   01    02    03    04

In big endian, the high-order byte of data is stored at the starting address, and the low-order byte is stored at the ending address. The same four-byte data <span>0x04030201</span> will be stored in memory as follows in big endian:

Address: 0x00  0x01  0x02  0x03
Data:   04    03    02    01
Little endian memory: low to low, high to high; big endian memory: high to low, low to high

[3] Target Binary Format (ELF)

The target binary format (ELF) is a standard file format used for executable files, object files, shared libraries, and kernel images. The ELF format was originally introduced by the System V distribution and is now widely used in many operating systems, especially Unix-like systems including Linux, FreeBSD, Solaris, etc.

The ELF format includes the following important parts:

• File Header: Contains information about the file itself, such as file type (executable, object file, or shared library), target architecture, entry point address, etc.

• Program Header Table: Only appears in executable files and shared libraries, describing the segment information of the program at runtime, how it is laid out and loaded in memory.

• Section Header Table: Describes information about different types of sections, such as code sections, data sections, symbol tables, relocation tables, etc.

• Data Sections: Includes actual data such as program code, data, symbol tables, relocation tables, etc.

[4] Target Architecture Variant (cortex-A7)

The target architecture variant refers to a specific implementation of a computer architecture for a particular variant. In this case, “cortex-A7” is a specific variant in the ARM architecture developed by ARM for embedded systems and mobile devices.

The ARM Cortex-A7 processor is a low-power, high-performance processor core launched by ARM, commonly used in smartphones, tablets, embedded systems, Internet of Things devices, etc. The Cortex-A7 is based on the ARMv7 architecture and is a variant in the ARM Cortex-A series focusing on low power consumption and high efficiency design.

Features of the Cortex-A7 processor core include:

1. Low-power design: The Cortex-A7 employs a series of techniques and mechanisms to reduce power consumption and improve energy efficiency. This makes it widely used in mobile devices and embedded systems.

2. High performance: Despite being a low-power design, the Cortex-A7 still provides considerable computational performance, making it capable of handling many light to moderate load scenarios.

3. Multi-core design: The Cortex-A7 can be configured as multi-core, allowing system designers to flexibly expand processing power in scenarios requiring higher performance.

[5] Target ABI (EABIhf)

The target ABI (Application Binary Interface) refers to the specification for the interaction of applications with the operating system or hardware on a specific platform. EABI (Embedded Application Binary Interface) is a standard that specifies the application binary interface for embedded systems.

In EABI, “hf” indicates the hard float instruction set. This ABI can be used for ARM architecture processors, particularly for ARM Cortex-A class processors (e.g., ARMv7-A, ARMv8-A).

EABIhf (Embedded Application Binary Interface Hard Float) specifies how to use the hardware floating point unit (FPU) on ARM processors. In systems using EABIhf, rules regarding function calling conventions, data alignment, stack layout, etc., are closely related to the hardware floating point capabilities of ARM processors. This allows developers to take full advantage of hardware floating point calculations, thereby improving program performance.

In systems using EABIhf, compatible compilers, linkers, and standard libraries must be used to ensure that the generated code adheres to the EABIhf specification and interacts correctly with other parts of the system.

[6]Floating point strategy (NEON/VFPv4)

The floating point strategy usually specifies the optimization strategy for using floating point operations on a specific architecture. In ARM architecture, NEON and VFPv4 are instruction sets used for floating point operations, representing different optimization strategies for floating point operations.

• NEON: NEON technology is a low-power, high-performance SIMD (Single Instruction Multiple Data) instruction set extension provided by ARM processors. It aims to improve the performance of digital signal processing (DSP) and media processing on embedded systems. The NEON instruction set supports parallel operations, allowing multiple data to be processed simultaneously. Therefore, when the compiler uses the NEON instruction set for floating point operations, it can leverage the SIMD characteristics to process multiple data in parallel, thus improving the speed and efficiency of floating point computations.

• VFPv4: VFP (Vector Floating Point) is a floating point processing unit that supports single precision and double precision floating point operations. VFPv4 is a version of the floating point processing extension supported on ARM processors. It provides high performance floating point capabilities and supports hardware floating point calculations. Compared to NEON, VFPv4 focuses more on single precision and double precision floating point operations, typically used for general floating point calculations. VFPv4 provides a rich set of floating point instructions to support many common floating point calculation operations.

When selecting a floating point strategy, developers can choose the appropriate instruction set based on the characteristics and performance requirements of the application. NEON is more suitable for compute-intensive tasks that require parallel processing of multiple data, while VFPv4 is more suitable for general single precision and double precision floating point operations.

[7]ARM instruction set (ARM)

The ARM instruction set is a set of instructions supported by ARM architecture processors, defining all basic operations that the processor can understand and execute. The ARM instruction set clearly defines the encoding, format, operation types, and execution behavior of instructions, including data processing instructions, load/store instructions, branch instructions, etc.

Features of the ARM instruction set include:

1. Reduced instruction set: The ARM architecture was originally designed for embedded systems, so its instruction set is designed to be simplified to save processor resources and improve efficiency. This allows ARM processors to execute efficiently in resource-limited environments.

2. Diverse data processing instructions: The ARM instruction set includes a rich set of data processing instructions covering integer operations, multiplication operations, logical operations, and bit manipulation to support various types of data processing needs.

3. Load/store instructions: Since ARM processors adopt a Load/Store architecture, all data processing needs to be done by loading to registers first, so load/store instructions occupy an important position in the ARM instruction set.

4. Conditional execution instructions: The ARM instruction set allows conditional judgment based on condition codes during instruction execution, enabling execution or skipping of instructions based on specific conditions, enhancing the flexibility of program execution.

5. Thumb mode: In addition to the traditional ARM instruction set, ARM processors also support the Thumb instruction set, which is a more compact instruction set designed to improve code density and reduce power consumption, suitable for embedded systems and mobile devices.

The configuration completion diagram is as follows:

# 1.3 | Configure Cross Compilation Toolchain

This article does not use the cross-compiler from the Linux driver guide; it doesn’t matter if the kernel uboot uses a different compiler than the root filesystem, so to simplify things, we can just use the ARM compiler from Buildroot, which also reduces the chance of errors. For the options below, we just need to check them.

With the tutorial above, I will do it all at once.

Configure the Toolchain option, the items to configure and their corresponding content are as follows (the content to select follows the “=” sign!): If there are no options, just ignore them.

Toolchain-> Toolchain type (Buildroot toolchain) = Buildroot toolchain-> GCC compiler Version (gcc 9.x)= gcc 9.x-> [*] Enable toolchain locale/i18n support-> [*] Enable C++ support-> [*] Enable MMU support (NEW)

“Toolchain” typically refers to a set of tools and libraries used to build software, including compilers, libraries, debuggers, etc. In this case, the mentioned “Buildroot toolchain” is a specific type of toolchain used to build software in embedded systems.

GCC is a widely used compiler collection for compiling programs in C, C++, and other languages. Version 9.x refers to a specific version of the GCC compiler.

Enabling toolchain locale support (i18n support) allows software to correctly display localized text and language under different regional settings.

Enabling C++ support allows the compiler to compile and execute C++ programs.

MMU support (Memory Management Unit memory protection) allows the operating system to isolate and protect different memory areas through hardware mechanisms, improving system security and stability. This is a specific improvement for embedded systems, allowing them to manage memory more effectively.

# 1.4 | Configure Qt Compilation Options

Configure Qt options, the options configured here include Qt’s gui module, Qt sql module, QtChart module, Quick module, Qt virtual keyboard, and Qt touch plugin Tslib. As seen, third-party libraries like the tslib plugin can be easily configured in Buildroot, so we don’t have to transplant third-party libraries one by one. To reduce compilation time, we will configure as follows, which is sufficient for some daily applications. If you need to support more module features, you can select them yourself.

Target packages->->Graphic libraries and applications (graphic/text) --->> [*] Qt5 ->->[*] Compile and install examples (with code)->[*] MySQL Plugin->SQLite 3 support (Qt SQLite)= Qt SQLite->   widgets module->   GIF support->   qt5charts[*]  Enable Tslib support[*]  qt5quickcontrol[*]  qt5quickcontrols2[*]  qt5virtualkeyboard

In the target software packages, you selected Qt5, which is a popular C++ cross-platform application development framework. Here are some features you enabled:

• Compile and install examples (with code): This will allow you to compile and install example programs and their corresponding source code along with installing Qt5, which can help you better understand how to use Qt5 to develop applications.

• MySQL Plugin: This option will include support plugins for the MySQL database, allowing Qt5 to interact with the MySQL database.

• Qt SQLite: This enables Qt5 support for SQLite 3 databases, allowing you to interact with SQLite databases using Qt5.

• Widgets module: This will include the Widgets module of Qt5, allowing you to use Qt5 UI components to build graphical user interfaces.

• GIF support: This will add support for GIF image format to Qt5, allowing you to use GIF images in your applications.

• qt5charts: This is a module of Qt5 that provides functionality to create and display charts, allowing you to integrate charts and statistical data displays in your applications.

• Enable Tslib support: Tslib is a touch screen processing library for embedded Linux systems, enabling this support allows Qt5 to integrate with Tslib, allowing your applications to interact with touch screen devices.

# 1.5 | Configure System Configuration

This option is used to set some system configurations, such as board name, welcome message, username, password, etc. The items to configure and their corresponding content are as follows:

System configuration-> System hostname=atkbuildrootQtfs//Platform name, set yourself-> System banner = Welcome to alientek Qt rootfs //Welcome message-> Init system = BusyBox /∥Use busybox-> /dev management = Dynamic using devtmpfs + mdev /∥Use mdev->[*] Enable root login with password (NEW)/∥Enable login password-> Root password = root /∥Login password is root

In the System configuration option, you can configure platform names, login passwords, and other information. It can be seen that buildroot allows setting a login password, but as an experiment, it is not recommended to set a login password, otherwise every time the board restarts, you will need to enter a password, which is inconvenient for development. However, if you want to use ssh, setting a password is convenient for development.

BusyBox is a collection of open-source embedded Linux tools that consolidates many common Unix tools and commands into a single executable file, including the init system. Its lightweight and efficient nature makes it ideal for embedded systems and devices, especially in resource-limited environments. The BusyBox init system is responsible for starting the system and managing other processes and services in the system.

devtmpfs is a temporary filesystem that can dynamically create device nodes at system startup. Combined with mdev, it can dynamically create or delete device nodes when devices are inserted or removed. mdev is a lightweight device management tool that, when the kernel detects new devices, is responsible for creating corresponding device nodes in the /dev directory, and when devices are removed, it is also responsible for cleaning up the corresponding device nodes.

Using mdev and devtmpfs allows the system to manage device files and nodes more flexibly and efficiently.

# 1.6 | Configure Filesystem Images

This option configures what format the final root filesystem we produce will be, configured as follows:

Filesystem images->[*] ext2/3/4 root filesystem //If it is EMMC or SD card, use ->ext3/ext4->ext2/3/4 variant=ext4 //Choose ext4 format->exact size =1G /ext4 format root filesystem 1GB (modify according to actual situation)->[*] ubi image containing an ubifs root filesystem /∥If using NAND, use ubifs

It can be seen that buildroot can directly create an ext4 format root filesystem, but generally we will add many other files to the root filesystem, so after the product development is completed, we need to package the root filesystem ourselves and then burn it onto the development board. Whether it is for the ext4 format root filesystem for EMMC or for the NAND ubi format root filesystem, the corresponding size must be set, for example, here we set the ext4 format root filesystem size to 1GB.

ext4 is a widely used Linux filesystem. It is the latest version in the ext filesystem series and is one of the filesystem types supported by the Linux kernel by default. ext4 offers many improvements, making it one of the most commonly used filesystems in many Linux distributions.

Here are some of the main features of ext4:

1. Larger filesystems and files: ext4 supports a single filesystem size of up to 1EB (Exabyte) and a single file size of up to 16TB (Terabyte).

2. Faster file allocation and retrieval: ext4 introduces some techniques to improve the efficiency of file allocation and retrieval, including delayed allocation and multi-block allocation.

3. Faster filesystem checks: ext4 provides faster filesystem check times compared to its predecessor ext3.

4. Better data consistency: ext4 can better protect the data consistency of the filesystem in case of system crashes or power outages.

5. More robust logging system: ext4 introduces a more reliable logging system that can better protect the filesystem from data corruption.

In embedded systems, UBI stands for “Unsorted Block Image”. It is a layer used to manage flash memory devices, designed to simplify and enhance the use of flash memory. Flash memory is commonly stored in embedded devices and is used to save operating systems, data, and applications.

UBI allows the operating system to treat flash memory devices as a unified block device without needing to consider the details of the underlying flash chips. It provides block-level management of erasure, writing, and erasure counts, as well as handling bad blocks. UBI can also increase reliability on flash memory devices by adding error detection and correction codes to improve data stability and reliability.

# 2 | Configure and Build Buildroot Root Filesystem

# 2.1 | Configure Buildroot (script auto-configured, the above manual configuration, the following is for reference only)

In Ubuntu, edit to create a atk_imx6ull_qt_defconfig file, then copy it to the root directory of the Buildroot source code under configs.

kali@ubuntu:~/Desktop/Buildroot/buildroot-2024.02$ gedit atk_imx6ull_qt_defconfig

Enter make atk_stm32mp157_qt_defconfig to start configuration

make atk_stm32mp157_qt_defconfig

# 2.1 | Build Buildroot

Enter make -j 16 to build, time is used to calculate time.x parameter is based on personal Ubuntu configuration values.Or directly input make.

sudo make

Note: Each version must match, otherwise many errors will occur. If you encounter insufficient disk space, please resolve it yourself and repeat the above steps. [Disk space should preferably have several GB]

Build successful as shown in the figure. It paused once in between, taking about 80 minutes.

Enter ls output/images/ to check the generated root filesystem, as shown in the figure below.

# 3 | Test Buildroot Qt Root Filesystem

Burn the generated Buildroot Qt root filesystem to the development board for testing.

# 3.1 | Burn Buildroot Qt Root Filesystem

Replace the generated rootfs.tar into the TF card system boot card’s rootfs partition, first delete the rootfs root filesystem files and then unzip them. If you do not know how to create a TF card system boot card, please search online, or test the generated Buildroot root filesystem through methods like nfs mounting, etc., without elaborating on the burning filesystem part. You can see that the Qt library has been installed into the TF card system boot card.

You can see that the Qt library has been installed into the TF card system boot card.

# 3.2 | Test Buildroot Qt Root Filesystem Startup

Insert the TF card into the development board, set the switch to SD card boot mode, after the system starts, it is as follows. You can see that the startup is very fast, taking less time than the factory system, and the shorter startup time may mean fewer functions; everything has two sides. We see the prompt to enter the password to log in. The configured user is root, password is root. Enter root twice!

After logging in, it looks as follows

# 3.3 | Test whether tslib can touch normally

As with the Qt porting document, set the relevant environment variables for tslib, first test whether tslib can touch normally! Since the related libraries of tslib are in /usr/lib/ after compilation, we do not need to set its environment variables. We first enter the ts test command to test whether we can draw lines normally; being able to draw lines indicates touch capability, and no further configuration is needed. If it cannot touch, it may be due to the default event it points to being incorrect and needs adjustment.

After entering the command above, it was found that there was no need to configure the tslib environment variable, and touch could work normally. If you need to adjust the touch events, add the following content to the /etc/profile file.

# 3.4 | Configure Qt’s Runtime Environment Variables

Enable Qt runtime environment variables, so that next time you boot, you don’t have to source again; the environment variables in profile will run on boot.

source /etc/profile

# 3.5 | Test whether Qt can run normally

Earlier, when we configured Qt, we compiled some examples, which are built-in examples in Qt, into our filesystem. We can directly run the Qt examples in our Buildroot Qt root filesystem. The path of the compiled Qt examples is /usr/lib/qt/examples/. Therefore, we can directly execute the example programs inside. As shown, we randomly executed a program from the following path.

/usr/lib/qt/examples/widgets/animation/animatedtiles/animatedtiles

The running interface is as follows; clicking the button in the lower right corner also responds to touch. This indicates that Qt’s touch functionality is normal.

# 4 | Compile Qt Project

Use the cross-compilation toolchain in Buildroot to compile the Qt project. We need to know that the compiled Qt project needs to use the same compiler as the one used to compile the Buildroot Qt root filesystem. Otherwise, it may report errors such as version mismatch.

# 3.5 | View Qt Version

Enter the command below to view the Qt version.

output/host/usr/bin/qmake -v

As seen, the result above is Qt version 5.15.8.

# 3.6 | Command Line Cross Compile Qt Project

As with the Qt porting document, we can configure the Qt Creator related suite to compile ARM type Qt executable programs.

Randomly enter a Qt project path that must have a xx.pro file, as below, the author has a Qt project named untitled in the home directory. Then execute the command below. Note to change to your own Buildroot path.

/home/alientek/buildroot-2022.02.3/output/host/usr/bin/qmake

After executing qmake, a Makefile will be generated for compilation, and we can directly input make to compile! Very simple!

make

The compilation is complete as shown in the figure. The compilation information may report some warnings, which is due to the difference between the compiler g++ version and the version of c++; as long as there are no errors in compilation, it’s fine! Copy the generated untitled to execute in our Buildroot Qt root filesystem!