Qt4.6 embedded sur la mini2440

Version du 12/11/2010

Avertissement

Cet article est en permanente mise à jour, au fur et à mesure que je découvre des choses. En effet, n’étant qu’un modeste explorateur et pas du tout un expert es Linux et consorts, je me rends compte au fur et à mesure que je progresse dans ma compréhension que ce que je croyais avoir compris s’avère en fait différent. Du coup ce que je prenais à un moment pour une solution n’était en fait qu’un heureux effet de bord d’une autre action, et donc non reproductible sur une autre configuration...

Pardonnez-moi pour ces errements, mais ainsi est faite la quête de la Vérité ;)

Objectifs

Ayant pour projet de ne pas utiliser la mini2440 comme un PDA, je n’ai donc pas besoin du Qtopia2 livré avec, ce qui permettra de récupérer de l’espace de stockage (et de la mémoire aussi). D’autre part, certaines fonctionnalités de Qt4 m’attirent vraiment. J’ai donc cherché à générer et installer la dernière version que Qt4 (4.6.2 au moment de la rédaction).

Crédits

Je ne serais jamais arrivé à cela sans les informations puisées dans divers sites Web, et notamment dans le blog de Bertrand Roussel, référencé dans l’article présentant une compilation de liens utiles. Merci donc à tous les auteurs de ces pages.

Mode opératoire

Je vais tâcher de retranscrire ici aussi fidèlement que possible les étapes que j’ai suivies, en espérant qu’elles resteront valables dans votre contexte.

Ma configuration système est une Ubuntu 9.10. Le cross-compilateur ARM gcc version 4.3.2 a été installé au préalable, à partir de l’archive disponible sur le site FriendlyARM.

Récupération des sources

La première opération est de récupérer l’archive de Qt4 everywhere qui contient tous les fichiers sources. Elle est disponible via le site Nokia, et l’archive utilisée au moment de la rédaction de cet article est
qt-everywhere-opensource-src-4.6.2.tar.gz. Décompressez le tout et placez le résultat dans un répertoire quelconque, que sera désigné dans la suite de cet article par <QTE_HOME>.

Pré-configuration

Avant de pouvoir configurer la génération via la classique commande configure, il est nécessaire de... configurer configure afin de l’adapter au contexte de la carte. Pour cela, il faut éditer le fichier :
<QTE_HOME>/mkspecs/qws/linux-arm-g++/qmake.conf, qui est le fichier de configuration du sur-make de Qt.

Les modifications à faire sont :

Ajouter les options spécifiques au compilateur fourni par FriendlyARM [1]

Si on utilise le compilateur version 4.3.2 fourni sur le site FriendlyARM en date de rédaction, il faut utiliser quelques options spécifiques pour éviter que l’exécution des applications sur la carte ne se solde par un Segmentation Fault.

Ajoutez simplement les lignes suivantes à qmake.conf :

QMAKE_CFLAGS_RELEASE += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4 -mtune=arm920t
QMAKE_CXXFLAGS_RELEASE += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4 -mtune=arm920t
QMAKE_CFLAGS_DEBUG += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4 -mtune=arm920t
QMAKE_CXXFLAGS_DEBUG += -msoft-float -D__GCC_FLOAT_NOT_NEEDED -march=armv4 -mtune=arm920t

(je n’ai pas essayé la configuration debug, et ne peux donc pas garantir que les deux configurations xx8DEBUG sont correctes. Merci de me signaler s’il y a un problème)

A noter que pas mal de pages Web indiquent de désactiver l’optimisation de compilation comme correction du problème. Ca marche également, mais au prix d’une dégradation très notable des performances d’exécution, ainsi que d’une augmentation de la taille des binaires. Jusqu’à preuve du contraire cette manière de gérer le problème semble donc préférable.

Rendons à César ce qui est à César au passage. La source de cette information qui n’a pas de prix est : http://wiki.linuxmce.org/index.php/.... Vous pensiez que j’avais trouvé cela tout seul ? Ben non, navré de vous décevoir ;)

Configuration

TRES IMPORTANT

Pour vous éviter de vous prendre à la figure un message d’erreur prétendant une erreur de configuration de tslib, pensez à inclure le répertoire des exécutables du cross-compilateur dans le path avant de lancer la commande configure. Vous risquez sinon de vous arracher les cheveux à comprendre ce qui se passe avec tslib, à chercher à le recompiler (ce qui n’est pas forcément utile car déjà sur la carte) et à vous battre avec ses propres problèmes de compilation.

Ce genre de souci peut être diagnostiqué en ajoutant l’option -verbose aux arguments de configure, et vous pourrez alors constater que l’erreur de la configuration de tslib vient du fait que le script n’arrive pas à lancer le compilateur. Or tslib étant considéré comme obligatoire du fait de la présence de l’option -qt-mouse-tslib (cf ci-après), toute erreur à cette étape est considérée comme un échec de configuration. Je précise cela car si vous regardez de près les messages produits en mode verbose, vous constaterez que la même erreur est détectée pour un bon lot d’autres caractéristiques avant tslib, sans que cela ne génère le message fatail. Il se trouve que ces autres caractéristiques de configuration sont considérées comme optionnelles, et sont donc désactivées par le processus de configuration.

Voilà, maintenant que vous savez tout et que vous avez mis à jour votre path [2], vous pouvez lancer la commande suivante :

./configure \
    -embedded arm \
    -xplatform qws/linux-arm-g++ \
    -prefix /usr/local/Qt \
    -qt-mouse-tslib \
    -little-endian

Pour ce qui est de la signification des options en général, reportez-vous l’aide de configure (configure -help). C’est le seul endroit pour le moment où j’ai trouvé les détails en question, et ça a le mérite d’être l’information de référence.

Pour gagner du temps et si vous n’envisagez pas de générer certaines parties de Qt (comme les exemples ou les démos), il est possible de les exclure du processus de configuration par l’option -nomake <component-name>. Par exemple :

-nomake examples

Pour ma part j’utilise cette version de la commande, qui économise pas mal de temps de processus et de compilation ensuite, et réduit également la taille du bazar :

./configure \
    -embedded arm \
    -xplatform qws/linux-arm-g++ \
    -prefix /usr/local/Qt \
    -little-endian \
    -opensource \
    -confirm-license \
    -silent \
    -qt-mouse-tslib \
    -no-qt3support \
    -nomake demos \
    -nomake examples \
    -nomake translations \
    -nomake tools

Les options ajoutées sont :

Au cas où on souhaite remettre la configuration à zéro, utilisez la commande :

make confclean

A noter qu’un script config.status est créé avec les options passées en argument, afin de relancer la commande sans devoir tout retaper.

Compilation

Lancez tout simplement make pour la compilation complète, ou éventuellement make sub-xxx pour générer un composant particulier.

Si votre machine dispose d’un multi-coeur, pensez ajouter l’option -j<n> la ligne de commande, qui aura pour effet de demander make de paralléliser plusieurs travaux. La règle pour déterminer n est 1.5 ou 2 fois le nombre de processeurs physiques. Sur mon core 2 duo, j’utilise -j4, et ai la satisfaction de voir l’indicateur de charge à 100% pour tous les processeurs (sinon on voit une charge de 100% passer en alternance d’un processeur à un autre).

Attention : tout n’est pas toujours si rose... Il m’est arrivé d’avoir des erreurs de make qui avaient tout l’air d’être causées par une chronologie incorrecte des builds lancés en parallèle, car elles faisaient référence à des éléments de librairies non disponibles. Pour vous éviter des migraines, et au prix d’un temps de génération plus long, essayez dans ce cas sans l’option -j. J’ai constaté ce problème en reproduisant la manip de génération des libs Qt sur une autre machine, et l’ai résolu de cette manière. L’autre option est de relancer la commande. Comme une partie des binaires est déjà là, l’agencement des tâches parallèles va alors être différent. Ben non, ce n’est pas une science exacte...

Prenez le temps de boire un café, manger, regarder un film,.... car il y en a pour un moment si vous avez lancé une make complet (ie sans paramètre).

Le set minimal de composants semble être :

make sub-tools-bootstrap sub-moc sub-rcc sub-uic sub-corelib \
  sub-xml sub-network sub-gui 

Si vous recevez une erreur relative à zlib, vérifiez que les librairies de développent zlib sont installes sur votre système.

Si tout se passe bien, vous allez obtenir les librairies dynamiques (.so) dans le sous-répertoire lib. Il ne reste plus qu’à les installer sur la mini2440 par le moyen de votre choix (ftp, copie sur carte SD, génération d’un root file system,....

Installation des librairies

Sur la mini2440, vous pouvez soit :
– copier les .so dans le répertoire /lib (en tant root)
– les installer dans un autre répertoire, et ajouter son path dans le fichier /etc/ld.so.conf qui indique au système où il peut trouver les .so au moment où il a besoin de les charger.

A noter que je n’utilise pas make install pour plusieurs raisons :
– un peu overkill pour copier juste quelques fichiers
– présente le risque de polluer une installation de Qt pour le Linux de la machine de développement si on ne fait pas attention
– si on utilise des chemins différents pour la version embarquée et pour la version de la machine de développement, afin d’éviter le problème ci-dessus, il faut que ces chemins soient reproduits à l’identique sur la mini2440, sinon vous serez gratifiés d’un message d’erreur à l’exécution, relatif au fait que le répertoire des fonts n’a pas été trouvé (le chemin utilisé pour la génération est stocké quelque part dans les libs apparemment)

De plus j’ai noté que make install copie toute la planète et pas seulement les .so. Ca se comprend dans la mesure où le résultat est supposé être l’environnement utilisé pour le développement des applications ensuite, d’où la nécessité des includes et autres fichiers, mais dans notre cas de figure on les a déjà dans l’arborescence qui a permis de produire les librairies. Alors ça fait un peu double emploi. Ceci étant, il se peut que je n’aie pas tout compris, donc à prendre avec les réserves habituelles.

Configuration de l’environnement système

Toujours sur la mini2440, créez le fichier /etc/qt4-env avec le contenu suivant :

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/ts
export TSLIB_CALIBFILE=/usr/local/etc/ts.calib
export TSLIB_CONFFILE=/usr/local/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/lib/ts
export QWS_MOUSE_PROTO=tslib:/dev/input/ts

Ce fichier définit toutes les variables d’environnement nécessaires Qt et tslib pour fonctionner. Pour qu’il soit pris en compte lors de l’initialisation du système, ajouter dans /etc/profile la ligne :

source /etc/qt4-env

A noter que le nom du fichier n’a pas d’importance particulière.

Pour que le touchscreen soit automatiquement défini, ajouter également dans ce fichier la ligne :

mknod /dev/input/ts c 13 64

Cela définit le device /dev/input/ts représentant le touchscreen, de type caractère et associé aux identificateurs MAJOR=13 et MINOR=64

ATTENTION :

Ces ids sont dépendants du type d’écran installé. Pour les obtenir, afficher le contenu du fichier /sys/devices/virtual/input/mice/dev. Ainsi les écrans 3.5" et 7" auront le même MAJOR mais des MINOR différents (63 pour le 3.5" si je me base sur ce qu’on peut trouver sur le net, mais c’est à vérifier car je n’en ai pas). Pour tout savoir sur les MAJOR/MINOR numbers : http://www.linux-tutorial.info/modu...

Comment savoir que c’est là qu’il faut chercher ?

/sys/devices/virtual contient les descripteurs des devices virtuels créés en fonction du hardware. Notre écran tactile émulant en fait une souris, il est assez logique de le trouver au niveau des inputs de type souris.

A noter qu’on retrouve les mêmes informations dans le fichier /sys/devices/virtual/input/input0/event0/dev. Mais c’était moins intuitif à dénicher.

Le mot de la fin

Voilà. Avec cela vous êtes maintenant prêts pour développer des applis Qt4 pour la mini2440 et les exécuter.

N’oubliez pas que si comme moi vous lancez l’application directement lors du démarrage de la carte, il n’y a pas de serveur actif. Ce n’est pas grave car la version embedded permet d’embarquer ce serveur dans l’application elle-même et de le lancer lors de son démarrage.

Il suffit d’ajouter l’option -qws la ligne de commande qui lance votre application. On peut s’économiser cela en initialisant l’objet application en mode serveur embarqué, via l’argument QApplication::GuiServer du constructeur C++ :

QApplication app(argc, argv, QApplication::GuiServer);

Plus besoin de -qws maintenant lors du lancement de l’exécutable. Si vous l’avez laissé, ce n’est pas grave, il n’aura pas d’effet priori.

Rendez-vous dans un prochain article pour entrer dans une appli Qt4 pour la mini2440.