Expanding on my previous blog post, which covered the basics of natively building a Linux kernel from scratch, we will now look at building a kernel for a different architecture. This is called cross-compiling.
What is Cross-compiling
Often, in the world of embedded computing, we need to compile a piece of software, whether that is a software application, some software libraries, or the operating system itself, non-natively. That is, build a piece of software on a machine dissimilar to the machine (architecture) it is destined to run on, hence the term cross-compiling. This is normally carried out for a number of reasons but perhaps the most important is the time required to compile the given piece of software locally; often embedded systems are limited in terms of processing power and available storage.
When cross-compiling there are some basic terms that we use to refer to the systems involved in the process. The two main elements are the target and the host. The target is the system that we wish to compile for. In this example we will compile a kernel for the BeagleBone Black system which is based on an ARM architecture. The host machine is the machine that we use to build the target software. This is where the toolchain will be installed. In this case, we are building on a 64-bit intel based architecture.
The process of cross-compiling the Linux kernel is much the same as compiling the kernel natively, except in this instance, we invoke the cross-compiler toolchain rather than the native toolchain.
The Target platform - The BeagleBone Black
The BeagleBone Black is a low-cost ARM Cortex A8 processor-based single board computer produced by the BeagleBoard.org foundation. In recent years at ITDev, we have seen a number of new and existing projects using hardware that is very similar to the BeagleBone Black platform. This platform lends itself to use in these projects because not only is the hardware open-source but it is also very well supported by Linux and the open-source communities.
As such, I will use the BeagleBone Black platform to demonstrate how we can build a kernel for a different architecture. Using a host platform, we will build a new Linux kernel and then deploy this to an existing BeagleBone filesystem. With that in mind, a working BeagleBone Black will be required to test the final kernel build. That is, a BeagleBone Black running a recent Debian based image.
The Host Platform
The host platform chosen to cross-compile the BeagleBone kernel is the same build machine that we used for the previous blog article, Building the Linux Kernel - An Introduction, an Ubuntu based virtual machine. All of the commands presented here are entered via the command line. In this case, I simply used Ubuntu server, 18.04 LTS. However, one can equally use a desktop based release or even an entirely different distro. This being the case, be aware that whilst the theory remains the same, the commands to install the various tools presented here may differ.
Install the toolchain
Since we are using Ubuntu, we have access to the Ubuntu repositories and the wealth of software they provide. This greatly simplifies the installation of an ARM based toolchain which we install with the following single line:
$ sudo apt-get install gcc-arm-linux-gnueabi
The above command will search the Ubuntu repositories and install the tools presented below:
arm-linux-gnueabi-addr2line arm-linux-gnueabi-gcov-7 arm-linux-gnueabi-ar arm-linux-gnueabi-gcov-dump arm-linux-gnueabi-as arm-linux-gnueabi-gcov-dump-7 arm-linux-gnueabi-c++filt arm-linux-gnueabi-gcov-tool arm-linux-gnueabi-cpp arm-linux-gnueabi-gcov-tool-7 arm-linux-gnueabi-cpp-7 arm-linux-gnueabi-gprof arm-linux-gnueabi-dwp arm-linux-gnueabi-ld arm-linux-gnueabi-elfedit arm-linux-gnueabi-ld.bfd arm-linux-gnueabi-gcc arm-linux-gnueabi-ld.gold arm-linux-gnueabi-gcc-7 arm-linux-gnueabi-nm arm-linux-gnueabi-gcc-ar arm-linux-gnueabi-objcopy arm-linux-gnueabi-gcc-ar-7 arm-linux-gnueabi-objdump arm-linux-gnueabi-gcc-nm arm-linux-gnueabi-ranlib arm-linux-gnueabi-gcc-nm-7 arm-linux-gnueabi-readelf arm-linux-gnueabi-gcc-ranlib arm-linux-gnueabi-size arm-linux-gnueabi-gcc-ranlib-7 arm-linux-gnueabi-strings arm-linux-gnueabi-gcov arm-linux-gnueabi-strip
This 'arm-linux-gnueabi' string in the tool name is the toolchain tuple - see Debian Tuples. In this case, the tuple simply implies that the tools will produce binaries for the 32-bit ARM platform, 'linux' is the tool vendor and finally, the 'gnueabi' implies that the tools are based on GNU glibc standard C library.
What is instantly noticeable from the above toolset is that the names are the same as the native tools prepended with this 'arm-linux-gnueabi-' string. Cross-compiling using these tools is much the same as native compilation, except that the 'arm-linux-gnueabi-' string is prepended. Although this is a simplified view, especially as some packages may require a number of additional libraries for either the host or the target platform, this is certainly true for a kernel.
Cross-Compiling a kernel
Our host should now be ready to cross-compile a kernel, all that is required is for us to do is download the kernel. There are a number of ways we can do this for the BeagleBone platform but here we will concentrate on the official kernel release which can be found on the BeagleBoard github repo and can be "checked out" using Git with the following command - note that this does take a good while:
$ git clone git://github.com/beagleboard/linux.git
Once complete change to the newly checked out directory. Note that this will have the same structure as the kernel downloaded in the previous blog article, Building the Linux Kernel - An Introduction. The only real difference is that this kernel should feature the latest configuration files and patches for the various BeagleBone Black platforms.
$ cd linux/
From here on in the process is much the same as that of the previous blog post. That is, we need to configure the kernel, then build it and finally deploy it. Let's start with the configuration.
Since here we are only concerned with the process of cross compiling a kernel, we will simply rebuild the same kernel version that is currently present on the running BeagleBone. This will greatly simplify the deployment of the kernel whilst still allowing us to illustrate exactly what is required. We can find the kernel version running on the BeagleBone by running the following command on the BeagleBone terminal:
$ uname -r 4.14.67-ti-r73
We can then ensure we are building a kernel against this version by checking out the correct kernel source version as follows - note that we should be able to check out the exact version we are running, unlike in the previous blog where we had to find a version that was close to the running kernel.
$ git checkout 4.14.67-ti-r73
Previously, when building for a x86 architecture, we copied a kernel configuration file from the system's boot partition and we could do the same with the BeagleBone platform. However, since we have cloned the official BeagleBoard source, we can call the default configuration straight from the sources. The following command initialises the kernel sources by copying the default BeagleBoard kernel configuration to the base directory of the kernel sources - and renames it '.config'.
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- bb.org_defconfig
As discussed previously, we notify the kernel build script that we are cross-compiling by passing make the 'ARCH' and 'CROSS_COMPILE' flags. This tells the build system that it needs to prepend some of the commands with 'arm-linux-gnueabi-' as discussed earlier.
If we need to fine-tune this configuration we can do so as we did in the previous kernel build using 'menuconfig' i.e. we simply run:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
Now the sources are configured, we should be able to build the kernel. As with the configuration command we also specify the 'ARCH' and 'CROSS_COMPILE' flags but this time we need to tell the build system the target kernel image type required - 'uImage' along with specifying the address that the kernel should be located with the 'LOADADDR' argument. We also specify that we want the device tree to be compiled too, as follows:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LOADADDR=0x80000000 uImage dtbs ... .~. ... CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK include/generated/ti-pm-asm-offsets.h CHK kernel/config_data.h CHK include/generated/ti-emif-asm-offsets.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.14.79 Created: Tue Dec 18 14:31:56 2018 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 10449408 Bytes = 10204.50 kB = 9.97 MB Load Address: 80000000 Entry Point: 80000000
We have now built a kernel for the BeagleBoard platform and have shown that the build process is much the same as the x86 platform build except this time we added some additional arguments to the make commands. If we intend to make any changes to the kernel modules, we need to build these modules in much the same way as we did with the x86 kernel. We simply add the arguments to the 'make modules' command as follows:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
That is it - all that remains is to test this newly built kernel ...
Deploying the kernel
There are more ways to deploy a kernel to an embedded system than there are ways to skin a cat, some of these require some additional setup, such as network booting, others require complicated configuration of bootloaders such as Grub or U-Boot. Many of these methods are too complicated to be featured in this post and could be a blog article in themselves. In this example, we are going to go for the simplest method possible, that is to drop the new kernel in-place, overwriting the existing kernel. Installing a kernel in this method is not for the faint-hearted since the slightest error could render the system useless. Hence, I recommend this is only carried out on BeagleBone that is running from an SD card - since this can easily be recovered if things go wrong.
The first thing we need to do is transfer this new kernel over to the BeagleBone, this can be carried out by either mounting the SD card on your build machine and directly copying it in place, in the '/boot' directory, or this can be copied over to a running BeagleBone using SCP, and then copied over to the correct place.
As mentioned previously, we are simply overwriting the existing kernel in this example. Here I have mounted the BeagleBone SD card under '/mnt/rootfs' on my build machine and then overwritten the existing kernel with the zImage file as follows:
$ cp arch/arm/boot/zImage /mnt/rootfs/boot/vmlinuz-4.14.67-ti-r73
Once the kernel image is installed, we now need to install the kernel modules. To do this we get the kernel build system to place these modules directly onto the SD card with the 'INSTALL_MOD_PATH' variable on the make command. We also instruct the build system to strip any debug data to reduce the size of the modules directory with the 'INSTALL_MOD_STRIP' variable:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=/mnt/rootfs modules_install
Now re-boot the device and we should be able to boot into our new kernel. If it is not obvious, we can confirm this with the 'uname' command as follows. Note that the build date should be the date we built the kernel:
$ uname -a Linux beaglebone 4.14.79 #1 SMP PREEMPT Tue Dec 11 13:34:06 UTC 2018 armv7l GNU/Linux
We have now successfully built and deployed a kernel for the BeagleBone Black platform.
To find out about future blog posts related to Linux and embedded software, follow us on Linkedin, Twitter or Facebook, or sign up to our Embedded Linux Interest Group.
How ITDev Can Help
As a provider of software and electronics design services, we are often working with the Linux and Android operating systems. We have extensive experience in developing, modifying, building, debugging and bring up of these operating systems, be it for new developments or working with existing kernels to demonstrate new device technologies and features.
We offer advice and assistance to companies considering to use or already using Linux or Android on their embedded system. Initial discussions are always free of charge, so if you have any questions, or would like to find out more, email us.
Embedded Linux workshop
We are running a workshop focused on the challenges around embedded Linux later this year. If you are interested in attending this workshop, sign up to our Embedded Linux Interest Group to be kept informed.
