Embedded Linux Labs

8/10/2019 Embedded Linux Labs

1/53

Embedded Linux Training

Lab Book

Free Electronshttp://free-electrons.com

September 5, 2014
http://free-electrons.com/http://free-electrons.com/


2/53

Free Electrons Embedded Linux Training

About this document

Updates to this document can be found on http://free-electrons.com/doc/training/embedded-linux{}/.

This document was generated from LaTeX sources found on http://git.free-electrons.com/training-materials.

More details about our training sessions can be found on http://free-electrons.com/training.

Copying this document

2004-2014, Free Electrons, http://free-electrons.com.

This document is released under the terms of the Creative Commons CC BY-SA3.0 license. This means that you are free to download, distribute and even modifyit, under certain conditions.

Corrections, suggestions, contributions and translations are welcome!

2 2004-2014Free Electrons,CC BY-SA license
http://free-electrons.com/doc/training/embedded-linux%7B%7D/http://free-electrons.com/doc/training/embedded-linux%7B%7D/http://free-electrons.com/doc/training/embedded-linux%7B%7D/http://git.free-electrons.com/training-materialshttp://git.free-electrons.com/training-materialshttp://git.free-electrons.com/training-materialshttp://free-electrons.com/traininghttp://free-electrons.com/traininghttp://free-electrons.com/http://free-electrons.com/http://creativecommons.org/licenses/by-sa/3.0/http://creativecommons.org/licenses/by-sa/3.0/http://free-electrons.com/http://free-electrons.com/http://free-electrons.com/http://creativecommons.org/licenses/by-sa/3.0/http://creativecommons.org/licenses/by-sa/3.0/http://free-electrons.com/http://free-electrons.com/traininghttp://free-electrons.com/traininghttp://git.free-electrons.com/training-materialshttp://git.free-electrons.com/training-materialshttp://free-electrons.com/doc/training/embedded-linux%7B%7D/http://free-electrons.com/doc/training/embedded-linux%7B%7D/


3/53


Training setupDownload files and directories used in practical labs

Install lab data

For the different labs in the training, your instructor has prepared a set of data (kernel images,kernel configurations, root filesystems and more). Download and extract its tarball from aterminal:

cd

wget http://free-electrons.com/doc/training/embedded-linux/embedded-linux-labs.tar.xz

sudo tar Jvxf embedded-linux-labs.tar.xz

sudo chown -R . embedded-linux-labs

Note that using rootpermissions are required to extract the character and block device filescontained in this lab archive. This is an exception. For all the other archives that you willhandle during the practical labs, you will never need root permissions to extract them. Ifthere is another exception, we will let you know.

Lab data are now available in an embedded-linux-labsdirectory in your home directory.For each lab there is a directory containing various data. This directory will also be used asworking space for each lab, so that the files that you produce during each lab are kept separate.

You are now ready to start the real practical labs!

Install extra packages

Ubuntu comes with a very limited version of the vi editor. Installvim, a improved version ofthis editor.

sudo apt-get install vim

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 first one which is issued. Somepeople stumble on very simple errors just because they specified a wrong file path anddidnt pay enough attention to the corresponding error message.

Never stay stuck with a strange problem more than 5 minutes. Show your problem toyour colleagues or to the instructor.

You should only use the root user for operations that require super-user privileges, suchas: mounting a file system, loading a kernel module, changing file ownership, configur-

2004-2014Free Electrons, CC BY-SA license 3


4/53


ing the network. Most regular tasks (such as downloading, extracting sources, compil-ing...) can be done as a regular user.

If you ran commands from a root shell by mistake, your regular user may no longerbe able to handle the corresponding generated files. In this case, use the chown -R

command to give the new files back to your regular user.Example:chown -R myuser.myuser linux-3.4

http://free-electrons.com/http://free-electrons.com/http://free-electrons.com/


5/53


Building a cross-compiling toolchain

Objective: Learn how to compile your own cross-compiling toolchain forthe uClibc C library

After this lab, you will be able to:

Configure thecrosstool-ngtool

Execute crosstool-ngand build up your own cross-compiling toolchain

Setup

Go to the $HOME/embedded-linux-labs/toolchaindirectory.

Install needed packages

Install the packages needed for this lab:

sudo apt-get install autoconf automake libtool libexpat1-dev \

libncurses5-dev bison flex patch curl cvs texinfo git bc \

build-essential subversion gawk python-dev gperf unzip \

pkg-config wget

Getting Crosstool-ngWe will need a recent version of Crosstool-ng for this lab, including code that is not part of arelease yet so we will use git to download it:

git clone http://crosstool-ng.org/git/crosstool-ng

cd crosstool-ng/

git checkout 71074b7f822c

Installing Crosstool-ng

We can either install Crosstool-ng globally on the system, or keep it locally in its downloaddirectory. 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



6/53


Configure the toolchain to produce

A single installation of Crosstool-ng allows to produce as many toolchains as you want, fordifferent architectures, with different C libraries and different versions of the various compo-nents.

Crosstool-ng comes with a set of ready-made configuration files for various typical setups:Crosstool-ng calls themsamples. They can be listed by using ./ct-ng list-samples.

We will use the arm-cortexa5-linux-uclibcgnueabihf sample. It can be loaded byissuing:

./ct-ng arm-cortexa5-linux-uclibcgnueabihf

Then, to refine the configuration, lets run the menuconfiginterface:

./ct-ng menuconfig

InPath and misc options:

Change Prefix directory to /usr/local/xtools/${CT_TARGET}. This is theplace where the toolchain will be installed.

Change Maximum log level to seeto DEBUGso that we can have more details onwhat happened during the build in case something went wrong.

InToolchain options:

Set Tuples aliasto arm-linux. This way, we will be able to use the compiler asarm-linux-gcc instead of arm-unknown-linux-uclibcgnueabihf-gcc, whichis much longer to type.

InDebug facilities:

Make sure thatgdbis enabled.

Remove the other options (dmalloc,duma),straceandltrace

In gdb options, make sure that the Cross-gdb and Build a static gdbserver op-tions are enabled; the other options are not needed.

Explore the different other available options by traveling through the menus and looking atthe help for some of the options. Dont hesitate to ask your trainer for details on the availableoptions. However, remember that we tested the labs with the configuration described above.You might waste time with unexpected issues if you customize the toolchain configuration.

Produce the toolchain

First, create the directory /usr/local/xtools/and change its owner to your user, so thatCrosstool-ng can write to it.

Then, create the directory $HOME/src in which Crosstool-NG will save the tarballs it willdownload.

Nothing is simpler:

./ct-ng build

And wait!



7/53


Known issues

Source archives not found on the Internet

It is frequent that Crosstool-ng aborts because it cant find 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 In-ternet, and copy such an archive to the src directory in your home directory. Note that evensource archives compressed in a different way (for example, ending with .gz instead of.bz2)will be fine too. Then, all you have to do is run ./ct-ng buildagain, and it will use thesource archive that you downloaded.

ppl-0.10.2 compiling error with gcc 4.7.1

If you are using gcc 4.7.1, for example in Ubuntu 12.10 (not officially supported in these labs),

compilation will fail in ppl-0.10.2with the below error:error: 'f_info' was not declared in this scope

One solution is to add the -fpermissiveflag to the CT_EXTRA_FLAGS_FOR_HOSTsetting(inPath and misc options -> Extra host compiler flags).

Testing the toolchain

You can now test your toolchain by adding /usr/local/xtools/arm-unknown-linux-uclibcgnueabihf/bin/ to your PATH environment variable and compiling the simple hello.cprogram in your main lab directory with arm-linux-gcc.

You can use the file command on your binary to make sure it has correctly been compiled

for the ARM architecture.

Cleaning up

To save about 3 GB of storage space, do a ./ct-ng cleanin the Crosstool-NG source direc-tory. This will remove the source code of the different toolchain components, as well as all thegenerated files that are now useless since the toolchain has been installed in /usr/local/xtools.



8/53


Bootloader - U-BootObjectives: Set up serial communication, compile and install the U-Bootbootloader, use basic U-Boot commands, set up TFTP communicationwith the development workstation.

As the bootloader is the first piece of software executed by a hardware platform, the installationprocedure of the bootloader is very specific to the hardware platform. There are usually twocases:

The processor offers nothing to ease the installation of the bootloader, in which case theJTAG has to be used to initialize flash storage and write the bootloader code to flash.Detailed knowledge of the hardware is of course required to perform these operations.

The processor offers a monitor, implemented in ROM, and through which access to thememories is made easier.

The Xplained board, which uses the SAMA5D3 SoCs, falls into the second category. The mon-itor integrated in the ROM reads the MMC/SD card to search for a valid bootloader beforelooking at the internal NAND flash for a bootloader. Whenever nothings available, it will op-erate in a fallback mode, that will allow to use an external tool through USB to reflash some

bootloader. Therefore, either by using an MMC/SD card or that fallback mode, we can start upa SAMA5D3-based board without having anything installed on it.

Setup

Go to the/embedded-linux-labs/bootloader directory.If you are using a 64 bit installation of Ubuntu, install support for executables built with a 32

bit C library:

sudo apt-get install ia32-libs

Were going to use that fallback mode, and its associated tool, sam-ba.

We first need to download this tool, from Atmels website.

wget http://www.atmel.com/Images/sam-ba_2.12.zip

unzip sam-ba_2.12.zip

Setting up serial communication with the board

Plug the USB-to-serial cable on the Xplained board. The blue end of the cable is going to GNDon J23, red on RXD and green on TXD. When plugged in your computer, a serial port shouldappear,/dev/ttyUSB0.

You can also see this device appear by looking at the output ofdmesg.

To communicate with the board through the serial port, install a serial communication pro-gram, such aspicocom:

sudo apt-get install picocom



9/53


You also need to make your user belong to the dialoutgroup to be allowed to write to theserial console:

sudo adduser $USER dialout

You need to log out and in again for the group change to be effective.

Run picocom -b 115200 /dev/ttyUSB0, to start serial communication on /dev/ttyUSB0,with a baudrate of 115200. If you wish to exit picocom, press [Ctrl][a] followed by [Ctrl][x].

AT91Bootstrap Setup

The boot process is done in two steps with the ROM monitor trying to execute a first piece ofsoftware, calledAT91Bootstrap, from its internal SRAM, that will initialize the DRAM, loadU-Bootthat will in turn load Linux and execute it.

As far as bootloaders are concerned, the layout of the NAND flash will look like:

Offset 0x0 for the first stage bootloader is dictated by the hardware: the ROM code of theSAMA5D3 looks for a bootloader at offset 0x0 in the NAND flash.

Offset0x40000for the second stage bootloader is decided by the first stage bootloader.This can be changed by changing the AT91Bootstrap configuration.

Offset0xc0000of the U-Boot environment is decided by U-Boot. This can be changedby modifying the U-Boot configuration.

The first item to compile is AT91Bootstrap that you can fetch from Atmels github account:

git clone git://github.com/linux4sam/at91bootstrap.git -b at91bootstrap-3.x

cd at91bootstrap

Then, we first need to configure the build system for our setup. Were going to need a fewinformations 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



10/53


You can get the list of the supported board by listing the board directory. Youll see that in eachof these folder, we have a bunch ofdefconfigfiles, that are the supported combinations. Inour case, we will load U-Boot, from the NAND.

Then, youve found the right defconfig, load it using make , and you

can start the compilation using make1

. Dont forget to set the CROSS_COMPILEenvironmentvariable!

At the end of the compilation, you should have a file called sama5d3_xplained-nandflashboot-uboot-*.bin, in thebinariesfolder.

In order to flash it, we need to do a few things. First, remove the NAND CS jumper on theboard. Its next to the pin header closest to the Micro-USB plug. Reset the board, and put thejumper back. On the serial port, you should see RomBoot.

Then, start sam-ba as root. Youll get a small window. Select the ttyACM0connection, andthe at91sama5d3x-ekboard. HitConnect.

You need to:

Hit the NANDFlash tab

In the scripts choices, selectEnable NandFlashand hit Execute

SelectErase All, and execute the command

Then, select Enable OS PMECC parameters in order to change the NAND ECC parame-ters to what RomBOOT expects. Change the number of ECC bits to 4, and the ECC offsetto 36.

Finally, send the image we just compiled using the commandSend Boot File

AT91Bootstrap should be flashed now, keep sam-ba opened, and move to the next section.

U-Boot setup

Download U-Boot:

wget ftp://ftp.denx.de/pub/u-boot/u-boot-2014.07.tar.bz2

Were going to use a specific U-Boot version, 2014.07, which we have tested to work on theAtmel Xplained board. More recent versions may also work, but we have not tested them.

Get an understanding of its configuration and compilation steps by reading the READMEfile,and specifically theBuilding the Softwaresection.

Basically, you need to:

set theCROSS_COMPILEenvironment variable;

run make _config, where is the name of your board as declared in

theboards.cfgfile. There are two flavors of the Xplained: one to run from the SD card(sama5d3_xplained_mmc) and one to run from the NANDflash (sama5d3_xplained_nandflash). Since were going to boot on the NAND, use the latter. Note that for ourplatform, both these choices are sharing most of their configuration, that is defined ininclude/configs/sama5d3_xplained.h. Read this file to get an idea of how a U-Boot configuration file is written;

Finally, runmake, which should build U-Boot.

1You can speed up the compiling by using the - jXoption withmake, where X is the number of parallel jobs usedfor compiling. Twice the number of CPU cores is a good value.



11/53


Now, in sam-ba, in the Send File Namefield, set the path to the u-boot.binthat was justcompiled, and set the address to 0x40000. Click on theSend Filebutton.

Testing U-Boot

Reset the board and check that it boots your new bootloaders. You can verify this by checkingthe build dates:

AT91Bootstrap 3.6.2-00090-g1e8fd41ce714 (mercredi 4 juin 2014, 11:08:41 (UTC+

NAND: ONFI flash detected

NAND: Manufacturer ID: 0x2c Chip ID: 0x32

NAND: Disable On-Die ECC

NAND: Initialize PMECC params, cap: 0x4, sector: 0x200

NAND: Image: Copy 0x80000 bytes from 0x40000 to 0x26f00000

NAND: Done to load image

U-Boot 2014.07 (Aug 26 2014 - 09:47:25)

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

Warning: failed to set MAC address

, macb0

Warning: failed to set MAC address

Interrupt the countdown to enter the U-Boot shell:

U-Boot #

In U-Boot, type thehelpcommand, and explore the few commands available.

Setting up Ethernet communication

Later on, we will transfer files from the development workstation to the board using the TFTPprotocol, which works on top of an Ethernet connection.

To start with, install and configure a TFTP server on your development workstation, as detailedin the bootloader slides.

With a network cable, connect the Ethernet port of your board to the one of your computer.If your computer already has a wired connection to the network, your instructor will provideyou with a USB Ethernet adapter. A new network interface, probablyeth1or eth2, shouldappear on your Linux system.



12/53


To configure this network interface on the workstation side, click on the Network Managertasklet on your desktop, and select Edit Connections.

Select the newwired network connection:

In the IPv4 Settings tab, press the Add button and make the interface use a static IP ad-dress, like 192.168.0.1 (of course, make sure that this address belongs to a separate networksegment from the one of the main company network).



13/53


You can use 255.255.255.0 as Netmask, and leave the Gateway field untouched (if youclick on the Gatewaybox, you will have to type a valid IP address, otherwise you wont beapply to click on theApplybutton).

Now, configure the network on the board in U-Boot by setting the ipaddr and serverip

environment variables:setenv ipaddr 192.168.0.100

setenv serverip 192.168.0.1

The first time you use your board, you also need to send the MAC address in U-boot:

setenv ethaddr 00:01:02:03:04:05

In case the board was previously configured in a different way, we also turn off automaticbooting after commands that can be used to copy a kernel to RAM:

setenv autostart no

To make these settings permanent, save the environment:

saveenv

Now switch your board off and on again2.

You can then test the TFTP connection. First, put a small text file in the directory exportedthrough TFTP on your development workstation. Then, from U-Boot, do:

tftp 0x22000000 textfile.txt

2Power cycling your board is needed to make your ethaddrpermanent, for obscure reasons. If you dont, U-bootwill complain thatethaddris not set.



14/53


Caution: known issue in Ubuntu 12.04 and later: if this command doesnt work, you mayhave to stop the server and start it again every time you boot your workstation:

sudo service tftpd-hpa restart

The tftp command should have downloaded the textfile.txt file from your development

workstation into the boards memory at location 0x22000000 (this location is part of the boardDRAM). You can verify that the download was successful by dumping the contents of thememory:

md 0x22000000

We will see in the next labs how to use U-Boot to download, flash and boot a kernel.

Rescue binaries

If you have trouble generating binaries that work properly, or later make a mistake that causesyou to loose your bootloader binaries, you will find working versions under data/ in thecurrent lab directory.



15/53


Kernel sourcesObjective: Learn how to get the kernel sources and patch them.


Get the kernel sources from the official location

Apply kernel patches

Setup

Create the $HOME/embedded-linux-labs/kerneldirectory and go into it.

Get the sources

Go to the Linux kernel web site (http://www.kernel.org/) and identify the latest stableversion.

Just to make sure you know how to do it, check the version of the Linux kernel running onyour machine.

We will use linux-3.14.x, which this lab was tested with.

To practice the patch command later, download the full 3.13 sources. Unpack the archive,which creates a linux-3.13 directory. Remember that you can use wget on thecommand line to download files.

Apply patches

Download the 2 patch files corresponding to the latest 3.14 stable release: a first patch to movefrom 3.13 to 3.14 and a second patch to move from 3.14 to 3.14.x.

Without uncompressing them (!), apply the 2 patches to the Linux source directory.

View one of the 2 patch files with vi or gvim(if you prefer a graphical editor), to understandthe information carried by such a file. How are described added or removed files?

Rename the linux-3.13directory tolinux-3.14..

http://www.kernel.org/http://www.kernel.org/http://free-electrons.com/http://free-electrons.com/http://www.kernel.org/


16/53


Kernel - Cross-compiling

Objective: Learn how to cross-compile a kernel for an ARM target plat-form.


Set up a cross-compiling environment

Configure the kernel Makefile accordingly

Cross compile the kernel for the Atmel SAMA5D3 Xplained ARM board

Use U-Boot to download the kernel

Check that the kernel you compiled starts the system

Setup

Go to the $HOME/embedded-linux-labs/kerneldirectory.

Install the package libqt4-devwhich is needed for thexconfigkernel configuration inter-face.

Target system

We are going to cross-compile and boot a Linux kernel for the Atmel SAMA5D3 Xplainedboard.

Kernel sources

We will re-use the kernel sources downloaded and patched in the previous lab.

Cross-compiling environment setup

To cross-compile Linux, you need to have a cross-compiling toolchain. We will use the cross-compiling toolchain that we previously produced, so we just need to make it available in the

PATH:

export PATH=/usr/local/xtools/arm-unknown-linux-uclibcgnueabihf/bin:$PATH

Also, dont forget to either:

Define the value of the ARCH and CROSS_COMPILE variables in your environment (usingexport)

Orspecify them on the command line at every invocation ofmake, i.e: make ARCH=...CROSS_COMPILE=...



17/53


Linux kernel configuration

By running make help, find the proper Makefile target to configure the kernel for the Xplainedboard (hint: the default configuration is not named after the board, but after the SoC name).Once found, use this target to configure the kernel with the ready-made configuration.

Dont hesitate to visualize the new settings by running make xconfigafterwards!

In the kernel configuration, as an experiment, change the kernel compression from Gzip to XZ.This compression algorithm is far more efficient than Gzip, in terms of compression ratio, atthe expense of a higher decompression time.

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 if you have

multiple cores on your machine!

Look at the end of the kernel build output to see which file contains the kernel image. You canalso see the Device Tree.dtbfiles which got compiled. Find which .dtbfile corresponds toyour board.

Setting up serial communication with the board

Plug the Xplained board on your computer. Start Picocom on /dev/ttyS0, or on /dev/ttyUSB0if you are using a serial to USB adapter.

You should now see the U-Boot prompt:

U-Boot #

Make sure that the bootargs U-Boot environment variable is not set (it could remain from aprevious training session, and this could disturb the next lab):

setenv bootargs

saveenv

Load and boot the kernel using U-Boot

We will use TFTP to load the kernel image to the Xplained board:

On your workstation, copy the zImage and DTB files to the directory exposed by theTFTP server.

On the target, loadzImagefrom TFTP into RAM at address 0x21000000:tftp 0x21000000 zImage

Now, also load the DTB file into RAM at address 0x22000000:tftp 0x22000000 at91-sama5d3_xplained.dtb

Boot the kernel with its device tree:bootz 0x21000000 - 0x22000000

You should see Linux boot and finally crashing. This is expected: we havent provided a work-ing root filesystem for our device yet.



18/53


You can now automate all this every time the board is booted or reset. Reset the board, andspecify a differentbootcmd:

setenv bootcmd 'tftp 0x21000000 zImage; tftp 0x22000000 at91-sama5d3_xplained.dtb; bootz 0x21000000 - 0x22000000'

saveenv

Flashing the kernel and DTB in NAND flash

In order to let the kernel boot on the board autonomously, we can flash the kernel image andDTB in the NAND flash available on the Xplained board.

After storing the first stage bootloader, U-boot and its environment variables, we will keepspecial areas in NAND flash for the DTB and Linux kernel images:

So, lets start by erasing the corresponding 128 KiB of NAND flash for the DTB:

nand erase 0x140000 0x20000

(NAND offset) (size)

Then, lets erase the 5 MiB of NAND flash for the kernel image:

nand erase 0x160000 0x500000

Then, copy the DTB and kernel binaries from TFTP into memory, using the same addresses asbefore.

Then, flash the DTB and kernel binaries:

nand write 0x22000000 0x140000 0x20000

(RAM addr) (NAND offset) (size)

nand write 0x21000000 0x160000 0x500000

Power your board off and on, to clear RAM contents. We should now be able to load the DTBand kernel image from NAND and boot with:

nand read 0x22000000 0x140000 0x20000

(RAM addr) (offset) (size)

nand read 0x21000000 0x160000 0x500000bootz 0x21000000 - 0x22000000

Write a U-Boot script that automates the DTB + kernel download and flashing procedure. Fi-nally, adjustbootcmdso that the Xplained board boots using the kernel in Flash.

Now, power off the board and power it on again to check that it boots fine from NAND flash.Check that this is really your own version of the kernel thats running.



19/53


Tiny embedded system with BusyBox

Objective: making a tiny yet full featured embedded system

After this lab, you will:

be able to configure and build a Linux kernel that boots on a directory on your worksta-tion, shared through the network by NFS.

be able to create and configure a minimalistic root filesystem from scratch (ex nihilo, outof nothing, entirely hand made...) for the Xplained board

understand how small and simple an embedded Linux system can be.

be able to install BusyBox on this filesystem.

be able to create a simple startup script based on /sbin/init.

be able to set up a simple web interface for the target.

have an idea of how much RAM a Linux kernel smaller than 1 MB needs.

Lab implementation

While (s)he develops a root filesystem for a device, a developer needs to make frequent changesto the filesystem contents, like modifying scripts or adding newly compiled programs.

It isnt practical at all to reflash the root filesystem on the target every time a change is made.Fortunately, it is possible to set up networking between the development workstation and thetarget. Then, workstation files 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 ofscript or application updates.

Setup

Go to the $HOME/embedded-linux-labs/tinysystem/directory.



20/53


Kernel configuration

We will re-use the kernel sources from our previous lab, in $HOME/embedded-linux-labs/kernel/.

In the kernel configuration built in the previous lab, verify that you have all options needed forbooting the system using a root filesystem mounted over NFS, and if necessary, enable themand rebuild your kernel.

Setting up the NFS server

Create a nfsrootdirectory in the current lab directory. This nfsrootdirectory will be usedto store the contents of our new root filesystem.

Install the NFS server by installing the nfs-kernel-server package if you dont have it yet.Once installed, edit the /etc/exports file as root to add the following line, assuming thatthe IP address of your board will be192.168.0.100:

/home//embedded-l inux-labs/tinysystem/nfsr oot 192.168.0.100(rw,no_root_ squash,no_subtree_check)

Make sure that the path and the options are on the same line. Also make sure that there is nospace between the IP address and the NFS options, otherwise default options will be used forthis IP address, causing your root filesystem to be read-only.

Then, restart the NFS server:

sudo service nfs-kernel-server restart

Booting the system

First, boot the board to the U-Boot prompt. Before booting the kernel, we need to tell it that theroot filesystem should be mounted over NFS, by setting some kernel parameters.

Use the following U-Boot command to do so, in just 1 line

setenv bootargs console=ttyS0,115200 root=/dev/nfs ip=192.168.0.100:::::eth0

nfsroot=192.168.0.1:/home//embedded-linux-labs/tinysystem/nfsroot rw

Of course, you need to adapt the IP addresses to your exact network setup. Save the environ-ment variables (withsaveenv).

You will later need to make changes to thebootargsvalue. Dont forget you can do this withtheeditenvcommand.

Now, boot your system. The kernel should be able to mount the root filesystem over NFS:

VFS: Mounted root (nfs filesystem) on device 0:13.

If the kernel fails to mount the NFS filesystem, look carefully at the error messages in theconsole. If this doesnt give any clue, you can also have a look at the NFS server logs in /var/log/syslog.

However, at this stage, the kernel should stop because of the below issue:

[ 7.476715] devtmpfs: error mounting -2

This happens because the kernel is trying to mount the devtmpfs filesystem in /dev/ in the rootfilesystem. To address this, create adevdirectory undernfsrootand reboot.

Now, the kernel should complain for the last time, saying that it cant find an init application:



21/53


Kernel panic - not syncing: No init found. Try passing init= option to kernel.

See Linux Documentation/init.txt for guidance.

Obviously, our root filesystem being mostly empty, there isnt such an application yet. In thenext paragraph, you will add Busybox to your root filesystem and finally make it usable.

Root filesystem with Busybox

Download the sources of the latest BusyBox 1.21.x release.

To configure BusyBox, we wont be able to use make xconfig, which is currently broken inUbuntu 12.04, because of Qt library dependencies.

We are going to use make gconfig this time. Before doing this, install the required packages:

sudo apt-get install libglade2-dev

Now, configure BusyBox with the configuration file provided in the data/directory (remem-ber that the Busybox configuration file is.configin the Busybox sources).

If you dont use the BusyBox configuration file that we provide, at least, make sure you buildBusyBox statically! Compiling Busybox statically in the first place makes it easy to set up thesystem, because there are no dependencies on libraries. Later on, we will set up shared librariesand recompile Busybox.

Build BusyBox using the toolchain that you used to build the kernel.

Going back to the BusyBox configuration interface specify the installation directory for Busy-Box 3 .It should be the path to your nfsrootdirectory.

Now run make installto install BusyBox in this directory.

Try to boot your new system on the board. You should now reach a command line prompt,allowing you to execute the commands of your choice.

Virtual filesystemsRun theps command. You can see that it complains that the /procdirectory does not exist.The ps command and other process-related commands use the procvirtual filesystem to gettheir information from the kernel.

From the Linux command line in the target, create the proc, sys and etc directories in yourroot filesystem.

Now mount the procvirtual filesystem. Now that /procis available, test again the ps com-mand.

Note that you can also now halt your target in a clean way with the haltcommand, thanks toprocbeing mounted 4 .

System configuration and startup

The first user space program that gets executed by the kernel is /sbin/initand its configu-ration file is/etc/inittab.

In the BusyBox sources, read details about/etc/inittabin theexamples/inittabfile.

3You will find this setting in Install Options -> BusyBox installation prefix.4halt can find the list of mounted filesystems in /proc/mounts, and unmount each of them in a clean way before

shutting down.



22/53


Then, create a /etc/inittab file and a /etc/init.d/rcS startup script declared in /etc/inittab. In this startup script, mount the/procand/sysfilesystems.

Any issue after doing this?

Switching to shared librariesTake the hello.c program supplied in the lab data directory. Cross-compile it for ARM,dynamically-linked with the libraries, and run it on the target.

You will first encounter a not founderror caused by the absence of the ld-uClibc.so.0executable, which is the dynamic linker required to execute any program compiled with sharedlibraries. Using the find command (see examples in your command memento sheet), look forthis file in the toolchain install directory, and copy it to the lib/directory on the target.

Then, running the executable again and see that the loader executes and finds out which sharedlibraries are missing. Similarly, find these libraries in the toolchain and copy them to lib/onthe target.

Once the small test program works, we are going to recompile Busybox without the static com-pilation option, so that Busybox takes advantages of the shared libraries that are now presenton the target.

Before doing that, measure the size of the busyboxexecutable.

Then, build Busybox with shared libraries, and install it again on the target filesystem. Makesure that the system still boots and see how much smaller the busyboxexecutable got.

Implement a web interface for your device

Replicatedata/www/to the/wwwdirectory in your target root filesystem.

Now, run the BusyBox http server from the target command line:

/usr/sbin/httpd -h /www/

It will automatically background itself.

If you use a proxy, configure your host browser so that it doesnt go through the proxy to con-nect to the target IP address, or simply disable proxy usage. Now, test that your web interfaceworks well by opening http://192.168.0.100on the host.

See how the dynamic pages are implemented. Very simple, isnt it?



23/53


Filesystems - Block file systemsObjective: configure and boot an embedded Linux system relying onblock storage


Manage partitions on block storage.

Produce file system images.

Configure the kernel to use these file systems

Use the tmpfs file system to store temporary files

Goals

After doing the A tiny embedded system lab, we are going to copy the filesystem contents tothe MMC flash drive. The filesystem will be split into several partitions, and your sama5d3X-plained board will be booted with this MMC card, without using NFS anymore.

Setup

Throughout this lab, we will continue to use the root filesystem we have created in the $HOME/embedded-linux-labs/tinysystem/nfsroot directory, which we will progressively adaptto use block filesystems.

Filesystem support in the kernel

Recompile your kernel with support for SquashFS and ext3.

Boot your board with this new kernel and on the NFS filesystem you used in this previous lab.5

Prepare the MMC card

Were going to use an MMC card for our block device.

Plug the MMC card your instructor gave you on your workstation. Type the dmesgcommandto see which device is used by your workstation. In case the device is /dev/sdb, you will see

something like

sd 3:0:0:0: [sdb] 3842048 512-byte hardware sectors: (1.96 GB/1.83 GiB)

If your PC has an internal MMC/SD card reader, the device may also been seen as /dev/mmcblk0, and the first partition as mmcblk0p1. 6.You will see that the MMC/SD card is seenin the same way by the board.

5If you didnt do or complete the tinysystem lab, you can use the data/rootfsdirectory instead.6This is not always the case with internal MMC/SDcard readers. On some PCs, such devices are behind an internal

USB bus, and thus are visible in the same way external card readers are



24/53


In the following instructions, we will assume that your MMC/SD card is seen as /dev/sdbbyyour PC workstation.

Caution: read this carefully before proceeding. You could destroy existing partitions onyour PC!

Do not make the confusion between the device that is used by your board to represent yourMMC/SD disk (probably /dev/sda), and the device that your workstation uses when thecard reader is inserted (probably/dev/sdb).So, dont use the /dev/sda device to reflash your MMC disk from your workstation. Peoplehave 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 work-station!

Type themountcommand to check your currently mounted partitions. If MMC/SD partitionsare 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 thecfdiskcommand to create the partitions that we are going to use.

In the cfdisk interface, two primary partition, starting from the beginning, with the followingproperties:

One partition, 64MB big, with theFAT16partition type.

One partition, 8 MB big 7 ,that will be used for the root filesystem. Due to the geometryof the device, the partition might be larger than 8 MB, but it does not matter. Keep theLinuxtype for the partition.

One partition, that fills the rest of the MMC card, that will be used for the data filesystem.Here also, keep theLinuxtype for the partition.

PressWritewhen you are done.

Data partition on the MMC disk

Caution: read this carefully before proceeding. You could destroy existing partitions onyour PC!Do not make the confusion between the device that is used by your board to represent yourMMC disk (/dev/mmcblk0) or /dev/sda if you are connecting the MMC card to the boardwith a USB card reader), and the device that your workstation uses (probably /dev/sdb).So, dont use the/dev/sdaXdevice to reflash your MMC disk from your workstation. Peo-ple have already destroyed their Windows partition by making this mistake.

Using the mkfs.ext3create a journaled file system on the third partition of the MMC disk.Remember that you can use the - L option to set a volume name for the partition. Move thecontents of the/www/upload/filesdirectory (in your target root filesystem) into this newpartition. The goal is to use the third partition of the MMC card as the storage for the uploadedimages.

7For the needs of our system, the partition could even be much smaller, and 1 MB would be enough. However, withthe 8 GB SD cards that we use in our labs, 8 MB will be the smallest partition that cfdiskwill allow you to create.



25/53


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 filesystem to do it automatically atboot time.

Reboot your target system and with the mount command, check that /www/upload/files isnow a mount point for the third MMC disk partition. Also make sure that you can still uploadnew images, and that these images are listed in the web interface.

Adding a tmpfs partition for log files

For the moment, the upload script was storing its log file in /www/upload/files/upload.log. To avoid seeing this log file in the directory containing uploaded files, lets store it in/var/loginstead.

Add the /var/log/ directory to your root filesystem and modify the startup scripts to mounta tmpfs filesystem on this directory. You can test your tmpfsmount command line on the

system before adding it to the startup script, in order to be sure that it works properly.

Modify the www/cgi-bin/upload.cfgconfiguration file to store the log file in /var/log/upload.log. You will lose your log file each time you reboot your system, but thats OKin our system. Thats whattmpfsis for: temporary data that you dont need to keep acrosssystem reboots.

Reboot your system and check that it works as expected.

Making a SquashFS image

We are going to store the root filesystem in a SquashFS filesystem in the second partition of theMMC disk.

In order to create SquashFS images on your host, you need to install the squashfs-toolspackage. Now create a SquashFS image of your NFS root directory.

Finally, using the dd command, copy the file system image to the second partition of the MMCdisk.

Booting on the SquashFS partition

In the U-boot shell, configure the kernel command line to use the second partition of the MMCdisk as the root file system. Also add the rootwaitboot argument, to wait for the MMC diskto be properly initialized before trying to mount the root filesystem. Since the MMC cards aredetected asynchronously by the kernel, the kernel might try to mount the root filesystem tooearly withoutrootwait.

Check that your system still works. Congratulations if it does!

Store the kernel image and DTB on the MMC card

Finally, copy the zImage kernel image and DTB to the first partition of the MMC card andadjust thebootcmdof U-Boot so that it loads the kernel and DTB from the MMC card insteadof loading them through the network.

Youll first need to format the first partition, using:



26/53


sudo mkfs.vfat -F 16 -n boot /dev/sdb1

It will create a new FAT16 partition, called boot. Remove and plug the MMC card. You cannow copy the image and DTBs to it.

In U-boot, you can load a file from a FAT filesystem using a command like

fatload mmc 0:1 0x21000000 dtb

Which will load the dtb file, at the address 0x21000000, from the first partition of the firstMMC device.



27/53


Filesystems - Flash file systems

Objective: Understand flash file systems usage and their integration onthe target


Prepare filesystem images and flash them.

Define partitions in embedded flash storage.

Setup

Stay in $HOME/embedded-linux-labs/tinysystem . Install the mtd-utils package, whichwill be useful to create JFFS2 filesystem images.

Goals

Instead of using an external MMC card as in the previous lab, we will make our system use itsinternal flash storage.

The root filesystem will still be in a read-only filesystem, put on an MTD partition. Read/writedata will be stored in a JFFS2 filesystem in another MTD partition. The layout of the internalNAND flash will be:

Enabling NAND flash and filesystems

First, recompile your kernel with support for JFFS2 and for support for MTD partitions speci-fied in the kernel command line (CONFIG_MTD_CMDLINE_PARTS).

Last but not least, disable CONFIG_PROVE_LOCKING. This option is currently causing prob-lems with the JFFS2 filesystem. This option is in Kernel Hacking Lock debugging:prove locking correctness.

Recompile your kernel, and we will update your kernel image on flash in the next section.

Filesystem image preparation

Find the erase block size of the NAND flash device in your board.



28/53


Prepare a JFFS2 filesystem image from the /www/upload/filesdirectory from the previouslab.

Modify the /etc/init.d/rcSfile to mount a JFFS2 filesystem on the eighth flash partition(we will declare flash partitions in the next section), instead of an ext3 filesystem on the third

MMC disk partition.Create a JFFS2 image for your root filesystem, with the same options as for the data filesystem.

MTD partitioning and flashing

Look at the way default flash partitions are defined in the board Device Tree sources ( arch/arm/boot/dts/at91-sama5d3_xplained.dts).

However, they do not match the way we wish to organize our flash storage. Therefore, we willdefine our own partitions at boot time, on the kernel command line.

Enter the U-Boot shell and erase NAND flash, from offset 0x160000, up to the end of the NANDflash storage. Youll have to compute the remaining size of the flash, from 0x160000 to the end.

Remember that you can look at U-Boot booting messages to find what the size of the NANDflash is.

The DTB (device tree blob) has been already written in the NAND flash and it didnt changeso we keep it.

Using thetftpcommand, download and flash the new kernel image at the correct location.

Using the tftp command, download and flash the JFFS2 image of the root filesystem thecorrect location.

Using the tftpcommand, download and flash the JFFS2 image of the data filesystem at thecorrection location.

Dont forget that you can write U-Boot scripts to automate these procedures. This is very handyto avoid mistakes when typing commands!

Set thebootargsvariable so that:

You define the 8 MTD partitions, as detailed previously

The root filesystem is mounted from the 7th partition, and is mounted read-only (kernelparameterro).

Important: even if this partition is mounted read-only, the MTD partition itselfmust be declared as read-write. Otherwise, Linux wont be able to perform ECCchecks on it, which involve both reading and writing.

Boot the target, check that MTD partitions are well configured, and that your system still worksas expected. Your root filesystem should be mounted read-only, while the data filesystemshould be mounted read-write, allowing you to upload data using the web server.



29/53


Third party libraries and applicationsObjective: Learn how to leverage existing libraries and applications: howto configure, compile and install them

To illustrate how to use existing libraries and applications, we will extend the small root filesys-tem built in the A tiny embedded system lab to add the ALSAlibraries and tools and an audioplayback application using these libraries.

Well see that manually re-using existing libraries is quite tedious, so that more automatedprocedures are necessary to make it easier. However, learning how to perform these operationsmanually will significantly help you when youll face issues with more automated tools.

Audio support in the Kernel

Recompile your kernel with audio support. The options we want are:CONFIG_SOUND, CONFIG_SND_USBandCONFIG_SND_USB_AUDIO.

Boot your board with this new kernel.

Figuring out library dependencies

Were going to integrate the alsa-utilsand ogg123. As most software components, theyin turn depend on other libraries, and these dependencies are different depending on the con-figuration chosen for them. In our case, the dependency chain for the alsa-utils is quitesimple, it only depends on the alsa-liblibrary.

The dependencies are a bit more complex for ogg123. It is part of the vorbis-tools, thatdepend on libao and libvorbis. libao in turn depend on alsa-lib, and libvorbis onlibogg.

libao, the alsa-utilsand the alsa-libare here to abstract the use ofALSA, one of theAudio Subsystems supported in Linux. The vorbis-tools, libvorbis and libogg areused to handle the audio files encoded using the Ogg codec, which is quite common.

So, we end up with the following dependency tree:



30/53


Of course, all these libraries rely on the C library, which is not mentioned here, because it isalready part of the root filesystem built in the A tiny embedded system lab. You might wonderhow to figure 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 configure, compile and install all the components of our system, were going to start fromthe bottom of the tree withalsa-lib, then continue with thealsa-utils,libao,libogg, andlibvorbis,to finally compile thevorbis-tools.

Preparation

For our cross-compilation work, we will need to separate spaces:

Astagingspace in which we will directly install all the packages: non-stripped versionsof the libraries, headers, documentation and other files needed for the compilation. Thisstaging space can be quite big, but will not be used on our target, only for compilinglibraries or applications;

Atargetspace, in which we will copy only the required files from the stagingspace: bina-ries and libraries, after stripping, configuration files needed at runtime, etc. This targetspace will take a lot less space than the stagingspace, and it will contain only the files thatare really needed to make the system work on the target.

To sum up, the stagingspace will contain everything thats needed for compilation, while thetargetspace will contain only whats needed for execution.

So, in $HOME/embedded-linux-labs/thirdparty, create two directories: stagingand

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 systemlab, so copy this system in thetarget directory:

sudo cp -a $HOME/embedded-linux-labs/tinysystem/nfsroot/* target/

The copy must be done as root, because the root filesystem of the A tiny embedded systemlabcontains a few device nodes.

Testing

Make sure thetarget/

directory is exported by your NFS server to your board by modifying/etc/exportsand restarting your NFS server.

Make sure your board boots as it used to and that you can get a prompt.

alsa-lib

alsa-lib is a library supposed to handle the interaction with the ALSA subsystem. It isavailable at http://alsa-project.org. Download version 1.0.28, and extract it in $HOME/embedded-linux-labs/thirdparty/ .

http://alsa-project.org/http://free-electrons.com/http://free-electrons.com/http://free-electrons.com/http://alsa-project.org/


31/53


By looking at the configure script, we see that this configure script has been generated byautoconf (the header contain a sentence like Generated by GNU Autoconf 2.62). Most of thetime, autoconfcomes with automake, that generates Makefiles from Makefile.am files. Sothe alsa-lib uses a rather common build system. Lets try to configure and build alsa-lib:

./configuremake

You can see that the files are getting compiled with gcc, which generates code for x86 and notfor the target platform. This is obviously not what we want, so we clean-up the object and tellthe configure 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 theconfigure script. The CC environment variable is the classical name for specifying the compilerto 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 file, you can see that the configure script compiles a binary withthe cross-compiler and then tries to run it on the development workstation. This is a ratherusual 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 scriptis to test the configuration of the system. To do so, it tries to compile and run a few sampleapplications to test if this library is available, if this compiler option is supported, etc. But inour case, running the test examples is definitely not possible.

We need to tell the configure script that we are cross-compiling, and this can be done using the--buildand--hostoptions, 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 --hostoption allows to specify on which system the package will run. By default, the value ofthe --build option is guessed and the value of--hostis the same as the value of the - -build option. The value is guessed using the ./config.guess script, which on your systemshould return i686-pc-linux-gnu. See http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Names.html for more details on these options.

So, lets override the value of the --hostoption:

CC=arm-linux-gcc ./configure --host=arm-linux

The configure script should end properly now, and create a Makefile. Run the make command,and you should see that at some point it is failing because of a missing python header.

You can get rid of this error by disabling the python support in the configure script by using the--disable-python option. Start make again, and this time you should have the compilationending fine.

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Names.htmlhttp://www.gnu.org/software/autoconf/manual/html_node/Specifying-Names.htmlhttp://free-electrons.com/http://free-electrons.com/http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Names.htmlhttp://www.gnu.org/software/autoconf/manual/html_node/Specifying-Names.html


32/53


Look at the result of compiling in src/.libs: a set of object files and a set oflibasound.so*files.

The libasound.so* files are a dynamic version of the library. The shared library itself islibasound.so.2.0.0, it has been generated by the following command line:

arm-linux-gcc -shared conf.o confmisc.o input.o output.o \

async.o error.o dlmisc.o socket.o shmarea.o \

userfile.o names.o -lm -ldl -lpthread -lrt \

-Wl,-soname -Wl,libasound.so.2 -o libasound.so.2.0.0

And creates the symbolic link libasound.soandlibasound.so.2.

ln -s libasound.so.2.0.0 libasound.so.2

ln -s libasound.so.2.0.0 libasound.so

These symlinks are needed for two different reasons:

libasound.sois used at compile time when you want to compile an application thatis dynamically linked against the library. To do so, you pass the -lLIBNAME optionto the compiler, which will look for a file named lib.so. In our case, thecompilation option is - lasoundand the name of the library file is libasound.so. So,thelibasound.sosymlink is needed at compile time;

libasound.so.2is needed because it is theSONAMEof the library. SONAMEstandsforShared Object Name. It is the name of the library as it will be stored in applicationslinked against this library. It means that at runtime, the dynamic loader will look forexactly this name when looking for the shared library. So this symbolic link is needed atruntime.

To know whats theSONAMEof a library, you can use:

arm-linux-readelf -d libasound.so.2.0.0

and look at the (SONAME)line. Youll also see that this library needs the C library, because ofthe(NEEDED)line on libc.so.0.

The mechanism ofSONAMEallows to change the library without recompiling the applicationslinked with this library. Lets say that a security problem is found in the alsa-lib release thatprovides libasound 2.0.0, and fixed in the next alsa-lib release, which will now provide liba-sound 2.0.1.

You can just recompile the library, install it on your target system, change the link libasound.so.2 so that it points to libasound.so.2.0.1 and restart your applications. And it willwork, because your applications dont look specifically for libasound.so.2.0.0but for theSONAMElibasound.so.2.

However, it also means that as a library developer, if you break the ABI of the library, you mustchange theSONAME: change fromlibasound.so.2to 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 prefix is /usr/local/ (so that the libraryis installed in /usr/local/lib, the headers in /usr/local/include, etc.). But in oursystem, we simply want the libraries to be installed in the /usr prefix, so lets tell the configurescript about this:

CC=arm-linux-gcc ./configure --host=arm-linux --disable-python --prefix=/usr

make



33/53


For this library, this option may not change anything to the resulting binaries, but for safety, it isalways recommended to make sure that the prefix matches where your library will be runningon the target system.

Do not confuse theprefix (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 buildingthe root filesystem.

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 filesystem,

but once our target system will be running, it will see libasound in /usr/lib.

The prefix corresponds to the path in the target system andneveron the host. So, one shouldneverpass a prefix like $HOME/embedded-linux-labs/thirdparty/target/usr, oth-erwise at runtime, the application or library may look for files inside this directory on thetarget system, which obviously doesnt exist! By default, most build systems will install theapplication or library in the given prefix (/usror /usr/local), but with most build systems(includingautotools), the installation prefix can be overriden, and be different from the config-uration prefix.

We now only have the installation process left to do.

First, lets make the installation in thestagingspace:

make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging install

Now look at what has been installed by alsa-lib:

Some configuration files in/usr/share/alsa

The headers in/usr/include

The shared library and its libtool file in/usr/lib

A pkgconfig file in/usr/lib/pkgconfig. Well come back to these later

Finally, lets install the library in the targetspace:1. Create thetarget/usr/libdirectory, it will contain the stripped version of the library

2. Copy the dynamic version of the library. Only libasound.so.2andlibasound.so.2.0.0 are needed, since libasound.so.2 is the SONAME of the library and libasound.so.2.0.0is 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

And were done with alsa-lib!

Alsa-utils

Download alsa-utils from the ALSA offical webpage. We tested the lab with version 1.0.28.

Once uncompressed, we quickly discover that the libpng 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 prefix and host options and the CCvariable:

CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr



34/53


35/53


Of course, if we wanted it, we would have had to build ncurses first, just like we built alsa-lib.We will also need to disable the xmlto support 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, letsinstall in a dummy directory, to see whats going to be installed (this dummy directory willnot be used afterwards, it is only to verify what will be installed before polluting the stagingspace):

make DESTDIR=/tmp/alsa-utils/ install

The DESTDIR variable can be used with all Makefiles based on automake. It allows to overridethe installation directory: instead of being installed in the configuration-prefix, the files 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



36/53


./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/binand/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 configuration samples in/usr/share/alsa.

Now, lets make the installation in thestagingspace:

make DESTDIR=$HOME/embedded-linux-labs/thirdparty/staging/ install

Then, lets install only the necessary files in the targetspace, manually:

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/pcmcp -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 finally done with the alsa-utils!

Now test that all is working fine by running the speaker-test utils on your board, with theheadset provided by your instructor plugged in. You will need to add the missing librariesfrom the toolchain install directory.



37/53


libogg

Now, lets work onlibogg. Download the version 1.3.2 from http://xiph.org and extract it.

Configuringliboggis very similar to the configuration of the previous libraries:

CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr

Of course, compile the library:

make

Installation to thestagingspace can be done using the classicalDESTDIRmechanism:


And finally, install manually the only needed files at runtime in the targetspace:

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

Libvorbisis the next step. Grab the version 1.3.4 fromhttp://xiph.organd uncompress it.

Once again, the libvorbis build system is a nice example of what can be done with a goodusage of the autotools. Cross-compiling libvorbis is very easy, and almost identical to whatweve seen with the 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 find the --with-ogg-libraries and --with-ogg-includesoptions. Use those:

CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr \

--with-ogg-includes=$HOME/embedded-linux-labs/thirdparty/staging/usr/includ

--with-ogg-libraries=$HOME/embedded-linux-labs/thirdparty/staging/usr/lib

Then, compile the library:

make

Install it in thestagingspace:


And install only the required files in the targetspace:

cd ..

cp -a staging/usr/lib/libvorbis.so.0* target/usr/lib/

arm-linux-strip target/usr/lib/libvorbis.so.0.4.7

cp -a staging/usr/lib/libvorbisfile.so.3* target/usr/lib/

arm-linux-strip target/usr/lib/libvorbisfile.so.3.3.6

And were done with libvorbis!

http://xiph.org/http://xiph.org/http://free-electrons.com/http://free-electrons.com/http://xiph.org/http://xiph.org/


38/53


libao

Now, lets work onlibao. Download the version 1.2.0 fromhttp://xiph.organd extract it.

Configuringlibao is once again fairly easy, and similar to every sane autotools based build

system:



CC=arm-linux-gcc ./configure --host=arm-linux \

--prefix=/usr

Of course, compile the library:

make

Installation to thestagingspace can be done using the classicalDESTDIRmechanism:


And finally, install manually the only needed files at runtime in the targetspace:

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 plugins that is loaded dynamically by the 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. Wecan now build the vorbis-tools themselves. Download the version 1.4.0 from the official web-site, athttp://xiph.org/.As usual, extract the tarball.

Before starting the configuration, lets have a look at the available options by running ./configure --help. A lot of options are available. We see that we can, in addition to theusual autotools configuration 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 vorbistools

So, lets begin with our usual configure line:



CC=arm-linux-gcc \


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

http://xiph.org/http://xiph.org/http://xiph.org/http://free-electrons.com/http://free-electrons.com/http://free-electrons.com/http://xiph.org/http://xiph.org/


39/53


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 at some point that it tests for the libao andfails to find it:

checking for AO... no

configure: WARNING: libao too old; >= 1.0.0 required

Ok, now at the end of the configure, we get:

If you look into the config.logfile now, you should find 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-configsystem to get the configuration parametersto link the library against libao. By default, pkg-configlooks in /usr/lib/pkgconfig/ for.pc files, and because the libao-devpackage is probably not installed in your system theconfigure script will not find the libao we just compiled.

It would have been worse if we had the package installed, because it would have detected andused our host package to compile libao, which, since were cross-compiling, is a pretty badthing to do.

This is one of the biggest issue with cross-compilation: mixing host and target libraries, becausebuild systems have a tendency to look for libraries in the default paths.

So, now, we must tell pkg-configto look inside the /usr/lib/pkgconfig/directory of ourstaging space. This is done through the PKG_CONFIG_PATH environment variable, as explained

in the manual page of pkg-config.

Moreover, the .pc files 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_DIRenvironment variable.

Then, lets run the configuration of the vorbis-tools again, passing the PKG_CONFIG_PATH andPKG_CONFIG_SYSROOT_DIRenvironment variables:



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 \




40/53


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

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/ubuntu/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:28:0,

from audio.c:22:

/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory

#include

compilation terminated.

make[2]: *** [audio.o] Error 1

make[2]: Leaving directory `/home/ubuntu/embedded-linux-labs/thirdparty/vorbis-tools-1.4.0/ogg123'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/ubuntu/embedded-linux-labs/thirdparty/vorbis-tools-1.4.0'

make: *** [all] Error 2

You can notice that /usr/includeis added to the include paths. Again, this is not what wewant because it contains includes for the host, not the target. It is coming from the autodetectedvalue forCURL_CFLAGS.

Add the--without-curloption to the configure invocation, restart the compilation.

The compilation may then fail with an error related to libm. While the code uses the functionfrom this library, the generated Makefile doesnt give the right command line argument inorder to link against the libm.

If you look at the configure help, you can seeLIBS libraries to pass to the linker, e.g. -l

And this is exactly what we are supposed to use to add new linker flags.

Add this to the configure command line to get



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 stagingspace using:


And then install them in thetargetspace:

cd ..

cp -a staging/usr/bin/ogg* target/usr/bin

arm-linux-strip target/usr/bin/ogg*



41/53


You can now test that everything works! Run ogg123 on the sample file found in thirdparty/data, and everything should work fine!



42/53


Using a build system, example with

BuildrootObjectives: discover how a build system is used and how it works, withthe example of the Buildroot build system. Build a Linux system withlibraries and make it work on the board.

Setup

Go to the $HOME/embedded-linux-labs/buildroot/ directory, which already containssome data needed for this lab.

Get Buildroot and explore the source code

The official Buildroot website is available at http://buildroot.org/.Download the lateststable 2014.05.x version which we have tested for this lab. Uncompress the tarball and go insidethe Buildroot source directory.

Several subdirectories or files are visible, the most important ones are:

bootcontains the Makefiles and configuration items related to the compilation of com-mon bootloaders (Grub, U-Boot, Barebox, etc.)

configscontains a set of predefined configurations, similar to the concept of defconfigin the kernel.

docs contains the documentation for Buildroot. You can start reading buildroot.htmlwhich is the main Buildroot documentation;

fscontains the code used to generate the various root filesystem image formats

linux contains the Makefile and configuration items related to the compilation of theLinux kernel

Makefile is the main Makefile that we will use to use Buildroot: everything worksthrough Makefiles in Buildroot;

package is a directory that contains all the Makefiles, patches and configuration items tocompile the user space applications and libraries of your embedded Linux system. Havea look at various subdirectories and see what they contain;

system contains the root filesystem skeleton and the device tables used when a static /devis used;

toolchain contains the Makefiles, patches and configuration items to generate the cross-compiling toolchain.

http://buildroot.org/http://buildroot.org/http://free-electrons.com/http://free-electrons.com/http://free-electrons.com/http://buildroot.org/


43/53


Configure Buildroot

In our case, we would like to:

Generate an embedded Linux system for ARM;

Use an already existing external toolchain instead of having Buildroot generating one forus;

Integrate Busybox, alsa-utils and vorbis-tools in our embedded Linux system;

Integrate the target filesystem into a tarball

To run the configuration utility of Buildroot, simply run:

make menuconfig

Set the following options:

Target options

Target Architecture: ARM (little endian)

Target Architecture Variant: cortex-A5

Target ABI: EABIhf

Floating point strategy: VFPv4-D16

Toolchain

Toolchain type: External toolchain

Toolchain: Custom toolchain

Toolchain path: use the toolchain you built: /usr/local/xtools/arm-unknown-linux-uclibcgnueabihf

External toolchain kernel headers series: 3.10.x

External toolchain C library: uClibc

We must tell Buildroot about our toolchain configuration, so: enable Toolchainhas large file support?, Toolchain has WCHAR support?, Toolchainhas SSP support? and Toolchain has C++ support?. Buildroot will checkthese parameters anyway.

SelectCopy gdb server to the Target

Target packages

KeepBusyBox(default version) and keep the Busybox configuration proposed byBuildroot;

Audio and video applications

* Select alsa-utils

* ALSA utils selection

Selectalsactl

Selectalsamixer

Select speaker-test

* Select vorbis-tools



44/53


Filesystem images

Selecttar the root filesystem

Exit the menuconfig interface. Your configuration has now been saved to the.configfile.

Generate the embedded Linux system

Just run:

make

Buildroot will first create a small environment with the external toolchain, then download,extract, configure, compile and install each component of the embedded system.

All the compilation has taken place in the output/subdirectory. Lets explore its contents:

build, is the directory in which each component built by Buildroot is extract, and wherethe build actually takes place

host, is the directory where Buildroot installs some components for the host. As Build-root doesnt want to depend on too many things installed in the developer machines, itinstalls some tools needed to compile the packages for the target. In our case it installedpkg-config (since the version of the host may be ancient) and tools to generate the rootfilesystem image (genext2fs, makedevs, fakeroot)

images, which contains the final images produced by Buildroot. In our case its jus

Documents

Embedded Linux Labs