Revision as of 05:56, 22 June 2014 by Craig Peacock (Talk | contribs)

Compiling the BeagleBone Black Kernel

The following contains instructions for building the BeagleBone Black kernel on Ubuntu 14.04.


ARM Cross Compiler

To compile the linux kernel for the BeagleBone Black, you must first have an ARM cross compiler installed. I use gcc-4.7-arm-linux-gnueabi-base that comes with Ubuntu 14.04. To install the compiler run:

sudo apt-get install gcc-arm-linux-gnueabi


The Beaglebone patches and build scripts are stored in a git repository. Install git:

sudo apt-get install git

And configure with your identity.

git config --global ""

lzop Compression

The kernel is compressed using lzo. Install the lzop parallel file compressor:

sudo apt-get install lzop

uBoot mkimage

The bootloader used on the BeagleBone black is u-boot. u-boot has a special image format called uImage. It includes parameters such as descriptions, the machine/architecture type, compression type, load address, checksums etc. To make these images, you need to have a mkimage tool that comes part of the u-Boot distribution. Download u-boot, make and install the u-boot tools:

tar -xjf u-boot-latest.tar.bz2
cd into u-boot directory
make tools-only
sudo install tools/mkimage /usr/local/bin

Compiling the BeagleBone Black Kernel

Here we compile the BeagleBone Black Kernel, and generate an uImage file with the DTB blob appended to the kernel for ease of use.

git clone git://
cd kernel
git checkout 3.14
cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
wget\;a=blob_plain\;f=bin/am335x-pm-firmware.bin\;hb=HEAD -O kernel/firmware/am335x-pm-firmware.bin
cd kernel
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- beaglebone_defconfig -j4
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage dtbs LOADADDR=0x80008000 -j4

Now we build any kernel modules:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules -j4

And if you have your rootfs ready, you can install them:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/home/cpeacock/export/rootfs modules_install


TFTP Server

Rather than flashing your newly created kernel to find out it doesn't work or it is not quite configured correctly, a better way is to load the kernel into RAM and boot it from there. u-boot allows kernel images to be loaded via TFTP.

To speed up development, I create an 'export' directory. A TFTP server is then configured to use this directory as the TFTP root.

From the export directory, add symbolic links to the kernel images. This way, you can recompile the kernel and the new image is instantly available without having to move it.

ln -s /path to linux/arch/arm/boot/uImage uImage-BBB-3.14.1
ln -s /path to linux/arch/arm/boot/dts/am335x-boneblack.dtb am335x-boneblack.dtb

u-boot tftpboot

To test your kernel, bring up a serial console to the BeagleBone Black. First we will need to configure the IP addresses. The ipaddr variable contains the IP address for the BeagleBone Black, while the serverip variable is the address of the TFTP server containing the kernel image.

setenv ipaddr
setenv serverip

These variables can be saved to non-volatile memory to speed up development.

Next load the Kernel image and device tree binary blob:

tftpboot ${fdtaddr} am335x-boneblack.dtb
tftpboot ${kloadaddr} uImage-BBB-3.14.1

Let's use the existing root filesystem, and send kernel messages to ttyO0:

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

And boot from the memory location:

bootm ${kloadaddr} - ${fdtaddr}

Your BeagleBone Black should now boot your new Kernel:

## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name:   Linux-3.14.1+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3815848 Bytes = 3.6 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
   Booting using the fdt blob at 0x80f80000
   XIP Kernel Image ... OK
   Using Device Tree in place at 80f80000, end 80f8ab3a

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.14.1+ (cpeacock@ubuntu) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #1 SMP Sat Jun 21 22:24:25 PDT 2014
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: TI AM335x BeagleBone

The example shown is to use the filesystem already in place (i.e. ext4 on mmcblk0p2). The preferred option is to export a root NFS filesystem.

Booting from NFS

Booting from NFS has the added advantage that you can compile userland binaries on your development box, install them to the NFS export and have instant access to them on your target system.

This requires a root filesystem to be present on your development box with binaries that have been cross compiled for ARM. Various distributions exist to assist you with this. It is assumed a NFS Server is installed and configured properly to export this directory.

Angstrom BeagleBone demo files can be downloaded from here

Download the raw filesystem and decompress:

mkdir rootfs
tar -xJf Angstrom-systemd-image-eglibc-ipk-v2012.12-beaglebone-2013.09.12.rootfs.tar.xz -C rootfs

At this point you will need to ensure your kernel modules are present. If not, run the following from your kernel folder to install the modules on your rootfs:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/home/cpeacock/export/rootfs modules_install

In uBoot, you can now issue the following commands to load your kernel from TFTP and your rootfs over NFS:

setenv ipaddr
setenv serverip
tftpboot ${fdtaddr} am335x-boneblack.dtb
tftpboot ${kloadaddr} uImage-BBB-3.14.1
setenv bootargs console=ttyO0,115200n8 root=/dev/nfs rw nfsroot= ip=
bootm ${kloadaddr} - ${fdtaddr}

NFS boot failures

If your NFS root freezes during boot with a message similar to:

nfs: server not responding, still trying

Then it is possible the network connection used by the NFS connection has been re-configured. On Angstrom, this connection is re-established by the Connection Manager (ConnMan.) To quickly overcome this problem, remove /lib/systemd/system/connman.service from your rootFS.