Building the Linux Kernel - Cross-compiling for a BeagleBone Black

Call: +44 (0)23 8098 8890

Posted 12th July 2019, By Steven S

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 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-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://

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


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/
  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 LinkedinTwitter 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.



Senior Software Engineer

MSc Digital Systems Engineering, University of Portsmouth - MIET

I have been a software engineer for ITDev since 2014, and am responsible for supporting a number of ITDev projects. I have a particular interest in open-source software, embedded systems, Linux, and all things wireless.

Outside of ITDev I like to spend my time building IoT solutions around the house, fixing my Transit van and brewing beer.

View all posts by Steven    |    View all ITDev team members

IET Enterprise Partners logo

Latest Blog Posts

Ladybug in sight
Posted 3rd August 2020, By James H
If debugging a Linux driver is bugging you, this 'how to' guide explains how to approach this using the function tracer within ftrace to find out what’s going ...more
Linux penguin sending an email
Posted 19th June 2020, By Quentin D
In this final part of his blog, Quentin explains the final part of the process: submitting your changes to the Linux Maintainers.
Linux penguin
Posted 5th June 2020, By Quentin D
In his second 'Contributing to the Linux kernel' blog, Quentin looks at finding something to fix, coding and committing changes.
Jenkins for FPGA
Posted 29th May 2020, By Hugh J
FPGA development should be enjoyable but when bugs slip through the net, it can be a headache to find them later on. Hugh looks at a few of the plugins ...more

Latest News

Posted 11th September 2020
From adapting to our new working situation to recruiting new staff members and engaging new clients, it’s been a busy summer. Find out more in our latest ...more
Spring 2020
Posted 17th April 2020
Following the beautiful weather over the Easter weekend, we are proud to be able to provide an update on our current activities, showing business is continuing ...more
Business as usual
Posted 20th March 2020
With a strong commitment to keeping our staff and clients safe during this period, we would like to reassure all our business contacts that we remain fully ...more
South Coast Tech Awards Trophy
Posted 6th December 2019
ITDev was excited to attend the first South Coast Technology Awards on Thursday 5th December at the Ageas Bowl. A much needed celebratory awards for a sector ...more