Labs

IInux TraInIng
Iab ook
Embedded Linux training
Lab book
Free Electrons
http://free-electrons.com
1 2004-2011, Iree Iectrons, http.//Iree-eIectrons.com, CreatIve Commons IIcense
IInux TraInIng
Iab ook
About this document
ThIs document can be Iound on http.//Iree-eIectrons.com/doc/traInIng/embedded-IInux
t Is Is composed oI severaI source documents that we aggregate Ior each traInIng sessIon. These
IndIvIduaI source documents can be Iound on http.//Iree-eIectrons.com/docs.
More detaIIs about our traInIng sessIons can be Iound on http.//Iree-eIectrons.com/traInIng.
Copying this document
2004-2011, Iree Iectrons, http.//Iree-eIectrons.com.
ThIs document Is reIeased under the terms oI the CreatIve Commons AttrIbutIon-
ShareAIIke 3.0 IIcense. ThIs means you are Iree to downIoad, dIstrIbute and even modIIy
It, under certaIn condItIons.
CorrectIons, suggestIons, contrIbutIons and transIatIons are weIcome!
2 CopyrIght 2004-2011, Iree Iectrons, http.//Iree-eIectrons.com, CreatIve Commons IIcense
2004-2011 Iree Iectrons, http.//Iree-eIectrons.com CreatIve Commons IIcense 2004-2011 Iree Iectrons, http.//Iree-eIectrons.com CreatIve Commons IIcense
Training setup
ownIoad IIIes and dIrectorIes used In practIcaI Iabs
Update your system
TIme mIght have eIapsed sInce your system was Iast updated.
Keep your system up to date.
sudo apt-get update
sudo apt-get dist-upgrade
lnstall lab data
Ior the dIIIerent Iabs In the traInIng, your Instructor has prepared a
set oI data (kerneI Images, kerneI conIIguratIons, root IIIesystems
and more). ownIoad the tarbaII at
http.//Iree-eIectrons.com/Iabs/embeddedIInux.tar.bz2.
Then, Irom a termInaI, extract the tarbaII usIng the IoIIowIng
command.
cd (going to your home directory)
sudo tar jxf embedded_linux.tar.bz2
sudo chown -R <user>.<user> felabs
Iab data are now avaIIabIe In a felabs dIrectory In your home
dIrectory. Ior each Iab there Is a dIrectory contaInIng varIous data.
ThIs dIrectory can aIso be used as a workIng space Ior each Iab so
that you properIy keep the work on each Iab weII-separated.
xIt SynaptIc II It Is stIII open. I you don't, you won't be abIe to run
apt-get install commands, because onIy one package
management tooI Is aIIowed at a tIme.
You are now ready to start the reaI practIcaI Iabs!
lnstall extra packages
!buntu comes wIth a very IImIted versIon oI the vI edItor. nstaII
vIm, a Improved versIon oI thIs edItor.
sudo apt-get install vim
More guidelines
Can be useIuI throughout any oI the Iabs
Iead InstructIons and tIps careIuIIy. Iots oI peopIe make
mIstakes or waste tIme because they mIssed an expIanatIon or a
guIdeIIne.
AIways read error messages careIuIIy, In partIcuIar the IIrst one
whIch Is Issued. Some peopIe stumbIe on very sImpIe errors just
because they specIIIed a wrong IIIe path and dIdn't pay enough
attentIon to the correspondIng error message.
ever stay stuck wIth a strange probIem more than 5 mInutes.
Show your probIem to your coIIeagues or to the Instructor.
You shouId onIy use the root user Ior operatIons that requIre
super-user prIvIIeges, such as. mountIng a IIIe system, IoadIng a
kerneI moduIe, changIng IIIe ownershIp, conIIgurIng the
network. Most reguIar tasks (such as downIoadIng, extractIng
mbedded IInux kerneI
and drIver deveIopment
TraInIng Iab book
TraInIng Iab book
root permIssIons are requIred to
extract the character and bIock
devIce IIIes contaIned In the Iab
structure.
sources, compIIIng...) can be done as a reguIar user.
I you ran commands Irom a root sheII by mIstake, your reguIar
user may no Ionger be abIe to handIe the correspondIng
generated IIIes. n thIs case, use the chown -R command to gIve
back the new IIIes to your reguIar user.
xampIe. chown -R myuser.myuser linux-2.6.25
n ebIan, !buntu and other derIvatIves, don't be surprIsed II
you cannot run graphIcaI appIIcatIons as root. You couId set the
DISPLAY varIabIe to the same settIng as Ior your reguIar user,
but agaIn, It's unnecessary and unsaIe to run graphIcaI
appIIcatIons as root.
TraInIng Iab book
TraInIng Iab book
Sysdev - Building a cross-compiling toolchain
ObjectIve. Iearn how to compIIe your own cross-compIIIng
tooIchaIn Ior the uCIIbc C IIbrary.
AIter thIs Iab, you wIII be abIe to
ConIIgure the crosstooI-ng tooI
xecute crosstooI-ng and buIId up your own cross-compIIIng
tooIchaIn
Setup
Go to the /home/<user>/felabs/sysdev/toolchain dIrectory.
Make sure you have at Ieast 2 G oI Iree dIsk space.
lnstall needed packages
nstaII the packages needed Ior thIs Iab.
sudo apt-get install autoconf automake libtool
sudo apt-get install libncurses-dev bison flex patch
sudo apt-get install cvs texinfo build-essential
sudo apt-get clean
Getting Crosstool-ng
Get the Iatest 1.11.x reIease oI CrosstooI-ng at http.//crosstooI-
ng.org. xpand the archIve rIght In the current dIrectory, and enter
the CrosstooI-ng source dIrectory.
lnstalling Crosstool-ng
We can eIther InstaII CrosstooI-ng gIobaIIy on the system, or keep It
IocaIIy In Its downIoad dIrectory. We'II choose the Iatter soIutIon. As
documented In docs/overview.txt, do.
./configure --local
make
make install
Then you can get CrosstooI-ng heIp by runnIng
./ct-ng help
Configure the toolchain to produce
A sIngIe InstaIIatIon oI CrosstooI-ng aIIows to produce as many
tooIchaIns as you want, Ior dIIIerent archItectures, wIth dIIIerent C
IIbrarIes and dIIIerent versIons oI the varIous components.
CrosstooI-ng comes wIth a set oI ready-made conIIguratIon IIIes Ior
varIous typIcaI setups. CrosstooI-ng caIIs them sampIes. They can
be IIsted by usIng ./ct-ng list-samples.
We wIII use the arm-unknown-linux-uclibcgnueabi sampIe. t can
be Ioaded by IssuIng.
./ct-ng arm-unknown-linux-uclibcgnueabi
Then, to reIIne the conIIguratIon, Iet's run the menuconfig InterIace.
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
./ct-ng menuconfig
n Iath and mIsc optIons.
Change the preIIx dIrectory to
/usr/local/xtools/${CT_TARGET}
ThIs Is the pIace where the tooIchaIn wIII be InstaIIed.
Change the number oI paraIIeI jobs to 2 tImes the number oI
CI! cores In your workstatIon. uIIdIng your tooIchaIn wIII
be Iaster.
n TooIchaIn optIons.
Set TupIe's aIIas to arm-linux. ThIs way, we wIII be abIe to
use the compIIer as arm-linux-gcc Instead oI arm-unknown-
linux-uclibcgnueabi-gcc, whIch Is much Ionger.
n ebug IacIIItIes.
nabIe gdb, strace and Itrace. Iemove the other optIons
(dmaIIoc and duma). n gdb optIons, enabIe the "Cross gdb"
and "uIId a statIc gdbserver" optIons, the other optIons are
not needed.
xpIore the dIIIerent other avaIIabIe optIons by traveIIng through the
menus and IookIng at the heIp Ior some oI the optIons. on't hesItate
to ask your traIner Ior detaIIs on the avaIIabIe optIons. Iowever,
remember that we tested the Iabs wIth the conIIguratIon descrIbed
above.
Produce the toolchain
IIrst, create the dIrectory /usr/local/xtools/ and change Its
owner to your user, so that CrosstooI-ng can wrIte to It.
Then, create the dIrectory $HOME/src In whIch CrosstooI-G wIII
save the tarbaIIs It wIII downIoad.
othIng Is sImpIer.
./ct-ng build
And waIt!
Testing the toolchain
You can now test your tooIchaIn by addIng /usr/local/xtools/arm-
unknown-linux-uclibcgnueabi/bin/ to your PATH envIronment
varIabIe and compIIIng the sImpIe hello.c program In your maIn Iab
dIrectory wIth arm-linux-gcc. You can use the file command on
your bInary to make sure It has correctIy been compIIed Ior the AIM
archItecture.
Cleaning up
To save aImost 2 G oI storage space, remove the .build/
subdIrectory In the CrosstooI-ng dIrectory.
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
Bootloader - U-Boot
ObjectIves. Set up serIaI communIcatIon, compIIe and InstaII
the X-Ioader and !-oot bootIoaders, use basIc !-oot
commands, set up TITI communIcatIon wIth the deveIopment
workstatIon.
As the bootIoader Is the IIrst pIece oI soItware executed by a
hardware pIatIorm, the InstaIIatIon procedure oI the bootIoader Is
very specIIIc to the hardware pIatIorm. There are usuaIIy two cases.
The processor oIIers nothIng to ease the InstaIIatIon oI the
bootIoader, In whIch case the jTAG has to be used to InItIaIIze
IIash storage and wrIte the bootIoader code to IIash. etaIIed
knowIedge oI the hardware Is oI course requIred to perIorm
these operatIons.
The processor oIIers a monItor, ImpIemented In IOM, and
through whIch access to the memorIes Is made easIer.
The GIv2 board, whIch uses the M3730 or the OMAI3530, IaIIs
Into the second category. The monItor Integrated In the IOM reads
the S card to search Ior a vaIId bootIoader beIore IookIng at the
InternaI A IIash Ior a bootIoader. ThereIore, by usIng a S card,
we can start up a OMAI3-based wIthout havIng anythIng InstaIIed on
It.
Setup
Go to the /home/<user>/felabs/sysdev/u-boot/ dIrectory.
MMClSD card setup
The IOM monItor can read IIIes Irom a IAT IIIesystem on the S
card. Iowever, the S card must be careIuIIy partItIonned, and the
IIIesystem careIuIIy created In order to be recognIzed by the IOM
monItor. Iere are the specIaI InstructIons to Iormat an MMC/S
card Ior the OMAI-based pIatIorms.
IIrst, connect your card reader to your workstatIon, wIth the
MMC/S card InsIde. Type the dmesg command to see whIch devIce
Is used by your workstatIon. Iet's assume that thIs devIce Is
/dev/sdb.
sd 3:0:0:0: [sdb] 3842048 512-byte hardware sectors: (1.96 GB/1.83 GiB)
You can aIso run cat /proc/partitions to IIst aII bIock devIces In
your system. AgaIn, make sure to dIstInguIsh the S card Irom the
hard drIve oI your deveIopment workstatIon!
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
Cauton. read thIs careIuIIy beIore proceedIng. You couId destroy exIstIng partItIons on your IC!
o not make the conIusIon between the devIce that Is used by your board to represent your MMC dIsk
(probabIy /dev/sda), and the devIce that your workstatIon uses when the card reader Is Inserted (probabIy
/dev/sdb).
So, don't use the /dev/sda devIce to reIIash your MMC dIsk Irom your workstatIon. IeopIe have aIready
destroyed theIr WIndows partItIon by makIng thIs mIstake.
Type the mount command to check your currentIy mounted
partItIons. I MMC/S partItIons are mounted, unmount them.
n a termInaI open the bIock devIce wIth fdisk.
$ sudo fdisk /dev/sdb
IspIay the on-IIne heIp by pressIng the m key.
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
IrInt the current partItIon tabIe typIng p.
Command (m for help): p
Disk /dev/sdb: 1967 MB, 1967128576 bytes
WrIte down the totaI sIze.
Iet's enter the expert mode Ior geometry settIngs.
Command (m for help): x
We must set the geometry to 255 heads, 63 sectors and caIcuIate the
number oI cyIInders correspondIng to your MMC card.
Expert command (m for help) : h
Number of heads (1-256, default 4): 255
Expert command (m for help) : s
Number of sectors (1-63, default 62): 63
Warning : setting sector offset for DOS compatibility
ow Ior the number oI cyIInders, we consIder the gIobaI sIze
(1967128576 bytes) then dIvIde It by (255*63*512) whIch gIves
around 239.16 cyIInders. We must round It down to 239.
Expert command (m for help) : c
Number of cylinders (1-1048576, default 4): 239
AIter these geometry settIngs, exIt expert mode ('r' command) then
prInt the partItIon tabIe agaIn to check geometry.
Command (m for help): p
Disk /dev/sdb: 1967 MB, 1967128576 bytes
I any partItIon exIsts, deIete It ('d' command).
ow, Iet's create the boot partItIon.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
Partition number (1-4): 1
First cylinder (1-239, default 1): 1
Last cylinder, +cylinders or +size{K,M,G} (1-239, default 239): +64M
Mark It bootabIe.
Command (m for help): a
Partition number (1-4): 1
Then we change Its type to IAT32
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
ow wrIte your changes and exIt.
Command (m for help): w
The partition table has been altered!
...
Iormat thIs new partItIon.
sudo mkfs.vfat -n boot -F 32 /dev/sdb1
Then, remove and Insert your card agaIn.
Your MMC/S card Is ready to use.
X-loader setup
ownIoad the X-Ioader source code Irom the GI support websIte.
wget http://downloads.igep.es/sources/x-loader-1.4.4-2.tar.gz
tar xvf x-loader-1.4.4-2.tar.gz
cd x-loader-1.4.4-2
We need to compIIe two versIons oI the bootIoader.
one that wIII be Ioaded by processor Irom the MMC card
one that we wIII IIash In the InternaI A IIash (so that the
GI can boot wIthout an MMC card).
n order to compIIe the X-Ioader, you need to.
set the CROSS_COMPILE envIronment varIabIe.
export CROSS_COMPILE=arm-linux-
specIIy the IATI to the tooIchaIn that you made.
export PATH=/usr/local/xtools/arm-unknown-linux-
uclibcgnueabi/bin:$PATH
run make igep0020-sdcard_config to set the conIIguratIon
Ior the target board. ThIs one Is Intended to be Ioaded by the
processor Irom the MMC card.
run make to buIId the Image
The resuItIng IIIe Is stored In the x-Ioader maIn dIrectory as x-
load.bin. ThIs IIIe must be "sIgned" In order to be executed by the
processor. !sIng the signGP tooI In the contrib/ subdIrectory, sIgn
the x-load.bin IIIe.
./contrib/signGP x-load.bin
ThIs produces an x-load.bin.ift IIIe. You can copy It to the MMC
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
n Iact, Ior a GeneraI Iurpose (GI)
devIce, the sIgnature onIy consIsts oI
addIng a "TabIe oI Contents" at the
begInnIng oI the Image, expIaInIng
whIch program to execute.
card, renamIng It as MLO.
ow, we need the X-Ioader that wIII be IIashed.
run make distclean to remove compIIed IIIes
run make igep0020-flash_config
run make to buIId It
sIgn It the same way as beIore, usIng signGP
The IIash chIp on the GI has a specIIIc Ieature that may makes It
ImpossIbIe Ior the IIrst stage bootIoader to Ioad data Irom the IIash.
the chIp has 2 pIanes oI data and 2 consecutIve bIocks oI data won't
be on the same pIane. ut the monItor In IOM wIII onIy Ioad data
Irom one pIane, so we need to repIIcate every bIock oI the bootIoader
twIce.
ow, Irom the X-Ioader source dIrectory, run the genddp.sh scrIpt
that Is avaIIabIe In the tools/ subdIrectory oI the Iab dIrectory. ThIs
resuIts In a IIIe named x-load-ddp.bin.ift ; copy It to the MMC
card.
U-Boot setup
ownIoad !-oot Irom the maInIIne Igep downIoad sIte.
wget http://downloads.igep.es/sources/u-boot-arm-2010.06-2.tar.gz
tar xvf u-boot-arm-2010.06-2.tar.gz
cd u-boot-arm-2010.06-2
Get an understandIng oI Its conIIguratIon and compIIatIon steps by
readIng the README IIIe, and specIIIcaIIy the uIIdIng the soItware
sectIon.
asIcaIIy, you need to.
set the CROSS_COMPILE envIronment varIabIe (you shouId have
aIready done It when you compIIed X-Ioader),
run make <NAME>_config, where <NAME> Is the name oI a
conIIguratIon IIIe In include/configs/. Ior our pIatIorm, the
conIIguratIon IIIe Is include/configs/igep0020.h. Iead
thIs IIIe to get an Idea oI how a !-oot conIIguratIon IIIe Is
wrItten,
IInaIIy, run make, whIch shouId buIId !-oot.
You can now copy the generated u-boot.bin IIIe to the MMC card.
!nmount the MMC card partItIon.
Setting up serial communication with the board
IIug the GIv2 board on your computer usIng the provIded !S-to-
serIaI cabIe. When pIugged-In, a serIaI port shouId appear,
/dev/ttyUSB0.
You can aIso see thIs devIce appear by IookIng at the output oI
dmesg.
To communIcate wIth the board through the serIaI port, InstaII a
serIaI communIcatIon program, such as picocom.
apt-get install picocom
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
You can speed up the compIIIng by
usIng the -jX optIon wIth make. Where
X Is the number oI paraIIeI jobs used
Ior compIIIng. TwIce the number oI
CI! cores Is a good vaIue.
Iun picocom -b 115200 /dev/ttyUSB0, to start a serIaI
communIcatIon on /dev/ttyUSB0, wIth a baudrate oI 115200.
I you wIsh to exIt pIcocom, press [Ctrl][a] IoIIowed by [Ctrl][x].
Testing U-Boot on the MMC card
nsert the MMC card Into the GI board, reset the board and check
that It now boots Irom the MMC card.
Texas Instruments X-Loader 1.4.4-2 (Mar 7 2011 -
12:24:42)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2010.06-2 (May 13 2011 - 12:13:22)
OMAP3630/3730-GP ES2.0, CPU-OPP2, L3-165MHz
IGEP v2 board + LPDDR/ONENAND
I2C: ready
DRAM: 512 MiB
Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
OneNAND version = 0x0031
Chip support all block unlock
Chip has 2 plane
block = 2048, wp status = 0x2
Scanning device for bad blocks
OneNAND: 512 MiB
OneNAND: Read environment from 0x00200000
In: serial
Out: serial
Err: serial
Die ID #4d5400011ff0000001592f350202c01d
Net: smc911x-0
Hit any key to stop autoboot: 3
nterrupt the countdown to enter the !-oot sheII.
U-Boot #
n !-oot, type the help command, and expIore the Iew commands
avaIIabIe.
Reflashing from U-boot
We wIII IIrst reIIash the X-Ioader In A. To do so, type the
IoIIowIng commands.
mmc init 0
ThIs InItIaIIzes the MMC InterIace
fatload mmc 0 81000000 x-load-ddp.bin.ift
ThIs Ioads the IIIe Irom MMC 0 partItIon 0 to memory at address
0x81000000
onenand erase 0 80000
ThIs command erases a 0x80000 byte Iong space oI the A IIash
Irom oIIset 0
onenand write 81000000 0 80000
ThIs command wrItes data to the A IIash. The source Is
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
0x81000000 (where we've Ioaded the IIIe to store In the IIash) and
the destInatIon Is oIIset 0 oI the A IIash. The Iength oI the copy
Is 0x80000 bytes, whIch corresponds to the space we've just erased
beIore. t Is Important to erase the IIash space beIore tryIng to wrIte
on It.
X-Ioader has been transIered to A IIash. You can now do the
same wIth !-oot. The storage oIIset In the A Is 0x80000 (just
aIter the space reserved Ior X-Ioader) and the Iength Is 0x180000.
AIter IIashIng the !-oot Image, you can remove MMC card, then
reset the GI board. You shouId see the IreshIy IIashed X-Ioader
and !-oot startIng.
You shouId now see the !-oot prompt.
U-Boot #
You can now use !-oot. Iun the help command to see the avaIIabIe
commands.
Setting up Ethernet communication
Iater on, we wIII transIer IIIes Irom the deveIopment workstatIon to
the board usIng the TITI protocoI, whIch works on top oI an
thernet connectIon.
To start wIth, InstaII and conIIgure a TITI server on your
deveIopment workstatIon, as detaIIed In the bootIoader sIIdes.
IIug the !S thernet adapter provIded by the Instructor and pIug It
to the GIv2 board through the thernet cabIe. A new network
InterIace, probabIy eth1 or eth2, shouId appear on your IInux
system.
To conIIgure thIs network InterIace, rIght-cIIck on the etwork
Manager taskIet on your desktop, and seIect Edit Connections.
SeIect the new wIred network connectIon, and In the IPv4 Settings
tab, make the InterIace use a statIc I address, IIke 192.168.0.1 (oI
course, make sure that thIs address beIongs to a separate network
segment Irom the one oI the maIn company network).
ow, conIIgure the network on the board In !-oot by settIng the
ipaddr and serverip envIronment varIabIes.
setenv ipaddr 192.168.0.100
setenv serverip 192.168.0.1
n case It Is not set yet, you may aIso need to conIIgure the MAC
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
address Ior the board.
setenv ethaddr 01:02:03:04:05:06
To make these settIngs permanent, save the envIronment.
saveenv
ow swItch your board oII and on agaIn.
You can then test the TITI connectIon. IIrst, put a smaII text IIIe In
the dIrectory exported through TITI on your deveIopment
workstatIon. Then, Irom !-oot, do.
tftp 0x80000000 textfile.txt
ThIs shouId downIoad the IIIe textfile.txt Irom your deveIopment
workstatIon Into the board's memory at IocatIon 0x80000000 (thIs
IocatIon Is part oI the board IAM). You can verIIy that the
downIoad was successIuI by dumpIng the contents oI the memory.
md 0x80000000
We wIII see In the next Iabs how to use !-oot to downIoad, IIash and
boot a kerneI.
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
Iower cycIIng your board Is needed to
make your ethaddr permanent, Ior
obscure reasons. I you don't, !-boot
wIII compIaIn that ethaddr Is not set.
Kernel - Kernel sources
ObjectIve. Iearn how to get the kerneI sources and patch
them.
Get the kerneI sources Irom the oIIIcIaI IocatIon
AppIy kerneI patches
Setup
Go to the /home/<user>/felabs/sysdev/kernel dIrectory.
Get the sources
Go to the IInux kerneI web sIte (http.//www.kerneI.org/) and
IdentIIy the Iatest stabIe versIon.
just to make sure you know how to do It, check the versIon oI the
IInux kerneI runnIng on your machIne.
We wIII use linux-2.6.38.x, whIch thIs Iab was tested wIth.
To practIce the patch command Iater, downIoad the IuII 2.6.37
sources. !npack the archIve, whIch creates a linux-2.6.37
dIrectory.
Apply patches
nstaII the patch command, eIther through the graphIcaIpackage
manager, or usIng the IoIIowIng command IIne.
sudo apt-get install patch
ownIoad the 2 patch IIIes correspondIng to the Iatest 2.6.38
stabIe reIease. a IIrst patch to move Irom 2.6.37 to 2.6.38 and a
second patch to move Irom 2.6.38 to 2.6.38.x.
WIthout uncompressIng them (!), appIy the 2 patches to the linux-
2.6.37 dIrectory.
VIew one oI the 2 patch IIIes wIth vi or gvim (II you preIer a
graphIc edItor), to understand the InIormatIon carrIed by such a
IIIe. Iow are descrIbed added or removed IIIes?
Iename the linux-2.6.37 dIrectory to linux-2.6.38.<x>.
mbedded IInux
kerneI usage
TraInIng Iab book
mbedded IInux
kerneI usage
TraInIng Iab book
Ior your convenIence, you may copy
the source !II Irom your web
browser and then use wget to
downIoad the sources Irom the
command IIne.
wget <url>
wget can contInue Interrupted
downIoads
VIm supports syntax hIghIIghtIng Ior
patch IIIes
Id you know It? gvim can open
compressed IIIes on the IIy!
Kernel - Cross-compiling
ObjectIve. Iearn how to cross-compIIe a kerneI Ior an OMAI
target pIatIorm.
Set up a cross-compIIIng envIronment
ConIIgure the kerneI Makefile accordIngIy
Cross compIIe the kerneI Ior the GIv2 arm board
!se !-oot to downIoad the kerneI
Check that the kerneI you compIIed starts the system
Setup
Go to the /home/<user>/felabs/sysdev/kernel dIrectory.
I you haven't done the prevIous Iabs, InstaII the IoIIowIng
packages. libqt3-mt-dev, g++
AIso InstaII uboot-mkimage.
Target system
We are goIng to cross-compIIe and boot a IInux kerneI Ior the
GIv2 board.
Kernel sources
We wIII re-use the kerneI sources downIoaded and patched In the
prevIous Iab.
Cross-compiling environment setup
To cross-compIIe IInux, you need to InstaII the cross-compIIIng
tooIchaIn. We wIII use the cross-compIIIng tooIchaIn that we
prevIousIy produced, so we just need to make It avaIIabIe In the
IATI.
export PATH=/usr/local/xtools/arm-unknown-linux-
uclibcgnueabi/bin:$PATH
Makefile setup
ModIIy the topIeveI MakeIIIe IIIe to cross-compIIe Ior the arm
pIatIorm usIng the above tooIchaIn.
Linux kernel configuration
y runnIng make help, IInd the proper MakeIIIe target to conIIgure
the kerneI Ior the GIv2 board (hInt. the deIauIt conIIguratIon Is
not named aIter the board, but aIter the CI! name). Once Iound,
use thIs target to conIIgure the kerneI wIth the ready-made
conIIguratIon.
on't hesItate to vIsuaIIze the new settIngs by runnIng make
xconfig aIterwards!
Ior Iater use, we need to edIt a bIt the conIIguratIon. Change the
kerneI compressIon Irom GzIp to IZMA. ThIs compressIon
1
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
aIgorIthm Is Iar more eIIIcIent than GzIp, In terms oI compressIon
ratIo, at the expense oI an hIgher decompressIon tIme.
Cross compiling
You're now ready to cross-compIIe your kerneI. SImpIy run.
make
and waIt a whIIe Ior the kerneI to compIIe.
Iook at the end oI the kerneI buIId output to see whIch IIIe contaIns
the kerneI Image.
Iowever, the deIauIt Image produced by the kerneI buIId process Is
not suItabIe to be booted Irom !-oot. A post-processIng operatIon
must be perIormed usIng the mkimage tooI provIded by !-oot
deveIopers. ThIs tooI has aIready been InstaIIed In your system as
part oI the uboot-mkimage package. To run the post-processIng
operatIon on the kerneI Image, sImpIy run.
make uImage.
Setting up serial communication with the board
IIug the GI board on your computer. Start IIcocom on
/dev/ttyS0, or on /dev/ttyUSB0 II you are usIng a serIaI to !S
adapter.
You shouId now see the !-oot prompt.
U-Boot #
Make sure that the bootargs !-oot envIronment varIabIe Is not
set (It couId remaIn Irom a prevIous traInIng sessIon, and thIs couId
dIsturb the next Iab).
setenv bootargs
saveenv
Load and boot the kernel using U-Boot
We wIII use TITI to Ioad the kerneI Image to the GI board .
On your workstatIon, make sure your uImage IIIe Is In the
dIrectory exposed by the TII server.
On the target, Ioad uImage Irom TITI Into IAM at address
0x80000000.
tftp 0x80000000 uImage
oot the kerneI.
bootm 0x80000000.
You shouId see IInux boot and IInaIIy hang wIth the IoIIowIng
message .
Waiting for root device /dev/mmcblk0p2...
ThIs Is expected. we haven't yet provIded a workIng root IIIesystem.
Ior our devIce.
You can automate now aII thIs every tIme the board Is booted or
reset. Ieset the board, and specIIy a dIIIerent bootcmd .
setenv bootcmd 'tftp 80000000 uImage;bootm 80000000'
saveenv
2
IInux TraInIng
Iab book
IInux TraInIng
Iab book
1Iashng the kerneI n NAND fIash
n order to Iet the kerneI boot on the board autonomousIy, we can
IIash It In the A IIash avaIIabIe on the GI. The A IIash
can be manIpuIated In !-oot usIng the onenand command, whIch
Ieatures severaI subcommands. Iun help onenand to see the
avaIIabIe subcommands and theIr optIons.
The A IIash Is IogIcaIIy spIIt In three partItIons by the IInux
kerneI, as deIIned In the igep2_onenand_partitions deIInItIon In
the board-specIIIc IIIe arch/arm/mach-omap2/board-igep0020.c.
The IIrst 3 partItIons are dedIcated to X-Ioader, to !-boot and to Its
envIronment varIabIes. The 4th partItIon, whIch Is 3 MI bIg, Irom
A address 0x280000 to 0x580000, Is reserved Ior the kerneI.
So, Iet's start by erasIng the correspondIng 3MI oI A IIash.
onenand erase 0x280000 0x300000
(NAND cddr) (size)
Then, copy the kerneI Irom the MMC/S card Into memory, usIng
the same address as beIore.
Then, IIash the kerneI Image.
onenand write 0x80000000 0x280000 0x300000
(RAM cddr) (NAND cddr) (size)
Then, we shouId be abIe to boot the kerneI Irom the A usIng.
onenand read 0x80000000 0x280000 0x300000
(RAM cddr) (NAND cddr) (size)
bootm 0x80000000
onenand read copIes the kerneI to IAM and then, bootm executes
It.
WrIte an !-oot scrIpt that automates the kerneI downIoad and
IIashIng procedure. IInaIIy, adjust the bootcmd so that the GI
board boots usIng the kerneI In IIash.
ow, power oII the board and power It on agaIn to check that It
boots IIne Irom A IIash. Check that thIs Is reaIIy your own
versIon oI the kerneI that's runnIng.
3
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
The easIest way to compute these
start and end addresses Is to read
them In the kerneI bootup messages!
Sysdev - Tiny embedded system with BusyBox
ObjectIve. makIng a tIny yet IuII Ieatured embedded system.
AIter thIs Iab, you wIII
be abIe to conIIgure and buIId a IInux kerneI that boots on a
dIrectory on your workstatIon, shared through the network by
IS.
be abIe to create and conIIgure a mInImaIIstIc root IIIesystem
from scratch (ex nIhIIo, out oI nothIng, entIreIy hand
made...) Ior the GI board
understand how smaII and sImpIe an embedded IInux system
can be.
be abIe to InstaII usyox on thIs IIIesystem.
be abIe to create a sImpIe startup scrIpt based on
/sbin/init.
be abIe to set up a sImpIe web InterIace Ior the target.
have an Idea oI how much IAM a IInux kerneI smaIIer than 1
M needs.
Lab implementation
WhIIe (s)he deveIops a root IIIesystem Ior a devIce, a deveIoper
needs to make Irequent changes to the IIIesystem contents, IIke
modIIyIng scrIpts or addIng newIy compIIed programs.
t Isn't practIcaI at aII to reIIash the root IIIesystem on the target
every tIme a change Is made. IortunateIy, It Is possIbIe to set up
networkIng between the deveIopment workstatIon and the target.
Then, workstatIon IIIes can be accessed by the target through the
network, usIng IS.
!nIess you test a boot sequence, you no Ionger need to reboot the
target to test the Impact oI scrIpt or appIIcatIon updates.
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
Development PC
Target (IGEPv2)
/root directory
nfsroot/root directory
Network
NFS export
Setup
Go to the /home/<user>/felabs/sysdev/tinysystem/ dIrectory.
Get the sources Irom the Iatest 2.6.38.x reIease and pIace them In
the current dIrectory. You can reuse sources Irom prevIous Iabs.
Kernel configuration
n the kerneI conIIguratIon buIIt In the prevIous Iab, verIIy that you
have aII optIons needed Ior bootIng the system usIng a root
IIIesystem mounted over IS.
Setting up the NFS server
Create a nfsroot dIrectory In the current Iab dIrectory. ThIs
nfsroot dIrectory wIII be used to store the contents oI our new root
IIIesystem.
nstaII the IS server by InstaIIIng the nfs-kernel-server
package II you don't have It yet. Once InstaIIed, create the
/etc/exports IIIe as root to add the IoIIowIng IIne, assumIng that
the I address oI your board wIII be 192.168.0.100 (the path and
the optIons must be on the same IIne!)
/home/<user>/felabs/sysdev/tinysystem/nfsroot
192.168.0.100(rw,no_root_squash,no_subtree_check)
Then, restart the IS server.
sudo /etc/init.d/nfs-kernel-server restart
Booting the system
IIrst, boot the board to the !-oot prompt. eIore bootIng the
kerneI, we need to teII It that the root IIIesystem shouId be mounted
over IS, by settIng some kerneI parameters.
!se the IoIIowIng !-oot command to do so (In just 1 IIne).
setenv bootargs console=ttyO2,115200 root=/dev/nfs ip=192.168.0.100
nfsroot=192.168.0.1:/home/<user>/felabs/sysdev/tinysystem/nfsroot
OI course, you need to adapt the I addresses to your exact
network setup. Save the envIronment varIabIes (wIth saveenv).
Booting the system
ow, boot your system. The kerneI shouId be abIe to mount the root
IIIesystem over IS.
Iowever, the kerneI wIII compIaIn that It can't IInd an InIt
appIIcatIon.
Kernel panic - not syncing: No init found. Try passing
init= option to kernel. See Linux Documentation/init.txt
for guidance.
ObvIousIy, our root IIIesystem beIng empty, there Isn't such an
appIIcatIon. IoIIow on to add usybox to our root IIIesystem and
IInaIIy make It useIuI.
IInux TraInIng
Iab book
IInux TraInIng
Iab book
CautIon. type ttyO2 ("O" IIke
"OMAI"), not zero (tty02)
Root filesystem with Busybox
ownIoad the Iatest usyox 1.18.x reIease and conIIgure It wIth
the conIIguratIon IIIe provIded In the data/ dIrectory.
At Ieast, make sure you buIId usyox statIcaIIy!
uIId usyox usIng the tooIchaIn that you used to buIId the kerneI.
nstaII usyox In the root IIIesystem by runnIng make install.
Try to boot your new system on the board. I everythIng goes rIght,
the kerneI shouId agaIn conIIrm that It managed to mount the IS
root IIIesystem. Then, you shouId get errors about mIssIng
/dev/ttyX IIIes. Create them wIth the mknod command (usIng the
same major and mInor number as In your G!/IInux workstatIon).
Try agaIn.
At the end, you wIII access a consoIe and wIII be abIe to Issue
commands through the deIauIt sheII.
Virtual filesystems
Iun the ps command. You can see that It compIaIns that the /proc
dIrectory does not exIst. The ps command and other process-
reIated commands use the proc vIrtuaI IIIesystem to get theIr
InIormatIon Irom the kerneI.
Irom the IInux command IIne In the target, create the proc, sys
and etc dIrectorIes In your root IIIesystem.
ow mount the proc vIrtuaI IIIesystem.
ow that /proc Is avaIIabIe, test agaIn the ps command.
ote that you can aIso haIt your target In a cIean way wIth the halt
command, thanks to proc beIng mounted.
System configuration and startup
The IIrst userspace program that gets executed by the kerneI Is
/sbin/init and Its conIIguratIon IIIe Is /etc/inittab.
n the usyox sources, read detaIIs about /etc/inittab In the
examples/inittab IIIe.
Then, create a /etc/inittab IIIe and a /etc/init.d/rcS startup
scrIpt decIared In /etc/inittab. n thIs startup scrIpt, mount the
/proc and /sys IIIesystems.
Any Issue aIter doIng thIs?
Switching to shared libraries
Take the hello.c program suppIIed In the data dIrectory. Cross-
compIIe It Ior AIM, dynamIcaIIy-IInked wIth the IIbrarIes, and run It
on the target.
You wIII IIrst encounter a not found error caused by the absence oI
the ld-uClibc.so.0 executabIe, whIch Is the dynamIc IInker
requIred to execute any program compIIed wIth shared IIbrarIes.
!sIng the find command (see exampIes In your command memento
sheet), Iook Ior thIs IIIe In the tooIchaIn InstaII dIrectory, and copy It
to the lib/ dIrectory on the target.
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
You can understand our approach to
buIId IIIesystems Irom scratch. We're
waItIng Ior programs to compIaIn
beIore addIng devIce or
conIIguratIon IIIes. ThIs Is a way oI
makIng sure that every IIIe In the
IIIesystem Is used.
CompIIIng usybox statIcaIIy In the
IIrst pIace makes It easy to set up the
system, because there are no
dependencIes on IIbrarIes. Iater on,
we wIII set up shared IIbrarIes and
recompIIe usybox.
ActuaIIy, you wIII probabIy have
severaI InstructIve surprIses when
tryIng to ImpIement thIs. on't
hesItate to share your questIons wIth
your Instructor!
Then, runnIng the executabIe agaIn and see that the Ioader
executes and IInds out whIch shared IIbrarIes are mIssIng.
SImIIarIy, IInd these IIbrarIes In the tooIchaIn and copy them to
lib/ on the target.
Once the smaII test program works, recompIIe usybox wIthout the
statIc compIIatIon optIon, so that usybox takes advantages oI the
shared IIbrarIes that are now present on the target.
lmplement a web interface for your device
IepIIcate data/www/ to the /www dIrectory In your target root
IIIesystem.
ow, run the usyox http server Irom the command IIne.
/usr/sbin/httpd -h /www/. t wIII automatIcaIIy background
ItseII.
I you use a proxy, conIIgure your host browser so that It doesn't go
through the proxy to connect to the target I address, or sImpIy
dIsabIe proxy usage. ow, test that your web InterIace works weII
by openIng http://192.168.0.100 on the host.
See how the dynamIc pages are ImpIemented. Very sImpIe, Isn't It?
How much RAM does your system need7
Check the /proc/meminfo IIIe and see how much IAM Is used by
your system.
You can try to boot your system wIth Iess memory, and see whether
It stIII works properIy or not. Ior exampIe, to test whether 20 M
are enough, boot the kerneI wIth the mem=20M parameter. IInux wIII
then use just 20 M oI IAM, and Ignore the rest.
Try to use even Iess IAM, and see what happens.
IInux TraInIng
Iab book
IInux TraInIng
Iab book
The totaI amount oI IAM shown by
/proc/meminfo Is the totaI physIcaI
IAM mInus the space taken by the
kerneI code and Its statIc data.
Filesystems - Block file systems
ObjectIve. conIIgure and boot an embedded IInux system
reIyIng on bIock storage.
Manage partItIons on bIock storage.
Iroduce IIIe system Images.
ConIIgure the kerneI to use these IIIe systems
!se the tmpIs IIIe system to store temporary IIIes
Goals
AIter doIng the "A tIny embedded system" Iab, we are goIng to copy
the IIIesystem contents to the MMC IIash drIve. The IIIesystem wIII
be spIIt Into severaI partItIons, and your GI board wIII be booted
wIth thIs MMC card, wIthout usIng IS anymore.
Setup
Go to /home/<user>/felabs/sysdev/fs.
Ieuse the kerneI that you used In
/home/<user>/felabs/sysdev/tinysystem.
IecompIIe It wIth support Ior SquashFS and ext3.
oot your board wIth thIs new kerneI and on the IS IIIesystem
you used In thIs prevIous Iab.
Add partitions to the MMC card
!sIng IdIsk, add two addItIonaI partItIons to the MMC card (In
addItIon to the exIstIng "boot" partItIon created In the bootIoaders
Iab) .
One partItIon, oI at Ieast 1 M, that wIII be used Ior the root
IIIesystem. ue to the geometry oI the devIce, the partItIon
mIght be Iarger than 1 M, but It does not matter. Keep the
"IInux" type Ior the partItIon.
One partItIon, that IIIIs the rest oI the MMC card, that wIII be
used Ior the data IIIesystem. Iere aIso, keep the "IInux" type
Ior the partItIon.
At the end, you shouId have three partItIons. one Ior the boot, one
Ior the root IIIesystem and one Ior the data IIIesystem.
1
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
I you dIdn't do or compIete the
tinysystem Iab, you can use the
data/rootfs dIrectory Instead.
Data partition on the MMC disk
!sIng the mkfs.ext3 create a journaIed IIIe system on the thIrd
partItIon oI the MMC dIsk. Iemember that you can use the -L
optIon to set a voIume name Ior the partItIon. Move the contents oI
the www/upload/files dIrectory (In your target root IIIesystem)
Into thIs new partItIon. The goaI Is to use the thIrd partItIon oI the
MMC card as the storage Ior the upIoaded Images.
Connect the MMC dIsk to your board whIIe It's runnIng IInux.
!sIng the dmesg command, or havIng a Iook at the consoIe, see how
the kerneI detects the partItIons and whIch devIce names It gIves to
them.
ModIIy the setup scrIpts In your root IIIesystem to mount the thIrd
dIsk partItIon on /www/upload/files.
Ieboot your target system and wIth the mount command, check that
/www/upload/files Is now a mount poInt Ior the thIrd MMC dIsk
partItIon. AIso make sure that you can stIII upIoad new Images, and
that these Images are IIsted In the web InterIace.
Adding a tmpfs partition for log files
Ior the moment, the upIoad scrIpt was storIng Its Iog IIIe In
/www/upload/files/upload.log. To avoId seeIng thIs Iog IIIe In
the dIrectory contaInIng upIoaded IIIes, Iet's store It In /var/log
Instead.
Add the /var/log/ dIrectory to your root IIIesystem and modIIy the
startup scrIpts to mount a tmpIs IIIesystem on thIs dIrectory.
ModIIy the www/cgi-bin/upload.cfg conIIguratIon IIIe to store the
Iog IIIe In /var/log/upload.log. You wIII Ioose your Iog IIIe each
tIme you reboot your system, but that's OK In our system. That's
what tmpIs Is Ior. temporary data that you don't need to keep
across system reboots.
Ieboot your system and check that It works as expected.
Making a SquashFS image
We are goIng to store the root IIIesystem In a SquashIS IIIesystem
In the second partItIon oI the MMC dIsk.
n order to create SquashIS Images on your host, you need to
InstaII the squashfs-tools package. ow create a SquashIS Image
oI your IS root dIrectory.
IInaIIy, usIng the dd command, copy the IIIe system Image to the
second partItIon oI the MMC dIsk.
Booting on the SquashFS partition
n the !-boot sheII, conIIgure the kerneI command IIne to use the
2
IInux TraInIng
Iab book
IInux TraInIng
Iab book
eIore changIng your startup scrIpts,
you may aIso try your mount
command In the runnIng system, to
make sure that It works as expected.
. read thIs careIuIIy beIore proceedIng. You couId destroy exIstIng partItIons on your IC!
o not make the conIusIon between the devIce that Is used by your board to represent your MMC dIsk
(probabIy /dev/sda1), and the devIce that your workstatIon uses (probabIy /dev/sdb1).
So, don't use the /dev/sdaX devIce to reIIash your MMC dIsk Irom your workstatIon. IeopIe have aIready
destroyed theIr WIndows partItIon by makIng thIs mIstake.
second partItIon oI the MMC dIsk as the root IIIe system. AIso add
the rootwait boot argument, to waIt Ior the MMC dIsk to be
properIy InItIaIIzed beIore tryIng to mount the root IIIesystem.
Check that your system stIII works. CongratuIatIons II It does!
Store the kernel image on the MMC card
IInaIIy, copy the uImage kerneI Image to the IIrst partItIon oI the
MMC card (the partItIon caIIed "boot"), and adjust the bootcmd oI
!-oot so that It Ioads the kerneI Irom the MMC card Instead oI
IoadIng the kerneI through the network.
3
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
I you don't do thIs, you wIII get a
kerneI panIc, because oI a IaIIure to
mount the root IIIesystem, beIng not
ready yet.
Filesystems - Flash file systems
ObjectIve. !nderstand IIash IIIe systems usage and theIr
IntegratIon on the target.
Irepare IIIesystem Images and IIash them.
eIIne partItIons In embedded IIash storage.
Setup
Stay In /home/<user>/felabs/sysdev/fs.
nstaII the mtd-utils package, whIch wIII be useIuI to create jIIS2
IIIesystem Images.
Goals
nstead oI usIng an externaI MMC card as In the prevIous Iab, we
wIII make our system use Its InternaI IIash storage.
The root IIIesystem wIII stIII be In a read-onIy IIIesystem, put on an
MT partItIon. Iead/wrIte data wIII be stored In a jIIS2 IIIesystem
In another MT partItIon. The Iayout oI the InternaI OneA
IIash wIII be .
Irom 0 to 0x80000, X-Ioader (512 K)
Irom 0x80000 to 0x200000, !-oot (1536 K)
Irom 0x200000 to 0x280000, !-oot envIronment (512 K)
Irom 0x280000 to 0x680000, IInux kerneI (4 M)
Irom 0x680000 to 0x880000, the jIIS2 root IIIesystem (2
M) as read-onIy
Irom 0x880000 to the end, the jIIS2 data IIIesystem
Filesystem image preparation
Irepare a jIIS2 IIIesystem Image Irom the /www/uploads/files
dIrectory Irom the prevIous Iab, specIIyIng an erase bIock sIze oI 256
KI and a page sIze oI 4 KI. nabIe the "pad" optIon, don't add
cIeanmarkers.
ModIIy the /etc/init.d/rcS file to mount a jIIS2 IIIesystem on
the sIxth IIash partItIon, Instead oI an ext3 IIIesystem on the thIrd
MMC dIsk partItIon. Create a jIIS2 Image Ior your root IIIesystem.
wIth the same optIons as the data IIIesystem.
Enabling NAND flash and filesystems
IecompIIe your kerneI wIth support Ior JFFS2 and Ior support Ior
MT partItIons specIIIed In the kerneI command IIne
(CONFIG_MTD_CMDLINE_PARTS).
AIso enabIe support Ior the IIash chIps on the board
(CONFIG_MTD_ONENAND_OMAP2).
ecause checkIng subpages wrItes oI 2KI-pages As Isn't
1
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook
workIng yet, you wIII need to make sure that
CONFIG_MTD_ONENAND_VERIFY_WRITE Isn't enabIed.
n the rest oI the Iab, we aIso assume that
CONFIG_MTD_ONENAND_2X_PROGRAM Is enabIed.
!pdate your kerneI Image on IIash.
MTD partitioning and flashing
Memory Iayout and partItIonIng can be deIIned InsIde kerneI sources,
naturaIIy In the arch/<arch>/<march>/<board>.c sInce It Is board
dependent. evertheIess, durIng devIce deveIopment, It can be
useIuI to deIIne partItIons at boot tIme, on the kerneI command IIne.
nter the !-oot sheII and erase the A IIash, Irom oIIset
0x00280000, up to the end oI the A IIash (rase sIze .
0x1I80000 bytes)
!sIng the tItp command, downIoad and IIash the kerneI Image at
the correct IocatIon.
!sIng the tftp command, downIoad and IIash the jIIS2-ro Image
the correct IocatIon.
!sIng the tftp command, downIoad and IIash the jIIS2 Image at
the correctIon IocatIon.
on't Iorget that you can wrIte !-oot scrIpts to automate those
procedures. ThIs Is very handy to avoId mIstakes when typIng
commands!
Iook at the way MT partItIons are deIIned In the kerneI sources
(arch/arm/mach-omap2/board-Igep-0020.c)
Set the bootargs varIabIe so that .
you deIIne the 6 MT partItIons, as detaIIed prevIousIy
the root IIIesystem Is mounted Irom the 5
th
partItIon, and Is
mounted read-onIy (kerneI parameter ro)
oot the target, check that MT partItIons are weII conIIgured, and
that your system stIII works as expected. Your root IIIesystem
shouId be mounted read-onIy, whIIe the data IIIesystem shouId be
mounted read-wrIte, aIIowIng you to upIoad data usIng the web
server.
2
IInux TraInIng
Iab book
IInux TraInIng
Iab book
Third party libraries and applications
ObjectIve. Iearn how to Ieverage exIstIng IIbrarIes and
appIIcatIons. how to conIIgure, compIIe and InstaII them.
To IIIustrate how to use exIstIng IIbrarIes and appIIcatIons, we wIII
extend the smaII root IIIesystem buIIt In the "A tIny embedded
system" Iab to add the IrectI graphIc IIbrary and sampIe
appIIcatIons usIng thIs IIbrary. ecause many boards do not have a
dIspIay, we wIII test the resuIt oI thIs Iab wIth Oemu.
We'II see that manuaIIy re-usIng exIstIng IIbrarIes Is quIte tedIous, so
that more automated procedures are necessary to make It easIer.
Iowever, IearnIng how to perIorm these operatIons manuaIIy wIII
sIgnIIIcantIy heIp you when you'II Iace Issues wIth more automated
tooIs.
Figuring out library dependencies
As most IIbrarIes, IrectI depends on other IIbrarIes, and these
dependencIes are dIIIerent dependIng on the conIIguratIon chosen
Ior IrectI. n our case, we wIII enabIe support Ior.
IG Image IoadIng,
jIG Image IoadIng,
Iont renderIng usIng a Iont engIne.
The IG Image IoadIng Ieature wIII be provIded by the libpng
IIbrary, the jIG Image IoadIng Ieature by the jpeg IIbrary and the
Iont engIne wIII be ImpIemented by the FreeType IIbrary. The libpng
IIbrary ItseII depends on the zlib compressIon/decompressIon
IIbrary. So, we end up wIth the IoIIowIng dependency tree.
OI course, aII these IIbrarIes reIy on the C IIbrary, whIch Is not
mentIoned here, because It Is aIready part oI the root IIIesystem buIIt
In the "A tIny embedded system" Iab. You mIght wonder how to
IIgure out thIs dependency tree by yourseII. asIcaIIy, there are
severaI ways, that can be combIned.
Iead the IIbrary documentatIon, whIch oIten mentIons the
dependencIes,
Iead the heIp message oI the configure scrIpt
(by runnIng ./configure --help).
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
IrectI
appIIcatIon
IrectI
IIbpng
jpeg Ireetype
zIIb
y runnIng the conIIgure scrIpt, compIIIng and IookIng at the
errors.
To conIIgure, compIIe and InstaII aII the components oI our system,
we're goIng to start Irom the bottom oI the tree wIth zIIb, then
contInue wIth IIbpng, jpeg and IreeType, to IInaIIy compIIe IrectI
and the IrectI sampIe appIIcatIons.
Preparation
Ior our cross-compIIatIon work, we wIII need to separate spaces.
A stagIng space In whIch we wIII dIrectIy InstaII aII the
packages. non-strIpped versIons oI the IIbrarIes, headers,
documentatIon and other IIIes needed Ior the compIIatIon.
ThIs stagIng space can be quIte bIg, but wIII not be used on
our target, onIy Ior compIIIng IIbrarIes or appIIcatIons,
A target space, In whIch we wIII copy onIy the requIred IIIes
Irom the stagIng space. bInarIes and IIbrarIes, aIter
strIppIng, conIIguratIon IIIes needed at runtIme, etc. ThIs
target space wIII take a Iot Iess space than the stagIng
space, and It wIII contaIn onIy the IIIes that are reaIIy needed
to make the system work on the target.
To sum up, the stagIng space wIII contaIn everythIng that's needed
Ior compIIatIon, whIIe the target space wIII contaIn onIy what's
needed Ior executIon.
So, In /home/<user>/felabs/sysdev/thirdparty, create two
dIrectorIes. staging and target.
Ior the target, we need a basIc system wIth usyox, devIce nodes
and InItIaIIzatIon scrIpts. We wIII re-use the system buIIt In the "A
tIny embedded system" Iab, so copy thIs system In the target
dIrectory.
sudo cp -a /home/<user>/felabs/sysdev/tinysystem/nfsroot/*
target/
The copy must be done as root, because the root IIIesystem oI the "A
tIny embedded system" Iab contaIns a Iew devIce nodes.
Testing
Make sure the target/ dIrectory Is exported by your IS server by
addIng the IoIIowIng IIne to /etc/exports.
/home/<user>/felabs/sysdev/thirdparty/target 172.20.0.2(rw
,no_root_squash,no_subtree_check)
And restart your IS server.
nstaII the Oemu emuIator Ior non-x86 archItectures by InstaIIIng the
qemu-kvm-extras package.
ModIIy the /etc/qemu-ifup scrIpt so that It just contaIns 2 IInes.
#!/bin/sh
/sbin/ifconfig $1 172.20.0.1
Then, run Oemu wIth the provIded scrIpt.
./run_qemu
The system shouId boot and gIve you a prompt.
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
y deIauIt, Oemu conIIgures brIdged
networkIng, but we wIII use a routed
network Instead.
zlib
ZIIb Is a compressIon/decompressIon IIbrary avaIIabIe at
http.//www.zIIb.net/. ownIoad versIon 1.2.5, and extract It In
/home/<user>/felabs/sysdev/thirdparty/.
y IookIng at the conIIgure scrIpt, we see that thIs conIIgure scrIpt
has not been generated by autoconf (otherwIse It wouId contaIn a
sentence IIke Generated by GNU Autoconf 2.62 ). Moreover,
the project doesn't use automake sInce there are no Makefile.am
IIIes. So zIIb uses a custom buIId system, not a buIId system based on
the cIassIcaI autotooIs.
Iet's try to conIIgure and buIId zIIb.
./configure
make
You can see that the IIIes are gettIng compIIed wIth gcc, whIch
generates code Ior x86 and not Ior the target pIatIorm. ThIs Is
obvIousIy not what we want, so we teII the conIIgure scrIpt to use the
AIM cross-compIIer.
CC=arm-linux-gcc ./configure
OI course, the arm-linux-gcc cross-compIIer must be In your PATH
prIor to runnIng the conIIgure scrIpt. The envIronment varIabIe Is
the cIassIcaI name Ior specIIyIng the compIIer to use. Moreover, the
begInnIng oI the conIIgure scrIpt teIIs us about thIs.
# To impose specific compiler or flags or
# install directory, use for example:
# prefix=$HOME CC=cc CFLAGS="-O4" ./configure
ow when you compIIe wIth make, the cross-compIIer Is used. Iook
at the resuIt oI compIIIng. a set oI object IIIes, a IIIe libz.a and set
oI IIbz.so* IIIes.
The libz.a IIIe Is the statIc versIon oI the IIbrary. t has been
generated usIng the IoIIowIng command .
ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o
deflate.o trees.o zutil.o inflate.o infback.o inftrees.o
inffast.o
t can be used to compIIe appIIcatIons IInked statIcaIIy wIth the zIIb
IIbrary, as shown by the compIIatIon oI the exampIe program.
arm-linux-gcc -O3 -DUSE_MMAP -o example example.o -L.
libz.a
n addItIon to thIs statIc IIbrary, there Is aIso a dynamIc versIon oI
the IIbrary, the libz.so* IIIes. The shared IIbrary ItseII Is
libz.so.1.2.5, It has been generated by the IoIIowIng command
IIne .
arm-linux-gcc -shared -Wl,-soname,libz.so.1 -o
libz.so.1.2.5 adler32.o compress.o crc32.o gzio.o
uncompr.o deflate.o trees.o zutil.o inflate.o infback.o
inftrees.o inffast.o
And creates symboIIc IInks libz.so and libz.so.1.
ln -s libz.so.1.2.3 libz.so
ln -s libz.so.1.2.3 libz.so.1
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
These symIInks are needed Ior two dIIIerent reasons.
libz.so Is used at compIIe tIme when you want to compIIe an
appIIcatIon that Is dynamIcaIIy IInked agaInst the IIbrary. To
do so, you pass the -lLIBNAME optIon to the compIIer, whIch
wIII Iook Ior a IIIe named lib<LIBNAME>.so. n our case, the
compIIatIon optIon Is -Iz and the name oI the IIbrary IIIe Is
libz.so. So, the libz.so symIInk Is needed at compIIe tIme,
libz.so.1 Is needed because It Is the SOAM oI the IIbrary.
SOAM stands Ior Shcred Object Ncme . t Is the name
oI the IIbrary as It wIII be stored In appIIcatIons IInked agaInst
thIs IIbrary. t means that at runtIme, the dynamIc Ioader wIII
Iook Ior exactIy thIs name when IookIng Ior the shared IIbrary.
So thIs symboIIc IInk Is needed at runtIme.
To know what's the SOAM oI a IIbrary, you can use.
arm-linux-readelf -d libz.so.1.2.5
and Iook at the (SOAM) IIne. You'II aIso see that thIs
IIbrary needs the C IIbrary, because oI the () IIne on
libc.so.0.
The mechanIsm oI SOAM aIIows to change the IIbrary
wIthout recompIIIng the appIIcatIons IInked wIth thIs IIbrary.
Iet's say that a securIty probIem Is Iound In zIIb 1.2.5, and
IIxed In the next reIease 1.2.6. You can recompIIe the IIbrary,
InstaII It on your target system, change the IInk libz.so.1 so
that It poInts to libz.so.1.2.6 and restart your appIIcatIons.
And It wIII work, because your appIIcatIons don't Iook
specIIIcaIIy Ior libz.so.1.2.5 but Ior the SOAM
libz.so.1. Iowever, It aIso means that as a IIbrary
deveIoper, II you break the A oI the IIbrary, you must
change the SOAM. change Irom libz.so.1 to libz.so.2.
IInaIIy, the Iast step Is to teII the conIIgure scrIpt where the IIbrary
Is goIng to be InstaIIed. Most conIIgure scrIpts consIder that the
InstaIIatIon preIIx Is /usr/local/ (so that the IIbrary Is InstaIIed In
/usr/local/lib, the headers In /usr/local/include, etc.). ut In
our system, we sImpIy want the IIbrarIes to be InstaIIed In the /usr
preIIx, so Iet's teII the conIIgure scrIpt about thIs.
CC=arm-linux-gcc ./configure --prefix=/usr
make
Ior the zIIb IIbrary, thIs optIon may not change anythIng to the
resuItIng bInarIes, but Ior saIety, It Is aIways recommended to make
sure that the preIIx matches where your IIbrary wIII be runnIng on
the target system.
o not conIuse the preIIx (where the appIIcatIon or IIbrary wIII be
runnIng on the target system) Irom the IocatIon where the
appIIcatIon or IIbrary wIII be InstaIIed on your host whIIe buIIdIng the
root IIIesystem. Ior exampIe, zIIb wIII be InstaIIed In
/home/<user>/felabs/sysdev/thirdparty/target/usr/lib/
because thIs Is the dIrectory where we are buIIdIng the root
IIIesystem, but once our target system wIII be runnIng, It wIII see zIIb
In /usr/lib. The preIIx corresponds to the path In the target system
and on the host. So, one shouId pass a preIIx IIke
/home/<user>/felabs/sysdev/thirdparty/target/usr, otherwIse
at runtIme, the appIIcatIon or IIbrary may Iook Ior IIIes InsIde thIs
dIrectory on the target system, whIch obvIousIy doesn't exIst! y
deIauIt, most buIId systems wIII InstaII the appIIcatIon or IIbrary In
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
the gIven preIIx (/usr or /usr/IocaI), but wIth most buIId systems
(IncIudIng autotooIs), the InstaIIatIon preIIx can be overrIden, and be
dIIIerent Irom the conIIguratIon preIIx.
IIrst, Iet's make the InstaIIatIon In the stagIng space.
make DESTDIR=../staging install
ow Iook at what has been InstaIIed by zIIb .
A manpage In /usr/share/man
A pkgconIIg IIIe In /usr/lib/pkgconfig. We'II come back to
these Iater
The shared and statIc versIons oI the IIbrary In /usr/lib
The headers In /usr/include
IInaIIy, Iet's InstaII the IIbrary In the target space.
1. Create the target/usr/lib dIrectory, It wIII contaIn the
strIpped versIon oI the IIbrary
2. Copy the dynamIc versIon oI the IIbrary. OnIy libz.so.1 and
libz.so.1.2.5 are needed, sInce libz.so.1 Is the SOAM
oI the IIbrary and libz.so.1.2.5 Is the reaI bInary.
cp -a libz.so.1* ../target/usr/lib
3. StrIp the IIbrary.
arm-linux-strip ../target/usr/lib/libz.so.1.2.5
Ok, we're done wIth zIIb!
Libpng
ownIoad IIbpng Irom Its oIIIcIaI websIte at
http.//www.IIbpng.org/pub/png/IIbpng.htmI. We tested the Iab wIth
versIon 1.4.3 IIease stIck to thIs versIon as newer versIons are
IncompatIbIe wIth the IrectI versIon we use In thIs Iab.
Once uncompressed, we quIckIy dIscover that the IIbpng buIId
system Is based on the autotooIs, so we wIII work wIth a reguIar
conIIgure scrIpt.
As we've seen prevIousIy, II we just run ./conIIgure, the buIId system
wIII use the natIve compIIer to buIId the IIbrary, whIch Is not what we
want. So Iet's teII the buIId system to use the cross-compIIer.
CC=arm-linux-gcc ./configure
OuIckIy, you shouId get an error sayIng.
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
I you Iook at conIIg.Iog, you quIckIy understand what's goIng on.
configure:2942: checking for C compiler default output file name
configure:2964: arm-linux-gcc conftest.c >&5
configure:2968: $? = 0
configure:3006: result: a.out
configure:3023: checking whether the C compiler works
configure:3033: ./a.out
./configure: line 3035: ./a.out: cannot execute binary file
The conIIgure scrIpt compIIes a bInary wIth the cross-compIIer and
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
then trIes to run It on the deveIopment workstatIon. ObvIousIy, It
cannot work, and the system says that It cannot execute bInary
IIIe. The job oI the conIIgure scrIpt Is to test the conIIguratIon oI the
system. To do so, It trIes to compIIe and run a Iew sampIe
appIIcatIons to test II thIs IIbrary Is avaIIabIe, II thIs compIIer optIon
Is supported, etc. ut In our case, runnIng the test exampIes Is
deIInIteIy not possIbIe. We need to teII the conIIgure scrIpt that we
are cross-compIIIng, and thIs can be done usIng the --buIId and --host
optIons, as descrIbed In the heIp oI the conIIgure scrIpt.
System types:
--build=BUILD configure for building on BUILD
[guessed]
--host=HOST cross-compile to build programs to run
on HOST [BUILD]
The --buIId optIon aIIows to specIIy on whIch system the package Is
buIIt, whIIe the --host optIon aIIows to specIIy on whIch system the
package wIII run. y deIauIt, the vaIue oI the --build optIon Is
guessed and the vaIue oI --host Is the same as the vaIue oI the
--buIId optIon. The vaIue Is guessed usIng the ./config.guess
scrIpt, whIch on your system shouId return i686-pc-linux-gnu. See
http.//www.gnu.org/soItware/autoconI/manuaI/htmInode/SpecIIyIng-
ames.htmI Ior more detaIIs on these optIons.
So, Iet's overrIde the vaIue oI the --host optIon.
CC=arm-linux-gcc ./configure --host=arm-linux
ow, we go a IIttIe bIt Iurther In the executIon oI the conIIgure
scrIpt, untII we reach.
checking for zlibVersion in -lz... no
configure: error: zlib not installed
AgaIn, we can check In conIIg.Iog what the conIIgure scrIpt Is tryIng
to do.
configure:12452: checking for zlibVersion in -lz
configure:12487: arm-linux-gcc -o conftest -g -O2
conftest.c -lz -lm >&5
/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/arm-
unknown-linux-uclibcgnueabi/sys-
root/usr/bin/../lib/gcc/arm-linux-
uclibcgnueabi/4.3.3/../../../../arm-linux-
uclibcgnueabi/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
The conIIgure scrIpt trIes to compIIe an appIIcatIon agaInst zIIb (as
can be seen Irom the -lz optIon) . IIbpng uses the zIIb IIbrary, so the
conIIgure scrIpt wants to make sure thIs IIbrary Is aIready InstaIIed.
!nIortunateIy, the ld IInker doesn't IInd thIs IIbrary. So, Iet's teII the
IInker where to Iook Ior IIbrarIes usIng the -L optIon IoIIowed by the
dIrectory where our IIbrarIes are (In staging/usr/lib). ThIs -L
optIon can be passed to the IInker by usIng the LDFLAGS at conIIgure
tIme, as toId by the heIp text oI the conIIgure scrIpt.
LDFLAGS linker flags, e.g. -L<lib dir> if you have
libraries in a nonstandard directory <lib dir>
Iet's use thIs IIIAGS varIabIe.
LDFLAGS=-
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
L/home/<user>/felabs/sysdev/thirdparty/staging/usr/lib \
CC=arm-linux-gcc ./configure --host=arm-linux
Iet's aIso specIIy the preIIx, so that the IIbrary Is compIIed to be
InstaIIed In /usr and not /usr/local.
LDFLAGS=-
CC=arm-linux-gcc ./configure --host=arm-linux \
--prefix=/usr
Then, run the compilation usIng make. OuIckIy, you shouId get a
pIIe oI error messages, startIng wIth.
In file included from png.c:13:
png.h:470:18: error: zlib.h: No such file or directory
OI course, sInce IIbpng uses the zIIb IIbrary, It IncIudes Its header
IIIe! So we need to teII the C compIIer where the headers can be
Iound. there are not In the deIauIt dIrectory /usr/include/, but In
the /usr/include dIrectory oI our stagIng space. The heIp text oI
the conIIgure scrIpt says.
CPPFLAGS C/C++/Objective C preprocessor flags,
e.g. -I<include dir> if you have headers
in a nonstandard directory <include dir>
Iet's use It.
LDFLAGS=-
CPPFLAGS=-
I/home/<user>/felabs/sysdev/thirdparty/staging/usr/include \
--prefix=/usr
Then, run the compIIatIon wIth make. IopeIuIIy, It works!
Iet's now begIn the InstaIIatIon process. eIore reaIIy InstaIIIng In
the stagIng dIrectory, Iet's InstaII In a dummy dIrectory, to see what's
goIng to be InstaIIed (thIs dummy dIrectory wIII not be used
aIterwards, It Is onIy to verIIy what wIII be InstaIIed beIore poIIutIng
the stagIng space).
make DESTDIR=/tmp/libpng/ install
The DESTDIR varIabIe can be used wIth aII MakeIIIes based on
automake. t aIIows to overrIde the InstaIIatIon dIrectory. Instead oI
beIng InstaIIed In the configuration-prefix, the IIIes wIII be
InstaIIed In DESTDIR/configuration-prefix.
ow, Iet's see what has been InstaIIed In /tmp/libpng/.
./usr/lib/libpng.la libpng14.la
./usr/lib/libpng14.a
./usr/lib/libpng14.la
./usr/lib/libpng14.so libpng14.so.14.3.0
./usr/lib/libpng14.so.14 libpng14.so.14.3.0
./usr/lib/libpng14.so.14.3.0
./usr/lib/libpng.a libpng14.a
./usr/lib/libpng.la libpng14.la
./usr/lib/libpng.so libpng14.so
./usr/lib/pkgconfig/libpng.pc libpng14.pc
./usr/lib/pkgconfig/libpng14.pc
./usr/share/man/man5/png.5
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
./usr/share/man/man3/libpngpf.3
./usr/share/man/man3/libpng.3
./usr/include/pngconf.h libpng14/pngconf.h
./usr/include/png.h libpng14/png.h
./usr/include/libpng14/pngconf.h
./usr/include/libpng14/png.h
./usr/bin/libpng-config libpng14-config
./usr/bin/libpng14-config
So, we have.
The IIbrary, wIth many symboIIc IInks
IIbpng14.so.14.3.0, the bInary oI the current versIon oI
IIbrary
IIbpng14.so.14, a symboIIc IInk to IIbpng14.so.14.3.0, so
that appIIcatIons usIng IIbpng14.so.14 as the SOAM oI
the IIbrary wIII IInd nIt and use the current versIon
IIbpng14.so Is a symboIIc IInk to IIbpng14.so.14.3.0. So It
poInts to the current versIon oI the IIbrary, so that new
appIIcatIons IInked wIth -Ipng14 wIII use the current
versIon oI the IIbrary
IIbpng.so Is a symboIIc IInk to IIbpng14.so. So appIIcatIons
IInked wIth -Ipng wIII be IInked wIth the current versIon oI
the IIbrary (and not the obsoIete one sInce we don't want
anymore to IInk appIIcatIons agaInst the obsoIete versIon!)
IIbpng14.a Is a statIc versIon oI the IIbrary
IIbpng.a Is a symboIIc IInk to IIbpng14.a, so that
appIIcatIons statIcaIIy IInked wIth IIbpng.a wIII In Iact use
the current versIon oI the IIbrary
IIbpng14.Ia Is a conIIguratIon IIIe generated by IIbtooI
whIch gIves conIIguratIon detaIIs Ior the IIbrary. t wIII be
used to compIIe appIIcatIons and IIbrarIes that reIy on
IIbpng.
IIbpng.Ia Is a symboIIc IInk to IIbpng14.Ia. we want to use
the current versIon Ior new appIIcatIons, once agaIn.
The pkg-config IIIes, In /usr/lib/pkgconfig/. These
conIIguratIon IIIes are used by the pkg-config tooI that we
wIII cover Iater. They descrIbe how to IInk new appIIcatIons
agaInst the IIbrary.
The manuaI pages In /usr/share/man/, expIaInIng how to use
the IIbrary.
The header IIIes, In /usr/include/, needed to compIIe new
appIIcatIons or IIbrarIes agaInst IIbpng. They deIIne the
InterIace to IIbpng. There are symboIIc IInks so that one can
choose between the IoIIowIng soIutIons.
!se #IncIude <png.h> In the source code and compIIe
wIth the deIauIt compIIer IIags
!se #IncIude <png.h> In the source code and compIIe
wIth -/usr/IncIude/IIbpng14
!se #IncIude <IIbpng14/png.h> In the source and compIIe
wIth the deIauIt compIIer IIags
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
The /usr/bIn/IIbpng14-conIIg tooI and Its symboIIc IInk
/usr/bIn/IIbpng-conIIg. ThIs tooI Is a smaII sheII scrIpt that
gIves conIIguratIon InIormatIons about the IIbrarIes, needed
to know how to compIIe appIIcatIons/IIbrarIes agaInst IIbpng.
ThIs mechanIsm based on sheII scrIpts Is now beIng
superseded by pkg-conIIg, but as oId appIIcatIons or IIbrarIes
may reIy on It, It Is kept Ior compatIbIIIty.
ow, Iet's make the InstaIIatIon In the stagIng space.
make
DESTDIR=/home/<user>/felabs/sysdev/thirdparty/staging/ install
Then, Iet's InstaII onIy the necessary IIIes In the target space,
manuaIIy.
cp -a staging/usr/lib/libpng14.so.* target/usr/lib
arm-linux-strip target/usr/lib/libpng14.so.14.3.0
And we're IInaIIy done wIth IIbpng!
libipeg
ow, Iet's work on IIbjpeg. ownIoad It Irom
http.//www.Ijg.org/IIIes/jpegsrc.v8.tar.gz and extract It.
ConIIgurIng IIbjpeg Is very sImIIar to the conIIguratIon oI the
prevIous IIbrarIes .
--prefix=/usr
OI course, compIIe the IIbrary.
make
nstaIIatIon to the stagIng space can be done usIng the cIassIcaI
DESTDIR mechanIsm, thanks to the patch appIIed prevIousIy.
make
And IInaIIy, InstaII manuaIIy the onIy needed IIIes at runtIme In the
target space.
cp -a staging/usr/lib/libjpeg.so.8* target/usr/lib/
arm-linux-strip target/usr/lib/libjpeg.so.8.0.0
one wIth IIbjpeg!
FreeType
The IreeType IIbrary Is the next step. Grab the tarbaII Irom
http.//www.Ireetype.org. We tested the Iab wIth versIon 2.4.2 but
more other versIons may aIso work. !ncompress the tarbaII.
The IreeType buIId system Is a nIce exampIe oI what can be done
wIth a good usage oI the autotooIs. Cross-compIIIng IreeType Is very
easy. IIrst, the conIIgure step.
--prefix=/usr
Then, compIIe the IIbrary.
make
nstaII It In the stagIng space.
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
make
And InstaII onIy the requIred IIIes In the target space.
cp -a staging/usr/lib/libfreetype.so.6* target/usr/lib/
arm-linux-strip target/usr/lib/libfreetype.so.6.6.0
one wIth IreeType!
DirectFB
IInaIIy, wIth zIIb, IIbpng, jpeg and IreeType, aII the dependencIes oI
IrectI are ready. We can now buIId the IrectI IIbrary ItseII.
ownIoad It Irom the oIIIcIaI websIte, at http.//www.dIrectIb.org/. We
tested versIon 1.4.5 oI the IIbrary. As usuaI, extract the tarbaII.
eIore conIIgurIng IrectI, Iet's have a Iook at the avaIIabIe
optIons by runnIng ./configure --help. A Iot oI optIons are
avaIIabIe. We see that.
Support Ior Ibdev (the IInux IramebuIIer) Is automatIcaIIy
detected, so that's IIne,
Support Ior IG, jIG and IreeType Is enabIed by deIauIt, so
that's IIne,
We shouId specIIy a vaIue Ior --with-gfxdrivers. The
hardware emuIated by Oemu doesn't have any acceIerated
drIver In IrectI, so we'II pass --with-gfxdrivers=none,
We shouId specIIy a vaIue Ior --with-inputdrivers. We'II
need keyboard (Ior the keyboard) and linuxinput to support
the IInux nput subsystem. So we'II pass --with-
inputdrivers=keyboard,linuxinput
So, Iet's begIn wIth a conIIgure IIne IIke.
--prefix=/usr --with-gfxdrivers=none \
--with-inputdrivers=keyboard,linuxinput
n the output, we see.
*** JPEG library not found. JPEG image provider will not be
built.
So Iet's Iook In conIIg.Iog Ior the jIG Issue. y search Ior jpeg,
you can IInd.
configure:24701: arm-linux-gcc -o conftest -O3 -ffast-math -pipe
-D_REENTRANT conftest.c -ljpeg -ldl -lpthread >&5
/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/arm-unknown-
linux-uclibcgnueabi/sys-root/usr/bin/../lib/gcc/arm-linux-
uclibcgnueabi/4.3.3/../../../../arm-linux-uclibcgnueabi/bin/ld:
cannot find -ljpeg
OI course, It cannot IInd the jpeg IIbrary, sInce we dIdn't pass the
proper LDFLAGS and CFLAGS teIIIng where our IIbrarIes are. So Iet's
conIIgure agaIn wIth.
LDFLAGS=-
CPPFLAGS=-
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
Ok, now at the end oI the conIIgure, we get.
JPEG yes -ljpeg
PNG yes
-I/usr/include/libpng12 -lpng12
[]
FreeType2 yes -
I/usr/include/freetyp2 -lfreetype
t Iound the jIG IIbrary properIy, but Ior IIbpng and Ireetype, It has
added -I optIons that poInts to the IIbpng and Ireetype IIbrarIes
InstaIIed on our host (x86) and not the one oI the target. ThIs Is not
correct!
n Iact, the IrectI conIIgure scrIpt uses the pkg-config system to
get the conIIguratIon parameters to IInk the IIbrary agaInst IIbpng
and IreeType. y deIauIt, pkg-config Iooks In
/usr/lib/pkgconfig/ Ior .pc IIIes, and because the libfreetype6-
dev and libpng12-dev packages are aIready InstaIIed In your system
(It was InstaIIed In a prevIous Iab as a dependency oI another
package), then the conIIgure scrIpt oI IrectI Iound the IIbpng and
IreeType IIbrarIes oI your host!
ThIs Is one oI the bIggest Issue wIth cross-compIIatIon . mIxIng host
and target IIbrarIes, because buIId systems have a tendency to Iook
Ior IIbrarIes In the deIauIt paths. n our case, II libfreetype6-dev
was not InstaIIed, then the /usr/lib/pkgconfig/freetype2.pc IIIe
wouIdn't exIst, and the conIIgure scrIpt oI IrectI wouId have saId
somethIng IIke Sorry, can't IInd IreeType.
So, now, we must teII pkg-config to Iook InsIde the
/usr/lib/pkgconfig/ dIrectory oI our stagIng space. ThIs Is done
through the PKG_CONFIG_PATH envIronment varIabIe, as expIaIned In
the manuaI page oI pkg-config.
Moreover, the .pc IIIes contaIn reIerences to paths. Ior exampIe, In
/home/<user>/felabs/sysdev/thirdparty/staging/usr/lib/pkgc
onfig/freetype2.pc, we can see.
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
[...]
Libs: -L${libdir} -lfreetype
Cflags: -I${includedir}/freetype2 -I${includedir}
So we must teII pkg-conIIg that these paths are not absoIute, but
reIatIve to our stagIng space. ThIs can be done usIng the
PKG_CONFIG_SYSROOT_DIR envIronment varIabIe.
!nIortunateIy, ThIs Is onIy possIbIe wIth pkg-config >= 0.23, whIch
Is not yet avaIIabIe In the !buntu dIstrIbutIon. So start by InstaIIIng
the pkg-config !buntu package avaIIabIe In the data/ dIrectory oI
the Iab.
sudo dpkg -i data/pkg-config_0.23-1_i386.deb
Then, Iet's run the conIIguratIon oI IrectI agaIn, passIng the
PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT_DIR envIronment
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
varIabIes.
LDFLAGS=-L/home/<user>/felabs/sysdev/thirdparty/staging/usr/lib \
CPPFLAGS=-
PKG_CONFIG_PATH=/home/<user>/felabs/sysdev/thirdparty/staging/us
r/lib/pkgconfig/ \
PKG_CONFIG_SYSROOT_DIR=/home/<user>/felabs/sysdev/thirdparty/sta
ging/ \
Ok, now, the IInes reIated to IIbpng and IreeType 2 Iooks much
better.
PNG yes
-I/home/<user>/felabs/sysdev/thirdparty/staging/usr/include/libpng14
-lpng14
FreeType2 yes
-I/home/<user>/felabs/sysdev/thirdparty/staging/usr/include/freetype2
-lfreetype
Iet's buIId IrectI wIth make. AIter a whIIe, It IaIIs, compIaInIng
that X11/Xlib.h and other reIated header IIIes cannot be Iound. n
Iact, II you Iook back the the ./configure scrIpt output, you can see.
X11 support yes -lX11 -lXext
ecause X11 was InstaIIed on our host, IrectI ./configure scrIpt
thought that It shouId enabIe support Ior It. ut we won't have X11
on our system, so we have to dIsabIe It expIIcItIy. n the ./configure
--help output, one can see .
--enable-x11 build with X11 support [default=auto]
So we have to run the conIIguratIon agaIn wIth the same arguments,
and add --disable-x11 to them.
The buIId now goes Iurther, but stIII IaIIs wIth another error .
/usr/lib/libfreetype.so: could not read symbols: File in
wrong format
As you can read Irom the above command IIne, the MakeIIIe Is tryIng
to Ieed an x86 bInary (/usr/lib/libfreetype.so) to your AIM
tooIchaIn. nstead, It shouId have been usIng
usr/lib/libfreetype.so Iound In your stagIng envIronment.
ThIs happens because the IIbtooI .la IIIes In your stagIng area need
to be IIxed to descrIbe the rIght paths In thIs stagIng area. So, In the
.la IIIes, repIace libdir='/usr/lib' by
libdir='/home/<user>/felabs/sysdev/thirdparty/staging/usr/
lib'. Iestart the buIId agaIn, preIerabIy Irom scratch (make clean
then make) to be sure everythIng Is IIne.
IInaIIy, It buIIds !
ow, InstaII IrectI to the stagIng space usIng.
make
And so the InstaIIatIon In the target space.
IIrst, the IIbrarIes.
cp -a staging/usr/lib/libdirect-1.4.so.5*
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
target/usr/lib
cp -a staging/usr/lib/libdirectfb-1.4.so.5*
target/usr/lib
cp -a staging/usr/lib/libfusion-1.4.so.5*
target/usr/lib
arm-linux-strip target/usr/lib/libdirect-
1.4.so.5.0.0
arm-linux-strip target/usr/lib/libdirectfb-
1.4.so.5.0.0
arm-linux-strip target/usr/lib/libfusion-
1.4.so.5.0.0
Then, the pIugIns that are dynamIcaIIy Ioaded by IrectI.
We IIrst copy the whoIe /usr/lib/directfb-1.4-5/
dIrectory, then remove the useIess IIIes (.la) and IInaIIy strIp
the .so IIIes.
cp -a staging/usr/lib/directfb-1.4-5/ target/usr/lib
find target/usr/lib/directfb-1.4-5/ -name '*.la'
-exec rm {} \;
find target/usr/lib/directfb-1.4-5/ -name '*.so'
-exec arm-linux-strip {} \;
DirectFB examples
To test that our IrectI InstaIIatIon works, we wIII use the exampIe
appIIcatIons provIded by the IrectI project. Start by downIoadIng
the tarbaII at http.//www.dIrectIb.org/downIoads/xtras/IrectI-
exampIes-1.2.0.tar.gz and extract It.
Then, we conIIgure It just as we conIIgured IrectI.
LDFLAGS=-
CPPFLAGS=-
PKG_CONFIG_PATH=/home/<user>/felabs/sysdev/thirdparty/staging/us
r/lib/pkgconfig/ \
PKG_CONFIG_SYSROOT_DIR=/home/<user>/felabs/sysdev/thirdparty/sta
ging/ \
--prefix=/usr
Then, compIIe It wIth make. Soon a compIIatIon error wIII occur
because "bzero" Is not deIIned. The "bzero" IunctIon Is a deprecated
S IunctIon, and memset shouId be used Instead. The G! C
IIbrary stIII deIInes "bzero", but by deIauIt, the uCIIbc IIbrary doesn't
provIde "bzero" (to save space). So, Iet's modIIy the source code In
src/df_knuckles/matrix.c to change the IIne.
#define M_CLEAR(m) bzero(m, MATRIX_SIZE)
to
#define M_CLEAR(m) memset(m, 0, MATRIX_SIZE)
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
Iun the compIIatIon agaIn, It shouId succeed.
Ior the InstaIIatIon, as IrectI exampIes are onIy appIIcatIons and
not IIbrarIes, we don't reaIIy need them In the stagIng space, but
onIy In the target space. So we'II dIrectIy InstaII In the target
space usIng the install-strip make target. ThIs make target Is
usuaIIy avaIIabIe wIth autotooIs based buIId systems. n addItIon to
the destInatIon dIrectory (DESTDIR varIabIe), we must aIso teII whIch
strIp program shouId be used, sInce strIppIng Is an archItecture-
dependent operatIon (STRIP varIabIe).
make STRIP=arm-linux-strip \
DESTDIR=/home/<user>/felabs/sysdev/thirdparty/target/
install-strip
Final setup
Start the system In Oemu usIng the run_qemu scrIpt, and try to run
the df_andi program, whIch Is one oI the IrectI exampIes.
The appIIcatIon wIII IaII to run, because the pthread IIbrary (whIch Is
a component oI the C IIbrary) Is mIssIng. ThIs IIbrary Is avaIIabIe
InsIde the tooIchaIn. So Iet's add It to the target.
cp -a /usr/local/xtools/arm-unknown-linux-
uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sys-
root/lib/libpthread* target/lib/
Then, try to run df_andi agaIn. t wIII compIaIn about libdl, whIch
Is used to dynamIcaIIy Ioad IIbrarIes durIng appIIcatIon executIon. So
Iet's add thIs IIbrary to the target.
root/lib/libdl* \
target/lib
When runnIng dIandI agaIn, It wIII compIaIn about IIbgccs, so Iet's
copy thIs IIbrary to the target.
root/lib/libgcc_s* target/lib
ow, the appIIcatIon shouId no Ionger compIaIn about mIssIng
IIbrary. ut when started, shouId compIaIn about InexIstIng /dev/fb0
devIce IIIe. So Iet's create thIs devIce IIIe.
sudo mknod target/dev/fb0 c 29 0
ext executIon oI the appIIcatIon wIII compIaIn about mIssIng
/dev/tty0 devIce IIIe, so Iet's create It.
sudo mknod target/dev/tty0 c 4 0
IInaIIy, when runnIng dIandI, another error message shows up.
Unable to dlopen '/usr/lib/directfb-1.4-
0/interfaces/IDirectFBImageProvider/libidirectfbimageprovi
der_png.so' !
File not found
IrectI Is tryIng to Ioad the IG pIugIn usIng the dlopen()
IunctIon, whIch Is part oI the libdl IIbrary we added to the target
system beIore. !nIortunateIy, IoadIng the pIugIn IaIIs wIth the IIIe
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
not Iound error. Iowever, the pIugIn Is properIy present, so the
probIem Is not the pIugIn ItseII. What happens Is that the pIugIn
depends on the libpng IIbrary, whIch ItseII depends on the
mathematIc IIbrary. And the mathematIc IIbrary libm (part oI the C
IIbrary) has not yet been added to our system. So Iet's do It.
uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sys-root/lib/libm*
target/lib
ow, you can try and run the df_andi appIIcatIon!
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
cd
Using a build system, example with Buildroot
ObjectIves. dIscover how a buIId system Is used and how It
works, wIth the exampIe oI the uIIdroot buIId system. uIId a
IInux system wIth IIbrarIes and make It work InsIde Oemu.
Setup
Go Into the /home/<user>/felabs/sysdev/buildroot/ dIrectory,
whIch aIready contaIns some data needed Ior thIs Iab, IncIudIng a
kerneI Image.
Get Buildroot and explore the source code
The oIIIcIaI uIIdroot websIte Is avaIIabIe at
http.//www.buIIdroot.net. ownIoad the stabIe 2011.05 versIon
whIch we have tested Ior thIs Iab. !ncompress the tarbaII and go
InsIde the buildroot dIrectory.
SeveraI subdIrectorIes or IIIes are vIsIbIe, the most Important ones
are.
boot contaIns the MakeIIIes and conIIguratIon Items reIated
to the compIIatIon oI common bootIoaders (Grub, !-oot,
arebox, etc.)
configs contaIns a set oI predeIIned conIIguratIons, sImIIar
to the concept oI deIconIIg In the kerneI.
docs contaIns the documentatIon Ior uIIdroot. You can start
readIng buildroot.html whIch Is the maIn uIIdroot
documentatIon,
linux contaIns the MakeIIIe and conIIguratIon Items reIated
to the compIIatIon oI the IInux kerneI
Makefile Is the maIn MakeIIIe that we wIII use to use
uIIdroot. everythIng works through MakeIIIes In uIIdroot,
package Is a dIrectory that contaIns aII the MakeIIIes, patches
and conIIguratIon Items to compIIe the userspace appIIcatIons
and IIbrarIes oI your embedded IInux system. Iave a Iook at
varIous subdIrectorIes and see what they contaIn,
target contaIns patches and other Items specIIIc to partIcuIar
hardware pIatIorms
toolchain contaIns the MakeIIIes, patches and conIIguratIon
Items to generate the cross-compIIIng tooIchaIn.
Configure Buildroot
n our case, we wouId IIke to.
Generate an embedded IInux system Ior AIM,
!se an aIready exIstIng externaI tooIchaIn Instead oI havIng
uIIdroot generatIng one Ior us,
ntegrate usybox, IrectI and IrectI sampIe
appIIcatIons In our embedded IInux system,
ntegrate the target IIIesystem Into both an ext2 IIIesystem
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
Image and a tarbaII
To run the conIIguratIon utIIIty oI uIIdroot, sImpIy run.
make menuconfig
Set the IoIIowIng optIons.
Target ArchItecture. AIM
Target ArchItecture VarIant. arm926t.
Target A. EABI
uIId optIons
umber oI jobs to run sImuItaneousIy. choose 2 or 4, Ior
exampIe, to speed up compIIIng, especIaIIy II you have a
duaI-core system.
TooIchaIn
Toolchcin type. External toolchain
Externcl toolchcin C librcry. uClibc
We must teII uIIdroot about our tooIchaIn conIIguratIon,
so. enabIe Iarge IIIe Support, IIC. uIIdroot wIII check
these parameters anyway.
Externcl toolchcin pcth. use the tooIchaIn you buIIt.
/usr/local/xtools/arm-unknown-linux-uclibcgnueabi
System conIIguratIon
Iort to run a getty (IogIn prompt) on, change ttyS0 to
tty1
Iackage seIectIon Ior the target
Keep usybox (deIauIt versIon) and keep the usybox
conIIguratIon proposed by uIIdroot,
n GraphIcs IIbrarIes and appIIcatIons
SeIect IrectI. uIIdroot wIII automatIcaIIy seIect the
necessary dependencIes.
Iemove touchscreen support Irom IrectI
SeIect IrectI exampIes
SeIect aII the IrectI exampIes
Target IIIesystem optIons
SeIect ext2 root filesystem
SeIect tar root filesystem
xIt the menuconfig InterIace. Your conIIguratIon has now been
saved to the .config IIIe.
Generate the embedded Linux system
just run
make
t IaIIs quIckIy because we Iack the gettext and subversion
packages, so InstaII them. uIIdroot wIII IIrst create a smaII
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
cd
envIronment wIth the externaI tooIchaIn, then downIoad, extract,
conIIgure, compIIe and InstaII each component oI the embedded
system.
AII the compIIatIon has taken pIace In the output/ dIrectory. Iet's
expIore Its contents .
build, Is the dIrectory In whIch each component buIIt by
uIIdroot Is extract, and where the buIId actuaIIy takes pIace
host, Is the dIrectory where uIIdroot InstaIIs some
components Ior the host. As uIIdroot don't want to depend
on too many thIngs InstaIIed In the deveIoper machInes, It
InstaIIs some tooIs needed to compIIe the packages Ior the
target. n our case It InstaIIed pkg-config (sInce the versIon
oI the most may be ancIent) and tooIs to generate the root
IIIesystem Image (genext2fs, makedevs, fakeroot)
images, whIch contaIns the IInaI Images produced by
uIIdroot. n our case It's just an ext2 IIIesystem Image and a
tarbaII oI the IIIesystem, but dependIng on the uIIdroot
conIIguratIon, there couId aIso be a kerneI Image or a
bootIoader Image. ThIs Is where we IInd rootfs.tar and
rootfs.ext2, whIch are respectIveIy the tarbaII and an ext2
Image oI the generated root IIIesystem.
staging, whIch contaIns the "buIId" space oI the target
system. AII the target IIbrarIes, wIth headers, documentatIon.
t aIso contaIns the system headers and the C IIbrary, whIch
In our case have been copIed Irom the cross-compIIIng
tooIchaIn.
target, Is the target root IIIesystem. AII appIIcatIons and
IIbrarIes, usuaIIy strIpped, are InstaIIed In thIs dIrectory.
Iowever, It cannot be used dIrectIy as the root IIIesystem, as
aII the devIce IIIes are mIssIng. It Is not possIbIe to create
them wIthout beIng root, and uIIdroot has a poIIcy oI not
runnIng anythIng as root.
toolchain, Is the IocatIon where the tooIchaIn Is buIIt.
Iowever, In our conIIguratIon, we re-used an exIstIng
tooIchaIn, so thIs dIrectory contaIns aImost nothIng.
Run the generated system
I you dIdn't do It In the prevIous Iab, InstaII OM! emuIator Ior non
x86 targets.
sudo apt-get install qemu-kvm-extras
We wIII use the kerneI Image In data/ and the IIIesystem Image
generated by uIIdroot In the ext2 Iormat to boot the generated
system In Oemu. We start by usIng a Oemu-emuIated AIM board
wIth dIspIay support, aIIowIng to test graphIcaI appIIcatIons reIyIng
on the IrectI IIbrary. Iater, we wIII be abIe move to a reaI board II
your hardware aIso has a graphIcaI dIspIay.
The run_qemu scrIpt contaIns what's needed to boot the system In
Oemu.
Iog In (root account, no password), run demo programs.
df_andi
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
df_dok
df_fire
...
Tests on the lGEPv2 board
I you have graphIcaI dIspIays to connect your GIv2 board to (IC
dIspIay wIth V- or IM Input, T IIco Irojector...), and the
correspondIng cabIes (IM to V- or IM to IM), you can
test your root IIIesystem on the board.
You can skIp to the next sectIon II you don't have a dIspIay.
Iere's what you can do.
dIt etc/inittab, uncomment the IIne wIth ttyS0 and
repIace aII the occurrences oI ttyS0 by ttyO2
Ither copy the ext2 Image to a bIock devIce that can be
accessed by your hardware (IIash card reader, !S drIve...)
Or mount the ext2 Image and copy Its contents to a IIash
partItIon on your board.
Connect your board to an V- or IM dIspIay
Get the Iatest IInux 2.6.39.x sources, take the deIauIt
conIIguratIon oI OMAI2 and buIId thIs IInux kerneI wIth the
IoIIowIng settIngs.
CONFIG_OMAP2_DSS=y
FB_OMAP2=y
CONFIG_PANEL_GENERIC_DPI=y
LOGO=y (optIonaI)
Add the IoIIowIng settIngs to the boot arguments.
console=tty0
(aIIows you to have both a IramebuIIer and serIaI consoIe)
vram=12M (vIdeo IAM)
omapfb.mode=dvi:640x480MR-16@60 (exampIe Ior the IIco
Irojector. You may IIrst try to do wIthout thIs parameter, and
then specIIy a mode that your monItor supports).
omapdss.def_disp=dvi (deIauIt output Ior the Omap
IspIay SubSystem drIver)
Going further
Add dropbear (SSI server and cIIent) to the IIst oI packages
buIIt by uIIdroot, add the network emuIatIon In Oemu (see the
../thirdparty/run_qemu scrIpt Ior an exampIe), and Iog to
your target system In Oemu usIng a ssh cIIent on your
deveIopment workstatIon. IInt. you wIII have to set a non-empty
password Ior the root account on your target Ior thIs to work.
Add a new package In uIIdroot Ior the G! GtypIst game.
Iead the uIIdroot documentatIon to see how to add a new
package. IInaIIy, add thIs package to your target system,
compIIe It and run It In Oemu.
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
I you haven't done It yet In the
prevIous Iab, you wIII aIso need to
modIIy the /etc/qemu-ifup scrIpt to
contaIn.
#!/bin/sh
/sbin/ifconfig $1 172.20.0.1
Sysdev - Application development
ObjectIve. CompIIe and run your own IrectI appIIcatIon on
the target.
Setup
Go to the /home/<user>/felabs/sysdev/appdev dIrectory.
Compile your own application
We wIII re-use the system buIIt durIng the uIIdroot Iab and add to
It our own appIIcatIon.
IIrst, Instead oI usIng an ext2 Image, we wIII mount the root
IIIesystem over IS to make It easIer to test our appIIcatIon. So,
create a qemu-rootfs/ dIrectory, and InsIde thIs dIrectory,
uncompress the tarbaII generated by uIIdroot In the prevIous Iab (In
the output/images/ dIrectory). on't Iorget to extract the archIve as
root sInce the archIve contaIns devIce IIIes.
Then, adapt the run_qemu scrIpt to your conIIguratIon, and verIIy
that the system works as expected.
ow, our appIIcatIon. n the Iab dIrectory the IIIe data/app.c
contaIns a very sImpIe IrectI appIIcatIon that dIspIays the
data/background.png Image Ior IIve seconds. We wIII compIIe and
Integrate thIs sImpIe appIIcatIon to our IInux system.
uIIdroot has generated tooIchaIn wrappers In
output/host/usr/bin, whIch make It easIer to use the tooIchaIn,
sInce those wrappers pass some mandatory IIags (especIaIIy the
--sysroot gcc IIag, whIch teIIs gcc where to Iook Ior the headers
and IIbrarIes).
Iet's add thIs dIrectory to our IATI .
export
PATH=/home/<user>/felabs/sysdev/buildroot/output/host/usr/
bin:$PATH
Iet's try to compIIe the appIIcatIon.
arm-linux-gcc -o app app.c
t compIaIns that It cannot IInd the directfb.h header. ThIs Is
normaI, sInce we dIdn't teII the compIIer where to IInd It. So Iet's use
pkg-conIIg to query the pkg-conIIg database about the IocatIon oI the
header IIIes and the IIst oI IIbrarIes needed to buIId an appIIcatIon
agaInst IrectI.
export
PKG_CONFIG_PATH=/home/<user>/felabs/sysdev/buildroot/outpu
t/staging/usr/lib/pkgconfig
export
PKG_CONFIG_SYSROOT_DIR=/home/<user>/felabs/sysdev/buildroo
t/output/staging/
arm-linux-gcc -o app app.c $(pkg-config --libs --cflags
directfb)
Our appIIcatIon Is now compIIed! Copy the generated bInary and the
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
background.png Image to the IS root IIIesystem (In the root/
dIrectory Ior exampIe), start your system, and run your appIIcatIon!
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
Sysdev - Remote application debugging
ObjectIve. !se strace and Itrace to dIagnose program Issues.
!se gdbserver and a cross-debugger to remoteIy
debug an embedded appIIcatIon
Setup
Go to the /home/<user>/felabs/sysdev/debugging dIrectory.
Debugging setup
oot your AIM board over IS on the IIIesystem produced In the
TIny embedded system Iab, wIth the same kerneI.
Setting up gdbserver, strace and ltrace
gdbserver, strace and ltrace have aIready been compIIed Ior your
target archItecture as part oI the cross-compIIIng tooIchaIn. IInd
them In the InstaIIatIon dIrectory oI your tooIchaIn. Copy these
bInarIes to the /usr/bin/ dIrectory In the root IIIesystem oI your
target system.
Enabling iob control
n thIs Iab, we are goIng to run a buggy program that keeps hangIng
and crashIng. ecause oI thIs, we are goIng to need job controI, In
partIcuIar [Ctrl] [C] aIIowIng to Interrupt a runnIng program.
At boot tIme, you probabIy notIced that warnIng that job controI was
turned oII.
/bin/sh: can't access tty; job control turned off
ThIs happens when the sheII Is started In the consoIe. The system
consoIe cannot be used as a controIIIng termInaI.
A work around Is to start thIs sheII In ttyO2 (the 3rd OMAI serIaI
port on the GIv2 board) by modIIyIng the /etc/inittab IIIe.
IepIace
::askfirst:/bin/sh (ImpIyIng /dev/console)
by
ttyO2::askfirst:/bin/sh (usIng /dev/ttyO2)
AIso create /dev/ttyO2 (major 4, mInor 66, IIke ttyS2) and reboot.
You shouId no Ionger see the "job controI turned oII" warnIng, and
shouId be abIe to use [Ctrl] [C].
Using strace
strace aIIows to trace aII the system caIIs made by a process.
openIng, readIng and wrItIng IIIes, startIng other processes,
accessIng tIme, etc. When somethIng goes wrong In your appIIcatIon,
strace Is an InvaIuabIe tooI to see what It actuaIIy does, even when
you don't have the source code.
WIth your cross-compIIIng tooIchaIn, compIIe the data/vista-
emulator.c program, and copy the resuItIng bInary to the /root
dIrectory oI the root IIIesystem (you mIght need to create thIs
dIrectory II It doesn't exIst yet).
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
arm-linux-gcc -o vista-emulator data/vista-emulator.c
cp vista-emulator path/to/root/filesystem/root
ack to target system, try to run the /root/vista-emulator
program. t shouId hang IndeIInIteIy!
nterrupt thIs program by hIttIng [Ctrl] [C].
ow, runnIng thIs program agaIn through the strace command and
understand why It hangs. You can guess It wIthout readIng the
source code!
ow add what the program was waItIng Ior, and now see your
program proceed to another bug, IaIIIng wIth a segmentatIon IauIt.
Using ltrace
Try to run the program through ltrace. You wIII see that another
IIbrary Is requIred to run thIs utIIIty. IInd thIs IIbrary In the tooIchaIn
and add It to your root IIIesystem agaIn.
ow, ltrace shouId run IIne and you shouId 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
segIauIts.
CompIIe vista-emulator.c agaIn wIth the -g optIon to IncIude
debuggIng symboIs. Keep thIs bInary on your workstatIon, and make
a copy In the /root dIrectory oI the target root IIIesystem. Then,
strIp the bInary on the target to remove the debuggIng symboIs. They
are onIy needed on your host, where the cross-debugger wIII run.
arm-linux-strip path/to/root/filesystem/root/vista-emulator
Then, on the target sIde, run vista-emulator under gdbserver.
gdbserver wIII IIsten on a TCI port Ior a connectIon Irom G, and
wIII controI the executIon oI vIsta-emuIator accordIng to the G
commands.
gdbserver localhost:2345 vista-emulator
On the host sIde, run arm-linux-gdb (aIso Iound In your tooIchaIn).
arm-linux-gdb vista-emulator
You can aIso start the debugger through the ddd InterIace.
ddd --debugger arm-linux-gdb vista-emulator
G starts and Ioads the debuggIng InIormatIon Irom the vista-
emulator bInary that has been compIIed wIth -g.
Then, we need to teII where to IInd our IIbrarIes, sInce they are not
present In the deIauIt /lib and /usr/lib dIrectorIes on your
workstatIon. ThIs Is done by settIng G sysroot varIabIe.
(gdb) set sysroot /usr/local/xtools/arm-unknown-linux-
uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sys-root/
And teII gdb to connect to the remote system.
(gdb) target remote <target-ip-address>:2345
Then, use gdb as usuaI to set breakpoInts, Iook at the source code,
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
run the appIIcatIon step by step, etc. GraphIcaI versIons oI gdb, such
as ddd can aIso be used In the same way. n our case, we'II just start
the program and waIt Ior It to hIt the segmentatIon IauIt.
(gdb) continue
You couId then ask Ior a backtrace to see where thIs happened.
(gdb) backtrace
ThIs wIII teII you that the segmentatIon IauIt occurred In a IunctIon oI
the C IIbrary, caIIed by our program. ThIs shouId heIp you In IIndIng
the bug In our appIIcatIon.
What to remember
urIng thIs Iab, we Iearned that...
CompIIIng an appIIcatIon Ior the target system Is very sImIIar
to compIIIng an appIIcatIon Ior the host, except that the cross-
compIIatIon Introduces a Iew compIexItIes when IIbrarIes are
used.
t's easy to study the behavIor oI programs and dIagnose
Issues wIthout even havIng the source code, thanks to strace
and ltrace.
You can Ieave a smaII gdbserver program (300 K) on your
target that aIIows to debug target appIIcatIons, usIng a
standard G debugger on the deveIopment host.
t Is IIne to strIp appIIcatIons and bInarIes on the target
machIne, as Iong as the programs and IIbrarIes wIth
debuggIng symboIs are avaIIabIe on the deveIopment host.
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
mbedded IInux
System deveIopment
TraInIng Iab book
Real-time - Timers and scheduling latency
ObjectIve. Iearn how to handIe reaI-tIme processes and
practIce wIth the dIIIerent reaI-tIme modes.
Measure scheduIIng Iatency.
AIter thIs Iab, you wIII
e abIe to appIy the rt-preempt patches and be more IamIIIar
wIth kerneI conIIguratIon settIngs reIated to reaI-tIme.
e abIe to check cIock accuracy.
e abIe to start processes wIth reaI-tIme prIorIty.
Iave compared scheduIIng Iatency on your system, between a
standard kerneI and a kerneI wIth reaI-tIme preempt patches.
Setup
Go to the /home/<user>/felabs/realtime/rttest dIrectory.
Ior thIs Iab, you must have compIIed a 2.6.35.9 kerneI Ior the GI
board, wIth the deIauIt conIIguratIon (named igep0020_defconfig,
the generIc omap2plus_defconfig dIdn't exIst In 2.6.35.9), except
that you wIII have to remove the IIbertas wIreIess moduIes. Iemove
the CONFIG_HIGH_RES_TIMERS optIon, to IIrst test the kerneI wIthout
hIgh-resoIutIon tImers.
oot the GI board by mountIng the root IIIesystem avaIIabIe at
/home/<user>/felabs/realtime/rttest/nfsroot/ wIth IS. ote
that In 2.6.35.9, the OMAI serIaI port were named ttyS, not ttyO, so
you must adjust your console= argument to use ttyS2.
IIease stay wIth a 2.6.35.9 versIon, as thIs Is the most recent versIon
wIth XenomaI support.
nstaII netcat on your host, by runnIng.
apt-get install netcat
ownIoad CodeSourcery's 2009q1 tooIchaIn at.
http.//www.codesourcery.com/sgpp/IIte/arm/portaI/reIease858
Choose "A32 G!/IInux TAI"
!ntar It.
Add /home/<user>/felabs/realtime/rttest/arm-2009q1/bin to
your PATH.
Using high-resolution timers
Iave a Iook at the rttest.c source IIIe avaIIabIe In root/ In the
nfsroot/ dIrectory. See how It shows the resoIutIon oI the
CLOCK_MONOTONIC cIock.
ow compIIe thIs program.
arm-none-linux-gnueabi-gcc -o rttest rttest.c -lrt
xecute the program on the board. s the cIock resoIutIon good or
bad? Compare It to the tImer tIck oI your system, as deIIned by
CONFIG_HZ.
ObvIousIy, thIs resoIutIon wIII not provIde accurate sIeep tImes, and
IeaI TIme In
embedded IInux systems
TraInIng Iab book
IeaI TIme In
TraInIng Iab book
We are usIng a gIIbc tooIchaIn because
gIIbc has better support Ior the IOSX
IT AI than uCIIbc. n our case, when
we created thIs Iab, uCIIbc dIdn't
support the clock_nanosleep IunctIon
used In our rttest.c program.
You wIII have to Iog wIth username
root and no password.
thIs Is because our kerneI doesn't use hIgh-resoIutIon tImers. So Iet's
enabIe the IoIIowIng optIons In the kerneI conIIguratIon.
CONFIG_HIGH_RES_TIMERS
IecompIIe your kerneI, boot your GI board wIth the new versIon,
and check the new resoIutIon. etter, Isn't It ?
Testing the non-preemptible kernel
ow, do the IoIIowIng tests.
Test the program wIth nothIng specIaI and wrIte down the
resuIts.
Test your program and at the same tIme, add some workIoad
to the board, by runnIng doload 300 > /dev/null 2>&1 & on
the board, and usIng netcat 192.168.0.100 5566 on your
workstatIon when you see the message "Listening on any
address 5566" In order to IIood the network InterIace oI the
GI board (where 192.168.0.100 Is the I address oI the
GI board)
Test your program agaIn wIth the workIoad, but by runnIng
the program In the SCHED_FIFO scheduIIng cIass at prIorIty
99, usIng the chrt command.
Testing the preemptible kernel
IecompIIe your kerneI wIth CONFIG_PREEMPT enabIed, whIch enabIes
kerneI preemptIon (except Ior crItIcaI sectIons protected by
spInIocks).
Ie-do the sImpIe tests wIth thIs new preemptIbIe kerneI and compare
the resuIts.
Testing Xenomai scheduling latency
Get XenomaI Irom Its downIoad area.
http://download.gna.org/xenomai/stable/
!ntar XenomaI.
Irepare the kerneI Ior XenomaI compIIatIon .
./scripts/prepare-kernel.sh \
--arch=arm --linux=/path/to/linux-2.6.35.9
You can reuse the kerneI conIIguratIon Irom a prevIous compIIe job,
then Iaunch kerneI conIIguratIon tooI agaIn and enabIe the optIons.
CONFIG_XENOMAI
CONFIG_XENO_DRIVERS_TIMERBENCH
Other optIons oI Interest (AIM specIIIc) are.
CONFIG_XENO_HW_UNLOCKED_SWITCH
Iead the heIp assocIated wIth these optIons, decIde whether you
want to enabIe them.
CompIIe rttest Ior the XenomaI IOSX skIn.
DESTDIR=/home/<user>/felabs/realtime/rttest/nfsroot/
export DESTDIR
IeaI TIme In
TraInIng Iab book
IeaI TIme In
TraInIng Iab book
CFL=`$DESTDIR/usr/bin/xeno-config --skin=posix --cflags`
LDF=`$DESTDIR/usr/bin/xeno-config --skin=posix --ldflags`
arm-none-linux-gnueabi-gcc $CFL -o rttest rttest.c $LDF
ow boot the board wIth the new kerneI.
Iun the IoIIowIng commands on the board .
echo 0 > /proc/xenomai/latency
ThIs wIII dIsabIe the tImer compensatIon Ieature oI XenomaI. ThIs
Ieature aIIows XenomaI to adjust the tImer programmIng to take Into
account the tIme the system needs to scheduIe a task aIter beIng
woken up by a tImer. Iowever, thIs Ieature needs to be caIIbrated
specIIIcaIIy Ior each system. y dIsabIIng thIs Ieature, we wIII have
raw XenomaI resuIts, that couId be Iurther Improved by doIng proper
caIIbratIon oI thIs compensatIon mechanIsm.
Ie-run the tests, compare the resuIts.
Testing Xenomai interrupt latency
Measure the Interrupt Iatency wIth and wIthout Ioad, runnIng the
IoIIowIng command.
latency -t 2
IeaI TIme In
TraInIng Iab book
IeaI TIme In
TraInIng Iab book
IeaI TIme In
TraInIng Iab book
IeaI TIme In
TraInIng Iab book
Using mdev
ObjectIve. IractIcIng wIth usyox mdev
!se mdev to popuIate the /dev dIrectory wIth devIce IIIes
correspondIng to devIces present on the system.
!se mdev to automount externaI dIsk partItIons.
Root filesystem
We wIII reuse the root IIIesystem Irom the "TIny system" Iab.
Kernel settings
Ieuse the IInux kerneI Irom the "TIny system" Iab. I you preIer to
start Irom Iresh sources, use the conIIguratIon suppIIed In the data
dIrectory.
ow add or modIIy the beIow settIngs to your kerneI.
nabIe IoadabIe moduIe support. COIGMO!IS=y
ModuIe unIoadIng. COIGMO!I!IOA=y
Support Ior Iost-sIde !S. COIG!S=
Make sure thIs Is set as a moduIe!
OIC IC support. COIG!SOICIC=
!S Mass Storage support. COIG!SSTOIAG=
And any other Ieature that couId be needed on your hardware
to access your hot-pIuggabIe devIce.
CompIIe your kerneI. nstaII the moduIes In your root IIIesystem
usIng.
make INSTALL_MOD_PATH=<root-dir-path> modules_install
Booting the system
oot your system through IS wIth the gIven root IIIesystem.
To make sure that moduIe IoadIng works, try to Ioad the usb-
storage moduIe.
modprobe usb-storage
First mdev tests
We are IIrst goIng to use mdev to popuIate the /dev dIrectory wIth aII
devIces present at boot tIme.
ModIIy the /etc/init.d/rcS scrIpt to mount a tmpIs IIIesystem on
/dev/, and run mdev -s to popuIate thIs dIrectory wIth aII mInImum
devIce IIIes. Very nIce, Isn't It?
Using mdev as a hotplug agent
!sIng the guIdeIInes In the Iectures, and usyox documentatIon,
use mdev to automatIcaIIy create aII the /dev/sd[a-z][1-9]* devIce
IIIes when a !S dIsk Is Inserted, correspondIng to the dIsk ItseII
mbedded IInux
System eveIopment
TraInIng Iab book
mbedded IInux
System eveIopment
TraInIng Iab book
and Its partItIons.
AIso make sure these devIce IIIes are aIso removed automatIcaIIy
when the IIash drIve Is removed.
Automatic mounting
IeIIne your conIIguratIon to aIso mount each partItIon automatIcaIIy
when a !S dIsk Is Inserted, and to do the opposIte aIter the dIsk Is
removed.
mbedded IInux
system deveIopment
TraInIng Iab book
mbedded IInux
system deveIopment
TraInIng Iab book
You couId use /media/<devname> as
mount poInt Ior each partItIon.
Backing up your lab files
ObjectIve. cIean up and make an archIve oI your Iab dIrectory
End of the training session
CongratuIatIons. You reached the end oI the traInIng sessIon. You
now have pIenty oI workIng exampIes you created by yourseII, and
you can buIId upon them to create more eIaborate thIngs.
n thIs Iast Iab, we wIII create an archIve oI aII the thIngs you
created. We won't keep everythIng though, as there are Iots oI
thIngs you can easIIy retrIeve agaIn.
Create a lab archive
Go to the dIrectory contaInIng your felabs dIrectory.
cd $HOME
ow, run a command that wIII do some cIean up and then create an
archIve wIth the most Important IIIes.
KerneI conIIguratIon IIIes
Other source conIIguratIon IIIes (usyox, CrosstooI-ng...)
KerneI Images
TooIchaIn
Other custom IIIes
Iere Is the command.
./felabs/archive-labs
At end end, you shouId have a felabs-<user>.tar.lzma archIve
that you can copy to a !S IIash drIve, Ior exampIe. ThIs IIIe shouId
onIy be a Iew hundreds oI M bIg.
IInux TraInIng
Iab ook
IInux TraInIng
Iab ook

Labs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Labs

Uploaded by

Copyright:

Available Formats

IInux TraInIng

You might also like