Inside an Open Source BIOS

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.
Continue reading

Open Source Bios at Scale

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.
Continue reading

From gengo to polylang: updating the theme

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:

    'en' => "English version:", 
    'fr' => "Version française : ");
function my_translations() {
    global $post;
    global $translation_title;
    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 !

From gengo to polylang: importing data

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 !

Building a custom debian CD

The French version was originally written for : Crée un CD d’installation d’une debian spécialisée.

The goal is to build a debian install CD suitable for the distribution of a complete system including the operating system and applications.

Debian already has a tool for that purpose: simple-cdd. Simple-cdd is a set of scripts wrapping debian-cd which is the tool used to build official CDs.

In our case, we will include some “non-free” packages (firmwares for instance) and application specific packages in the system.

Continue reading

Kernel develpoment on e60

Now that I have access to the serial console on Samsung e60 reader let’s build a new linux kernel for it.

The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don’t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung’s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don’t seam to embed homemade patches. As for ggc I didn’t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do).

Installing the cross-development toolchain on debian

First the archive keys:

sudo apt-get install emdebian-archive-keyring

Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:

deb lenny main
deb-src lenny main

The we update the package list to install the needed packages:

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

That’s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove.

The kernel sources

Samsung released it’s modified version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the version (the last in the branch).

In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones).

One particular point on those patches is that some include binary files:

  • fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don’t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB…
  • drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn’t check if Alan Stern’s name appears in the doc) but I’d have liked that Samsung give that source code.


Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let’s build the U-Boot released by Samsung, and let’s just copy the tools/mkimage to a location in our PATH (that’s the only install method I could find).

make smdkc100_config 
make CROSS_COMPILE=arm-linux-gnueabi-

cp tools/mkimage ~/bin/

Building linux

For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung’s config.

Finally we can compile!

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

We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:

sudo dnw arch/arm/boot/uImage

That’it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel.

Missing source code

The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let’s wait …


We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for and our kernel does not want to load them. (I’ve already done a few tests but that will be a next posts’ topic.)
But without the missing sources it will be hard for us to best use our e60 reader.

Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

Serial console on Samsung E60 reader

Thanks to some discounts last January in France, I got a Samsung E60 reader.

A community started around the french forum (e60 – and the google code (e60-open).

There are many information there especially on the serial console. I own an USB to serial adapter that uses LVTTL 3.3V signals (based on FTDI FT2232C) so I choose to connect on R232 and R233. But RXD (R232) is already connected to the MAX232 chip that shift LVTTL levels to serial levels, and it seams that this chip is styronger than my FTDI… So I removed R232 to connect me FTDI there. Remains to know on which PAD ? Luckily the first one I tried was the one: the one on the battery side.

A picture on my nice soldering:
E60 RS232 LVTTL 3.3V

That was it. I then followed the testing a kernel procedure thus loading the kernel image from the project’s SVN. And it worked ! (except that I had to unload the secbulk module, so it’s either me or it’s useless).

Next time, compiling and testing a Linux kernel.

Triage X Bugs of the Week (TXBW18)

Better later than never, I restarted to triage last week, here is the report for it.

  • #526095 ping & close – KVM switch change makes mouse stop working.
  • #495139 upstream – cleanlinks: warning in “find” usage.
  • #550308 ping – x11-apps: xedit search dialog shows garbage.
  • #555647 ping – x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt.

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.

Benchmarking microSD

First, I didn’t ask manufacturers for free cards to run my tests, so this test is not comprehensive. In fact I’m only comparing two cards!
My brother and I bought some microSD SDHC 16G cards: one from SanDisk and one from Kingstone. We picked branded cards to ensure we had good performances.

Testing method

I was trying to define my test procedures, like copying several kind of file, when I found this blog: MicroSD class 6 Performance Benchmarks. He is using a tool from the GNOME desktop: palimpsest.
Well this tool doesn’t want to test cards if it detects a partition table on it. The above blog proposed to erase the card with the following command:

dd if=/dev/zero of=/dev/sdb

Erasing an SD card that way is probably not a so good idea. Especially when you know that the “erased” state of a flash is with all bits set to 1, so writing 0 everywhere is more like filling than erasing…
But I didn’t had this thoughts when I ran the test, so I went with:

sync; date; sudo time dd if=/dev/zero of=/dev/sdb; sync; date

Calls to date gives a first write time estimate, but in fact, dd gives some statistics so it was really not necessary.

Then the test itself:

LANG=C palimpsest

Beware when choosing and USB port for a SDHC adapter, if your kernel traces (dmesg) shows the following line you need to pick another port!

not running at top speed; connect to a high speed hub

OK, enough blah …

The results

Kingston microSD 16G SDHC Class 4

dd results: 15997075456 bytes (16 GB) copied in 6491.87 s (1h48) or 2.5 MB/s.

Reading performance (blue line):

  • Minimum read rate: 18.6 MB/s
  • Maximum read rate: 20.9 MB/s
  • Average read rate: 18.9 MB/s

Writing performance (red line):

  • Minimum write rate: 1.7 MB/s
  • Maximum write rate: 4.7 MB/s
  • Average write rate: 2.4 MB/s

Average access time: 2.2ms (green line)

kingstone microSD 16G performance graph

SanDisk microSD 16G SDHC Classe 4

dd results: 15931539456 bytes (16 GB) copied en 4934.48 s (1h22) or 3.2 MB/s

Reading performance (blue line):

  • Minimum read rate: 20.6 MB/s
  • Maximum read rate: 21.1 MB/s
  • Average read rate: 21.0 MB/s

Writing performance (red line):

  • Minimum write rate: 1.3 MB/s
  • Maximum write rate: 5.7 MB/s
  • Average write rate: 2.4 MB/s

Average access time: 1.6ms (green line)

SanDisk microSD 16G performance graph


Those two cards are similar with a light advantage for the SanDisk one.