Use buildroot to create your own cross-compilation toolchain

This article is reproduced from: https://blog.csdn.net/linczone/article/details/45894181

Use buildroot to create your own cross-compilation toolchain

Keywords: buildroot cross-compilation

Author: chad  
Mail: linczone@163.com

Development environment: deepin 14.03 + mini2440 (using the original linux2.6.29)

Once, for a long time, I had a doubt: why the program I compiled with the at91sam9260 cross-compilation toolchain can only run on the at91sam9260, but not on the mini2440? Conversely, programs compiled with the cross-compilation toolchain for mini2440 will not run on at91? Both mini2440 and at91sam9260 are arm platforms, and they also use linux system. Why can't binary programs be universal?

This article will answer these questions. We don't recommend reinventing the wheel, but if we don't invent it once, we'll never know how the wheel came about.

  The first step in embedded Linux development is to create a cross-compilation toolchain. For a long time in the past, building a cross-compilation toolchain was a nightmare for embedded developers, because they had to manually Track dependencies between various source packages (and their updates). Until the advent of buildroot changed that fact.

Buildroot is a command set of Makefiles and patches, which can generate a cross-compilation toolchain and root file system for your target system very simply. The entire creation process is like compiling the Linux kernel.

1. Download buildroot

Download the latest source package directly from the official website: http://buildroot.net/downloads/

2. Install dependent libraries and software packages

Taken from the following buildroot official website operation instructions:

1. Build tools:

gcc (version 2.95 or any later) g++ (version 2.95 or any later) python (version 2.6 or 2.7) 2. dependencies packages: Install the following as needed ncurses5 ;menuconfig use qt4 ;xconfig use glib2, gtk2 and glade2 ;gconfig use 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

3. Unzip the buildroot archive

4. Enter the source code directory, make menuconfig configuration

Take a look at the s3c2440 data sheet excerpt before matching: 
A few more important options are briefly explained below:

Target Architecture      --->     Schema for selecting targets,I choose here ARM (little endian)(s3c2440 Can run in little-endian and big-endian modes,The default is little endian mode)
Target Architecture Variant ---> Kernel type(arm920t) Target ABI (EABI) ---> The application binary interface used by the target,There are two options ①EABI(Embedded ABI) we choose EABI. ②OABI(Old ABI) Build options ---> Mainly some options used when compiling,for example dl path of,The path used to download the code package,The upper limit of running multiple compilations at the same time,Whether to enable the compiler buffer, etc.,Here it is by default. Toolchain ---> Toolchain Options Toolchain type (Buildroottoolchain) ---> Toolchain Type,Here we do not use external Buildroot,default . *** Kernel Header Options *** Kernel Headers (Linux 3.18.x kernel headers) ---> C library (glibc) ---> Have uclibc/glibc and other options, here I choose glibc,The reason will be explained later glibc version (2.20) ---> *** Binutils Options *** Binutils Version (binutils 2.24) ---> () Additional binutils options *** GCC Options *** GCC compiler Version (gcc 4.8.x) ---> () Additional gcc options [*] Enable C++ support [ ] Enable compiler OpenMP support [ ] Enable libmudflap support [ ] Enable graphite support [ ] Build cross gdb for the host [ ] Purge unwanted locales () Generate locale data [ ] Copy gconv libraries [*] Enable MMU support () Target Optimizations () Target linker options 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32

5. Save and exit, generate a .config file

6. Compile

$make

make-jN cannot be used here because Buildroot does not support top-levelparallel make, instead, use the BR2_JLEVEL option to tell Buildroot to run and compile each package using make -JN.

use make The following steps are executed after the command:
     ①Download source files(Required)
     ②configure,Compile and install cross-compiling toolchain(If using internal toolchain),or output a toolchain(If an external toolchain uses)
     ③Construct/Install the target package of cup selection
     ④Build the kernel image(if there is a choice)
     ⑤Build the boot code image(if there is a choice)
     ⑥Create root file system(if there is a choice)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

7. Introduction to output files

The output files are all in the output/ directory:

  • images/ — stores all image files generated after compilation (kernel image, load boot image and root file system image)
  • build/ — Stores all components except for building cross-compilation toolchain components, in this directory each function has a subdirectory to store their respective components.
  • staging/ — Contains a hierarchy similar to the root filesystem hierarchy. This directory contains the installed cross-compilation toolchain and all userspace packages selected for the target board.
  • target/ — contains the root filesystem, but not for your board
  • host/ — contains the set of cross-compilation tools we need

We can see many of the binaries we need in host/usr/bin/ as follows: # cd host/usr/bin/

8. Modify environment variables

In the /etc/profile file add:

# vim/etc/profile
 add on:         exportPATH=$PATH:/home/chad/works/binutils/buildroot-2015.02/output/host/usr/bin after saving,Execute the following command to make it take effect: # source/etc/profile
  • 1
  • 2
  • 3
  • 4

9. Test arm-linux-gcc

Printing out the version number indicates that the compilation was successful:

10. hello.c test

Write a hello.c program, compile it with arm-linux-gcc and download it to the development board for testing. 

According to the above configuration, the program must run normally. 
But if uclibc is selected above, duang! An error occurs when the program runs!

Clibrary (uclibc)  --->  Have uclibc/glibc and other options, here if you choose uclibc
  • 1

If we use hexdump to view the hello binary, we will find the following information:

#hexdump -C hello
  • 1

 

Then we use the same method to view the information of the binary program that can be executed correctly, and open a random information as follows:

Did you notice the difference? The mini2440 calls the glibc library by default, not the uclibc library.

It should be noted that the buildroot compilation efficiency is very low. After one compilation is completed, if you want to modify something, you must recompile all! ! That is, make clean first and then make.

How to recompile the package?

  After the first complete compilation, if we need to reconfigure the source package, we cannot make directly in the root directory on buildroot. Buildroot does not know that you have reconfigured the source code, it will only compile the first time The resulting file is packaged again into a root file system image file. However, we can modify the configuration of the source code in the following two ways.

  1. Directly delete the source package. For example, if we want to recompile openssh, then we can directly delete the output/build/openssh-vesion folder, then when you make, it will automatically extract the source package from the dl folder, and re- Install
  2. Taking openssh as an example, if we don't want to recompile, we just want to reconfigure, that is, ./configure,
    We can directly delete .stamp_configured in the output/build/openssh-version directory
    If you just want to reinstall you can delete .stamp_target_install
    Re make can delete .stamp_built

Summarize:

Why is the cross-compilation toolchain for mini2440 not compatible with the cross-compilation toolchain for at91sam9260?

Look at the important parameters that we specified in the cross-compilation toolchain we made earlier:

TargetArchitecture ---> target architecture,s3c2440 and at9260 both arm,this is the same
Target Architecture Variant  ---> Kernel type(s3c2440[arm920t] and at91sam9260[arm926EJ-S],But when configuring arm926t),different here
Target ABI (EABI)   ---> The application binary interface used by the target,different here ①EABI(Embedded ABI) mini2440 s Choice. ②OABI(Old ABI) at91sam9260 s Choice Kernel Headers (Linux 3.18.x kernel headers) ---> There is little difference here C library (glibc) ---> both choose glibc glibc version (2.20) ---> different version 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

So far, I think the reason why the cross-compilation toolchains of the two platforms are not universal should be clear.

--—–2015-05-21

Tags: Linux Operation & Maintenance server

Posted by alexcrosson on Tue, 12 Jul 2022 16:57:03 +0530