This is a three part series of blogs which explains the complete procedure to cross compile

  1. Bootloader
  2. Kernel/O.S
  3. File system

This will be done for ARM processor based development platform.

In short, this blog series explains how to setup an embedded linux machine that suits your needs

Development environment prerequisites

  1. Linux machine running any flavour of ubuntu, fedora or arch linux.
  2. Internet connection.

Hardware needed

1.ARM based development board.
a.This is very important as the build process and the cross compiler we choose depends on the type of processor. For this blog series we are using beaglebone black development which is based on ARMv7 architecture.
2.4/8 GB Micro SD Card.
3.USB to Serial adaptor.

Topics discussed in this document

  • What is Bootloader?
  • Das U-Boot — the Universal Boot Loader
  • Stages in boot loading
  • Downloading the source
  • Brief about the directories and the functionality it provides
  • Cross compiling bootloader for ARM based target platform
  • Setup the environment variables
  • Start the build
  • Micro SD card Booting procedure in beaglebone black

What is Bootloader?

There are so many answers to this question, but if you look at the core of all the answers it would contain some kind of initialization. In short this is the piece of software which is executed as soon as you turn on your hardware device. The hardware device can be anything, from your mobile phones, routers, microwave ovens, smart tv, and to the world’s fastest supercomputer. After all, everything has a beginning right?

The reason I said there are so many ways to answer this question, is because the use case of each device is different, and we need to choose the bootloader carefully, which initializes the device. So much research and decision making time is spent on this to make sure that the devices which are initialized are absolutely needed. Everyone likes their devices to boot up fast.

In embedded systems the bootloader is a special piece of software whose main purpose is to load the kernel and hand over the control to it. To achieve this, it needs to initialize the required peripherals which helps the device to carry out its intended functionality. In other words, it initializes the absolutely needed peripherals alone and hands over the control to the O.S aka kernel.

Das U-Boot — the Universal Boot Loader

U-Boot is the most popular boot loader in linux based embedded devices. It is released as open source under the GNU GPLv2 license. It supports a wide range of microprocessors like MIPS, ARM, PPC, Blackfin, AVR32 and x86. It even supports FPGA based nios platforms. If your hardware design is based out of any of these processors and if you are looking for a bootloader the best bet is to try U-Boot first. It also supports different methods of booting which is pretty much needed on fallback situations.

For example, it has support to boot from USB, SD Card, NOR and NAND flash (non volatile memory). It also has the support to boot linux kernel from the network using TFTP. The list of filesystems supported by U-Boot is huge. So you are covered in all aspects that is needed from a bootloader and more so.

Last but not least, it has a command line interface which gives you a very easy access to it and try many different things before finalizing your design. You configure U-Boot for various boot methods like MMC, USB, NFS or NAND based and it allows you to test the physical RAM of any issues.
Now its upto the designer to pick what device he wants and then use U-Boot to his advantage.

Stages in boot loading

For starters, U-Boot is both a first stage and second stage bootloader. When U-Boot is compiled we get two images, first stage (MLO) and second stage (u-boot.img) images. It is loaded by the system’s ROM code (this code resides inside the SoC’s and it is already preprogrammed) from a supported boot device. The ROM code checks for the various bootable devices that is available. And starts execution from the device which is capable of booting. This can be controlled through jumpers, though some resistor based methods also exists. Since each platform is different and it is advised to look into the platforms datasheet for more details.
Stage 1 bootloader is sometimes called a small SPL (Secondary Program Loader). SPL would do initial hardware configuration and load the rest of U-Boot i.e. second stage loader. Regardless of whether the SPL is used, U-Boot performs both first-stage and second-stage booting.

In first stage, U-Boot initializes the memory controller and SDRAM. This is needed as rest of the execution of the code depends on this. Depending upon the list of devices supported by the platform it initializes the rest. For example, if your platform has the capability to boot through USB and there is no support for network connectivity, then U-Boot can be programmed to do exactly the same.
If you are planning to use linux kernel, then setting up of the memory controller is the only mandatory thing expected by linux kernel. If memory controller is not initialized properly then linux kernel won’t be able to boot.

Block Diagram of the target

The above is the block diagram of AM335X SoC.

Downloading the source

U-Boot source code is maintained using git revision control. Using git we can clone the latest source code from the repo.

Brief about the directories and the functionality it provides

arch –> Contains architecture specific code. This is the piece of code which initializes the CPU and board specific peripheral devices.

board → Source in both arch and board directory work in tandem to initialize the memory and other devices.

cmd –> Contains code which adds command line support to carry out different activity depending on the developer’s requirement. For example, command line utilities are provided to erase NAND flash and reprogram it. We will be using similar commands in the next blog.

configs –> Contains the platform level configuration details. This is very much platform specific. The configs are much like a static mapping with reference to the platform’s datasheet.

drivers –> This directory needs a special mention as it has support for a lot of devices:
Each subdirectory under the driver directory corresponds to a particular device type. This structure is followed in accordance with the linux kernel. For example, network drivers are all accumulated inside the net directory:

This makes sure the code is not bloated and it is much easier for us to navigate and make the needed changes.

fs –> Contains the code which adds support for filesystems. As mentioned earlier, U-Boot has a rich filesystem support. It supports both read only file system like cramfs and also journalling file system like jffs2 which is used on NAND flash based devices.

include –> This is a very important directory in U-Boot. It not only contains the header files but also the files which define platform specific information like supported baud rates, starting RAM address, stack size, default command line arguments etc.

lib –> Contains support for library files. They provide the needed helper functions used by U-Boot.

net –> Contains support for networking protocols like ARP, TFTP, Ping, Bootp and etc.

scripts and tools –> Contains helper scripts to create images and binaries. It contains scripts to create a patch file (hopefully with some useful fixes) in the correct format if we are planning to send it the development community.

With the source code available and some understanding about the directory structure let us do what we actually want to do i.e. create a bootloader

Since the target board which we are using is based on ARM processor we will need a cross compiler which helps us to create binaries to run on that processor. There are a lot of options for this. Linaro provides the latest cross tool for ARM based processors and it is very easy to get. For this reason, we have chosen to go for the cross tool provided by linaro.

Cross compiling bootloader for ARM based target platform

For cross compiling we can need to download the toolchain from the linaro website using the below link:

The toolchain comes compressed as tar file and  we can unzip it using the below command:

Setup the environment variables

With the pre build tool chain, we need to set up a few environment variables like path of the toolchain before proceeding to compile U-Boot. Below are the shell commands that we need to issue.

In our work space <YOUR_WORK_DIRECTOY> points to /home/kasi/git/ as this is the workspace which we are using.

The exact command from our machine is:

Please double check the above commands so that it suits your workspace.

Config File

With everything setup it’s time to choose the proper config file and start the compilation.

The board which we are using is beagle bone black which is based on TI’s AM3358 SoC.

So we need to look for similar kind of name in include/configs. The file which corresponds to this board is “am335x_evm.h

So from command line we need to execute the below command:

There are a lot of things that happened in the background when the above command was executed. We don’t want to go much deeper into that as that could be another blog altogether…!

We have created the config file which is used by U-Boot in the build process. For those who want to know more, please open the “.config” file and check it. Modifications can be done here to the config file directly but we shall discuss about this later.

Start the build

To start the build we need to give the most used/abused command in the embedded linux programmer’s life which is make.

If you are compiling U-Boot for the first time, then there are chances that you may get the above error. Since the build machine which we are using didn’t have the device-tree-compiler package installed we got the above error.

Dependency installation (if any)


Again make

Simple ls -l will show the first stage bootloader and second stage bootloader.

MLO is the first stage bootloader and u-boot.img is the second stage bootloader.

With the bootloader available it’s time to partition the Micro SD card, load these images and test it on the target.


We are using an 8GB Micro SD card and using “gparted” (gui based partition tool) to partition it. It is a much easier approach to use gparted and create the filesystems. We have created two partitions:
1. FAT16 of size 80MB with boot flag enabled.
2. EXT4 of size more than 4GB.

Choosing the size of the partition is an availability as well as a personal choice. One important thing to note here is that the FAT16 partition has the boot flag set. This is needed for us to boot the device using the Micro SD card. Please see the image below to get a clear picture of the partitions in the Micro SD card.

After the creating the partitions in the Micro SD card, remove the card from the build machine and insert it again. In most of the modern distro’s partitions in the Micro SD card get auto mounted which will confirm us that the partitions are created correctly. It will help us to cross verify the created partitions.

Copy the images

Now it’s time to copy the builded images into the Micro SD card. When the Micro SD card is inserted into the build machine it was automatically mounted in /media/kasi/BOOT directory.

With the above commands we have loaded the first stage bootloader as well as the second stage bootloader into the bootable Micro SD card.

Micro SD card Booting procedure in beaglebone black

Since the target board has both eMMC and MicroSD card slot, on power up it tries to boot from both the places. To make sure it boots from MicroSD card we need to keep the button near the MicroSD card slot pressed while providing power to the device. This makes sure that the board sees the MicroSD card first and loads the first stage and second stage bootloader which we just copied there.

Above flowchart shows the booting procedure of the target.

Serial Header

The above diagram shows the close up of the serial port header details of that target. You should connect your pinouts from USB to TTL Serial Cable (if you are using one) to these pins in the target to see the below log.

Below is the output from the serial port while loading U-Boot which was compiled by us.

As you can clearly see this is the U-Boot which we compiled and loaded into the target (Check for string MSYS technologies in the log, second line of the output.

First stage bootloader checks and loads the u-boot.img into RAM and hands over the control to it which is the second stage bootloader. As shared before U-Boot also provides us with a cli which can be used to set up various parameters like IP address, load addresses and a lot more which the developer can use for tweaking and testing purposes.

To the second stage bootloader we need to provide proper kernel image to load and proceed with the next step of bootstrapping. We shall discuss about this in next blog.