Développement noyau sur e60

Sun, 03 Apr 2011 20:52:14 +0100

Comme j’ai accès à la console série sur liseuse Samsung e60 compilons un nouveau noyau linux.

Le processeur de la liseuse e60 est un ARM, pour compiler le noyau pour ce processeur il nous faut une chaine de compilation croisée.
La première option est d’utiliser celle fournie par samsung avec le reste des sources. A priori ça fonctionne mais utiliser des binaires de sources inconnue ne m’enchantait guerre.
La seconde solution serait de recompiler la chaine nous même, c’est souvent la seule solutions pour des systèmes exotiques nécessitant quelques patchs.
Ici, a bien regardé les fichiers de Samsung, les binutils viennent d’une version entre 2.17 et 2.18 (leur version est nommée 2.17.50 mais ne correspond pas tout à fait à se snapshot non plus…) mais il ne semble pas y avoir de patch ‘maison’. Quand a gcc j’ai pas pris le temps de vérifier.
J’ai opté pour la chaine de compilation croisée du projet emdebian dans sa version lenny (Tout comme le propose le magazine Open Silicium n°1 dans son article sur FriendlyARM).

Installation de la chaine de compilation croisée sur debian

Tout d’abord les clef des l’archive:


sudo apt-get install emdebian-archive-keyring

Ensuite nous ajoutons un fichier /etc/apt/sources.list.d/emdebian.list avec le contenu suivant:


deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

Puis une mise à jours des liste des paquets afin d’installer les paquets nécessaires:


sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Voila, nous disposons maintenant d’une chaine de compilation croisée installée avec des paquets, donc facile à mettre à jour ou à désinstaller.

Les sources du noyau

Samsung fournit une version modifiée du 2.6.29.4, en récupérant la branche git 2.6.29.y du noyau, j’ai rapidement vu que leur changement s’appliquait à la version 2.6.29.6 (dernière de cette branche).

Afin de mieux trier les changements michel.s avait déjà séparé les changements de Samsung en plusieurs patchs (les patchs sur le projet e60-open). Après quelques essai j’ai concocté un fichier series qui permet d’appliquer ces patchs avec quilt ou mieux encore de des importer dans une branche git avec git quiltimport. L’ordre que j’ai choisit permet en particulier de se débarrasser facilement des quelques patchs (les derniers).

On notera dans ces patchs la présence de quelques fichiers binaires:

fs/rfs/*.o une couche de journalisation propriétaire sur la fat. Si vous voulez mon avis, elle n’est pas nécessaire, après tout nous disposons de systèmes de fichiers journalisé libre, et linux est capable de monter autre chose que de la FAT par USB…
drivers/usb/gadget/file_storage.o le fichier .c correspondant a de plus été retiré, la licence BSD/GPL de l’original autorise une distribution binaire (toutefois, je n’ai pas vérifié si Alan Stern est cité dans la doc) mais j’aurais bien apprécié que Samsung fournisse le source.

U-Boot

Avant de compiler le noyau, il nous faut l’utilitaire mkimage fourni par U-Boot. Ici, pas de chichis, nous compilons la version de U-Boot fournie par Samsung, et nous copions tools/mkimage dans notre path (c’est la seule méthode d’installation que j’ai pu trouver).


make smdkc100_config 
make CROSS_COMPILE=arm-linux-gnueabi-

cp tools/mkimage ~/bin/

Compilation de linux

Pour la configuration un des patch fourni un .config qui est une copie de config_rfs donc même sans appliquer ce patch, nous pouvons récupérer la config de samsung.

Ensuite, on compile enfin !


make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage

Nous pouvons charger notre noyau en suivant la procédure de test de noyau du projet e60-open la commande pour changer le noyau sera alors


sudo dnw arch/arm/boot/uImage

Voila, ça marche ! Enfin presque, le noyau ne trouve pas ses modules. Ceux présents dans nos sources ne sont pas un vrai problème (mais le sujet d’un prochain article) en revanche les modules /lib/modules/max14540.ko et lib/modules/dhd.ko ne sont pas présent dans les sources alors qu’ils présentent une licence GPL au noyau.

Les sources manquants

Le site Samsung Open Source Release Center possède une interface pour les contacter, mais elle ne semble pas bien fonctionner (j’ai même booter mon netbook sous windows pour essayer avec IE8 sans succes!). En fouillant le forum e60 j’ai retrouvé leur adresse email et leur ai écrit, pas de réponse jusqu’à présent (pas même automatique…). Patience …

Conclusion

Nous pouvons compiler le noyau de la liseuse e60 sans utiliser la chaine de compilation fournie par Samsung.
Il reste du travail pour le changement des modules car ceux présent sur la liseuses sont compilé pour la version 2.6.29.4 du noyau et notre noyau refuse de les charger. (J’ai déjà fait quelques tests mais ça sera le sujet d’un prochain article.)
Et surtout sans les sources manquants nous allons avoir du mal a exploiter au mieux notre liseuse e60.

Mise à jours: Je viens de recevoir une réponse de Samsung, ils ont mis a jours leur archive. Il faut encore que je test ça.

Console série sur liseuse Samsung E60

Tue, 22 Mar 2011 16:36:25 +0100

Les bons plans Samsung de janvier avait déjà fait le tour du web, et je n’en reparlerais pas (sauf pour dire que j’en ai profiter pour acquérir une liseuse Samsung E60).

Une communauté s’est formée autour d’un forum (e60 sur hardware.fr) et d’un espace google code (e60-open).

On y trouve pas mal d’infos et en particulier la console série. De mon coté je dispose d’un adaptateur USB vers série en LVTTL 3.3V (à base de FTDI FT2232C) donc j’ai opté pour la connexion sur R232 et R233. Or RDX (R232) est déjà connecté au circuit MAX232 qui converti les niveau LVTTL vers les niveaux série, et apparemment ce petit gars était plus fort que mon FTDI… J’ai donc retiré R232 et connecté mon FTDI à la palace. Restait à savoir quel pad de R232 allait vers le CPU… Coup de pot, le premier que j’ai essayé était le bon: le coté le plus proche de la batterie.

Une petite photo de mes belles soudures :

Et voila, j’ai ensuite suivi la procédure pour tester un kernel en chargeant le kernel fourni sur le SVN du projet. Et ça à marché (à ceci prêt que j’ai dû déchargé le module secbulk, donc soit j’ai pas compris, soit il ne sert pas).

Prochain épisode, compilation et test d’un noyau Linux.

e60 on Silicone's web