Git tutorial

Git is a distributed version control system which means that it does not require a central server to store all the data, unlike SVN or CVS. In practice, there is usually a central repository (remote repository, typically hosted on the internet) that one can copy (cloning). When cloning an existing repository , the user grabs the whole working tree. If you'd like to create a branch for instance to work on a specific part of your code in parallel, the branch will be local. The central copy does not need to have a counterpart.

Linux kernel's project is using git as its version control system. Some of the following commands may be useful :

Create a Git repository

# Run it in your development directory
git init

This folder will then contain a .git directory containing the complete history of the repository and .git/config will store the local configuration for it.

Add files to the repository

# Replace . by the file name if you're not planning to add all files
git add .

The marked files have been added to the staging area. It means that they will be part of the next commit. All of your modified files need to be staged (added) so that they will be included in the next commit.

Check repository status

git status

You will see which files have been modified, which ones are staged and which are not, conflicts, etc...

Commit files to the repository

git commit -m "Commit message"

Trace back your modifications

git log

You will see the list of your commits and your activity in your working tree.

Move / Rename a file

git mv <orignial file path> <new file path>

Remove a file from repository

git rm <file name>

Note : you can also simply delete the file manually. In this case, you have to add the '-a' option to the commit command to take the deletion into account.

Remove a file from staging area

git reset <file name>

Working with Remote Repositories

Ok, now we got the basics, how do we synchronize our work with others ? In the example above, we started from scratch, and our repository is local. What if somebody would like to copy it ?

Clone a remote repository

Imagine that we created a repo in a folder named "original_repo". Let's move back and create a new folder :

cd ..
mkdir clone_repo
cd clone_repo

Once we're here, we will clone the "original_repo" into "clone_repo" :

git clone ../original_repo.git .

Note : A git repository address always end with a ".git" extension.
Note 2 : If you omit the '.' at the end of the command, git will create a directory named like the origin (here 'original_repo'), move into it and pull the files from there.

If the git repository is hosted on the web, it is almost the same :

git clone https://linux389pi@bitbucket.org/linux389pi/linux389pi.git

Push changes to a remote repository

You probably noticed that git commit does not mirror your modifications on the remote repository. Instead, it creates a local commit object (snapshot). To send your modification to the central repository, you will have to push your local repository:

git push

Pull changes from the remote repository

The opposite action of pushing is pulling. You will synchronize your repository with the central one by pulling :

git pull

If you are looking for more information about git, check this link :

Git - Book 

If you are also willing to experiment git with a very cool tutorial, here is the link :

Git in practice 

Read More

Boot sequence on embbeded platform

When powered on, the CPU will fetch its first instruction from an address preassigned by the manufacturer. From there, two options :

• the bootlader is programmed at this address (on a NOR memory)
• the CPU has an integrated boot code that will start ( ROM memory)

The former is not very common anymore as it requires some NOR flash to be wired to the CPU while the latter boots in two steps (first and second stage). Here is a typical example with an AT91 CPU:

The mechanism is almost always identical with other CPUs. The first stage bootloader is usually provided by the CPU vendor (X-Loader instead of AT91Bootstrap for OMAP3 CPUs) and limited in size due to hardware constraints (SRAM size).

The Bootloader

It is a small piece of code responsible of :

• low level hardware initialization (network, USB, ...)
• loading the operating system kernel to memory (from disk, network or non-volatile storage)
• booting the kernel 

Additionally, the bootloader may provide a shell and some services for testing, diagnosis or file transfer.

You can find information about the existing bootloaders at :
Comparison of bootloaders

A very good page describing the boot sequence in details for AT91:
AT91 Boot sequence

We will focus on the bootloader named u-boot as it is the most popular one for ARM platforms.

Read More

Embedded development setups

Linked Setup (most common)

The host and the target are permanently connected using a cable (serial or ethernet). With this configuration, the host builds the cross-compiled binaries and downloads them directly on the device's storage media. The cable is also used for debugging although there are usually 2 cables : serial for debugging and ethernet for downloading the software.

Requirements for this setup :

• host : cross-platform development environment installed
• target : appropriate bootloader, functional kernel, minimal root filesystem

Note : the root filesystem could also be NFS-mounted instead of being on the storage media in the target. This is perfect for development as it avoids having to copy the program modifications all the time.

Removable Storage Setup

The host and the target are not physically connected. Instead, the host builds the binaries and copy them to a removable storage media such as an MMC Card. The card is then inserted into the device's socket and loaded by the target's minimal bootloader upon startup.

Requirements for this setup :

• host : cross-platform development environment installed
• target : minimal bootloader 
• card : kernel, root filesystem, optionnally a second bootloader

Standalone setup

The development is made exclusively on the target. The development tools run in their native environments and the required storage is local to the target. We are not in a Host/Target setup anymore but more a Host/Host setup.

Requirements for this setup :

• target : bootloader, kernel, full root filesystem, native development environment

Read More

Delivered !

I am now the lucky owner of this small piece of hardware :-)

The Raspberry Pi will be our development board during our initiation to linux. It is small, light, cheap and powerful enough to read 720p videos without a hitch.

You can find additional information about this very popular board on :

www.raspberrypi.org

Read More

GPL and LGPL licenses

Most of the components making up a Linux system are distributed under two type of licenses :

•  GPL : mainly used for applications (gcc compiler, gdb debugger)
•  LGPL : mainly used for libraries (C library, GTK widget toolkit, ...)

Other licenses exist (BSD, Mozilla, ...) but are less used.

GPL restrictions (summarized) :

• one can make several copies of the program as long as the licence and copyright remain intact
• a program distributed under this licence comes with no warranty whatsoever unless it is brought by the distributor
• you can charge for the act of copying and for warranty protection
• if you distribute copies of the binary, you must accompany them with the original source code
• if you're modifying the source code of a GPL binary, the resulting program will be subject to the GPL license as well with no additional restriction permitted

If you're planning to link your software against a GPL-licensed library (statically or dynamically), you're falling under the GPL too. It is the main difference with LGPL which allows you to use unmodified parts of a program without license restriction. Thus, you can link against an LGPL library with no fear of being forced to distribute your binary under the same license. However, you are not free to distribute a modified LGPL library under any other license than LGPL.

Read More

Embedded Linux (part 2)

Méthodologie de création d'un système Linux embarqué

La structure du système est calquée sur les autres systèmes Unix libres ou propriétaires à savoir :

• un noyau ou kernel réalisant les fonctions essentielles comme la gestion des tâches et de la mémoire, ainsi que l’interfaçage entre le matériel et les applicatifs grâce entre autres aux pilotes de périphériques ou en anglais device drivers ;

• une bibliothèque principale appelée libc ou glibc (GNU libc) sous Linux et contenant

les fonctions de base utilisées par les applicatifs ;

• les applicatifs eux-mêmes, appelés également commandes, soit livrés en standard avec

le système ou bien développés pour des besoins spécifiques.

À ces éléments standards il faut ajouter un programme de démarrage ou bootstrap comme LILO (LInux LOader). À la différence des autres composants du système, le programme de démarrage ou chargeur est très dépendant du matériel utilisé.

Le schéma de démarrage d’un système Linux est relativement simple et on peut le décomposer comme suit :

1. Chargement du système par LILO ou un programme équivalent, comme GRUB.

2. Chargement du noyau Linux. Le chargement s’accompagne de l’initialisation des périphériques matériels indispensables au démarrage, et donc au chargement des pilotes de périphériques associés. Le noyau Linux tente également de charger sa partition principale ou root partition sur laquelle il ira chercher les éléments nécessaires à la suite du lancement du système.

3. Lorsque le noyau Linux est chargé, il exécute un programme d’initialisation qui, par défaut, correspond à la commande /sbin/init. Cependant, on peut indiquer facilement au noyau de passer la main à un autre programme.

4. Dans le cas de l’utilisation du programme init standard, ce dernier explore le fichier de configuration /etc/inittab qui contient le chemin d’accès à un script de démarrage, comme ceci :

# System initialization (runs when system boots).

si:S:sysinit:/etc/rc.d/rc.d/rc.sysinit

Le script en question poursuit l’initialisation du système.

1.Le noyau LINUX

Le noyau est l’élément principal du système, d'abord parce que ce noyau fut initialement conçu par Linus Torvalds, créateur du système Linux et de composants provenant en majorité du projet GNU de Richard Stallman. Ensuite parce que la structure monolithique du noyau en fait l’interface unique entre le système et le matériel dans la quasi-totalité des cas de figure.

1.1. Structure globale du noyau

Dans le cas de Linux, le noyau est un fichier exécutable, monolithique ou presque, chargé d’assurer les fonctions essentielles du système comme la gestion des tâches, ou scheduling, la gestion de la mémoire et le pilotage des périphériques que ceux-ci soient réellement des périphériques matériels ou bien qu’ils soient des périphériques virtuels.

Dans une distribution Linux classique, le noyau est physiquement représenté par un fichier localisé sur le répertoire /boot :

serge@serge-Aspire-4830TG:/boot$ ls -lrt

total 46484

-rw------- 1 root root 2320733 Oct 9 2012 System.map-3.5.0-17-generic

-rw-r--r-- 1 root root 154429 Oct 9 2012 config-3.5.0-17-generic

-rw-r--r-- 1 root root 853738 Oct 9 2012 abi-3.5.0-17-generic

-rw-r--r-- 1 root root 5171760 Oct 17 19:08 vmlinuz-3.5.0-17-generic

-rw-r--r-- 1 root root 178944 Jan 3 23:47 memtest86+_multiboot.bin

-rw-r--r-- 1 root root 176764 Jan 3 23:47 memtest86+.bin

-rw------- 1 root root 5169520 Mar 25 21:29 vmlinuz-3.5.0-27-generic

-rw------- 1 root root 2320304 Mar 25 21:29 System.map-3.5.0-27-generic

-rw-r--r-- 1 root root 154652 Mar 25 21:29 config-3.5.0-27-generic

-rw-r--r-- 1 root root 860818 Mar 25 21:29 abi-3.5.0-27-generic

-rw-r--r-- 1 root root 15066322 Apr 16 21:16 initrd.img-3.5.0-17-generic

drwxr-xr-x 5 root root 4096 Apr 16 21:29 grub

-rw-r--r-- 1 root root 15142645 Apr 16 21:30 initrd.img-3.5.0-27-generic

Le nom du noyau est libre mais il est généralement suffixé en fonction de la version du noyau, ici 3.5.0 et de l’extra-version choisie par celui qui a généré ce noyau, soit 17 dans le cas présent.

Nous verrons que l’extra-version est définie dans le fichier Makefile de l’arborescence des sources du noyau.

Le noyau Linux utilise également un fichier nommé System.map qui contient des informations sur des adresses internes du noyau. Ces informations sont utiles à la gestion des modules décrits ci-après. Le fichier System.map est également présent sur le répertoire /boot. En toute rigueur, il est lié à la version complète du noyau généré, y compris l’extra-version, car il est généré lors de la compilation du noyau.

1.2. Les modules chargeables du noyau

Dans les cas d’applications classiques de Linux, le noyau utilise le plus souvent des modules qui peuvent être dynamiquement chargés et déchargés en fonction des besoins du système.

Ces modules peuvent être des pilotes de périphériques matériels, comme des cartes d’extension, ou bien liés à un support générique de plus haut niveau comme le support SCSI. L’utilisation des modules permet d’optimiser la mémoire du système à un instant donné car un pilote non utilisé pourra être déchargé, libérant ainsi sa mémoire.

De même, l’utilisation des modules permettra d’ajouter dynamiquement des périphériques sans redémarrer le système.

Dans le cas d’un noyau embarqué, on pourra cependant se poser la question quant à l’utilisation des modules sachant que ceux-ci nécessitent la validation d’options spécifiques lors de la compilation du noyau, ce qui augmente légèrement sa taille. De même, la hiérarchie des modules nécessite la mise en place du répertoire /lib/modules, ce qui augmente le nombre de fichiers, la complexité du système et aussi légèrement l’espace occupé par ce dernier.

Le choix de l’utilisation ou non des modules sera laissé à la charge de l’intégrateur du système en fonction de ses besoins.

serge@serge-Aspire-4830TG:/boot$ ls -l /lib/modules

total 8

drwxr-xr-x 4 root root 4096 Oct 17 17:00 3.5.0-17-generic

drwxr-xr-x 4 root root 4096 Apr 16 21:28 3.5.0-27-generic

À chaque sous-répertoire correspond une version du noyau. Dans le cas présent, les

modules utilisés par le noyau seront localisés dans le répertoire 3.5.0-17.

serge@serge-Aspire-4830TG:/lib/modules$ ls -l 3.5.0-17-generic

total 4640

lrwxrwxrwx 1 root root 39 Nov 14 23:08 build -> /usr/src/linux-headers-3.5.0-17-generic

drwxr-xr-x 2 root root 4096 Oct 17 16:58 initrd

drwxr-xr-x 10 root root 4096 Oct 17 16:59 kernel

-rw-r--r-- 1 root root 739381 Oct 17 17:00 modules.alias

-rw-r--r-- 1 root root 719847 Oct 17 17:00 modules.alias.bin

-rw-r--r-- 1 root root 6027 Oct 9 2012 modules.builtin

-rw-r--r-- 1 root root 7365 Oct 17 17:00 modules.builtin.bin

-rw-r--r-- 1 root root 69 Oct 17 17:00 modules.ccwmap

-rw-r--r-- 1 root root 351471 Oct 17 17:00 modules.dep

-rw-r--r-- 1 root root 518442 Oct 17 17:00 modules.dep.bin

-rw-r--r-- 1 root root 214 Oct 17 17:00 modules.devname

-rw-r--r-- 1 root root 889 Oct 17 17:00 modules.ieee1394map

-rw-r--r-- 1 root root 295 Oct 17 17:00 modules.inputmap

-rw-r--r-- 1 root root 21817 Oct 17 17:00 modules.isapnpmap

-rw-r--r-- 1 root root 2486 Oct 17 17:00 modules.ofmap

-rw-r--r-- 1 root root 144391 Oct 9 2012 modules.order

-rw-r--r-- 1 root root 471479 Oct 17 17:00 modules.pcimap

-rw-r--r-- 1 root root 1765 Oct 17 17:00 modules.seriomap

-rw-r--r-- 1 root root 131 Oct 17 17:00 modules.softdep

-rw-r--r-- 1 root root 285690 Oct 17 17:00 modules.symbols

-rw-r--r-- 1 root root 363056 Oct 17 17:00 modules.symbols.bin

-rw-r--r-- 1 root root 1063926 Oct 17 17:00 modules.usbmap

Les modules sont répartis dans des sous-répertoires selon une classification fonctionnelle.

La liste ci-après permet de visualiser les modules correspondant à des pilotes réseau :

serge@serge-Aspire-4830TG:/lib/modules/3.5.0-17-generic$ ls -l /lib/modules/3.5.0-17-generic/kernel/drivers/net | head

total 244

drwxr-xr-x 2 root root 4096 Oct 17 16:59 appletalk

drwxr-xr-x 2 root root 4096 Oct 17 16:59 arcnet

drwxr-xr-x 2 root root 4096 Oct 17 16:58 bonding

drwxr-xr-x 2 root root 4096 Oct 17 16:59 caif

drwxr-xr-x 7 root root 4096 Oct 17 16:59 can

drwxr-xr-x 2 root root 4096 Oct 17 16:59 dsa

-rw-r--r-- 1 root root 7464 Oct 9 2012 dummy.ko

-rw-r--r-- 1 root root 9280 Oct 9 2012 eql.ko

drwxr-xr-x 46 root root 4096 Oct 17 16:59 ethernet

serge@serge-Aspire-4830TG:/lib/modules/3.5.0-17-generic/kernel/net/wireless$ ls -lrt

total 268

-rw-r--r-- 1 root root 9608 Oct 9 2012 lib80211.ko

-rw-r--r-- 1 root root 6760 Oct 9 2012 lib80211_crypt_wep.ko

-rw-r--r-- 1 root root 12672 Oct 9 2012 lib80211_crypt_tkip.ko

-rw-r--r-- 1 root root 8328 Oct 9 2012 lib80211_crypt_ccmp.ko

-rw-r--r-- 1 root root 225020 Oct 9 2012 cfg80211.ko

Le fichier modules.dep contient les dépendances entre les modules sous la forme d’une

simple liste contenant une définition de dépendance par ligne. Cette liste est générée au

démarrage du système par la commande depmod -a.

On doit également utiliser cette commande chaque fois que l’on ajoute un nouveau

module à l’arborescence des modules. Un extrait de la liste est présenté ci-après :

/lib/modules/2.4.7-10/kernel/fs/vfat/vfat.o:

/lib/modules/2.4.7-10/kernel/fs/fat/fat.o

La ligne ci-après montre que le module vfat.o nécessite la présence du module fat.o.

Bien que les modules soient normalement chargés de manière automatique par le système, nous allons décrire en quelques lignes les principales commandes de manipulation des modules, et ce afin de donner un bon aperçu des opérations possibles sur les modules.

Remarque

Les modules sont manipulés grâce à un paquetage nommé modutils. En cas d’utilisation du noyau 2.6, il est nécessaire d’utiliser une version récente du paquetage (module-init-tools-3.0 ou supérieur) disponible en téléchargement avec les sources du noyau. Ces dernières versions sont compatibles 2.4 et 2.6.

On peut forcer le chargement d’un module en utilisant la commande insmod. Prenons l’exemple d’un module hello.o sans dépendance avec aucun autre module.
On peut charger ce module au moyen de la commande :
root#> insmod hello.o

On peut aussi ajouter ce module à l’arborescence des modules standards en effectuant :
root#> cp hello.o /lib/modules/2.4.7-10/kernel/drivers/char/lib/modules/2.4.7-1/kernel/driver/char
root#> depmod -a

puis charger ce module avec la commande :
root#> insmod hello Using /lib/modules/2.4.7-10/kernel/drivers/char/hello.o

Notez qu’il est nécessaire d’être super-utilisateur pour charger un module.
Dans le cas où le module est installé dans l’arborescence, on ne spécifie pas le suffixe. La trace du chargement effectif du module est visible dans le fichier des messages du noyau(dmesg). On peut également vérifier sa présence en utilisant la commande lsmod:

root#> dmesg | tail -1
Hello world!
root#> lsmod
Module   Size Used by
hello     292   0 (unused)

Lors du chargement du module, il est possible de spécifier des paramètres par la ligne de commande :
root#> insmod bttv card=39

Les paramètres peuvent être spécifiés dans le fichier /etc/modules.conf afin d’être utilisés automatiquement lors du chargement du module. Dans le cas du noyau 2-6, on utilise le fichier /etc/conf.modules :
alias eth0 3c59x
options i2c-algo-bit bit_test=1
options bttv card=39

La commande alias permet de faire une association automatique entre un nom de module générique et le nom de module effectif. Dans le cas présent, le module 3c59x sera chargé lors de l’initialisation de l’interface réseau Ethernet qui nécessite le module générique eth0. Après chaque modification du fichier, on doit utiliser la commande /sbin/depmod -a.
Pour décharger le module, on utilise la commande rmmod :
root#> rmmod hello
root#> dmesg | tail -1
Goodbye cruel world!

Remarque

Dans le cas de modules dépendant d’autres modules, on ne peut cependant pas utiliser la commande
insmod.

Le système de fichier /proc

Pour communiquer avec l’espace utilisateur, le noyau Linux utilise un concept emprunté à Unix System V : le système de fichier /proc. À la différence des systèmes de fichiers classiques qui sont associés à des périphériques réels, le système de fichier /proc est virtuel. Sa structure de système de fichier en fait une représentation facile pour manipuler des paramètres du noyau Linux. On peut en effet utiliser les commandes standards de manipulation des fichiers classiques, ainsi que la redirection des entrées/sorties très utilisée sous Linux.

On peut aussi:

lister les modules charger dans le kernel:
root#> cat /proc/modules

visualiser la mémoire disponible:
root#> cat /proc/meminfo

visualiser les systèmes de fichiers supportés par le noyau:
root#> cat /proc/filesystems

visualiser la version du noyau:
root#> cat /proc/version

visualiser le type de processeur utilisé:
root#> cat /proc/cpuinfo

De même, les valeurs numériques présentes dans /proc représentent les zones d’information des processus courant, chaque valeur correspondant au PID du processus en question. Ces sous-répertoires contiennent les informations propres au processus en question :

serge@serge-Aspire-4830TG:/proc$ ls -l /proc/3962
ls: cannot read symbolic link /proc/3962/cwd: Permission denied
ls: cannot read symbolic link /proc/3962/root: Permission denied
ls: cannot read symbolic link /proc/3962/exe: Permission denied
total 0
dr-xr-xr-x 2 root root 0 Apr 20 13:36 attr
-rw-r--r-- 1 root root 0 Apr 20 13:36 autogroup
-r-------- 1 root root 0 Apr 20 13:36 auxv
-r--r--r-- 1 root root 0 Apr 20 13:36 cgroup
--w------- 1 root root 0 Apr 20 13:36 clear_refs
-r--r--r-- 1 root root 0 Apr 20 13:36 cmdline
-rw-r--r-- 1 root root 0 Apr 20 13:36 comm
-rw-r--r-- 1 root root 0 Apr 20 13:36 coredump_filter
-r--r--r-- 1 root root 0 Apr 20 13:36 cpuset
lrwxrwxrwx 1 root root 0 Apr 20 13:36 cwd
-r-------- 1 root root 0 Apr 20 13:36 environ
lrwxrwxrwx 1 root root 0 Apr 20 13:36 exe
dr-x------ 2 root root 0 Apr 20 13:36 fd
dr-x------ 2 root root 0 Apr 20 13:36 fdinfo
-r-------- 1 root root 0 Apr 20 13:36 io
-r--r--r-- 1 root root 0 Apr 20 13:36 latency
-r--r--r-- 1 root root 0 Apr 20 13:36 limits
-rw-r--r-- 1 root root 0 Apr 20 13:36 loginuid
dr-x------ 2 root root 0 Apr 20 13:36 map_files
-r--r--r-- 1 root root 0 Apr 20 13:36 maps
-rw------- 1 root root 0 Apr 20 13:36 mem
-r--r--r-- 1 root root 0 Apr 20 13:36 mountinfo
-r--r--r-- 1 root root 0 Apr 20 13:36 mounts
-r-------- 1 root root 0 Apr 20 13:36 mountstats
dr-xr-xr-x 5 root root 0 Apr 20 13:36 net
dr-x--x--x 2 root root 0 Apr 20 13:36 ns
-rw-r--r-- 1 root root 0 Apr 20 13:36 oom_adj
-r--r--r-- 1 root root 0 Apr 20 13:36 oom_score
-rw-r--r-- 1 root root 0 Apr 20 13:36 oom_score_adj
-r--r--r-- 1 root root 0 Apr 20 13:36 pagemap
-r--r--r-- 1 root root 0 Apr 20 13:36 personality
lrwxrwxrwx 1 root root 0 Apr 20 13:36 root
-rw-r--r-- 1 root root 0 Apr 20 13:36 sched
-r--r--r-- 1 root root 0 Apr 20 13:36 schedstat
-r--r--r-- 1 root root 0 Apr 20 13:36 sessionid
-r--r--r-- 1 root root 0 Apr 20 13:36 smaps
-r--r--r-- 1 root root 0 Apr 20 13:36 stack
-r--r--r-- 1 root root 0 Apr 20 13:36 stat
-r--r--r-- 1 root root 0 Apr 20 13:36 statm
-r--r--r-- 1 root root 0 Apr 20 13:36 status
-r--r--r-- 1 root root 0 Apr 20 13:36 syscall
dr-xr-xr-x 3 root root 0 Apr 20 13:36 task
-r--r--r-- 1 root root 0 Apr 20 13:36 wchan

Par exemple, le fichier status contient des informations sur l’état du processus en question.
Le système de fichier /proc est également utilisable en écriture, ce qui permet de
modifier dynamiquement le comportement du noyau Linux sans aucune compilation.
Un exemple classique est la validation d’option comme par le transfert de paquets IP (IP forwarding). On peut connaître la valeur de l’option d’IP forwarding en faisant :
root#> cat /proc/sys/net/ipv4/ip_forward
1
Le système retourne la valeur 1, ce qui signifie que l’IP forwarding est validé. On peut l’inhiber en faisant simplement :
root#> echo 0 > /proc/sys/net/ipv4/ip_forward

Une description complète du pseudo-système de fichiers /proc est disponible dans le répertoire de documentation des sources du noyau Linux, soit :
root#> more usr/src/linux-2.4/Documentation/filesystems/proc.txt
pour les noyaux 2.4 et 2.6.

###########################################################

Bibliographie

• Linux embarqué (2e edition - Eyrolles)
• wikipédia
  

Read More

Cross-compiling for ARM

Environment settings

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-

ARCH defines the architecture we're building for.
CROSS_COMPILE defines the prefix of the gnu tools to use. Full path must be set if the ARM cross-compiling tools' path is not set in environment.

Multi-threaded build

If you have a multi-core CPU, you may want to enjoy a quicker build. To do so, define the number of threads used to build your linux

alias make='make -j2'

Usually, the specified number is obtained by multiplying the number of your cpu's cores by 2.

Configuration

The configuration of the kernel is saved in a file named .config

The most common way of configuring your kernel for an embedded platform is to use the default configuration for your board / CPU. These files, if they exist, are stored in /arch/<arch>/configs/. To check their availability, run :

make help

An exemple of default configuration usage :

make myboard_defconfig

This operation overwrites the .config file.

If you don't have a default configuration file, you will either find a configuration file that fits your needs on the web or customize the kernel on your own (experts only). To do so, run :

make menuconfig

Build

The final step :

make

Go grab a coffee, it may take a while...

Once built, the kernel is image is in /arch/<arch>/boot/. Several output format exists (bzImage, uImage, zImage,...) so be careful when copying the kernel to your target storage. The wrong image format will simply not boot...


Clean

Clean-up generated files

make clean

Clean-up generated files + .config file deletion

make mrproper

Read More

LINUX commands related to kernel

dmesg

The dmesg command can be used to examine or control the kernel ring buffer. 
Ring buffer
A ring buffer is a cyclic data structure similar to a normal buffer having a fixed size but it is managed in such a way that the newest entries are recorded, and if required, only the oldest entries are removed to keep the size of the buffer constant. Just think about a ring as if it reaches the end point it will start from the beginning.
The kernel Ring buffer
Also called the Kernel Log Buffer, it is a kind of Ring Buffer which contains messages related to the kernel and its different modules. For example it prints messages when any new kernel module is loaded or when a new file-system is registered in the kernel etc. The Linux kernel outputs these messages which are of great help in debugging and troubleshooting although it contains a great amount of noise. These messages are further classified into log levels depending upon the severity of the message.
The Log Level of Kernel Messages.
LOG_EMERG system is unusable
LOG_ALERT action must be taken immediately
LOG_CRIT critical conditions
LOG_ERR error conditions
LOG_WARNING warning conditions
LOG_NOTICE normal, but significant, condition
LOG_INFO informational message
LOG_DEBUG debug-level message
 ---------------------------------------------------------------------------------------------------------------------------------

uname -r

print the kernel release.

 ---------------------------------------------------------------------------------------------------------------------------------

rpm -q kernel (RedHat/CentOS)

dpkg --list | grep linux-image (Ubuntu, debian)

list all installed kernel and its version.

 ---------------------------------------------------------------------------------------------------------------------------------

lsmod

show the status of modules in the Linux Kernel.

---------------------------------------------------------------------------------------------------------------------------------

ldd

print shared library dependencies of a binary

---------------------------------------------------------------------------------------------------------------------------------

Read More

Embedded LINUX (part 1)

Linux embarqué

===========

Préambule

La lecture de cet article nécessite des notions de programmation en langage C et en langage de script Unix (Bourne Shell), ainsi que quelques connaissances générales en informatique industrielle.
Les sources complets des exemples présentés sont disponibles en téléchargement sur le site d’accompagnement du livre à l’adresse:
http://www.editions-eyrolles.com.

Au niveau des exemples de réalisation, j'ai porté un
regard particulier sur la Freebox développée par Free SA. Le célèbre terminal de connexion
multimédia du premier opérateur Internet français est à ce jour un exemple d’innovation,
d’autant que c’est un pur produit de l’Hexagone.


Due to its low cost and ease of customization, Linux has been shipped in many consumer devices. Devices covering PDAs (like the Sharp Zaurus family), TomTom GPS navigation devices, residential gateways like the Linksys WRT54G series or smartphones: the Motorola exz series, the Openmoko handsets, the Nokia N900 and Nokia N9 cell phones were all using the Linux kernel. Nowadays the operating system that dominates the cell phone market is the Android operating system which is based on a modified Linux kernel along with a custom user space. The first device shipping with the Android operating system was the HTC Dream, which was released on 22 October 2008.

On machine control systems, industrial automation, and medical instruments Linux has also been used extensively. The website LinuxForDevices has many examples of such devices shipping with an embedded Linux as the operating system.

Introduction

Linux est un système d’exploitation multitâche de la famille Unix.
Linux est conforme à la norme Posix, ce qui signifie que les programmes développés sous Linux peuvent être recompilés facilement sur d’autres systèmes d’exploitation compatibles Posix.
Le système d’exploitation Linux est libre, le code source des différents composants du système est disponible gratuitement sur le réseau Internet(sous licence GPL).

Dans les cas les plus classiques d’utilisation de Linux, il est cependant possible de n’utiliser que des composants libres comme le serveur HTTP Apache, les langages de programmation Perl, PHP ou Python, ou bien les systèmes de base de données MySQL et PostgreSQL pour ne citer que les plus connus.
Linux est aujourd'hui bien implanté dans le monde des serveurs.

Systèmes embarqués - généralités

Un logiciel embarqué (embedded software en anglais) est un programme utilisé dans un équipement industriel ou un bien de consommation.
L’équipement est valorisé uniquement par son aspect fonctionnel et un bon
logiciel intégré le sera à un tel point qu’on finira par l’oublier.
Les concepteurs de logiciels embarqués sont rarement des informaticiens purs, plus souvent des êtres hybrides entachés de neurones d’électroniciens.
Dans la majorité des cas, un tel logiciel n’utilise pas les interfaces classiques clavier/souris propres à la micro-informatique.
S’ils existent, les périphériques d’affichage sont souvent limités à des panneaux de petite taille de type LCD (Liquid Crystal Display), et les périphériques d’entrée à quelques boutons poussoirs ou autres composants inhabituels dans l’informatique traditionnelle.
Attention un logiciel embarqué doit être optimisé:
"Software becomes slower faster than hardware becomes faster".

Alors que la micro-informatique a débuté avec 1 kilo-octet de mémoire vive et un système sur 8 Ko de ROM, il n’est pas rare aujourd’hui de voir des adolescents
pester contre le PIII de l’année précédente qui n’affiche pas assez vite les formes plantureuses de Lara Croft.
L’exemple le plus flagrant de cette course à la consommation est bien entendu les différentes moutures du système Microsoft Windows et les applications associées pour lesquelles chaque version est systématiquement accompagnée d’une augmentation de taille, compensée bien sûr par l’achat de quelques giga-octets de disque dur ou d’une barrette de mémoire supplémentaire.

Nous avons pour l’instant parlé de logiciel embarqué alors qu’il est fréquent d’entendre la terminologie de système embarqué. Cette terminologie désigne le plus souvent un système d’exploitation, version complexe et multi-usage du concept de logiciel.

Avantages

Les avantages de l’utilisation d’un système d’exploitation sont les suivants :

• Comme dans le cas du développement de logiciel classique, il affranchit le développeur de l’applicatif embarqué d’un travail d’adaptation très proche du matériel, ce qui permet de diminuer le temps de développement et donc les coûts. L’écriture du support de standards du marché comme les bus PCI ou USB est extrêmement lourde en cas de non-utilisation d’un système d’exploitation.
• Si le système d’exploitation utilisé est suffisamment répandu, il permet aux applications industrielles et embarquées de bénéficier des mêmes avancées technologiques que les applications classiques. C’est ainsi qu’il est aujourd’hui possible d’utiliser dans des systèmes réduits des protocoles de communication hérités de l’informatique classique et du multimédia.
L’utilisation d’un système d’exploitation qui inclut un support natif et largement
débogué de ces protocoles est alors un bien meilleur choix car le support d’un protocole se réduira le plus souvent à l’ajout d’un module ou d’un programme externe déjà testé, comparé aux nombreuses heures de mise au point nécessaires à la mise en place d’une version « maison ».
Remarque:
HTTP est le protocole utilisé pour le transfert des données multimédias entre un serveur web et un poste client équipé d’un navigateur ou browser. Plus ancien, le protocole FTP est lui réservé au simple transfert de fichier.
L’utilisation dans l’embarqué de ces protocoles standards en remplacement de protocoles propriétaires facilite l’interopérabilité des systèmes.

• Les systèmes d’exploitation fournissent en général un environnement de développement facilitant la mise au point des programmes dans un contexte beaucoup plus accueillant et performant que le système cible – celui sur lequel est censé tourner le programme définitif.
Un exemple industriel célèbre est celui de la PlayStation2 de SONY. Les développeurs de jeux ne pouvant disposer de la console définitive immédiatement, ils utilisèrent un environnement de développement basé sur Red Hat Linux permettant de simuler le fonctionnement de la console sur des stations de travail.

Inconvénients

Le principal inconvénient de l’utilisation d’un véritable système d’exploitation proche d’un système classique est la taille mémoire nécessaire. Il est bien évident que, si l’espace disponible est réduit à quelques centaines d’octets pour accomplir une tâche rudimentaire, un vrai système d’exploitation ne s’imposera pas.

Champs d'application

D’un point de vue technique, le champ d’application peut être grossièrement divisé en deux grandes familles :
• le contrôle de processus sans contrainte ou à faible contrainte temps réel (on pourra envisager l’utilisation d’un système d’exploitation dérivé d’un système classique comme Linux. L’adaptation se situera principalement au niveau du développement de pilotes de périphériques et de l’optimisation du système en taille ou en performances.

• le contrôle de processus avec contrainte temps réel. Les contraintes matérielles nécessiteront l’utilisation de composants spécialisés, soit un logiciel spécifique, soit un système d’exploitation dit temps réel (Real Time Operating System ou RTOS).

Typologie des systèmes embarqués

Un système d’exploitation classique comme Unix, Linux ou Windows utilise la notion de temps partagé, par opposition au temps réel. Dans ce type de système, le but de l’ordonnanceur est de donner à l’utilisateur une impression de confort d’utilisation tout en assurant que toutes les tâches demandées sont finalement exécutées. Ce type d’approche entraîne une grande complexité dans la structure même de l’ordonnanceur qui doit tenir compte de notions comme la régulation de la charge du système ou la date depuis laquelle une tâche donnée est en cours d’exécution.

La notion de priorité entre les tâches est peu prise en compte, car l’ordonnanceur a pour but premier le partage équitable du temps entre les différentes tâches du système. Notez que sur les différentes versions d’Unix dont Linux, la commande nice permet de modifier la priorité de la tâche lors du lancement.
Ensuite, les différentes tâches doivent accéder à des ressources dites partagées, ce qui entraîne des incertitudes temporelles. Si une des tâches effectue une écriture sur le disque dur, ce dernier n’est plus disponible pour les autres tâches à un instant donné et le délai de disponibilité du périphérique n’est pas prévisible.

Rappel:
La gestion des ressources partagées entre différentes tâches se fera grâce à des composants appelés sémaphores.

En outre, la gestion des entrées/sorties peut générer des temps morts, car une tâche peut être bloquée en attente d’accès à un élément d’entrée/sortie.

La gestion des interruptions reçues par une tâche n’est pas optimisée. Le temps de latence – soit le temps écoulé entre la réception de l’interruption et son traitement – n’est pas garanti par le système. Par comparaison, le temps de latence dans le cas d’un système temps réel est souvent inférieur à 100us.

Enfin, l’utilisation du mécanisme de mémoire virtuelle peut entraîner des fluctuations dans les temps d’exécution des tâches.
Rappel:
La mémoire virtuelle permet au système de disposer d’une quantité de mémoire, supérieure à la quantité de mémoire vive réellement disponible. Le système pourra pour cela utiliser des espaces dédiés sur la mémoire de masse afin de simuler une mémoire virtuelle. L’inconvénient en sera bien sûr une forte dégradation des performances.
Toutes ces limitations font que le temps de réponse d’un système classique n’est pas garanti.

Un système est dit temps réel lorsqu’il est soumis à des contraintes de temps et qu’il y répond dans un intervalle acceptable.
On pourra diviser les systèmes temps réel en deux catégories :
• Les systèmes dits à contraintes souples ou molles (soft real time). Ces systèmes acceptent des variations dans le traitement des données de l’ordre de la demi-seconde (ou 500 ms) ou la seconde. On peut citer l’exemple des systèmes multimédias : si quelques images ne sont pas affichées, cela ne met pas en péril le fonctionnement correct de l’ensemble du système. Ces systèmes se rapprochent fortement des systèmes d’exploitation classiques à temps partagé.
• Les systèmes dits à contraintes dures (hard real time) pour lesquels une gestion stricte du temps est nécessaire pour conserver l’intégrité du service rendu. On citera en guise d’exemples les contrôles de processus industriels sensibles comme la régulation des centrales nucléaires ou les systèmes embarqués utilisés dans l’aéronautique.

Commutation de contexte

Le noyau (kernel) est le composant principal d’un système d’exploitation multitâche moderne. Dans un tel système, chaque tâche (ou processus) est décomposée en threads (processus léger ou tâche légère) ; ce sont des éléments de programmes, chacun étant capable d’exécuter une portion de code dans un même espace d’adressage. Chaque thread est caractérisé par un contexte local contenant la priorité du thread, ses variables locales ou l’état de ses registres. Le passage d’un thread à un autre est appelé changement de contexte (context switch). Ce changement de contexte sera plus rapide sur un thread que sur un processus car les threads d’un processus évoluent dans le même espace d’adressage, ce qui permet le partage des données entre les threads d’un même processus.
Dans certains cas, un processus ne sera composé que d’un seul thread et le changement de contexte s’effectuera sur le processus lui-même.

Remarque:
Dans le cas du système Linux, le même appel système clone() est utilisé pour créer un processus ou un thread. La primitive fork() de création de processus correspond en fait à clone(0, SIGCLD|COPYVM).

Dans le cas d’un système temps réel, le noyau est dit préemptif, c’est-à-dire qu’un thread peut être interrompu par l’ordonnanceur en fonction du niveau de sa priorité, et ce afin de permettre l’exécution d’un thread de plus haut niveau de priorité. On peut ainsi affecter les plus hauts niveaux de priorité à des tâches dites critiques par rapport à l’environnement réel contrôlé par le système. La vérification des contextes à commuter est réalisée de manière régulière par l’ordonnanceur en fonction de l’horloge logicielle interne du système, ou tick système.
Dans le cas d’un noyau non préemptif, un thread sera interrompu uniquement dans le cas d’un appel au noyau ou d’une interruption externe. La notion de priorité étant très peu utilisée (excepté avec la commande nice dans le cas de Linux), c’est le noyau qui décide ou non de commuter le thread actif en fonction d’un algorithme complexe.

Extensions Posix

Posix est l’acronyme de Portable Operating System Interface ou interface portable pour les systèmes d’exploitation.
Un programme qui est destiné à un système d’exploitation qui respecte Posix doit pouvoir être adapté à moindre frais sous n’importe quel autre système Posix.
En théorie, le portage d’une application d’un système Posix vers un autre doit se résumer à une compilation des sources du programme.

Empreinte mémoire

Par définition, l’empreinte est la taille mémoire occupée par le système. Même si ce n’est pas une obligation, les systèmes embarqués ont en général une faible empreinte, et ce afin d’optimiser le système tant au niveau des coûts que de la sécurité de fonctionnement. La réduction de l’empreinte mémoire est la tâche principale d’un développeur de système embarqué car elle a un impact économique énorme sur l’industrialisation finale du produit.
Il faut faire la différence entre l’empreinte mémoire du système d’exploitation et celle des données.
Dans certains cas, on pourra par sécurité avoir un système d’exploitation réduit à quelques (Mo) sur une mémoire morte et dans d'autres cas un disque dur de plusieurs dizaines ou centaines de (Go) destiné à recevoir les données.

Langages utilisés

Les langages C et C++ restent aujourd’hui le choix favori des développeurs en partie à cause des liens privilégiés du langage C avec les standards Posix et les systèmes de type Unix. Historiquement, le langage C est également un langage permettant une programmation relativement proche du matériel, donc bien adaptée au logiciel embarqué.
La contrainte principale étant le plus souvent l’empreinte mémoire, la programmation en langage C nécessite d’utiliser le compilateur de la manière la plus efficace possible, et ce en utilisant au maximum les options d’optimisation adaptées au matériel.
Dans le cas du compilateur GNU gcc (GNU C Compiler), on notera en particulier les options suivantes
-O3, -O2, -O3, selon le niveau d’optimisation, et -Os qui permet d’optimiser le code afin de minimiser sa taille.
Des options spécifiques au processeur utilisé comme -m386 ou -mpentium permettront également d’adapter le code au matériel utilisé.
Dans le cas de l’utilisation de systèmes de type Unix (UNIX-like), on pourra également employer d’autres langages de programmation ou langages de scripts en particulier le shell-script, langage de script d’Unix (ou Bourne shell), qui associé à d’autres commandes pourra se révéler très utile dans l’écriture de procédures système. Le résultat sera le plus souvent plus facile à maintenir qu’un programme écrit en langage C et surtout ne nécessitera pas de recompilation avant exécution sur un autre système de type Unix.
D’autres produits encore plus réduits, comme BusyBox permettent d’intégrer des versions simplifiées d’un bon nombre de commandes Unix dans seulement 150 kilo-octets.
D’autres langages de scripts célèbres dans le monde Unix comme Perl, Tcl/Tk ou Python sont eux assez peu utilisés dans les environnements embarqués de par l’espace mémoire nécessaire à leur installation et à leur fonctionnement.

Les langages les plus répandus dans le monde de l’embarqué sont le C, le C++ et l’assembleur.
L’empreinte mémoire d’un système embarqué peut varier de 64 Mo à 0,1 Mo. On parle alors de système profondément enfoui.

Tour d’horizon des systèmes existants

Rappel:
Un environnement de compilation croisé permet de développer pour le système cible sur une autre machine
dans un environnement plus confortable. On peut citer par exemple la disponibilité sous Linux d’un environnement de développement pour PalmOS, basé sur le compilateur GNU gcc.

• VxWorks et pSOS 

VxWorks est aujourd’hui le noyau temps réel le plus utilisé dans l’industrie. VxWorks inclut en natif un support TCP/IP et une interfacede programmation intégrant les sockets. Le gros inconvénient de ces deux systèmes est le coût important des licences. Il est également nécessaire d’utiliser un environnement de compilation croisé.

• QNX

QNX est un noyau temps réel de type Unix très intéressant. Il est parfaitement conforme à Posix, permet de développer directement sur la plate-forme cible et intègre l’environnement graphique Photon.

QNX peut être utilisé gratuitement pour des applications non commerciales. Il peut occuper une très faible empreinte mémoire et, de ce fait, peut être utilisé dans des environnements très réduits comme les téléphones portables GSM Timeport de chez Motorola.

• Windows CE, μC/OS et μC/OS II, etc...

Linux comme système embarqué

Les trois points suivants de la définition du logiciel Open Source sont fondamentaux dans le cas du logiciel embarqué :
• redistribution sans royalties ;
• disponibilité du code source ;
• possibilité de réaliser un développement dérivé de ce code source.

La disponibilité du code source est encore plus fondamentale car elle est la base de la conception d’un logiciel de qualité et surtout maintenable dans le temps.
La documentation des logiciels Open Source largement répandus comme Linux est souvent de très bonne qualité car elle a pu bénéficier d’un gros travail collaboratif.

Fiabilité
Le fameux kernel panic (erreur fatale du noyau) tant redouté par les développeurs est un animal rare, presque autant que le Yéti ou le monstre du LochNess. Une erreur de ce type s’explique toujours par un problème matériel ou une erreur de programmation dans un pilote de périphérique. Ces derniers travaillant dans un espace privilégié appelé « espace noyau » (kernel space ou kernel level), ils sont les seuls à pouvoir provoquer ce type d’erreur.
Les autres applications travaillent dans l’espace dit utilisateur (user space ou user level) et n’ont pas les droits nécessaires à la génération de ce type d’erreur.
La fiabilité de Linux est démontrable au moyen de la commande uptime qui permet d’afficher le temps d’activité du système depuis le dernier redémarrage. La couche TCP/IP de Linux, au cœur de nombreuses applications embarquées communicantes, est également d’une grande fiabilité.
Faible cout:
Linux est non seulement exempt de royalties mais les outils de développement sont également disponibles sous GPL. Le seul effort financier nécessaire à l’adoption de Linux se situe sur la formation – souvent indispensable – et le support technique.
Performance:
De nombreux tests comparatifs (benchmarks) entre Linux et d’autres systèmes concurrents comme Windows NT on démontré la supériorité de Linux.
Portabilité et adaptabilité:
Linux est aujourd’hui porté sur un très grand nombre de processeurs et d’architectures matérielles, y compris des processeurs de faible puissance, comme le démontre le projet μClinux. Même si le processeur ou l’architecture que vous désirez utiliser ne figurent pas dans la liste des portages actuels, l’énorme base de connaissance disponible facilitera le travail et vous pourrez souvent vous inspirer de travaux déjà réalisés.
La structure modulaire de Linux héritée de l’architecture Unix est également un de ses gros avantages. La structure du système est stricte et clairement définie, et il sera aisé de le configurer de manière à trouver une correspondance exacte avec les besoins requis.
Ouverture:
Linux cohabite facilement avec d'autres OS installés sur la même machine comme Windows, alors que le contraire n'est pas forcément vrai.

Choix matériels pour un système Linux embarqué

 

Le concept du MMU

Linux a été initialement développé sur la base du mécanisme de mémoire protégée du processeur Intel 80386. Ce mécanisme, qui repose sur un composant matériel appelé MMU (Memory Management Unit), permet à un processus de ne jamais écraser l’espace mémoire d’un autre processus. La MMU autorise la conversion entre les adresses physiques – adresses effectivement utilisées dans la machine – et les adresses logiques – adresses vues par le
processus et allouées par le système d’exploitation.
Si un processus tente de sortir par erreur de l’espace mémoire qui lui est accordé, la MMU détecte l’erreur et stoppe le programme en générant une erreur de « violation de segmentation » (segmentation violation ou SIGSEGV). De ce fait, un programme tournant sous Linux dans l’espace dit « utilisateur » – par opposition à l’espace « noyau » – ne peut jamais « planter » le système.
Les versions courantes du noyau Linux sont prévues pour fonctionner sur des processeurs avec MMU, ce qui concerne la majorité des processeurs utilisés dans la micro-informatique classique et aussi dans un bon nombre d’applications embarquées. En revanche, ces processeurs sont en général plus gourmands en ressources matérielles, et certaines applications dites « profondément enfouies » (deeply embedded) ne pourront utiliser que des processeurs dépourvus de MMU.
Il existe bien entendu des systèmes d’exploitation dédiés à ces micro-contrôleurs – μC/OS en est un très bon exemple – mais ceux-ci sont en général bien plus limités que Linux au niveau des protocoles standards et de l’interopérabilité avec le monde extérieur.

μClinux: Linux sans MMU

Un portage du noyau Linux est cependant disponible pour les processeurs dépourvus de MMU : μClinux – pour Micro-C Linux (Linux pour micro-contrôleurs) mais à prononcer You see Linux (http://www.uclinux.org). Le portage est initialement basé sur la version 2.0.38 du noyau Linux mais des versions basées sur les noyaux 2.4 et 2.6 sont également disponibles.
L’API du système est identique au vrai noyau Linux bien que μClinux utilise une libC – bibliothèque de base de programmation – différente de la glibc de la version standard de Linux. La motivation est toujours la même : le gain d’espace, lorsqu’on sait que les versions récentes de la glibc ont une taille largement supérieure au méga-octet. La principale limitation de μClinux par rapport à Linux est l’absence de protection de mémoire entre les processus mais également avec le noyau. De ce fait, une application erronée pourra facilement « planter » le système.

Les system on Chip

A system on a chip or system on chip (SoC or SOC) is an integrated circuit (IC) that integrates all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radiofrequency functions—all on a single chip substrate.
A typical application is in the area of embedded systems.

The contrast with a microcontroller is one of degree. Microcontrollers typically have under 100 kB of RAM (often just a few kilobytes) and often really are single-chip-systems, whereas the term SoC is typically used with more powerful processors, capable of running software such as the desktop versions of Windows and Linux, which need external memory chips (flash, RAM) to be useful, and which are used with various external peripherals. In short, for larger systems, the term system on a chip is hyperbole, indicating technical direction more than reality: increasing chip integration to reduce manufacturing costs and to enable smaller systems. Many interesting systems are too complex to fit on just one chip built with a process optimized for just one of the system's tasks.

For instance, the Samsung Galaxy S II has a 1.2 GHz dual core ARM Cortex-A9 processor(équivalent microcontrolleur) that uses Samsung's own 'Exynos 4210' System on a chip (SoC).

###########################################################

Bibliographie

• Linux embarqué (2e edition - Eyrolles)
• wikipédia
  

Read More