This post was originally published as A look from behind the Open Source Bios on Scaleway’s blog.
This is a followup post of Open Source Bios at Scale so you might what to read it first as this post will get more into details.
As explained in the previous post our BIOS is build with three main components: coreboot, Intel FSP and TianoCore. We will describe here how those three parts are fitting together.
This post is a summary of my talk at FOSDEM’18 and was originally posted on Scaleway’s blog.
At Scaleway we started to design our servers with the ARM C1.
Later we switched to a x86 architecture to provide the C2 and Dedibox SC2016.
On x86 a BIOS is required to start the server. BIOS software got many legacy and backward compatible software to ensure a reliable behavior across many boards. I was in charge of the BIOS development for our new generation of x86 servers.
This article presents technical choices we used during our development.
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.
Je voulais me mettre au développement noyau, mais je ne savais pas par où commencer, alors un sage m’a dit: « pour apprendre rien de tel que de le faire: vous achetez un petit périphérique USB et vous en écrivez le driver. »
Ma réponse a été: « effectivement, je n’y avais pas pensé, en général on utilise la libusb pour ce genre de choses. »
Et voila que quelques jours après, sans avoir trouvé de périphérique sympa je me suis dit, mais pourquoi pas le faire aussi ?
Comme je vous l’ai déjà raconté, j’ai déjà bricolé un périphérique USB: l’USBtinyISP, donc je suis allé rechercher le code original de usbtiny et je me suis monté un petit prototype avec 4 LED et 2 boutons:
Bon plutôt que d’utiliser un ATtiny, j’ai pris un ATmega8 histoire d’avoir un peu de place pour y ajouter du code plus tard 😉 (l’ATtiny2313 est déjà super plein pour l’USBtinyISP).
Et voila le schéma (en image, les sources gschem sont sous git dans le répertoire sch):
Une fois le montage prêt, quelques lignes de code basées sur l’exemple de tinyusb et hop un firmware pour l’ATmega (à la racine du projet).
Qu’il a fallut tester, hop la première méthode évoquée plus haut, quelques lignes de code avec libusb, disponible dans le répertoire test, m’ont permis de parfaire le firmware 😉
Voila, tout marche, on va pouvoir entrer dans le vif du sujet.
En fait j’ai tout simplement suivi et adapté les tutoriels suivants:
En regardant la version de usbled.c présente dans les sources de Linux afin de mettre à jour les derniers détails.
Cela donne un driver qui ajoute les pseudo-fichiers leds et keys dans le répertoire du périphérique déjà créé dans /sys/bus/usb/ par le noyau Linux.
Voila ! Vous je sais pas mais moi j’ai appris plein de choses ! 😉
Tout le code est disponible sous GPL2 et GPL2+ sur mon gitweb: jvdg_usbgadget.git
Pour le nom un peu égocentrique, c’était surtout pour éviter tout risque de conflit, comme de toutes façons ceci n’a pas vocation à être intégré dans Linux (le périphérique utilise un ID USB réservé aux prototypes, donc inutilisable en grande série…)
I’ve been more on software recently, and I didn’t blog much…
I’m still maintaining openchrome Xorg driver, not much to do now that the latest upstream SVN version is on KiBi’s X autobuild system. Except waiting for the bugs to occur.
I also just requested to become DM to release the X Strike Force of the task of sponsoring me…
After a rather awkward first message (still sorry about that), I started working on webalizer’s debian package.
Nothing’s published yet, but this will come.
Finally I received an email from Axel Beckert about xrootconsole, well he already blogged about it, I accepted to co-maintain xrootconsole with him. More details on my xrootconsole page.
To conclude, after some month following the debian community, I’m starting to feel part of it!
After some work here it is : netsed 1.00a !!
Basically this version is an architecture rewrite to add UDP support and remove the use of fork().
I’m pretty happy with the current feature set and code state so I think it will stay like that for a moment.
However feel free to test it and report bugs.
I’ve recently learned to use git (for my xorg adapted packages) and used it later for netsed.
In order to develop UDP in netsed, I had to try several stuff, my network programming experience in C is back to some school time, so this was really trial and errors. And here git really helps, all I had to do is create branches for each trial, so I don’t loose any tracks I’ve taken, then when I found the right way to do it, I could just merge or cherry pick from the branches (or even just copy past from gitk to my favorite editor gvim) and that was it !
Of course I can now delete the trial branches, but those were really helpful during development time.
This meant abusing of git commit --amend, git merge ( --squash ) and git cherry-pick commands, but well you cannot build a clean code without effort.
I should probably give another look at git stash which seams to fill similar needs.
Netsed, the network packet stream editor, is a program originally written by Michal Zalewski .
While the program idea is good, it’s implementation had some lack, and nobody seamed to care enough to fix it.
I did already hack it some years ago, and it appeared that my changes was fixing a debian RC bug (#586037) so I took netsed maintenance as one of my new projects!
For now only my changes and patches proposed by Mats Erik Andersson are integrated.
But I will start working on a test suite (still have to find the right tools for that, would ruby be nice ?), and of course implement UDP support.
Also I’d like to really thank Mats Erik Andersson and Tim Retout for their answers and support.
Resources:
À la suite des déboires d’hier, je viens de mettre à jours tous mes plugins.
Le changement des URI par le plugin Gengo, qui ajoutait les code des langues m’embarquait dans une redirection infinie (en ajoutant des fr+en/ à l’URI) j’ai du le désactiver. Mais ce faisant, j’ai cassé les URI existante de vos marque-pages (si vous en aviez) et surtout de Google…
Donc j’ai encore modifié gengo, maintenant les URI qui se terminent par un code de langue sont redirigé vers l’URI sans.
Une lecture récente: Cool URIs don’t change exprime ce besoin de conserver les URI, ici je redirige, c’est mieux que rien et vous évite le 404 😉
J’ai trouvé ce lien sur le Blog de Peter Eisentraut. Je lisait sont article a propos de Remove et Purge. Je fut séduit par l’idée, je l’ai même appliqué quelques jours. Puis j’ai lut les commentaires, j’en reste à la méthode l~c pour crée une vue dans aptitude 😉 . Par le passé, j’utilisais synaptic pour purger les résidus restant…
Trying to use zenphoto I found it does not have an option to have the admin tasks in https and the gallery in regular http.
WordPress is doing this and reading Rian’s article: SSL and Cookies in WordPress 2.6 I had a better idea on how it works.
Before coding, I also read How to Properly Provide Mixed HTTP and HTTPS Support from mikeperry’s blog.
And this is basically what I implemented.
For once the result of my work is not hosted on my blog but directly on zenphoto’s trac : The ticket with zenphoto patch to allow both http and https.