Embedded Linux Labs
Embedded Linux Labs
Embedded Linux Labs
Lab Book
free electrons
http://free-electrons.com
Training setup
Download les and directories used in practical labs
Note that root permissions are required to extract the character and block device les contained
in this lab archive. This is an exception. For all the other archives that you will handle during
the practical labs, you will never need root permissions to extract them. If there is another
exception, we will let you know.
Lab data are now available in an embedded-linux-labs directory in your home directory. For
each lab there is a directory containing various data. This directory will also be used as working
space for each lab, so that the les that you produce during each lab are kept separate.
You are now ready to start the real practical labs!
More guidelines
Can be useful throughout any of the labs
Read instructions and tips carefully. Lots of people make mistakes or waste time because
they missed an explanation or a guideline.
Always read error messages carefully, in particular the rst one which is issued. Some
people stumble on very simple errors just because they specied a wrong le path and
didnt pay enough attention to the corresponding error message.
Never stay stuck with a strange problem more than 5 minutes. Show your problem to
your colleagues or to the instructor.
You should only use the root user for operations that require super-user privileges, such
as: mounting a le system, loading a kernel module, changing le ownership, conguring
the network. Most regular tasks (such as downloading, extracting sources, compiling...)
can be done as a regular user.
If you ran commands from a root shell by mistake, your regular user may no longer be
able to handle the corresponding generated les. In this case, use the chown -R command
to give the new les back to your regular user.
Example: chown -R myuser.myuser linux-3.4
Setup
Go to the $HOME/embedded-linux-labs/toolchain directory.
Getting Crosstool-ng
Lets download the 1.20.0 release of Crosstool-ng, through its git source repository:
git clone git://crosstool-ng.org/crosstool-ng
cd crosstool-ng/
git checkout -b crosstool-ng-1.22.0
Note that if cloning through git:// doesnt work due to network restrictions, you can clone
through http:// instead.
Installing Crosstool-ng
We can either install Crosstool-ng globally on the system, or keep it locally in its download direc-
tory. Well choose the latter solution. As documented in docs/2\ -\ Installing\ crosstool-
NG.txt, do:
autoreconf
./configure --enable-local
make
make install
Then you can get Crosstool-ng help by running
./ct-ng help
And wait!
Known issues
It is frequent that Crosstool-ng aborts because it cant nd a source archive on the Internet,
when such an archive has moved or has been replaced by more recent versions. New Crosstool-ng
versions ship with updated URLs, but in the meantime, you need work-arounds.
If this happens to you, what you can do is look for the source archive by yourself on the Internet,
and copy such an archive to the src directory in your home directory. Note that even source
archives compressed in a dierent way (for example, ending with .gz instead of .bz2) will be
ne too. Then, all you have to do is run ./ct-ng build again, and it will use the source archive
that you downloaded.
If you are using gcc 4.7.1, for example in Ubuntu 12.10 (not ocially supported in these labs),
compilation will fail in ppl-0.10.2 with the below error:
error: 'f_info' was not declared in this scope
One solution is to add the -fpermissive ag to the CT_EXTRA_FLAGS_FOR_HOST setting (in Path
and misc options -> Extra host compiler flags).
Cleaning up
To save about 6 GB of storage space, do a ./ct-ng clean in the Crosstool-NG source directory.
This will remove the source code of the dierent toolchain components, as well as all the gen-
erated les that are now useless since the toolchain has been installed in /usr/local/xtools.
Bootloader - U-Boot
Objectives: Set up serial communication, compile and install the
U-Boot bootloader, use basic U-Boot commands, set up TFTP com-
munication with the development workstation.
As the bootloader is the rst piece of software executed by a hardware platform, the installation
procedure of the bootloader is very specic to the hardware platform. There are usually two
cases:
The processor oers nothing to ease the installation of the bootloader, in which case the
JTAG has to be used to initialize ash storage and write the bootloader code to ash.
Detailed knowledge of the hardware is of course required to perform these operations.
The processor oers a monitor, implemented in ROM, and through which access to the
memories is made easier.
The Xplained board, which uses the SAMA5D3 SoCs, falls into the second category. The
monitor integrated in the ROM reads the MMC/SD card to search for a valid bootloader before
looking at the internal NAND ash for a bootloader. In case nothing is available, it will operate
in a fallback mode, that will allow to use an external tool to reash some bootloader through
USB. Therefore, either by using an MMC/SD card or that fallback mode, we can start up a
SAMA5D3-based board without having anything installed on it.
AT91Bootstrap Setup
The boot process is done in two steps with the ROM monitor trying to execute a rst piece of
software, called AT91Bootstrap, from its internal SRAM, that will initialize the DRAM, load
U-Boot that will in turn load Linux and execute it.
As far as bootloaders are concerned, the layout of the NAND ash will look like:
Oset 0x0 for the rst stage bootloader is dictated by the hardware: the ROM code of the
SAMA5D3 looks for a bootloader at oset 0x0 in the NAND ash.
Oset 0x40000 for the second stage bootloader is decided by the rst stage bootloader.
This can be changed by changing the AT91Bootstrap conguration.
Oset 0xc0000 of the U-Boot environment is decided by U-Boot. This can be changed by
modifying the U-Boot conguration.
The rst item to compile is AT91Bootstrap that you can fetch from Atmels GitHub account:
git clone git://github.com/linux4sam/at91bootstrap.git
cd at91bootstrap
git checkout v3.7.1
Then, we rst need to congure the build system for our setup. Were going to need a few pieces
of information for this:
Which board you want to run AT91Bootstrap on
Which device should AT91Bootstrap will be stored on
What component you want AT91Boostrap to load
You can get the list of the supported boards by listing the board directory. Youll see that in
each of these folders, we have a bunch of defconfig les, that are the supported combinations.
In our case, we will load U-Boot, from NAND ash (nf in the defconfig le names).
After nding the right defconfig le, load it using make <defconfig_filename> (just the le
name, without the directory part).
In recent versions of AT91Bootstrap, you can now run make menuconfig to explore options
available in this program.
The next thing to do is to specic the cross-compiler prex (the part before gcc in the cross-
compiler executable name):
export CROSS_COMPILE=arm-linux-
You can now start compiling using make2 .
At the end of the compilation, you should have a le called sama5d3_xplained-nandflashboot-
uboot-*.bin, in the binaries folder.
In order to ash it, we need to do a few things. First, remove the NAND CS jumper on the board.
Its next to the pin header closest to the Micro-USB plug. Now, press the RESET button. On
the serial port, you should see RomBoot.
Put the jumper back.
Then, start sam-ba (or sam-ba_64 if using a 64 bit installation of Ubuntu). Run the executable
from where it was extracted. Youll get a small window. Select the ttyACM0 connection, and the
at91sama5d3x-ek board. Hit Connect.
You need to:
Hit the NANDFlash tab
In the Scripts choices, select Enable NandFlash and hit Execute
Select Erase All, and execute the command
Then, select and execute Enable OS PMECC parameters in order to change the NAND ECC
parameters to what RomBOOT expects. Change the number of ECC bits to 4, and the
ECC oset to 36.
Finally, send the image we just compiled using the command Send Boot File
AT91Bootstrap should be ashed now, keep sam-ba open, and move to the next section.
U-Boot setup
Download U-Boot:
wget ftp://ftp.denx.de/pub/u-boot/u-boot-2015.04.tar.bz2
2 You can speed up the compiling by using the -jX option with make, where X is the number of parallel jobs
used for compiling. Twice the number of CPU cores is a good value.
Were going to use a specic U-Boot version, 2015.04, which we have tested to work on the
Atmel Xplained board. More recent versions may also work, but we have not tested them.
Extract the source archive and get an understanding of U-Boots conguration and compilation
steps by reading the README le, and specically the Building the Software section.
Basically, you need to:
Set the CROSS_COMPILE environment variable;
Run make <NAME>_defconfig, where <NAME> is the name of your board as declared in
boards.cfg. There are two avors of the Xplained conguration: one to run from the SD
card (sama5d3_xplained_mmc) and one to run from the NAND ash (sama5d3_xplained_
nandflash). Since were going to boot on the NAND, use the latter. Note that for our
platform, both these choices are sharing most of their conguration, that is dened in
include/configs/sama5d3_xplained.h. Read this le to get an idea of how a U-Boot
conguration le is written;
Now that you have a valid initial conguration, you can now run make menuconfig to
further edit your bootloader features.
Finally, run make, which should build U-Boot.
Now, in sam-ba, in the Send File Name eld, set the path to the u-boot.bin that was just
compiled, and set the address to 0x40000. Click on the Send File button.
You can now exit sam-ba.
Testing U-Boot
Reset the board and check that it boots your new bootloaders. You can verify this by checking
the build dates:
AT91Bootstrap 3.7.1 (Wed Oct 28 06:48:23 CET 2015)
CPU: SAMA5D36
Crystal frequency: 12 MHz
CPU clock : 528 MHz
Master clock : 132 MHz
DRAM: 256 MiB
NAND: 256 MiB
MMC: mci: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: gmac0
Error: gmac0 address not set.
, macb0
Error: macb0 address not set.
U-Boot #
In U-Boot, type the help command, and explore the few commands available.
Later on, we will transfer les from the development workstation to the board using the TFTP
protocol, which works on top of an Ethernet connection.
To start with, install and congure a TFTP server on your development workstation, as detailed
in the bootloader slides.
With a network cable, connect the Ethernet port labelled ETH0/GETH of your board to the
one of your computer. If your computer already has a wired connection to the network, your
instructor will provide you with a USB Ethernet adapter. A new network interface, probably
eth1 or eth2, should appear on your Linux system.
To congure this network interface on the workstation side, click on the Network Manager tasklet
on your desktop, and select Edit Connections.
In the IPv4 Settings tab, press the Add button and then choose the Manual method to make
the interface use a static IP address, like 192.168.0.1 (of course, make sure that this address
belongs to a separate network segment from the one of the main company network).
You can use 255.255.255.0 as Netmask, and leave the Gateway eld untouched (if you click on
the Gateway box, you will have to type a valid IP address, otherwise you wont be allowed to
click on the Apply button).
Now, congure the network on the board in U-Boot by setting the ipaddr and serverip envi-
ronment variables:
setenv ipaddr 192.168.0.100
setenv serverip 192.168.0.1
The rst time you use your board, you also need to set the MAC address in U-boot:
The tftp command should have downloaded the textfile.txt le from your development
workstation into the boards memory at location 0x220000004 .
You can verify that the download was successful by dumping the contents of the memory:
md 0x22000000
We will see in the next labs how to use U-Boot to download, ash and boot a kernel.
Rescue binaries
If you have trouble generating binaries that work properly, or later make a mistake that causes
you to loose your bootloader binaries, you will nd working versions under data/ in the current
lab directory.
3 Resetting your board is needed to make your ethaddr permanent, for obscure reasons. If you dont, U-boot
Kernel sources
Objective: Learn how to get the kernel sources and patch them.
Setup
Create the $HOME/embedded-linux-labs/kernel directory and go into it.
Apply patches
Download the 2 patch les corresponding to the latest 4.4 stable release: a rst patch to move
from 4.3 to 4.4 and a second patch to move from 4.4 to 4.4.x.
Without uncompressing them (!), apply the 2 patches to the Linux source directory.
View one of the 2 patch les with vi or gvim (if you prefer a graphical editor), to understand
the information carried by such a le. How are described added or removed les?
Rename the linux-4.3 directory to linux-4.4.<x>.
Kernel - Cross-compiling
Objective: Learn how to cross-compile a kernel for an ARM target
platform.
Cross compile the kernel for the Atmel SAMA5D3 Xplained ARM board
Setup
Go to the $HOME/embedded-linux-labs/kernel directory.
Install the package libqt4-dev which is needed for the xconfig kernel conguration interface.
Target system
We are going to cross-compile and boot a Linux kernel for the Atmel SAMA5D3 Xplained board.
Kernel sources
We will re-use the kernel sources downloaded and patched in the previous lab.
export PATH=/usr/local/xtools/arm-cortexa5-linux-uclibcgnueabihf/bin:$PATH
Dene the value of the ARCH and CROSS_COMPILE variables in your environment (using
export)
Or specify them on the command line at every invocation of make, i.e: make ARCH=...
CROSS_COMPILE=... <target>
Cross compiling
Youre now ready to cross-compile your kernel. Simply run:
make
and wait a while for the kernel to compile. Dont forget to use make -j<n> if you have multiple
cores on your machine!
Look at the end of the kernel build output to see which le contains the kernel image. You can
also see the Device Tree .dtb les which got compiled. Find which .dtb le corresponds to your
board.
Copy the linux kernel image and DTB les to the TFTP server home directory.
After storing the rst stage bootloader, U-boot and its environment variables, we will keep
special areas in NAND ash for the DTB and Linux kernel images:
So, lets start by erasing the corresponding 128 KiB of NAND ash for the DTB:
nand erase 0x140000 0x20000
(NAND offset) (size)
Then, lets erase the 5 MiB of NAND ash for the kernel image:
nand erase 0x160000 0x500000
Then, copy the DTB and kernel binaries from TFTP into memory, using the same addresses as
before.
Then, ash the DTB and kernel binaries:
nand write 0x22000000 0x140000 0x20000
(RAM addr) (NAND offset) (size)
nand write 0x21000000 0x160000 0x500000
Power your board o and on, to clear RAM contents. We should now be able to load the DTB
and kernel image from NAND and boot with:
nand read 0x22000000 0x140000 0x20000
(RAM addr) (offset) (size)
nand read 0x21000000 0x160000 0x500000
bootz 0x21000000 - 0x22000000
Write a U-Boot script that automates the DTB + kernel download and ashing procedure.
Finally, using editenv bootcmd, adjust bootcmd so that the Xplained board boots using the
kernel in ash.
Now, reset the board to check that it boots ne from NAND ash. Check that this is really
your own version of the kernel thats running.
Lab implementation
While (s)he develops a root lesystem for a device, a developer needs to make frequent changes
to the lesystem contents, like modifying scripts or adding newly compiled programs.
It isnt practical at all to reash the root lesystem on the target every time a change is made.
Fortunately, it is possible to set up networking between the development workstation and the
target. Then, workstation les can be accessed by the target through the network, using NFS.
Unless you test a boot sequence, you no longer need to reboot the target to test the impact of
script or application updates.
Setup
Go to the $HOME/embedded-linux-labs/tinysystem/ directory.
Kernel conguration
We will re-use the kernel sources from our previous lab, in $HOME/embedded-linux-labs/kernel/.
In the kernel conguration built in the previous lab, verify that you have all options needed for
booting the system using a root lesystem mounted over NFS, and if necessary, enable them
and rebuild your kernel.
Make sure that the path and the options are on the same line. Also make sure that there is no
space between the IP address and the NFS options, otherwise default options will be used for
this IP address, causing your root lesystem to be read-only.
Then, restart the NFS server:
sudo service nfs-kernel-server restart
Obviously, our root lesystem being mostly empty, there isnt such an application yet. In the
next paragraph, you will add Busybox to your root lesystem and nally make it usable.
Virtual lesystems
Run the ps command. You can see that it complains that the /proc directory does not exist.
The ps command and other process-related commands use the proc virtual lesystem to get
their information from the kernel.
From the Linux command line in the target, create the proc, sys and etc directories in your
root lesystem.
Now mount the proc virtual lesystem. Now that /proc is available, test again the ps command.
Note that you can also now halt your target in a clean way with the halt command, thanks to
proc being mounted6 .
Goals
After doing the A tiny embedded system lab, we are going to copy the lesystem contents to
the MMC ash drive. The lesystem will be split into several partitions, and your sama5d3
X-plained board will be booted with this MMC card, without using NFS anymore.
Setup
Throughout this lab, we will continue to use the root lesystem we have created in the $HOME/
embedded-linux-labs/tinysystem/nfsroot directory, which we will progressively adapt to use
block lesystems.
If your PC has an internal MMC/SD card reader, the device may also been seen as /dev/mmcblk0,
and the rst partition as mmcblk0p18 . You will see that the MMC/SD card is seen in the same
way by the board.
In the following instructions, we will assume that your MMC/SD card is seen as /dev/sdb by
your PC workstation.
Caution: read this carefully before proceeding. You could destroy existing parti-
tions on your PC!
Do not make the confusion between the device that is used by your board to repre-
sent your MMC/SD disk (probably /dev/sda), and the device that your workstation
uses when the card reader is inserted (probably /dev/sdb).
So, dont use the /dev/sda device to reash your MMC disk from your workstation.
People have already destroyed their Windows partition by making this mistake.
You can also run cat /proc/partitions to list all block devices in your system. Again, make
sure to distinguish the SD/MMC card from the hard drive of your development workstation!
Type the mount command to check your currently mounted partitions. If MMC/SD partitions
are mounted, unmount them:
$ sudo umount /dev/sdb*
Then, clear possible MMC/SD card contents remaining from previous training sessions:
$ sudo dd if=/dev/zero of=/dev/sdb bs=1M count=256
Now, lets use the cfdisk command to create the partitions that we are going to use:
$ sudo cfdisk /dev/sdb
In the cfdisk interface, delete existing partitions, then create three primary partitions, starting
from the beginning, with the following properties:
One partition, 64MB big, with the FAT16 partition type.
One partition, 8 MB big9 , that will be used for the root lesystem. Due to the geometry
of the device, the partition might be larger than 8 MB, but it does not matter. Keep the
Linux type for the partition.
One partition, that lls the rest of the MMC card, that will be used for the data lesystem.
Here also, keep the Linux type for the partition.
Press Write when you are done.
To make sure that partition denitions are reloaded on your workstation, remove the MMC card
and insert it again.
internal USB bus, and thus are visible in the same way external card readers are
9 For the needs of our system, the partition could even be much smaller, and 1 MB would be enough. However,
with the 8 GB SD cards that we use in our labs, 8 MB will be the smallest partition that cfdisk will allow you
to create.
partition. The goal is to use the third partition of the MMC card as the storage for the uploaded
images.
Connect the MMC disk to your board. You should see the MMC partitions in /proc/partitions.
Mount this third partition on /www/upload/files.
Once this works, modify the startup scripts in your root lesystem to do it automatically at
boot time.
Reboot your target system and with the mount command, check that /www/upload/files is
now a mount point for the third MMC disk partition. Also make sure that you can still upload
new images, and that these images are listed in the web interface.
Going further
At this point our board still uses the bootloaders (at91bootstrap and U-Boot) stored in the
NAND ash. Lets try to have everything on our MMC card.
The ROM code can load the rst stage bootloader from an SD card, from a le named BOOT.BIN
located in the rst FAT partition of an MMC card.
For this you will need to recompile at91bootstrap to support booting from an MMC card.
When testing, do not forget to remove the NAND CS jumper!
Setup
Stay in $HOME/embedded-linux-labs/tinysystem. Install the mtd-utils package, which will be
useful to create UBIFS and UBI images.
Goals
Instead of using an external MMC card as in the previous lab, we will make our system use its
internal ash storage.
We will create an MTD partition to be attached to the UBI layer (the partitions previously used
to store the kernel image and the DTB should be merged with this UBI partition).
The kernel and DTB images will be stored in two separate static (read-only) UBI volumes.
The root lesystem will be a UBI volume storing a UBIFS lesystem mounted read-only, the web
server upload data will be stored in another UBI volume storing a UBIFS lesystem mounted
read/write. These volumes will be dynamic volumes and will be 16 MiB large.
Which gives the following layout:
Recompile your kernel if needed. We will update your kernel image on ash in the next section.
Because of a bug in the UBI layer implemented by U-Boot, youll have to reboot the board after
ashing the UBI image.
Going further
Resizing an existing volume and creating a new one
In some cases you might need to adapt your NAND partitioning without re-ashing everything.
Thanks to UBI this is possible.
From Linux, resize the data volume to occupy 128 MiB, and then create a new log volume of
16MiB. Mount this volume as a UBIFS lesystem and see what happens.
Update your init script to mount the UBI log volume on /var/log. Reboot your system and
check that the log is correcly mounted.
Root lesystems are often a sensitive part of your system, and you dont want it to be corrupted,
hence some people decide to use a read-only le system for their rootfs and use another le system
to store their auxiliary data.
squashfs is one of these read-only le systems. However, squashfs expects to be mounted on a
block device.
Use the ubiblk layer to emulate a read-only block device on top of a static UBI volume to mount
a squashfs lesystem as the root lesystem:
First create a squashfs image with your rootfs contents
Then create a new static volume to store your squashfs and update it with your squashfs
image
Enable and setup the ubiblk layer
Boot on your new rootfs
Atomic update
UBI also provides an atomic update feature, which is particularly useful if you need to safely
upgrade sensitive parts of your system (kernel, DTB or rootfs).
Duplicate the kernel volume and create a U-Boot script to fallback on the second kernel volume
if the rst one is corrupted:
First create a new static volume to store your kernel backup
Flash a valid kernel on the backup volume
Modify your bootcmd to fallback to the backup volume if the rst one is corrupted
Now try to update the kernel volume and interrupt the process before it has nished and
see what happens (unplug the platform)
Create a shell script to automate kernel updates (executed in Linux). Be careful, this
script should also handle the case where the backup volume has been corrupted (copy the
contents of the kernel volume into the backup one)
To illustrate how to use existing libraries and applications, we will extend the small root lesys-
tem built in the A tiny embedded system lab to add the ALSA libraries and tools and an audio
playback application using these libraries.
Well see that manually re-using existing libraries is quite tedious, so that more automated
procedures are necessary to make it easier. However, learning how to perform these operations
manually will signicantly help you when you face issues with more automated tools.
Recompile your kernel with audio support. The options we want are: CONFIG_SOUND, CONFIG_SND,
CONFIG_SND_USB and CONFIG_SND_USB_AUDIO.
At this stage, the easiest solution to update your kernel is probably to get back to copying it
to RAM from tftp. Anyway, we will have to modify U-Boot environment variables, as we are
going to switch back to NFS booting anyway.
Make sure that your board still boots with this new kernel.
Were going to integrate the alsa-utils and ogg123 executables. As most software components,
they in turn depend on other libraries, and these dependencies are dierent depending on the
conguration chosen for them. In our case, the dependency chain for alsa-utils is quite simple,
it only depends on the alsa-lib library.
The dependencies are a bit more complex for ogg123. It is part of vorbis-tools, that depend
on libao and libvorbis. libao in turn depends on alsa-lib, and libvorbis on libogg.
libao, alsa-utils and alsa-lib are here to abstract the use of ALSA, one of the Audio Subsys-
tems supported in Linux. vorbis-tools, libvorbis and libogg are used to handle the audio
les encoded using the Ogg codec, which is quite common.
Of course, all these libraries rely on the C library, which is not mentioned here, because it is
already part of the root lesystem built in the A tiny embedded system lab. You might wonder
how to gure out this dependency tree by yourself. Basically, there are several ways, that can
be combined:
Read the library documentation, which often mentions the dependencies;
Read the help message of the configure script (by running ./configure --help).
By running the configure script, compiling and looking at the errors.
To congure, compile and install all the components of our system, were going to start from
the bottom of the tree with alsa-lib, then continue with alsa-utils, libao, libogg, and libvorbis, to
nally compile vorbis-tools.
Preparation
For our cross-compilation work, we will need two separate spaces:
A staging space in which we will directly install all the packages: non-stripped versions
of the libraries, headers, documentation and other les needed for the compilation. This
staging space can be quite big, but will not be used on our target, only for compiling
libraries or applications;
A target space, in which we will only copy the required les from the staging space: binaries
and libraries, after stripping, conguration les needed at runtime, etc. This target space
will take a lot less space than the staging space, and it will contain only the les that are
really needed to make the system work on the target.
To sum up, the staging space will contain everything thats needed for compilation, while the
target space will contain only whats needed for execution.
So, in $HOME/embedded-linux-labs/thirdparty, create two directories: staging and target.
For the target, we need a basic system with BusyBox, device nodes and initialization scripts.
We will re-use the system built in the A tiny embedded system lab, so copy this system in the
target directory:
cp -a $HOME/embedded-linux-labs/tinysystem/nfsroot/* target/
Note that for this lab, a lot of typing will be required. To save time typing, we advise you to
copy and paste commands from the electronic version of these instructions.
Testing
Make sure the target/ directory is exported by your NFS server to your board by modifying
/etc/exports and restarting your NFS server.
Make your board boot from this new directory through NFS.
alsa-lib
alsa-lib is a library supposed to handle the interaction with the ALSA subsystem. It is available
at http://alsa-project.org. Download version 1.0.28, and extract it in $HOME/embedded-
linux-labs/thirdparty/.
By looking at the configure script, we see that it has been generated by autoconf (the header
contains a sentence like Generated by GNU Autoconf 2.62). Most of the time, autoconf comes
with automake, that generates Makeles from Makefile.am les. So alsa-lib uses a rather com-
mon build system. Lets try to congure and build it:
./configure
make
You can see that the les are getting compiled with gcc, which generates code for x86 and not
for the target platform. This is obviously not what we want, so we clean-up the object and tell
the congure script to use the ARM cross-compiler:
make clean
CC=arm-linux-gcc ./configure
Of course, the arm-linux-gcc cross-compiler must be in your PATH prior to running the congure
script. The CC environment variable is the classical name for specifying the compiler to use.
Quickly, you should get an error saying:
checking whether we are cross compiling... configure: error: in `.../thirdparty/alsa-lib-1.0.28':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
If you look at the config.log le, you can see that the configure script compiles a binary with
the cross-compiler and then tries to run it on the development workstation. This is a rather
usual thing to do for a configure script, and thats why it tests so early that its actually doable,
and bails out if not.
Obviously, it cannot work in our case, and the scripts exits. The job of the configure script
is to test the conguration of the system. To do so, it tries to compile and run a few sample
applications to test if this library is available, if this compiler option is supported, etc. But in
our case, running the test examples is denitely not possible.
We need to tell the configure script that we are cross-compiling, and this can be done using
the --build and --host options, as described in the help of the configure script:
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
The --build option allows to specify on which system the package is built, while the --host
option allows to specify on which system the package will run. By default, the value of the
--build option is guessed and the value of --host is the same as the value of the --build
option. The value is guessed using the ./config.guess script, which on your system should
However, it also means that as a library developer, if you break the ABI of the library, you must
change the SONAME: change from libasound.so.2 to libasound.so.3.
Finally, the last step is to tell the configure script where the library is going to be installed.
Most configure scripts consider that the installation prex is /usr/local/ (so that the library
is installed in /usr/local/lib, the headers in /usr/local/include, etc.). But in our system,
we simply want the libraries to be installed in the /usr prex, so lets tell the configure script
about this:
CC=arm-linux-gcc ./configure --host=arm-linux --disable-python --prefix=/usr
make
For this library, this option may not change anything to the resulting binaries, but for safety, it
is always recommended to make sure that the prex matches where your library will be running
on the target system.
Do not confuse the prex (where the application or library will be running on the target system)
from the location where the application or library will be installed on your host while building
the root lesystem.
For example, libasound will be installed in $HOME/embedded-linux-labs/thirdparty/target/
usr/lib/ because this is the directory where we are building the root lesystem, but once our
target system will be running, it will see libasound in /usr/lib.
The prex corresponds to the path in the target system and never on the host. So, one
should never pass a prex like $HOME/embedded-linux-labs/thirdparty/target/usr, otherwise
at runtime, the application or library may look for les inside this directory on the target
system, which obviously doesnt exist! By default, most build systems will install the application
or library in the given prex (/usr or /usr/local), but with most build systems (including
autotools), the installation prex can be overridden, and be dierent from the conguration
prex.
We now only have the installation process left to do.
First, lets make the installation in the staging space:
make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging install
Now look at what has been installed by alsa-lib:
Some conguration les in /usr/share/alsa
The headers in /usr/include
The shared library and its libtool (.la) le in /usr/lib
A pkgcong le in /usr/lib/pkgconfig. Well come back to these later
Finally, lets install the library in the target space:
1. Create the target/usr/lib directory, it will contain the stripped version of the library
2. Copy the dynamic version of the library. Only libasound.so.2 and libasound.so.2.0.0
are needed, since libasound.so.2 is the SONAME of the library and libasound.so.2.0.0
is the real binary:
cp -a staging/usr/lib/libasound.so.2* target/usr/lib
3. Strip the library:
arm-linux-strip target/usr/lib/libasound.so.2.0.0
Alsa-utils
Download alsa-utils from the ALSA ocal webpage. We tested the lab with version 1.0.28.
Once uncompressed, we quickly discover that the alsa-utils build system is based on the autotools,
so we will work once again with a regular configure script.
As weve seen previously, we will have to provide the prex and host options and the CC variable:
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr
Now, we should quiclky get an error in the execution of the configure script:
checking for libasound headers version >= 1.0.27... not present.
configure: error: Sufficiently new version of libasound not found.
Again, we can check in config.log what the configure script is trying to do:
configure:7130: checking for libasound headers version >= 1.0.27
configure:7192: arm-linux-gnueabihf-gcc -c -g -O2 conftest.c >&5
conftest.c:15:28: fatal error: alsa/asoundlib.h: No such file or directory
Of course, since alsa-utils uses alsa-lib, it includes its header le! So we need to tell the C
compiler where the headers can be found: there are not in the default directory /usr/include/,
but in the /usr/include directory of our staging space. The help text of the configure script
says:
CPPFLAGS C/C++/Objective C preprocessor flags,
e.g. -I<includedir> if you have headers
in a nonstandard directory <includedir>
Lets use it:
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
Now, it should stop a bit later, this time with the error:
checking for libasound headers version >= 1.0.27... found.
checking for snd_ctl_open in -lasound... no
configure: error: No linkable libasound was found.
The configure script tries to compile an application against libasound (as can be seen from
the -lasound option): alsa-utils uses alsa-lib, so the configure script wants to make sure this
library is already installed. Unfortunately, the ld linker doesnt nd it. So, lets tell the linker
where to look for libraries using the -L option followed by the directory where our libraries
are (in staging/usr/lib). This -L option can be passed to the linker by using the LDFLAGS at
congure time, as told by the help text of the configure script:
LDFLAGS linker flags, e.g. -L<lib dir> if you have
libraries in a nonstandard directory <lib dir>
Lets use this LDFLAGS variable:
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
Once again, it should fail a bit further down the tests, this time complaining about a missing
curses helper header. curses or ncurses is a graphical framework to design UIs in the terminal.
This is only used by alsamixer, one of the tools provided by alsa-utils, that we are not going to
use. Hence, we can just disable the build of alsamixer.
Of course, if we wanted it, we would have had to build ncurses rst, just like we built alsa-lib.
We will also need to disable support for xmlto that generates the documentation.
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr \
--disable-alsamixer --disable-xmlto
Then, run the compilation with make. Hopefully, it works!
Lets now begin the installation process. Before really installing in the staging directory, lets
install in a dummy directory, to see whats going to be installed (this dummy directory will not
be used afterwards, it is only to verify what will be installed before polluting the staging space):
make DESTDIR=/tmp/alsa-utils/ install
The DESTDIR variable can be used with all Makeles based on automake. It allows to override
the installation directory: instead of being installed in the conguration prex directory, the
les will be installed in DESTDIR/configuration-prefix.
Now, lets see what has been installed in /tmp/alsa-utils/:
./lib/udev/rules.d/90-alsa-restore.rules
./usr/bin/aseqnet
./usr/bin/aseqdump
./usr/bin/arecordmidi
./usr/bin/aplaymidi
./usr/bin/aconnect
./usr/bin/alsaloop
./usr/bin/speaker-test
./usr/bin/iecset
./usr/bin/aplay
./usr/bin/amidi
./usr/bin/amixer
./usr/bin/alsaucm
./usr/sbin/alsaconf
./usr/sbin/alsactl
./usr/share/sounds/alsa/Side_Left.wav
./usr/share/sounds/alsa/Rear_Left.wav
./usr/share/sounds/alsa/Noise.wav
./usr/share/sounds/alsa/Front_Right.wav
./usr/share/sounds/alsa/Front_Center.wav
./usr/share/sounds/alsa/Side_Right.wav
./usr/share/sounds/alsa/Rear_Right.wav
./usr/share/sounds/alsa/Rear_Center.wav
./usr/share/sounds/alsa/Front_Left.wav
./usr/share/locale/ru/LC_MESSAGES/alsaconf.mo
./usr/share/locale/ja/LC_MESSAGES/alsaconf.mo
./usr/share/locale/ja/LC_MESSAGES/alsa-utils.mo
./usr/share/locale/fr/LC_MESSAGES/alsa-utils.mo
./usr/share/locale/de/LC_MESSAGES/alsa-utils.mo
./usr/share/man/fr/man8/alsaconf.8
./usr/share/man/man8/alsaconf.8
./usr/share/man/man1/aseqnet.1
./usr/share/man/man1/aseqdump.1
./usr/share/man/man1/arecordmidi.1
./usr/share/man/man1/aplaymidi.1
./usr/share/man/man1/aconnect.1
./usr/share/man/man1/alsaloop.1
./usr/share/man/man1/speaker-test.1
./usr/share/man/man1/iecset.1
./usr/share/man/man1/aplay.1
./usr/share/man/man1/amidi.1
./usr/share/man/man1/amixer.1
./usr/share/man/man1/alsactl.1
./usr/share/alsa/speaker-test/sample_map.csv
./usr/share/alsa/init/ca0106
./usr/share/alsa/init/hda
./usr/share/alsa/init/test
./usr/share/alsa/init/info
./usr/share/alsa/init/help
./usr/share/alsa/init/default
./usr/share/alsa/init/00main
So, we have:
The udev rules in lib/udev
The alsa-utils binaries in /usr/bin and /usr/sbin
Some sound samples in /usr/share/sounds
The various translations in /usr/share/locale
The manual pages in /usr/share/man/, explaining how to use the various tools
Some conguration samples in /usr/share/alsa.
Now, lets make the installation in the staging space:
make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging/ install
Then, lets install only the necessary les in the target space, manually:
cd ..
cp -a staging/usr/bin/a* staging/usr/bin/speaker-test target/usr/bin/
cp -a staging/usr/sbin/alsa* target/usr/sbin
arm-linux-strip target/usr/bin/a*
arm-linux-strip target/usr/bin/speaker-test
arm-linux-strip target/usr/sbin/alsactl
mkdir -p target/usr/share/alsa/pcm
cp -a staging/usr/share/alsa/alsa.conf* target/usr/share/alsa/
cp -a staging/usr/share/alsa/cards target/usr/share/alsa/
cp -a staging/usr/share/alsa/pcm/default.conf target/usr/share/alsa/pcm/
And were nally done with alsa-utils!
Now test that all is working ne by running the speaker-test util on your board, with the
headset provided by your instructor plugged in. You will need to add the missing libraries from
the toolchain install directory.
Caution: dont copy the dmix.conf le. speaker-test will tell you that it cannot nd this le,
but it wont work if you copy this le from the staging area.
The sound you get will be mainly noise (as what you would get by running speaker-test on
your PCs). At least, sound output is showing some signs of life! It will get much better when
we play samples with ogg123.
libogg
Now, lets work on libogg. Download the 1.3.2 version from http://xiph.org and extract it.
Conguring libogg is very similar to the conguration of the previous libraries:
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr
Of course, compile the library:
make
Installation to the staging space can be done using the classical DESTDIR mechanism:
make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging/ install
And nally, only install manually in the target space the les needed at runtime:
cd ..
cp -a staging/usr/lib/libogg.so.0* target/usr/lib/
arm-linux-strip target/usr/lib/libogg.so.0.8.2
Done with libogg!
libvorbis
Libvorbis is the next step. Grab the 1.3.4 version from http://xiph.org and uncompress it.
Once again, the libvorbis build system is a nice example of what can be done with a good usage
of the autotools. Cross-compiling libvorbis is very easy, and almost identical to what weve seen
with alsa-utils. First, the configure step:
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
It will fail with:
configure: error: Ogg >= 1.0 required !
By running ./configure --help, you will nd the --with-ogg-libraries and --with-ogg-
includes options. Use these:
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr \
--with-ogg-includes=$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
--with-ogg-libraries=$HOME/embedded-linux-labs/thirdparty/staging/usr/lib
Then, compile the library:
make
libao
Now, lets work on libao. Download the 1.2.0 version from http://xiph.org and extract it.
Conguring libao is once again fairly easy, and similar to every sane autotools based build
system:
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc ./configure --host=arm-linux \
--prefix=/usr
Of course, compile the library:
make
Installation to the staging space can be done using the classical DESTDIR mechanism:
make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging/ install
And nally, install manually the only needed les at runtime in the target space:
cd ..
cp -a staging/usr/lib/libao.so.4* target/usr/lib/
arm-linux-strip target/usr/lib/libao.so.4.1.0
We will also need the alsa plugin that is loaded dynamically by libao at startup:
mkdir -p target/usr/lib/ao/plugins-4/
cp -a staging/usr/lib/ao/plugins-4/libalsa.so target/usr/lib/ao/plugins-4/
Done with libao!
vorbis-tools
Finally, thanks to all the libraries we compiled previously, all the dependencies are ready. We
can now build the vorbis tools themselves. Download the 1.4.0 version from the ocial website,
at http://xiph.org/. As usual, extract the tarball.
Before starting the conguration, lets have a look at the available options by running ./
configure --help. Many options are available. We see that we can, in addition to the usual
autotools conguration options:
Enable/Disable the various tools that are going to be built: ogg123, oggdec, oggenc, etc.
Enable or disable support for various other codecs: FLAC, Speex, etc.
Enable or disable the use of various libraries that can optionally be used by the vorbis
tools
So, lets begin with our usual configure line:
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
At the end, you should see the following warning:
configure: WARNING: Prerequisites for ogg123 not met, ogg123 will be skipped.
Please ensure that you have POSIX threads, libao, and (optionally) libcurl
libraries and headers present if you would like to build ogg123.
Which is unfortunate, since we precisely want ogg123.
If you look back at the script output, you should see that at some point that it tests for libao
and fails to nd it:
checking for AO... no
configure: WARNING: libao too old; >= 1.0.0 required
If you look into the config.log le now, you should nd something like:
configure:22343: checking for AO
configure:22351: $PKG_CONFIG --exists --print-errors "ao >= 1.0.0"
Package ao was not found in the pkg-config search path.
Perhaps you should add the directory containing `ao.pc'
to the PKG_CONFIG_PATH environment variable
No package 'ao' found
In this case, the configure script uses the pkg-cong system to get the conguration parameters
to link the library against libao. By default, pkg-cong looks in /usr/lib/pkgconfig/ for .pc
les, and because the libao-dev package is probably not installed in your system the configure
script will not nd libao library that we just compiled.
It would have been worse if we had the package installed, because it would have detected and
used our host package to compile libao, which, since were cross-compiling, is a pretty bad thing
to do.
This is one of the biggest issue with cross-compilation: mixing host and target libraries, because
build systems have a tendency to look for libraries in the default paths.
So, now, we must tell pkg-cong to look inside the /usr/lib/pkgconfig/ directory of our staging
space. This is done through the PKG_CONFIG_PATH environment variable, as explained in the
manual page of pkg-config.
Moreover, the .pc les contain references to paths. For example, in $HOME/embedded-linux-
labs/thirdparty/staging/usr/lib/pkgconfig/ao.pc, we can see:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
[...]
Libs: -L${libdir} -lao
Cflags: -I${includedir}
So we must tell pkg-config that these paths are not absolute, but relative to our staging space.
This can be done using the PKG_CONFIG_SYSROOT_DIR environment variable.
Then, lets run the conguration of the vorbis-tools again, passing the PKG_CONFIG_PATH and
PKG_CONFIG_SYSROOT_DIR environment variables:
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
PKG_CONFIG_PATH=$HOME/embedded-linux-labs/thirdparty/staging/usr/lib/pkgconfig \
PKG_CONFIG_SYSROOT_DIR=$HOME/embedded-linux-labs/thirdparty/staging \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
Now, the configure script should end properly, we can now start the compilation:
make
It should fail rather quickly, complaining that the curl headers are missing. This is because the
configure script, in curls case, didnt actually test whether it was available or not, but just
assumed it was.
It may also fail with the following cryptic message:
make[2]: Entering directory
`/home/tux/embedded-linux-labs/thirdparty/vorbis-tools-1.4.0/ogg123'
if arm-linux-gcc -DSYSCONFDIR=\"/usr/etc\"
-DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I. -I..
-I/usr/include -I../include -I../intl
-I/home/tux/embedded-linux-labs/thirdparty/staging/usr/include -O2
-Wall -ffast-math -fsigned-char -g -O2 -MT audio.o -MD -MP -MF
".deps/audio.Tpo" -c -o audio.o audio.c; \
then mv -f ".deps/audio.Tpo" ".deps/audio.Po"; else rm -f
".deps/audio.Tpo"; exit 1; fi
In file included from /usr/include/stdio.h:27:0,
from audio.c:22:
/usr/include/features.h:398:23: fatal error: gnu/stubs.h: No such file
or directory
#include <gnu/stubs.h>
^
compilation terminated.
You can notice that /usr/include is added to the include paths. Again, this is not what we
want because it contains includes for the host, not the target. It is coming from the autodetected
value for CURL_CFLAGS.
Add the --without-curl option to the configure invocation, restart the compilation.
The compilation may then fail with an error related to libm. While the code uses the function
from this library, the generated Makele doesnt give the right command line argument in order
to link against the libm.
If you look at the configure help, you can see
LIBS libraries to pass to the linker, e.g. -l<library>
And this is exactly what we are supposed to use to add new linker ags.
Add this to the configure command line to get
LDFLAGS=-L$HOME/embedded-linux-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/embedded-linux-labs/thirdparty/staging/usr/include \
PKG_CONFIG_PATH=$HOME/embedded-linux-labs/thirdparty/staging/usr/lib/pkgconfig \
PKG_CONFIG_SYSROOT_DIR=$HOME/embedded-linux-labs/thirdparty/staging \
LIBS=-lm \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr --without-curl
Finally, it builds!
Now, install the vorbis-tools to the staging space using:
make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging/ install
And then install them in the target space:
cd ..
cp -a staging/usr/bin/ogg* target/usr/bin
arm-linux-strip target/usr/bin/ogg*
You can now test that everything works! Run ogg123 on the sample le found in thirdparty/
data, and everything should work ne (after copying a few extra C library objects if needed)!
Setup
Create the $HOME/embedded-linux-labs/buildroot directory and go into it.
Congure Buildroot
In our case, we would like to:
Going further
Flash the new system on the ash of the board
First, in buildroot, select the UBIFS lesystem image type.
Youll also need to provide buildroot some information on the underlying device
that will store the lesystem. In our case, the logical eraseblock size is 124KiB, the
minimum I/O unit size is 2048 and the Maximum logical eraseblock (LEB) count is
1000.
Then, once the image has been generated, update your rootfs volume.
Add dropbear (SSH server and client) to the list of packages built by Buildroot and log to
your target system using an ssh client on your development workstation. Hint: you will
have to set a non-empty password for the root account on your target for this to work.
Add a new package in Buildroot for the GNU Gtypist game. Read the Buildroot documen-
tation to see how to add a new package. Finally, add this package to your target system,
compile it and run it. The newest versions require a library that is not fully supported by
Buildroot, so youd better stick with the latest version in the 2.8 series.
Application development
Objective: Compile and run your own ncurses application on the
target.
Setup
Go to the $HOME/embedded-linux-labs/appdev directory.
12 Again, output/host/usr/bin has a special pkg-config that automatically knows where to look, so it already
Setup
Go back to the $HOME/embedded-linux-labs/buildroot directory.
Debugging setup
Boot your ARM board over NFS on the lesystem produced in the Using a build system, example
with Buildroot lab, with the same kernel.
Using strace
Now, go to the $HOME/embedded-linux-labs/debugging directory.
strace allows to trace all the system calls made by a process: opening, reading and writing les,
starting other processes, accessing time, etc. When something goes wrong in your application,
strace is an invaluable tool to see what it actually does, even when you dont have the source
code.
With your cross-compiling toolchain, compile the data/vista-emulator.c program, strip it with
arm-linux-strip, and copy the resulting binary to the /root directory of the root lesystem.
Back to target system, try to run the /root/vista-emulator program. It should hang inde-
nitely!
Interrupt this program by hitting [Ctrl] [C].
Now, running this program again through the strace command and understand why it hangs.
You can guess it without reading the source code!
Now add what the program was waiting for, and now see your program proceed to another bug,
failing with a segmentation fault.
Using ltrace
Now run the program through ltrace.
Now you should see what the program does: it tries to consume as much system memory as it
can!
Using gdbserver
We are now going to use gdbserver to understand why the program segfaults.
Compile vista-emulator.c again with the -g option to include debugging symbols. This time,
just keep it on your workstation, as you already have the version without debugging symbols
on your target.
Then, on the target side, run vista-emulator under gdbserver. gdbserver will listen on a TCP
port for a connection from gdb, and will control the execution of vista-emulator according to
the gdb commands:
gdbserver localhost:2345 vista-emulator
On the host side, run arm-linux-gdb (also found in your toolchain):
arm-linux-gdb vista-emulator
You can also start the debugger through the ddd interface:
ddd --debugger arm-linux-gdb vista-emulator
gdb starts and loads the debugging information from the vista-emulator binary that has been
compiled with -g.
Then, we need to tell where to nd our libraries, since they are not present in the default /lib
and /usr/lib directories on your workstation. This is done by setting the gdb sysroot variable
(on one line):
(gdb) set sysroot /home/<user>/embedded-linux-labs/buildroot/
buildroot-XXXX.YY/output/staging
And tell gdb to connect to the remote system:
(gdb) target remote <target-ip-address>:2345
If at this point you received timeout or packet error messages and if the gdbserver is stuck,
then you will have to remove /lib/libthread_db.so.1 from the target. This library allows
multithread debugging but this library is currently buggy for our conguration. Fortunately we
dont have to debug a multithread application.
Then, use gdb as usual to set breakpoints, look at the source code, run the application step by
step, etc. Graphical versions of gdb, such as ddd can also be used in the same way. In our case,
well just start the program and wait for it to hit the segmentation fault:
(gdb) continue
You could then ask for a backtrace to see where this happened:
(gdb) backtrace
This will tell you that the segmentation fault occurred in a function of the C library, called by
our program. This should help you in nding the bug in our application.
What to remember
During this lab, we learned that...
Its easy to study the behavior of programs and diagnose issues without even having the
source code, thanks to strace.
You can leave a small gdbserver program (300 KB) on your target that allows to debug
target applications, using a standard gdb debugger on the development host.
It is ne to strip applications and binaries on the target machine, as long as the programs
and libraries with debugging symbols are available on the development host.
Setup
Go to the $HOME/embedded-linux-labs/realtime/rttest directory.
Install the netcat package.
Root lesystem
Create an nfsroot directory.
To compare real-time latency between standard Linux and Xenomai, we are going to need a
root lesystem and a build environment that supports Xenomai.
Lets build this with Buildroot.
Reuse and extract the Buildroot 2014.11 sources. Congure Buildroot with the following set-
tings, using the / command in make menuconfig to nd parameters by their name:
In Target:
Target architecture: ARM (little endian)
Target Architecture Variant: cortex-a5
In Toolchain:
Toolchain type: External toolchain
Toolchain: Sourcery CodeBench ARM 2013.11
In System configuration:
/dev management: Dynamic using devtmpfs only
in getty options, TTY port: ttyS0
In Target packages:
Enable Show packages that are also provided by busybox. We need this to build
the standard netcat command, not provided in the default BusyBox conguration.
In Debugging, profiling and benchmark, enable rt-tests. This will be a few
applications to test real-time latency.
In Networking applications, enable netcat
In Real-Time, enable Xenomai Userspace:
* Enable Install testsuite
* Make sure that POSIX skin library is enabled.
Now, build your root lesystem.
At the end of the build job, extract the output/images/rootfs.tar archive in the nfsroot
directory.
The last thing to do is to add a few les that we will need in our tests:
cp data/* nfsroot/root
Have a look at the rttest.c source le available in root/ in the nfsroot/ directory. See how it
shows the resolution of the CLOCK_MONOTONIC clock.
Now compile this program:
arm-none-linux-gnueabi-gcc -o rttest rttest.c -lrt
Execute the program on the board. Is the clock resolution good or bad? Compare it to the
timer tick of your system, as dened by CONFIG_HZ.
Obviously, this resolution will not provide accurate sleep times, and this is because our kernel
doesnt use high-resolution timers. So lets enable the CONFIG_HIGH_RES_TIMERS option in the
kernel conguration.
Recompile your kernel, boot your Xplained with the new version, and check the new resolution.
Better, isnt it?
Compile your kernel, and in the meantime, compile rttest for the Xenomai POSIX skin:
cd $HOME/embedded-linux-labs/realtime/rttest/nfsroot/root
export PATH=$HOME/embedded-linux-labs/realtime/rttest/buildroot-2014.11/output/host/usr/bin:$PATH
arm-none-linux-gnueabi-gcc -o rttest rttest.c \
$(pkg-config --libs --cflags libxenomai_posix)