For about six months I’ve been using a Raspberry Pi 3 as my desktop computer at home.
The overall experience is fine, but I had to do a few adjustments.
First was to use KeePass, the second to compile gcc for cross-compilation (ie use buildroot).
For about six months I’ve been using a Raspberry Pi 3 as my desktop computer at home.
The overall experience is fine, but I had to do a few adjustments.
First was to use KeePass, the second to compile gcc for cross-compilation (ie use buildroot).
Cet article a été rédigé a l’origine pour linuxembedded.fr : Crée un CD d’installation d’une debian spécialisée.
Parfois un système embarqué se résume à un serveur spécifique et quelques applicatifs. Dans ce cas l’utilisation d’une distribution standard peut être préférable à un buildroot ou autre openembedded. Ici nous avons fait le choix de debian et nous voudrions avoir un CD d’installation complet de notre système.
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).
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.
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.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/
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.
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 …
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.
Better later than never, I restarted to triage last week, here is the report for it.
In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage.
Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD.
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
This report is 2 week late… It was delayed by an important event, not the release of squeeze, but the birth of my first child: Célestine is born Monday the 31th of January.
My wife and Célestine are both fine now but the firsts days were not that easy. I’m starting to recover from the lack of sleep, but I’m still very late on my debian tasks 😉 So I guess I just drop Triaging for week 13, 14 and maybe 15…
Now the bugs I triaged just before :
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !
The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !
I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!
Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.
The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o !
Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉
Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.
This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!
bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉
To submitters, please keep the bug CCed when you answer, thanks.
Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉
Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.
As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉
Get involved !
Happy new year !
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
For some reason1 bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn’t write to me, this bug will have waited for what… about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort 😉
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail. ↩︎
An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875…
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.