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.
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).
So I postponed hacking a mode with multiple languages on the same page and decided to set polylang on my production site (hem) my blog.
But Gengo was using some customized template tags so the theme was adapted to it and this needed to be changed.
With polylang it’s a lot simpler, all navigation is handled by filters, so only thing really custom had to be written:
Basically my hacked version of the_translations had to be ported. And to keep it simple it can even be part of the functions.php file in the theme and use the pll_the_languages function.
I want to display the other language title prefixed by “Language version” written in this language. As the gettext like functions would only return strings in the current language, I hardcoded those strings, but adding them in Polylang admin “strings translation” would have been nice…
So here is the code:
$translation_title=array(
'en' => "English version:",
'fr' => "Version française : ");
function my_translations() {
global $post;
global $translation_title;
$post_id=$post->ID;
if ( function_exists('pll_the_languages') ) {
$translations = pll_the_languages(array('post_id' => $post_id, 'hide_if_no_translation'=>1, 'hide_current'=>1, 'raw'=>1));
if(!empty($translations)) {
foreach($translations as $tr) {
$trid=pll_get_post($post_id, $tr['slug']);
?><li lang="<?php echo esc_attr($tr['slug']);?>"><?php echo $translation_title[$tr['slug']]; ?><a hreflang="<?php echo esc_attr($tr['slug']);?>" href="<?php echo esc_url($tr['url']);?>" rel="alternate"><?php echo get_the_title($trid); ?></a></li><?php
}
}
}
}
Instead of porting the old theme, I did build a new one based on WordPress’ Twenty Twelve updated with my previous header and dark color scheme.
I also played with a few css3 features for more neon light effects 🙂
And here it is !
As you might know, my blog is using gengo to enable translations.
But gengo is an old unmaintained plugin (I’m even running a custom version that I recently needed to fix again) so I’d like to migrate away.
Recently, I studied the available options (thanks to Multilingual WordPress page) and selected Polylang. This one seams to be what Gengo could have been with a rewrite: no extra database tables but using WP3 custom taxonomies. (I can’t find the message but I remember Pixline telling this would be the way to go, so…).
Anyway, I started to test Polylang, what it misses compared to Gengo, is the ability to really mix languages on the same page, so it will need some customizations before replacing Gengo here, but it will come.
It’s only a few days layer that I found the WPML to Polylang plugin.
This basically triggered the development of Gengo to Polylang a plugin to import translations informations from Gengo to Polylang.
It seams to work… I missed the Site Title and Tagline (but they are no longer translated on my blog so I don’t need it 😕 ) and I did take some shortcut for terms (tags & categories) that are the same in both languages.
UPDATE 2014-02-04: I fixed that as it caused the tag archive to contain both english and french posts so… also fixed the Title and Tagline part.
So if you still have a Gengo powered blog and want to migrate, the code could help you, but don’t just run it blindly, make a backup, setup a test instance and be prepared to hack the code ! You have been warned !
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.
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.
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.
Bon pour commencer, je n’ai pas demandé aux fabricants de m’offrir des cartes pour les tester, donc ce test est loin d’être exhaustif. En fait je ne compare que deux cartes !
Voila mon frère et moi avons acheté quelques cartes microSD SDHC 16G : une de marque SanDisk et une de marque Kingstone. Nous avons choisi des marques pour être à peu près sûrs d’avoir des performances correctes.
J’ai cherché à définir un protocole de test, copier des fichiers de différentes tailles… puis je suis tombé sur ce blog: MicroSD class 6 Performance Benchmarks. Il propose d’utiliser un outil présent dans le bureau GNOME: palimpsest.
Bon alors cet outil ne veut pas tester la carte si il y détecte une table des partitions, le blog cité précédemment propose d’effacer toute la flash avec la commande suivante:
dd if=/dev/zero of=/dev/sdb
Brutaliser de la sorte une carte SD n’est peut être pas ce qu’il y a de mieux à faire. Surtout quand l’on sait que l’état « effacé » d’une flash est avec tous ses bits à 1, écrire 0 partout revient en fait à la remplir plus qu’à l’effacer…
Mais bon j’y ai pas trop réfléchit quand j’ai fait le test, donc je suis parti la dessus:
sync; date; sudo time dd if=/dev/zero of=/dev/sdb; sync; date
Les appels à date permettent d’avoir une première estimation du temps d’écriture, en fait, dd donne aussi quelques statistiques donc c’était pas nécessaire.
Puis le test proprement dit:
LANG=C palimpsest
Attention au port USB utilisé pour le lecteur SDHC, si les traces du noyau (dmesg) contiennent la ligne suivante, il faut trouver un autre port !
not running at top speed; connect to a high speed hub
Bon, assez de blabla…
Résultats de dd: 15997075456 octets (16 GB) copiés en 6491,87 s (1h48) soit 2,5 MB/s.
Performance en lecture (courbe bleue):
Performance en écriture (courbe rouge):
Temps d’accès moyen: 2,2ms (courbe verte)
Résultats de dd: 15931539456 octets (16 GB) copiés en 4934,48 s (1h22) soit 3,2 MB/s
Performance en lecture (courbe bleue):
Performance en écriture (courbe rouge):
Temps d’accès moyen: 1,6ms (courbe verte)
Ces deux cartes se valent à peu prés, avec un léger avantage pour la carte SanDisk.