Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Linux

fail2ban : punir les récidivistes

Fabien Nicoleau

Fail2ban permet de bannir des adresses IP tentant de s'attaquer à votre système. Elles sont repérées grâce aux fichiers de log des différents services. Fail2ban les consulte et agit en fonction des expressions régulières qui lui sont données, et d'une tolérance d'erreurs donnée.

Les "bans" ont une durée, mais parfois on se rend compte qu'aussitôt son ban terminé, une adresse tente de nouveau de s'attaquer au système. Une solution simple peut être de mettre une rêgle permanante avec iptables, ce qui règlera définitivement le problème. Cependant cette solution ne me convient pas totalement car je n'aime pas le fait d'ajouter des règles à iptables qui ne seront peut être pas toujours utiles (l'attaquant peut s'arrêter, ou son adresse peut changer). De plus, j'aime assez l'idée qu'un serveur puisse être un minimum autonome. Si je ne consulte pas les logs de mon serveur pendant 1 mois et que je ne me rend pas compte qu'une adresse m'attaque à longueur de journée, mon serveur risque d'être en danger.

Pour régler ce problème, il suffit de créer un jail dans fail2ban qui scrutera son propre log. Ainsi il sera possible de bannir pour une très longue durée une IP qui déjà été bannie plusieurs fois. Cette technique est expliquée dans un article en anglais, je propose ici une explication en  français.

La première chose à faire est de créer un filtre, qu'on placera dans /etc/fail2ban/filter.d/fail2ban-recidivist.conf . En voici le contenu :

[Definition]
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban-recidivist\] Ban <HOST>

La ligne du failregex indique la regex qui permettra de repérer les lignes de ban dans le fichier de log de fail2ban. La dernière ligne permet d'ignorer les bans ajoutés par notre nouvelle règle. Cela évitera de les comptabiliser et donc de fausser le nombre de bans à prendre en compte pour une IP. Notez ici que nous ignorons les bans pour le jail fail2ban-recidivist. Si vous changez le nom du jail, pensez aussi à modifier le filtre pour que l'ignoreregex soit correcte.

Il faut ensuite ajouter un jail dans le fichier /etc/fail2ban/jail.conf, dont voici la définition :

[fail2ban-recidivist]
enabled  = true
filter   = fail2ban-recidivist
action   = iptables-allports[name=recidivist]
logpath  = /var/log/messages
maxretry = 5
# 1 semaine
findtime = 604800
# 1 semaine
bantime  = 604800

Comme pour les autres jails, on indique ici le nom du filtre utilisé (et dont nous avons donné la définition précédemment), l'action à effectuer (je choisis ici de bannir sur tous les ports l'attaquant, et de passer le nom "recidivist" à iptables pour la règle. Il serait aussi possible, voir même judicieux, d'envoyer un e-mail pour vous prévenir de ce ban particulier grâce à l'action sendmail-whois), le fichier de log à scruter, qui est pour ce jail celui de fail2ban (qui utilise SYSLOG dans mon cas), le nombre de tentatives infructueuses, la plage de temps sur laquelle on fait le décompte, et enfin le temps de banissement.

Pour ce cas précis, je bannis pendant une semaine une personne qui a déja été bannie 5 fois durant la dernière semaine par d'autres règles. Sachant que chaque règle a elle aussi un nombre de tentatives d'essais (3 par défaut), cela donne tout de même une bonne tolérance.

Il faut noter que si vous utilisez une action qui ne prend pas en compte de nom (ici recidivist), et qui enregistre simplement l'adresse IP, ce système ne fonctionnera pas. En effet, si une personne est bannie parce qu'elle a essayé de s'authentifier sans succès plusieurs fois, pour une durée d'un jour, et qu'ensuite ce jail bannit l'IP pour une semaine, au bout d'une journée, le premier ban sera retiré, l'IP donc retirée, et le ban d'une semaine annulé. Ce problème n'apparait pas avec iptables car il prend en compte le nom de l'action, et ne confond donc pas les bans. En revanche, cela semble pouvoir se produire avec ipfw, hostsdeny et shorewall.

Voilà grâce à cette règle un serveur un peu plus autonome, qui sévira de façon plus dure s'il est attaqué trop souvent par la même personne.


Fabien (eponyme)

fail2ban : punir les récidivistes

Fabien Nicoleau

Fail2ban permet de bannir des adresses IP tentant de s'attaquer à votre système. Elles sont repérées grâce aux fichiers de log des différents services. Fail2ban les consulte et agit en fonction des expressions régulières qui lui sont données, et d'une tolérance d'erreurs donnée.

Les "bans" ont une durée, mais parfois on se rend compte qu'aussitôt son ban terminé, une adresse tente de nouveau de s'attaquer au système. Une solution simple peut être de mettre une rêgle permanante avec iptables, ce qui règlera définitivement le problème. Cependant cette solution ne me convient pas totalement car je n'aime pas le fait d'ajouter des règles à iptables qui ne seront peut être pas toujours utiles (l'attaquant peut s'arrêter, ou son adresse peut changer). De plus, j'aime assez l'idée qu'un serveur puisse être un minimum autonome. Si je ne consulte pas les logs de mon serveur pendant 1 mois et que je ne me rend pas compte qu'une adresse m'attaque à longueur de journée, mon serveur risque d'être en danger.

Pour régler ce problème, il suffit de créer un jail dans fail2ban qui scrutera son propre log. Ainsi il sera possible de bannir pour une très longue durée une IP qui déjà été bannie plusieurs fois. Cette technique est expliquée dans un article en anglais, je propose ici une explication en  français.

La première chose à faire est de créer un filtre, qu'on placera dans /etc/fail2ban/filter.d/fail2ban-recidivist.conf . En voici le contenu :

[Definition]
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban-recidivist\] Ban <HOST>

La ligne du failregex indique la regex qui permettra de repérer les lignes de ban dans le fichier de log de fail2ban. La dernière ligne permet d'ignorer les bans ajoutés par notre nouvelle règle. Cela évitera de les comptabiliser et donc de fausser le nombre de bans à prendre en compte pour une IP. Notez ici que nous ignorons les bans pour le jail fail2ban-recidivist. Si vous changez le nom du jail, pensez aussi à modifier le filtre pour que l'ignoreregex soit correcte.

Il faut ensuite ajouter un jail dans le fichier /etc/fail2ban/jail.conf, dont voici la définition :

[fail2ban-recidivist]
enabled  = true
filter   = fail2ban-recidivist
action   = iptables-allports[name=recidivist]
logpath  = /var/log/messages
maxretry = 5
# 1 semaine
findtime = 604800
# 1 semaine
bantime  = 604800

Comme pour les autres jails, on indique ici le nom du filtre utilisé (et dont nous avons donné la définition précédemment), l'action à effectuer (je choisis ici de bannir sur tous les ports l'attaquant, et de passer le nom "recidivist" à iptables pour la règle. Il serait aussi possible, voir même judicieux, d'envoyer un e-mail pour vous prévenir de ce ban particulier grâce à l'action sendmail-whois), le fichier de log à scruter, qui est pour ce jail celui de fail2ban (qui utilise SYSLOG dans mon cas), le nombre de tentatives infructueuses, la plage de temps sur laquelle on fait le décompte, et enfin le temps de banissement.

Pour ce cas précis, je bannis pendant une semaine une personne qui a déja été bannie 5 fois durant la dernière semaine par d'autres règles. Sachant que chaque règle a elle aussi un nombre de tentatives d'essais (3 par défaut), cela donne tout de même une bonne tolérance.

Il faut noter que si vous utilisez une action qui ne prend pas en compte de nom (ici recidivist), et qui enregistre simplement l'adresse IP, ce système ne fonctionnera pas. En effet, si une personne est bannie parce qu'elle a essayé de s'authentifier sans succès plusieurs fois, pour une durée d'un jour, et qu'ensuite ce jail bannit l'IP pour une semaine, au bout d'une journée, le premier ban sera retiré, l'IP donc retirée, et le ban d'une semaine annulé. Ce problème n'apparait pas avec iptables car il prend en compte le nom de l'action, et ne confond donc pas les bans. En revanche, cela semble pouvoir se produire avec ipfw, hostsdeny et shorewall.

Voilà grâce à cette règle un serveur un peu plus autonome, qui sévira de façon plus dure s'il est attaqué trop souvent par la même personne.


Fabien (eponyme)

fail2ban : classement des IP les plus bannies

Fabien Nicoleau

J'utilise depuis très longtemps fail2ban, qui permet de bannir des IP générant trop d'erreurs (le plus souvent des échecs d'authentification). Il se base sur les logs des différents services et des expressions régulières pour retrouver les tentatives et les bannir.

Je m'y suis un peu plus intéressé ces derniers temps car j'ai été attaqué par des scripts vraiment insistants (ce sera l'objet d'un prochain billet). Dans un premier temps, j'ai voulu obtenir une liste des adresses bannies, avec le nombre de fois, afin de déceler des "récidivistes". Voici la commande utilisée (fail2ban log avec SYSLOG sur mon serveur) :

cat /var/log/messages|grep Ban|awk '{print $7" "$9}'|sort|uniq -c|sort -r

Voici l'explication de la commande :

  • cat : affichage du fichier de log
  • grep Ban : on ne conserve que les lignes concernant un bannissement
  • awk : on extrait simplement les 7ème et 9ème parties, c'est à dire le "jail" utilisé pour le ban, et l'IP bannie
  • un premier sort pour faire en sorte que les IP identiques soient listées les unes en dessous des autres
  • uniq -q : réunies les lignes communes et affiche devant le nombre de fois qu'elles apparaissent
  • un dernier sort (avec l'option reverse) pour faire un tri inverse

On se retrouve ainsi avec une liste indiquant le nombre de fois qu'a été bannie une IP, le jail utilisé et l'IP bannie, le tout dans l'ordre décroisant. Voici un exemple :

      8 [ssh-iptables] 188.138.98.75
      2 [apache-dfind] 93.174.2.202
      2 [apache-dfind] 81.196.179.210
      2 [apache-dfind] 217.70.51.154
      1 [ssh-iptables] 96.8.121.185
      1 [ssh-iptables] 87.106.132.104
      1 [ssh-iptables] 58.211.5.130
      1 [ssh-iptables] 221.207.229.6
      1 [ssh-iptables] 201.140.103.17

Le défaut de cette commande est que l'odre est faire sur du texte, et donc si une IP est bannie plus de 9 fois, elle apparaitra en bas, au lieu d'être en haut.

Cela permet cependant de repérer rapidement une IP trop "agressive" pour la bannir définitivement par exemple.


Fabien (eponyme)

fail2ban : classement des IP les plus bannies

Fabien Nicoleau

J'utilise depuis très longtemps fail2ban, qui permet de bannir des IP générant trop d'erreurs (le plus souvent des échecs d'authentification). Il se base sur les logs des différents services et des expressions régulières pour retrouver les tentatives et les bannir.

Je m'y suis un peu plus intéressé ces derniers temps car j'ai été attaqué par des scripts vraiment insistants (ce sera l'objet d'un prochain billet). Dans un premier temps, j'ai voulu obtenir une liste des adresses bannies, avec le nombre de fois, afin de déceler des "récidivistes". Voici la commande utilisée (fail2ban log avec SYSLOG sur mon serveur) :

cat /var/log/messages|grep Ban|awk '{print $7" "$9}'|sort|uniq -c|sort -r

Voici l'explication de la commande :

  • cat : affichage du fichier de log
  • grep Ban : on ne conserve que les lignes concernant un bannissement
  • awk : on extrait simplement les 7ème et 9ème parties, c'est à dire le "jail" utilisé pour le ban, et l'IP bannie
  • un premier sort pour faire en sorte que les IP identiques soient listées les unes en dessous des autres
  • uniq -q : réunies les lignes communes et affiche devant le nombre de fois qu'elles apparaissent
  • un dernier sort (avec l'option reverse) pour faire un tri inverse

On se retrouve ainsi avec une liste indiquant le nombre de fois qu'a été bannie une IP, le jail utilisé et l'IP bannie, le tout dans l'ordre décroisant. Voici un exemple :

      8 [ssh-iptables] 188.138.98.75
      2 [apache-dfind] 93.174.2.202
      2 [apache-dfind] 81.196.179.210
      2 [apache-dfind] 217.70.51.154
      1 [ssh-iptables] 96.8.121.185
      1 [ssh-iptables] 87.106.132.104
      1 [ssh-iptables] 58.211.5.130
      1 [ssh-iptables] 221.207.229.6
      1 [ssh-iptables] 201.140.103.17

Le défaut de cette commande est que l'odre est faire sur du texte, et donc si une IP est bannie plus de 9 fois, elle apparaitra en bas, au lieu d'être en haut.

Cela permet cependant de repérer rapidement une IP trop "agressive" pour la bannir définitivement par exemple.


Fabien (eponyme)

Mise à jour de quvi pour rawhide : éclatement des paquets

Fabien Nicoleau

Je paquage le logiciel "quvi" pour Fedora. Ce logiciel fournit une bibliothèque (libquvi) permettant de parser les vidéos des sites tels que youtube ou dailymotion (et beaucoup d'autres) ainsi qu'un outil (quvi) utilisant libquvi pour parser les vidéos. La dernière version, la 0.4.0, est maintenant divisée en 3 sources : libquvi (la bibliothèque), libquvi-scripts (les scripts lua utilisés par libquvi permettant de parser les sites) et quvi, l'utilitaire.

J'ai donc aujourd'hui fait les demandes de revue pour les paquets libquvi et libquvi-scripts. Je mettrai à jour quvi quand les deux dépendances auront été importées dans les dépôts:

Ces changements sont importants et ne seront donc effectués que dans rawhide.


Fabien (eponyme)

Mise à jour de quvi pour rawhide : éclatement des paquets

Fabien Nicoleau

Je paquage le logiciel "quvi" pour Fedora. Ce logiciel fournit une bibliothèque (libquvi) permettant de parser les vidéos des sites tels que youtube ou dailymotion (et beaucoup d'autres) ainsi qu'un outil (quvi) utilisant libquvi pour parser les vidéos. La dernière version, la 0.4.0, est maintenant divisée en 3 sources : libquvi (la bibliothèque), libquvi-scripts (les scripts lua utilisés par libquvi permettant de parser les sites) et quvi, l'utilitaire.

J'ai donc aujourd'hui fait les demandes de revue pour les paquets libquvi et libquvi-scripts. Je mettrai à jour quvi quand les deux dépendances auront été importées dans les dépôts:

Ces changements sont importants et ne seront donc effectués que dans rawhide.


Fabien (eponyme)

Momonga Linux, l’écureuil japonais.

Sébastien Natroll Aujourd’hui, j’ai pris 15 minutes au boulot pour agir de manière à rassembler les deux grandes composantes de mon blog, à savoir : Linux et le Japon. Le résultat ? C’est Momonga Linux. Une distribution au look un peu Chibi manga faîte par des Japonais pour des Japonais. J’ai donc chopé une vieille machine à La suite >

NomNom présent dans les dépôts !

Fabien Nicoleau

clive et cclive sont deux logiciels (du même auteur) permettant de récupérer les vidéos de sites tels que youtube ou dailymotion (et beaucoup d'autres !). Il existait auparavant un "frontend" à ces utilitaires, toujours du même auteur : abby. Ce dernier a été remplacé par NomNom (encore et toujours du même auteur), et permet de visionner les vidéos directement en streaming, ou simplement de les télécharger. Il permet aussi de profiter des options de umph (dont je vous laisse deviner l'auteur ..) pour télécharger toute une liste de lecture, ou de favoris de YouTube. NomNom peut être une bonne alternative à ceux ne souhaitant pas utiliser de plugin flash avec leur navigateur.

umph et NomNom n'étaient pas présents dans les dépôts. Je les ai donc packagés et  proposés. Ces deux paquets ont été acceptés et sont maintenant disponnibles dans les dépôts de Fedora, à partir de la version 15. Pour installer NomNom, en root :

# yum install nomnom


Fabien (eponyme)

NomNom présent dans les dépôts !

Fabien Nicoleau

clive et cclive sont deux logiciels (du même auteur) permettant de récupérer les vidéos de sites tels que youtube ou dailymotion (et beaucoup d'autres !). Il existait auparavant un "frontend" à ces utilitaires, toujours du même auteur : abby. Ce dernier a été remplacé par NomNom (encore et toujours du même auteur), et permet de visionner les vidéos directement en streaming, ou simplement de les télécharger. Il permet aussi de profiter des options de umph (dont je vous laisse deviner l'auteur ..) pour télécharger toute une liste de lecture, ou de favoris de YouTube. NomNom peut être une bonne alternative à ceux ne souhaitant pas utiliser de plugin flash avec leur navigateur.

umph et NomNom n'étaient pas présents dans les dépôts. Je les ai donc packagés et  proposés. Ces deux paquets ont été acceptés et sont maintenant disponnibles dans les dépôts de Fedora, à partir de la version 15. Pour installer NomNom, en root :

# yum install nomnom


Fabien (eponyme)

Orphan de certains de mes paquets

Fabien Nicoleau

Bonjour,

En raison de manque de temps, et souhaitant me concentrer sur les paquets que j'utilise avec Fedora, j'ai pris la décision "d'orphan" 6 des paquets que je maintiens dans les dépôts :

  • gestikk : permet de lancer des logiciels avec un simple mouvement de souris
  • immix : mixage de photos
  • itaka : serveur de capture d'écran
  • perl-WWW-Curl : extension perl pour manipuler libcurl
  • vbindiff : visualiseur de fichiers en hexadécimal, avec prise en charge de fichiers à forte taille
  • xcftools : suite d'utilitaires en ligne de commande permettant de manipuler les fichiers au format XCF

J'ai de plus retiré deux paquets :

  • abby : cette interface graphique à clive et cclive a été remplacée par nomnom, que j'ai ajouté dans les dépôts (j'en parlerai bientôt)
  • trustyrc : mon robot IRC, que je ne maintiens plus

Ceux qui souhaitent maintenir ces paquets pourrons compter sur moi en cas de besoins/questions.


Fabien (eponyme)

Orphan de certains de mes paquets

Fabien Nicoleau

Bonjour,

En raison de manque de temps, et souhaitant me concentrer sur les paquets que j'utilise avec Fedora, j'ai pris la décision "d'orphan" 6 des paquets que je maintiens dans les dépôts :

  • gestikk : permet de lancer des logiciels avec un simple mouvement de souris
  • immix : mixage de photos
  • itaka : serveur de capture d'écran
  • perl-WWW-Curl : extension perl pour manipuler libcurl
  • vbindiff : visualiseur de fichiers en hexadécimal, avec prise en charge de fichiers à forte taille
  • xcftools : suite d'utilitaires en ligne de commande permettant de manipuler les fichiers au format XCF

J'ai de plus retiré deux paquets :

  • abby : cette interface graphique à clive et cclive a été remplacée par nomnom, que j'ai ajouté dans les dépôts (j'en parlerai bientôt)
  • trustyrc : mon robot IRC, que je ne maintiens plus

Ceux qui souhaitent maintenir ces paquets pourrons compter sur moi en cas de besoins/questions.


Fabien (eponyme)

Bloody Monday (ブラッディ・マンデイ) : du hack, du Linux, des terroristes et du fun !

Sébastien Natroll Vous avez déjà regardé « Les Experts » ? Vous vous êtes dit « What the fuck ?! » en voyant leurs PC 3D de-la-mort-qui-tue-mais-pas-crédibles-pour-un-sou ? Vous êtes informaticien (ou pas) et ça vous dérange quand on prend le téléspectateur pour un abruti ? (c’est-à-dire : « On va lui faire croire que des effets 3D de la mort, ça La suite >

Fedora 15 vs Fedora 14 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

C'est avec retard que je livre les résultats comparatifs de Fedora 15 vs Fedora 14...

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 15 avec mise à jour version 32 bits avec le noyau Fedora 2.6.38.8-35.fc15.i686.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 15 et exécuté sous Fedora 15 (noyau Fedora 2.6.38.8-35.fc15.i686).
  • 10 séries de tests avec UnixBench compilé sous Fedora 14 et exécuté sous Fedora 14 (noyau Fedora 2.6.35.6-48.fc14.i686).
Voici les résultats obtenus :

Fedora 15 version 32 bits :

Série 1 : 626.3
Série 2 : 655.9
Série 3 : 638.3
Série 4 : 659.9
Série 5 : 661.4
Série 6 : 657.1
Série 7 : 642.9
Série 8 : 661.3
Série 9 : 663.1
Série 10 : 653.2

Moyenne : 651,9

Fedora 14 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 14 :
Série 1 : 659.8
Série 2 : 673.2
Série 3 : 675.2
Série 4 : 663.2
Série 5 : 662.6
Série 6 : 665.7
Série 7 : 658.5
Série 8 : 666.8
Série 9 : 658.9
Série 10 : 663.6

Moyenne : 664,8



Résultats :

Pour Fedora 15, on obtient un indice moyen de 651,9 pour UnixBench.
Pour Fedora 14, j'avais obtenu un indice moyen de 664,8 pour UnixBench.


On a donc une perte moyenne de près de 1,9 % de Fedora 15 32 bits par rapport à Fedora 14 32 bits...
Encore un fois, on assiste à une légère érosion des performances comme montré sur la figure suivante :

perfs_fedora_F15.png

Conclusion :


Au moment de ces tests, le noyau Fedora 15 (basé sur le noyau vanilla 2.6.38) accuse une légère baisse de 1,9 % par rapport au noyau Fedora 14 (basé sur le noyau vanilla 2.6.35).


++

Linux a 20 ans !

Patrice Kadionik

Salut.

Il y a tout juste 20 ans exactement (le 25 août 1991 à 20:57:08 GMT), Linus Torvalds postait son message mythique sur le newsgroup comp.os.minix :

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID:
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki

Hello everybody out there using minix -

Im doing a (free) operating system (just a hobby, wont be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. Id like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

Ive currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that Ill get something practical within a few months, and
Id like to know what features most people would want. Any suggestions
are welcome, but I wont promise Ill implement them :-)

Linus (torvalds@kruuna.helsinki.fi)


Bon anniversaire Linux !



++

mini2440. Séance 8 : bilan... provisoire

Patrice Kadionik

Salut.

Pour cette séance 8 de mise en oeuvre de la carte mini2440, nous allons faire un bilan provisoire...

Nous avons pu voir au cours de 7 séances la construction détaillée et pas à pas d'un système Linux embarqué pour la carte mini2440 :

  • Séance 1 : mise en place de l'environnement de compilation croisée
  • Séance 2 : compilation et programmation du bootloader u-boot
  • Séance 3 : construction d'un système de fichiers root minimal
  • Séance 4 : configuration et compilation de busybox
  • Séance 5 : configuration et compilation du noyau Linux
  • Séance 6 : configuration et compilation de la bibliothèque tslib pour l'écran tactile
  • Séance 7 : configuration et compilation de Qt

La carte mini2440 offre d'autres ressources à explorer comme les GPIO, l'I2C, le SPI..., ce qui fera l'objet d'autres futurs billets.

Ces 7 séances doivent vous permettre maintenant dappréhender sereinement l'environnement Linux embarqué pour cette carte cible.

Une phase d'optimisation est de diminuer le temps de boot. Cela fera l'objet d'un prochain billet pour donner des références sur cet exercice particulier...

++

mini2440. Séance 7 : configuration et compilation de Qt/embedded

Patrice Kadionik

Salut.

Pour cette séance 7 de mise en oeuvre de la carte mini2440, nous allons voir comment configurer et compiler Qt pour la carte mini2440. Nous avons ici utilisé un écran 7" de type A70. Qt utilise la bibliothèque tslib précédemment compilée.

On installe dans un premier temps les sources de Qt disponibles ici :

$ cd mini2440
$ tar -xvzf qt-everywhere-opensource-src-4.7.3.tar.gz

On configurera Qt avec le shell script goconfig :

$ cd qt-everywhere-opensource-src-4.7.3 
$ unset $CC
$ unset $CROSS_COMPILE
$ cat goconfig
./configure \
-embedded arm \
-xplatform qws/linux-arm-g++ \
-prefix /usr/local/qt \
-qt-mouse-tslib \
-little-endian
$ ./goconfig

On notera que linstallation ne se fera pas directement dans le système de fichiers root sous root_fs/ mais dans le répertoire absolu /usr/local/qt/ du PC hôte. Il faut procéder comme cela car Qt/embedded aura codé en dur ces chemins absolus et lon ne peut pas avoir un chemin en /home/… sous peine de non fonctionnement.

Il convient de modifier le fichier qt-everywhere-opensource-src-4.7.3/mkspecs/qws/linux-arm-g++/qmake.conf en suivant les indications dans le document Upgrade Qt4.6.2 in mini2440. On obtient au final le fichier qt-everywhere-opensource-src-4.7.3/mkspecs/qws/linux-arm-g++/qmake.conf suivant.

On compilera Qt avec le shell script go :

$ cat go
make
$ unset $CC
$ unset $CROSS_COMPILE
$ ./go

La compilation prend plusieurs dizaines de minutes… Il faut prendre garde à bien supprimer les variables denvironnement  $CC et $CROSS_COMPILE que l'on avait définies lors de la séance 1.

On installera Qt avec le shell script goinstall sous /usr/local/qt/ du PC hôte en étant superutilisateur :

$ cat goinstall
make install
$ su
# ./goinstall

Qt sera installé dans le système de fichiers root sous root_fs/ : cp -r /usr/local/qt/lib/* ./root_fs/usr/local/qt/lib/

Il faut au préalable configurer des variables denvironnement pour Qt en plus de celles pour tslib comme on a pu le voir lors de la séance 6. On placera ces variables denvironnement dans le fichier root_fs/etc/init.d/rcS :

# Set tslib environment
export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts

# Set Qt environment
export QWS_MOUSE_PROTO=tslib:/dev/input/event0
# Ecran 7" A70
export QWS_DISPLAY=LinuxFB:mmWidth=310:mmHeight=190
# Ecran 3"1/2 T35 #export QWS_DISPLAY=LinuxFB:mmWidth=160:mmHeight=100
export QWS_SIZE=800x480
export LD_LIBRARY_PATH=/usr/local/tslib/lib:/usr/local/qt/lib:/lib:/usr/lib
export QTDIR=/usr/local/qt

if [ -f /etc/pointercal ]; then
echo "Touchscreen already calibrated..."
else
echo "Calibrating Touchscreen..."
/usr/local/tslib/bin/ts_calibrate
fi

On placera aussi ces variables denvironnement dans le fichier root_fs/etc/profile pour quelles soient renseignées quand on accède au shell Linux de la carte mini2440 :

$ cat root_fs/etc/profile
USER="`id -un`"
LOGNAME=$USER
PS1='[\u@\h \W]\# '

# PATH
PATH=/usr/local/jamvm/bin:/usr/local/tslib/bin/:$PATH
HOSTNAME=`/bin/hostname`
export USER LOGNAME PS1 PATH HOSTNAME

# Set tslib environment
export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts

# Set Qt environment
export QWS_MOUSE_PROTO=tslib:/dev/input/event0
# Ecran 3"1/2 T35 #export QWS_DISPLAY=LinuxFB:mmWidth=160:mmHeight=100
# Ecran 7" A70 export QWS_DISPLAY=LinuxFB:mmWidth=310:mmHeight=190
export QWS_SIZE=800x480

export LD_LIBRARY_PATH=/usr/local/tslib/lib:/usr/local/qt/lib:/lib:/usr/lib
export QTDIR=/usr/local/qt

Le test de fonctionnement de Qt a été réalisé sur la carte mini2440 avec le système de fichiers root complet mis à jour en utilisant lapplication de démonstration Nokia patientcare exécutée sur la carte mini2440 :

# ./patientcare –qws

08-07-11_1749.jpg

28-06-11_1442.jpg

Il faut noter que l'on utilise ici le framebuffer qui a été validé lors de la configuration du noyau Linux...

Nous avons donc au final un système Linux embarqué opérationnel et minimal pour la carte mini2440 avec Qt et tslib pour pouvoir utiliser l'écran tactile (A70 pour ces séances).

Prochaine séance : petit bilan sur la mise en oeuvre de la carte mini2440...

++

Sources :

mini2440. Séance 6 : configuration et compilation de la bibliothèque tslib pour l'écran tactile

Patrice Kadionik

Salut.

Pour cette séance 6 de mise en oeuvre de la carte mini2440, nous allons voir comment configurer et compiler la bibliothèque tslib pour l'écran tactile de la carte mini2440. Nous avons ici utilisé un écran 7" de type A70.

On installe dans un premier temps les sources de tslib :

$ cd mini2440
$ git clone http://github.com/kergoth/tslib.git

On  procédera comme précédemment maintenant. On configurera tslib avec le shell script goconfig :

$ cd tslib
$ cat goconfig
./autogen.sh
./configure --host=arm-none-linux-gnueabi --prefix=/usr/local/tslib --enable-static --enable-shared
$ ./goconfig

On notera que linstallation ne se fera pas directement dans le système de fichiers root sous root_fs/ mais dans le répertoire absolu /usr/local/tslib/ du PC hôte. Il faut procéder comme cela car Qt/embedded aura codé en dur ces chemins absolus et lon ne peut pas avoir un chemin en /home/… comme précédemment sous peine de non fonctionnement.

On compilera tslib avec le shell script go :

$ cat go
make
$ ./go

On installera tslib avec le shell script goinstall sous /usr/local/tslib/ du PC hôte en étant superutilisateur :

$ cat goinstall
make install
$ su
# ./goinstall

tslib sera installé dans le système de fichiers root sous root_fs/ :

$ cd mini2440
$ su
# cp -r /usr/local/tslib/* ./root_fs/usr/local/tslib/
On créera un fichier ts.conf dont le contenu est le suivant que l'on mettra sous ./root_fs/usr/local/tslib/etc :
module_raw input
module pthres pmin=1
module variance delta=30
module dejitter delta=100
module linear
Il faut au préalable configurer des variables denvironnement pour tslib. On placera ces variables denvironnement dans le fichier root_fs/etc/init.d/rcS :
# Set tslib environment
export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts

export LD_LIBRARY_PATH=/usr/local/tslib/lib:/usr/local/qt/lib:/lib:/usr/lib

if [ -f /etc/pointercal ]; then
echo "Touchscreen already calibrated..."
else
echo "Calibrating Touchscreen..."
/usr/local/tslib/bin/ts_calibrate
fi
On placera aussi ces variables denvironnement dans le fichier root_fs/etc/profile pour quelles soient renseignées quand on accède au shell Linux de la carte mini2440 :
PATH=/usr/local/tslib/bin/:$PATH 
HOSTNAME=`/bin/hostname`
export USER LOGNAME PS1 PATH HOSTNAME

# Set tslib environment
export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts

export LD_LIBRARY_PATH=/usr/local/tslib/lib:/usr/local/qt/lib:/lib:/usr/lib
On mettra à jour le système de fichiers root de la carte mini2440 soit en NAND Flash, soit sur la carte SD.
On reboote la carte. Si on lance la commande ts_calibrate, on voit apparaître la fenêtre suivante :
# ts_calibrate

calibrate.png

Il faut noter que l'on utilise ici le framebuffer qui a été validé lors de la configuration du noyau Linux...

Prochaine séance : configuration et compilation de Qt/embedded pour la carte mini2440...

++

Sources :

mini2440. Séance 5 : configuration et compilation du noyau Linux

Patrice Kadionik

Salut.

Pour cette séance 5 de mise en oeuvre de la carte mini2440, nous allons voir comment configurer et compiler le noyau Linux qui sera ensuite installé dans la mémoire NAND Flash de la carte mini2440.

On installe dans un premier temps les sources du noyau Linux 2.6.32.2 pour la carte mini2440 ici :

$ cd mini2440
$ tar -xvzf linux-2.6.32.2-mini2440_20110305.tgz

Le noyau Linux est ensuite configuré puis compilé pour la carte mini2440.

On se placera dans le répertoire des sources du noyau. On créera au préalable le lien symbolique kernel :

$ ln -s linux-2.6.32.2 kernel
$ cd kernel


On configurera le noyau Linux avec le shell script goconfig :

$ cd kernel
$ cat goconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
$ ./goconfig


Le fichier de configuration est sauvegardé dans le fichier .config. On pourra utiliser les fichiers config suivants adaptés à la carte mini2440 que l'on recopiera en lieu et place du fichier .config (il existe des fichiers de configuration par défaut config_mini2440_* correspondant à différents types d'écrans LCD sous kernel/) :


On compile le noyau Linux avec le shell script go :

$ cat go
make -j4 ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
$ ./go


On compile les modules éventuels du noyau Linux avec le shell script gomodules :

$ cat gomodules 
ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- make modules
$ ./gomodules


1.2.    Installation

On installera les modules du noyau Linux avec le shell script gomodules_install dans le système de fichiers root (répertoire root_fs/)  :

$ cat gomodules_install
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=/home/eddy33/mini2440/root_fs modules_install
$ ./gomodules_install


On ajustera au préalable la variable INSTALL_MOD_PATH vers le chemin absolu du répertoire root_fs/ en fonction de son environnement de développement sur le PC hôte.

Il faudra bien sûr alors mettre à jour son système de fichiers root installé dans la mémoire NAND Flash ou sur la carte SD de la carte mini2440...

On installera le noyau Linux via le fichier uImage avec le shell script goinstall :

$ cat goinstall
cp arch/arm/boot/uImage /tftpboot
$ ./goinstall


Le noyau Linux uImage est installé dans le répertoire /tftpboot/. Il sera téléchargé via le protocole TFTP en RAM avec u-boot puis programmé dans la partition MTD 2 de la mémoire NAND Flash avec u-boot.

On télécharge donc le fichier uImage depuis u-boot en RAM de la carte mini2440 puis on le programme dans la partition MTD 2 de la mémoire NAND Flash. On suppose que le PC hôte a comme adresse IP 192.168.0.1 et la carte mini2440 a comme adresse IP 192.168.0.100. On configurera u-boot en conséquence :

MINI2440 # setenv netmask 255.255.255.0
MINI2440 # setenv ipaddr 192.168.0.100
MINI2440 # setenv serverip 192.168.0.1
MINI2440 # saveenv
MINI2440 # tftp 32000000 uImage
dm9000 i/o: 0x20000300, id: 0x90000a46
DM9000: running in 16 bit mode
MAC: 08:08:11:18:12:27
TFTP from server 192.168.0.1; our IP address is 192.168.0.100
Filename 'uImage'.
Load address: 0x32000000
Loading: T #################################################
###################################################
done
Bytes transferred = 2058212 (1f67e4 hex)
MINI2440 # nand erase kernel
MINI2440 # nand write.e 0x32000000 kernel

On pourra éventuellement créer la macro u-boot gokernel pour faciliter les prochaines programmations :

MINI2440 # setenv gokernel tftp 32000000 uImage\;nand erase kernel\;nand write.e 0x32000000 kernel
MINI2440 # saveenv

La programmation du fichier uImage se fera alors simplement par la commande u-boot :

MINI2440 # run gokernel

On précise enfin la variable u-boot bootargs qui correspond aux paramètres passés au noyau Linux :

MINI2440 # setenv bootargs root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200 mini2440=1tb rootnowait 
MINI2440 # saveenv

On rappelle que le paramètre mini2440 précise la taille de l'écran LCD :

  • mini2440=0tb : écran 3"1/2
  • mini2440=1tb : écran 7"


On fait un reset de la carte mini2440. On doit avoir les traces de boot du noyau Linux (qui ne trouve pas encore son système de fichiers root…) :

## Booting kernel from Legacy Image at 32000000 ...
Image Name: Linux-2.6.32.2
Created: 2011-06-24 11:33:32 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2058148 Bytes = 2 MB
Load Address: 30008000
Entry Point: 30008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel                                                                             
Uncompressing Linux.............................................................
Linux version 2.6.32.2 (kadionik@ipcchip) (gcc version 4.3.2 (Sourcery G++ Lite1
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: FriendlyARM Mini2440 development board
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C24XX Clocks, (c) 2004 Simtec Electronics
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
. . .

On a alors accès au login. Cela valide ainsi toutes ces 5 séances. Nous avons au final un système Linux embarqué opérationnel sur la carte mini2440

Prochaine séance : configuration et compilation de la bibliothèque tslib pour l'écran tactile de la carte mini2440...

++

Sources :

  • Sources du noyau 2.6.32.2 pour la carte mini2440

mini2440. Séance 4 : configuration et compilation de busybox

Patrice Kadionik

Salut.

Pour cette séance 4 de mise en oeuvre de la carte mini2440, nous allons voir comment configurer et compiler busybox qui sera ensuite installé dans le système de fichiers root.

Busybox est LE couteau suisse quand on fait du Linux embarqué ! Il permet à l'aide d'un seul exécutable d'avoir accès à un ensemble configurable de commandes Linux. Chaque commande est un lien symbolique vers l'exécutable busybox : on exploite ainsi dans les sources C de busybox l'argument argv[0]...

On installe dans un premier temps les sources de busybox disponibles ici :

$ cd mini2440
$ tar -xvzf linux-busybox-mini2440-1.13.3.tgz
$ cd busybox-1.13.3

La configuration par défaut correspond au shell script godefconfig :

$ cd busybox-1.13.3
$ cat godefconfig
cp fa.config .config

On pourra éventuellement configurer busybox avec le shell script goconfig afin de sélectionner les commandes Linux (applets) que l'on veut en plus :

$ cat goconfig
make ARCH=arm CC=arm-linux-gcc menuconfig
$ ./goconfig

On compilera busybox avec le shell script go :

$ cat go
make ARCH=arm CC=arm-linux-gcc
$ ./go

On installera busybox avec le shell script goinstall dans le système de fichiers root que l'on a construit lors de la séance 3 (répertoire root_fs/)  :

$ cat goinstall
make ARCH=arm CC=arm-linux-gcc CONFIG_PREFIX=/home/eddy33/mini2440/root_fs install
$ su
# ./goinstall

On ajustera au préalable la variable CONFIG_PREFIX vers le chemin absolu du répertoire root_fs/ en fonction de son environnement de développement sur le PC hôte.

Notre système de fichiers root est presque opérationnel. Il reste à rajouter les bibliothèques pour le processeur ARM :

$ cd mini2440
$ su
# \cp -a ./arm-2008q3/arm-none-linux-gnueabi/libc/armv4t/lib/* ./root_fs/lib
# \cp ./arm-2008q3/arm-none-linux-gnueabi/libc/armv4t/usr/lib/* ./root_fs/usr/lib

Il manque éventuellement les modules Linux et le firmware des périphériques à rajouter sous root_fs/lib (on verra cela à la prochaine séance) mais le système de fichiers root sous root_fs/ doit être utilisable en l'état...

Les tests peuvent se faire en utilisant le système de fichiers root ainsi créé soit en mémoire NAND flash (partition MTD 3), soit sur la carte SD.

Pour mettre le système de fichiers root en mémoire NAND Flash de la carte mini2440, il faut au préalable le convertir en système de fichiers de type JFFS2. On utilisera la commande mkfs.jffs2. On utilisera le shell script gojffs2 :

$ cd mini2440
$ cat gojffs2
mkfs.jffs2 -lqnp -e 16 -r ./root_fs -o rootfs.jffs2
cp rootfs.jffs2 /tftpboot
$ su
# ./gojffs2
On suppose que le PC hôte a comme adresse IP 192.168.0.1 et la carte mini2440 a comme adresse IP 192.168.0.100. On configurera u-boot en conséquence :
MINI2440 # setenv netmask 255.255.255.0
MINI2440 # setenv ipaddr 192.168.0.100
MINI2440 # setenv serverip 192.168.0.1
MINI2440 # saveenv
On utilisera ensuite u-boot pour télécharger par TFTP le fichier image JFFS2 rootfs.jffs2 puis on le programmera dans la partition MTD 3 de la mémoire NAND Flash :
MINI2440 # tftp 32000000 rootfs.jffs2
MINI2440 # nand erase rootfs
MINI2440 # nand write.jffs2 32000000 rootfs $(filesize)

On pourra éventuellement créer la macro u-boot gorootfs pour faciliter les prochaines programmations :

MINI2440 # setenv gorootfs tftp 32000000 rootfs.jffs2\;nand erase rootfs\;nand write.jffs2 32000000 rootfs \$(filesize)
MINI2440 # saveenv

La programmation du fichier rootfs.jffs2 se fera alors simplement par la commande u-boot :

MINI2440 # run gorootfs

Pour recopier le système de fichiers root sur la carte SD, on utilisera le shell script gosd. On branchera au préalable un lecteur de cartes SD sur le PC hôte, la carte SD sera enfichée dans le lecteur.

Pour la première fois, la carte SD sera formatée au format ext3. On suppose que la carte SD est vue comme le périphérique /dev/sde :

$ cd mini2440
$ su
# fdisk -l
# fdisk /dev/sde
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1016, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1016, default 1016):
Using default value 1016
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
# mkfs.ext3 /dev/sde1

On copiera ensuite le répertoire root_fs/ sur la carte SD ainsi formatée à laide du shell script gosd :

# cat gosd
umount /dev/sde1
mount -t ext3 /dev/sde1 /mnt
\rm -rf /mnt/*
sync
\cp -r root_fs/* /mnt
sync
umount /dev/sde1
# ./gosd

Pour utiliser le système de fichiers root en mémoire NAND Flash, on configurera u-boot comme suit :

MINI2440 # setenv boot_nand setenv bootargs root=/dev/mtdblock3 rootfstype=jffs2 mini2440=1tb console=tty0,115200 console=ttySAC0,115200 rootwait \; nboot.e kernel \; bootm
MINI2440 # setenv bootcmd run boot_nand
MINI2440 # saveenv

Pour utiliser le système de fichiers root sur la carte SD, on configurera u-boot comme suit :

MINI2440 # setenv boot_sd setenv bootargs console=tty0,115200 console=ttySAC0,115200 mini2440=1tb rootfstype=ext3 root=/dev/mmcblk0p1 rw rootwait \; nboot.e kernel \; bootm
MINI2440 # bootcmd run boot_sd
MINI2440 # saveenv

Il faut noter que le paramètre mini2440 précise la taille de l'écran LCD :

  • mini2440=0tb : écran 3"1/2
  • mini2440=1tb : écran 7"

On pourra tester notre système de fichiers root une fois que l'on aura un noyau Linux opérationnel pour la carte mini2440, ce qui sera expliqué à la prochaine séance.

Prochaine séance : configuration et compilation du noyau Linux pour la carte mini2440...

++

Sources :

mini2440. Séance 3 : construction d'un système de fichiers root minimal

Patrice Kadionik

Salut.

Pour cette séance 3 de mise en oeuvre de la carte mini2440, nous allons voir comment construire un système de fichiers root minimal.

Avoir un système de fichiers root est indispensable pour avoir un noyau Linux fonctionnel car l'un ne marche pas sans l'autre. Le système de fichiers root peut être local en RAM, en mémoire NAND Flash ou sur la carte SD pour la carte mini2440 ou bien distant monté par NFS. Le choix se fera par des paramètres passés au boot du noyau Linux, paramètres sauvegardés comme variables d'environnement (setenv) du bootloader u-boot.

Pour construire le système de fichiers root, on doit respecter le standard FHS (Filesystem Hierarchy Standard) dont la structure globale est la suivante :

rootfs (/)
|--bin
|--dev
|--etc
| |--init.d
|--lib
|--mnt
|--proc
|--sys
|--sbin
|--tmp
|--usr
| |--bin
| |--sbin
|--var

Nous allons donc construire le système de fichiers root en s'aidant du document Build Root File System...

Tout sera mis dans le répertoire root_fs/ :

$ cd mini2440
$ mkdir root_fs

Le système de fichiers root ainsi construit sera minimal (et non opérationnel) car cela ne sera qu'un squelette qu'il faudra compléter avec busybox, avec les bibliothèques dynamiques pour le processeur ARM sous root_fs/lib/ ainsi qu'éventuellement les modules du noyau Linux. On verra cette étape à la prochaine séance consacrée à busybox...

On crée les répertoires de base :

$ cd root_fs
$ mkdir dev
$ mkdir -p etc/init.d
$ mkdir lib
$ mkdir mnt
$ mkdir proc
$ mkdir sys
$ mkdir -m 777 tmp
$ mkdir var

On crée l'entrée console sous root_fs/dev/ :

$ cd root_fs/dev
$ su
# mknod -m 622 console c 5 1

Les principaux fichiers de configuration, notamment ceux qui seront utilisés par busybox sont sous root_fs/etc/.

On créera le fichier root_fs/etc/inittab utilisé par le processus init dont le contenu est le suivant :

::sysinit:/etc/init.d/rcS
::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r
::shutdown:/sbin/swapoff -a
::restart:/sbin/init
#::respawn:/sbin/getty -L 115200 /dev/ttySAC0 vt100
console::respawn:/sbin/getty -L 9600 tty0 vt100

On créera le fichier root_fs/etc/init.d/rcS, shell script exécuté après le lancement du processus init dont le contenu est le suivant :

#! /bin/sh

# Setup the bin file location and export to system PATH
PATH=/sbin:/bin:/usr/sbin:/usr/bin
umask 022
export PATH

# mount the filesystem directories
mount -a
mkdir /dev/pts
mount -t devpts devpts /dev/pts -o mode=0622

# create device nodes and directories
echo /sbin/mdev>/proc/sys/kernel/hotplug
mdev -s
mkdir /var/lock

# start logging utility services
klogd
syslogd

# set system clock from RTC
hwclock -s

# set host and config loopback interface
ifconfig lo 127.0.0.1
ifconfig eth0 192.168.0.100

On créera le fichier root_fs/etc/mdev.conf pour le processus mdev de création dynamique des points d'entrée sous /dev dont le contenu est le suivant :

# system all-writable devices
full 0:0 0666
null 0:0 0666
ptmx 0:0 0666
random 0:0 0666
tty 0:0 0666
zero 0:0 0666

# console devices
tty[0-9]* 0:5 0660
vc/[0-9]* 0:5 0660

# serial port devices
s3c2410_serial0 0:5 0666 =ttySAC0
s3c2410_serial1 0:5 0666 =ttySAC1
s3c2410_serial2 0:5 0666 =ttySAC2
s3c2410_serial3 0:5 0666 =ttySAC3

# loop devices
loop[0-9]* 0:0 0660 =loop/

# i2c devices
i2c-0 0:0 0666 =i2c/0
i2c-1 0:0 0666 =i2c/1

# frame buffer devices
fb[0-9] 0:0 0666

# input devices
mice 0:0 0660 =input/
mouse.* 0:0 0660 =input/
event.* 0:0 0660 =input/
ts.* 0:0 0660 =input/

# rtc devices
rtc0 0:0 0644 >rtc
rtc[1-9] 0:0 0644

# misc devices
#mmcblk0p1 0:0 0600 =sdcard */bin/hotplug
#sda1 0:0 0600 =udisk * /bin/hotplug

On créera le fichier root_fs/etc/fstab pour le montage des divers systèmes de fichiers (virtuels) dont le contenu est le suivant :

# device mount-point type options dump fsck order
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
var /var tmpfs defaults 0 0

On créera le fichier root_fs/etc/profile qui est exécuté quand on se connecte au système dont le contenu est le suivant :

USER="`id -un`"                                                 
LOGNAME=$USER
PS1='[\u@\h \W]\# '
PATH=$PATH
HOSTNAME=`/bin/hostname`
export USER LOGNAME PS1 PATH HOSTNAME

On créera le fichier root_fs/etc/issue qui contient le message de bienvenue dont le contenu est le suivant :

Welcome to Mini2440
Kernel \r on an \m (\l)
On créera le fichier root_fs/etc/passwd avec un seul utilisateur, root dont le contenu est le suivant :
root::0:0:root:/:/bin/sh
On créera le fichier root_fs/etc/group dont le contenu est le suivant :
root:x:0:root
Enfin, nous réajustons les droits attribués à root du répertoire root_fs/ qui sera recopié soit sur une carte SD, soit transformé en fichier image JFFS2 :
$ cd mini2440
$ su
# chown -R root:root root_fs
$
Nous en avons fini avec ce système de fichiers root minimal. Il n'est pas encore opérationnel car il convient de le compléter avec :
  • busybox
  • Les bibliothèques pour processeur ARM
  • les modules du noyau Linux ainsi que les firmwares si nécessaire

Le résultat de la construction de ce système de fichiers root est disponible ici.


Prochaine séance : compilation et mise en oeuvre de busybox et intégration dans le système de fichiers root minimal...

++

Sources :