Mender: How to integrate an OTA updater

Recently, our customer Senic asked us to integrate an Over-The-Air (OTA) mechanism in their embedded Linux system, and after some discussion, they ended up chosing Mender. This article will detail an example of Mender’s integration and how to use it.

What is Mender?

Mender is an open source remote updater for embedded devices. It is composed of a client installed on the embedded device, and a management server installed on a remote server. However, the server is not mandatory as Mender can be used standalone, with updates triggered directly on the embedded device.

Image taken from Mender’s website

In order to offer a fallback in case of failure, Mender uses the double partition layout: the device will have at least 2 rootfs partitions, one active and one inactive. Mender will deploy an update on the inactive partition, so that in case of an error during the update process, it will still have the active partition intact. If the update succeeds, it will switch to the updated partition: the active partition becomes inactive and the inactive one becomes the new active. As the kernel and the device tree are stored in the /boot folder of the root filesystem, it is possible to easily update an entire system. Note that Mender needs at least 4 partitions:

  • bootloader partition
  • data persistent partition
  • rootfs + kernel active partition
  • rootfs + kernel inactive partition

It is, of course, customizable if you need more partitions.

Two reference devices are supported: the BeagleBone Black and a virtual device. In our case, the board was a Nanopi-Neo, which is based on an Allwinner H3.

Mender provides a Yocto Project layer containing all the necessary classes and recipes to make it work. The most important thing to know is that it will produce an image ready to be written to an SD card to flash empty boards. It will also produce “artifacts” (files with .mender extension) that will be used to update an existing system.

Installation and setup

In this section, we will see how to setup the Mender client and server for your project. Most of the instructions are taken from the Mender documentation that we found well detailed and really pleasant to read. We’ll simply summarize the most important steps.

Server side

The Mender server will allow you to remotely update devices. The server can be installed in two modes:

  • demo mode: Used to test a demo server. It can be nice to test it if you just want to quickly deploy a Mender solution, for testing purpose only. It includes a demo layer that simplify and configure for you a default Mender server on localhost of your workstation.
  • production mode: Used for production. We will focus on this mode as we wanted to use Mender in a production context. This mode allows to customize the server configuration: IP address, certificates, etc. Because of that, some configuration will be necessary (which is not the case in the demo mode).

In order to install the Mender server, you should first install Docker CE and Docker Compose. Have a look at the corresponding Docker instructions.


  • Download the integration repository from Mender:
  • $ git clone mender-server
  • Checkout 1.1.0 tag (latest version at the moment of the test)
  • $ cd mender-server
    $ git checkout 1.1.0 -b my-production-setup
  • Copy the template folder and update all the references to “template”
  • $ cp -a template production
    $ cd production
    $ sed -i -e 's#/template/#/production/#g' prod.yml
  • Download Docker images
  • $ ./run pull
  • Use the keygen script to create certificates for domain names (e.g. and
  • $ ../keygen
  • Some persistent storage will be needed by Mender so create a few Docker volumes:
  • $ docker volume create --name=mender-artifacts
    $ docker volume create --name=mender-deployments-db
    $ docker volume create --name=mender-useradm-db
    $ docker volume create --name=mender-inventory-db
    $ docker volume create --name=mender-deviceadm-db
    $ docker volume create --name=mender-deviceauth-db

Final configuration

This final configuration will link the generated keys with the Mender server. All the modifications will be in the prod.yml file.

  • Locate the storage-proxy service in prod.yml and set it to your domain name. In our case under the networks.mender.aliases
  • Locate the minio service. Set MINIO_ACCESS_KEY to “mender-deployments” and the MINIO_SECRET_KEY to a generated password (with e.g.: $ apg -n1 -a0 -m32)
  • Locate the mender-deployments service. Set DEPLOYMENTS_AWS_AUTH_KEY and DEPLOYMENTS_AWS_AUTH_SECRET to respectively the value of MINIO_ACCESS_KEY and MINIO_SECRET_KEY. Set DEPLOYMENTS_AWS_URI to point to your domain such as

Start the server

Make sure that the domain names you have defined ( and are accessible, potentially by adding them to /etc/hosts if you’re just testing.

  • Start the server
  • $ ./run up -d
  • If it is a new installation, request initial user login:
  • $ curl -X POST  -D - --cacert keys-generated/certs/api-gateway/cert.crt
  • Check that you can create a user and login to mender UI:
  •  $ firefox 

Client side – Yocto Project

Mender has a Yocto Project layer to easily interface with your own layer.
We will see how to customize your layer and image components (U-Boot, Linux kernel) to correctly configure it for Mender use.

In this section, we will assume that you have your own U-Boot and your own kernel repositories (and thus, recipes) and that you retrieved the correct branch of this layer.

Machine and distro configurations

  • Make sure that the kernel image and Device Tree files are installed in the root filesystem image
  • RDEPENDS_kernel-base += "kernel-image kernel-devicetree"
  • Update the distro to inherit the mender-full class and add systemd as the init manager (we only tested Mender’s integration with systemd)
  • # Enable systemd for Mender
    DISTRO_FEATURES_append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"
    VIRTUAL-RUNTIME_initscripts = ""
    INHERIT += "mender-full"
  • By default, Mender assumes that your storage device is /dev/mmcblk0, that mmcblk0p1 is your boot partition (containing the bootloader), that mmcblk0p2 and mmcblk0p3 are your two root filesystem partitions, and that mmcblk0p5 is your data partition. If that’s the case for you, then everything is fine! However, if you need a different layout, you need to update your machine configuration. Mender’s client will retrieve which storage device to use by using the MENDER_STORAGE_DEVICE variable (which defaults to mmcblk0). The partitions themselves should be specified using MENDER_BOOT_PART, MENDER_ROOTFS_PART_A, MENDER_ROOTFS_PART_B and ROOTFS_DATA_PART. If you need to change the default storage or the partitions’ layout, edit in your machine configuration the different variables according to your need. Here is an example for /dev/sda:
  • MENDER_STORAGE_DEVICE = "/dev/sda"
  • Do not forget to update the artifact name in your local.conf, for example:

    MENDER_ARTIFACT_NAME = "release-1"

As described in Mender’s documentation, Mender will store the artifact name in its artifact image. It must be unique which is what we expect because an artifact will represent a release tag or a delivery. Note that if you forgot to update it and upload an artifact with the same name as an existing in the web UI, it will not be taken into account.

U-Boot configuration tuning

Some modifications in U-Boot are necessary to be able to perform the rollback (use a different partition after an unsuccessful update)

  • Mender needs BOOTCOUNT support in U-Boot. It creates a bootcount variable that will be incremented each time a reboot appears (or reset to 1 after a power-on reset). Mender will use this variable in its rollback mechanism.
    Make sure to enable it in your U-Boot configuration. This will most likely require a patch to your board .h configuration file, enabling:
  • Remove environment variables that will be redefined by Mender. They are defined in Mender’s documentation.
  • Update your U-Boot recipe to inherit Mender’s one and make sure to provide U-Boot virtual package (using PROVIDES)
  • # Mender integration
    require recipes-bsp/u-boot/
    PROVIDES += "u-boot"
    RPROVIDES_${PN} += "u-boot"
    BOOTENV_SIZE = "0x20000"

    The BOOTENV_SIZE must be set the same content as the U-Boot CONFIG_ENV_SIZE variable. It will be used by the u-boot-fw-utils tool to retrieve the U-Boot environment variables.

    Mender is using u-boot-fw-utils so make sure that you have a recipe for it and that Mender include’s file is included. To do that, you can create a bbappend file on the default recipe or create your own recipe if you need a specific version. Have a look at Mender’s documentation example.

  • Tune your U-Boot environment to use Mender’s variables. Here are some examples of the modifications to be done. Set the root= kernel argument to use ${mender_kernel_root}, set the bootcmd to load the kernel image and Device Tree from ${mender_uboot_root} and to run mender_setup. Make sure that you are loading the Linux kernel image and Device Tree file from the root filesystem /boot directory.
    setenv bootargs 'console=${console} root=${mender_kernel_root} rootwait'
    setenv mmcboot 'load ${mender_uboot_root} ${fdt_addr_r} boot/my-device-tree.dtb; load ${mender_uboot_root} ${kernel_addr_r} boot/zImage; bootz ${kernel_addr_r} - ${fdt_addr_r}'
    setenv bootcmd 'run mender_setup; run mmcboot'

Mender’s client recipe

As stated in the introduction, Mender has a client, in the form of a userspace application, that will be used on the target. Mender’s layer has a Yocto recipe for it but it does not have our server certificates. To establish a connection between the client and the server, the certificates have to be installed in the image. For that, a bbappend recipe will be created. It will also allow to perform additional Mender configuration, such as defining the server URL.

  • Create a bbappend for the Mender recipe
  • FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
    SRC_URI_append = " file://server.crt"
  • Copy your server certificates in the bbappend recipe folder

Recompile an image and now, we should have everything we need to be able to update an image. Do not hesitate to run the integration checklist, it is really a convenient way to know if everything is correctly configured (or not).

If you want to be more robust and secure, you can sign your artifacts to be sure that they come from a trusted source. If you want this feature, have a look at this documentation.


Standalone mode

To update an artifact using the standalone mode (i.e. without server), here are the commands to use. You will need to update them according to your needs.

  • On your work station, create a simple HTTP server in your Yocto deploy folder:
  • $ python -m SimpleHTTPServer
  • On the target, start mender in standalone mode
  • $ mender -log-level info -rootfs

    You can also use the mender command to start an update from a local .mender file, provided by a USB key or SD card.

  • Once finished, you will have to reboot the target manually
  • $ reboot

    After the first reboot, you will be on the the new active partition (if the previous one was /dev/mmcblk0p2, you should be on /dev/mmcblk0p3). Check the kernel version, artifact name or command line:

    $ uname -a
    $ cat /etc/mender/artifact_info
    $ cat /proc/cmdline

    If you are okay with this update, you will have to commit the modification otherwise the update will not be persistent and once you will reboot the board, Mender will rollback to the previous partition:

    $ mender -commit

Using Mender’s server UI

The Mender server UI provides a management interface to deploy updates on all your devices. It knows about all your devices, their current software version, and you can plan deployments on all or a subset of your devices. Here are the basic steps to trigger a deployment:

  • Login (or create an account) into the mender server UI:
  • Power-up your device
  • The first time, you will have to authorize the device. You will find it in your “dashboard” or in the “devices” section.
  • After authorizing it, it will retrieve device information such as current software version, MAC address, network interface, and so on
  • To update a partition, you will have to create a deployment using an artifact.
  • Upload the new artifact in the server UI using the “Artifacts” section
  • Deploy the new artifact using the “deployment” or the “devices” section. You will retrieve the status of the deployment in the “status” field. It will be in “installing”, “rebooting”, etc. The board will reboot and the partition should be updated.


Here are some issues we faced when we integrated Mender for our device. The Mender documentation also has a troubleshooting section so have a look at it if you are facing issues. Otherwise, the community seems to be active even if we did not need to interact with it as it worked like a charm when we tried it.

Update systemd’s service starting

By default, the Mender systemd service will start after the service “resolved” the domain name. On our target device, the network was available only via WiFi. We had to wait for the wlan0 interface to be up and configured to automatically connect a network before starting Mender’s service. Otherwise, it leads to an error due to the network being unreachable. To solve this issue which is specific to our platform, we set the systemd dependencies to “” to be sure that a network is available:


It now matches our use case because the Mender service will start only if the wlan0 connection is available and working.

Certificate expired

The certificates generated and used by Mender have a validity period. In case your board does not have a RTC set, Mender can fail with the error:

systemctl status mender
... level=error msg="authorize failed: transient error: authorization request failed: failed to execute authorization request:
Post https:///api/devices/v1/authentication/auth_requests: x509: certificate has expired or is not yet valid" module=state

To solve this issue, update the date on your board and make sure your RTC is correctly set.

Device deletion

While testing Mender’s server (version 1.0), we always used the same board and got into the issue that the board was already registered in the Server UI but had a different Device ID (which is used by Mender to identify devices). Because of that, the server was always rejecting the authentication. The next release of the Mender server offers the possibility to remove a device so we updated the Mender’s server to the last version.

Deployments not taken into account

Note that the Mender’s client is checking by default every 30 minutes if a deployment is available for this device. During testing, you may want to reduce this period, which you can in the Mender’s configuration file using its UpdatePollIntervalSeconds variable.


Mender is an OTA updater for Embedded devices. It has a great documentation in the form of tutorials which makes the integration easy. While testing it, the only issues we got were related to our custom platform or were already indicated in the documentation. Deploying it on a board was not difficult, only some U-Boot/kernel and Yocto Project modifications were necessary. All in all, Mender worked perfectly fine for our project!

Zentera Systems, Inc.'s CoIP Security Enclave

On the heels of being crowned "Cool Vendor in Cloud Security" by Gartner, Zentera Systems, Inc., announced an upgrade to its flagship CoIP Security Enclave solution. more>>

Séminaire Aristote / CAP'TRONIC : What sort of thing is the Internet of Things ? - Palaiseau Le 12 décembre 2017

La vague IoT déferle sur la 4ème révolution industrielle : sommes-nous prêts à relever le défi ?

Séminaire Mardi 12 décembre 2017
à l'Ecole Polytechnique à Palaiseau, Amphithéâtre Becquerel


L'Internet des Objet , l'IoT… « IoT » ça « buzze » c'est la nouvelle Frontière de cette année 2017. Mais comme on le sait, une Nouvelle Frontière, cela peut être la découverte et l'exploration d'un nouveau monde, mais aussi un territoire flou ou fleurissent les villes champignons qui deviendront villes Fantômes, les chercheurs d'or, et ceux qui font fortune en vendant le matériel et les divertissements.

Loin de nous de comparer les acteurs de l'écosystème « IoT » à des vendeurs d'illusion, mais au-delà du mot balise, il est bon de le mettre en perspective. Quoi de nouveau dans les architectures bout en bout applicatives, quoi de différent par rapport au traditionnel « machine to machine » dans l'IoT en cette fin 2017 ?

Cet Internet des « choses » ce ne sont pas seulement des objets (smartphones, PC, Tablettes, capteurs, tensiométres, caméras…) mais aussi leur connectivité : connectivité aux réseaux, entre objets, aux clouds et aux systèmes de Deep Tech (nom amusant qu'on trouvé les marketeux lassés du Data Mining et de l'Intelligence Artificielle). Ce sont aussi de nouveaux services, dans tous les domaines fonctionnels et, le MINEFI l'espère, potentiellement de nouvelles productions industrielles en France.

Le rôle d'une association savante comme Aristote et d'un animateur d'écosystème technologique comme OpticsValley est de permettre aux acteurs de celui-ci de donner leur vision de l'Internet of Things, leur place ou leur niche dans ces nouvelles architectures de services et de produits, de présenter les solutions disponibles en terme de connectivité (5G, LorAWAn, protocoles IP, NbIot, Sigfox) et leurs avantages et inconvénients respectifs en fonction des contraintes de déploiement, des performances attendues, des coûts et de la disponibilité.

Ce sera l'objet du séminaire du séminaire de sortir du buzzword pour aller vers le concret :
« What sort of thing is the Internet of Things ? »

Programme :

- 09h00-09h30 : Accueil & café

- 09h30-09h40 : Présentation de la journée
Paul Stéfanut - Opticsvalley

- 09h40-10h10 : IoT Blockchain pour une économie numérique décentralisée
Stefan Sundermann - Kalima Systems

- 10h10-10h40 : Réaliser les promesses de l'IoT grâce à l'apprentissage de modèles prédictifs individuels et explicables
Clodéric Mars - craft ai

- 10h40-11h10 : Du capteur au supercalculateur : un projet de capteurs mobiles pour l'analyse de la qualité de l'air
François Bodin - IRISA

- 11h10-11h30 : Pause café

- 11h30-12h00 : Internet des objets : un enjeu analytique pour les organisations Mouloud Dey - SAS Analytics for IoT

- 12h00-12h30 : Design, innovation & IoT
Jean-Louis Frechin - No Design

- 12h30-13h00 : Vers des aéronefs connectés par liaison optique
Béatrice Sorrente - ONERA

- 13h00-14h30 : Déjeuner buffet au salon d'Honneur

- 14h30-15h00 : IoT industriel : retours sur 10 années d'expérience SUEZ avec la télérelève longue portée
Hugues Haeffner - SUEZ

- 15h00-15h30 : Routes intelligentes : repenser le rapport aux infrastructures pour créer de nouvelles sources de valeur et optimiser l'impact environnemental
Cécile Villette - Altaroad

- 15h30-15h50 : Pause café

- 15h50-16h20 : Objets connectés : quelle protection des données et apport pour la sécurité ?
Myriam Quéméner - Ministère de l'Intérieur

- 16h20-16h50 : Projets IoT dans l'industrie : 10 vraies questions à se poser Emmanuel Cox - SNCF

- 16h50-17h20 : Modélisation, IoT et l'Analytics, au service de l'efficience et de la compétitivité
Jacques Bourgain - GA-MM

- 17h20-17h30 : Conclusions avec la salle
Bertrand Lapraye - Opticsvalley

Participation aux frais

- Gratuit pour les membres Aristote

- Payant pour les non membres : 60 € par chèque à l'ordre de l'Association Aristote. Pour vous inscrire, cliquez-ici

- CAP'TRONIC vous offre la possibilité de prendre en charge vos frais de participation
(offre réservée uniquement pour les 12 premières PME inscrites - 1 personne par entreprise)
Pour cela, nous vous remercions de remplir le formulaire ci-dessous, une confirmation vous sera envoyée.

Contacts :

Contact séminaire : Samuel EVAIN- 06 33 38 41 04 -
Contact inscription : Céline GONCALVES - 01 69 08 93 47 -

Lieu de l'événement :

Amphithéâtre Becquerel, Ecole Polytechnique, Palaiseau

Back from ELCE: selection of talks from the Free Electrons team

As discussed in our previous blog post, Free Electrons had a strong presence at the Embedded Linux Conference Europe, with 7 attendees, 4 talks, one BoF and one poster during the technical show case.

In this blog post, we would like to highlight a number of talks from the conference that we found interesting. Each Free Electrons engineer who attended the conference has selected one talk, and gives his/her feedback about this talk.

uClibc Today: Still Makes Sense – Alexey Brodkin

Talk selected by Michael Opdenacker

uClibc Today: Still Makes Sense – Alexey BrodkinAlexey Brodkin, an active contributor to the uClibc library, shared recent updates about this C library, trying to show people that the project was still active and making progress, after a few years during which it appeared to be stalled. Alexey works for Synopsys, the makers of the ARC architecture, which uClibc supports.

If you look at the repository for uClibc releases, you will see that since version 1.0.0 released in 2015, the project has made 26 releases according to a predictable schedule. The project also runs runtime regression tests on all its releases, which weren’t done before. The developers have also added support for 4 new architectures (arm64 in particular), and uClibc remains the default C library that Buildroot proposes.

Alexey highlighted that in spite of the competition from the musl library, which causes several projects to switch from uClibc to musl, uClibc still makes a lot of sense today. As a matter of fact, it supports more hardware architectures than glibc and musl do, as it’s the only one to support platforms without an MMU (such as noMMU ARM, Blackfin, m68k, Xtensa) and as the library size is still smaller that what you get with musl (though a static hello_world program is much smaller with musl if you have a close look at the library comparison tests he mentioned).

Alexey noted that the uClibc++ project is still alive too, and used in OpenWRT/Lede by default.

Read the slides and watch the video of his talk.

Identifying and Supporting “X-Compatible” hardware blocks – Chen-Yu Tsai

Talk selected by Quentin Schulz

Identifying and Supporting “X-Compatible” hardware blocks – Chen-Yu TsaiAn SoC is made of multiple IP blocks from different vendors. In some cases the source or model of the hardware blocks are neither documented nor marketed by the SoC vendor. However, since there are only very few vendors of a given IP block, stakes are high that your SoC vendor’s undocumented IP block is compatible with a known one.

With his experience in developing drivers for multiple IP blocks present in Allwinner SoCs and as a maintainer of those same SoCs, Chen-Yu first explained that SoC vendors often either embed some vendors’ licensed IP blocks in their SoCs and add the glue around it for platform- or SoC-specific hardware (clocks, resets and control signals), or they clone IP blocks with the same logic but some twists (missing, obfuscated or rearranged registers).

To identify the IP block, we can dig into the datasheet or the vendor BSP and compare those with well documented datasheets such as the one for NXP i.MX6, TI KeyStone II or the Zynq UltraScale+ MPSoC, or with mainline drivers. Asking the community is also a good idea as someone might have encountered an IP with the same behaviour before and can help us identify it quicker.

Some good identifiers for IPs could be register layouts or names along with DMA logic and descriptor format. For the unlucky ones that have been provided only a blob, they can look for the symbols in it and that may slightly help in the process.

He also mentioned that identifying an IP block is often the result of the developer’s experience in identifying IPs and other time just pure luck. Unfortunately, there are times when someone couldn’t identify the IP and wrote a complete driver just to be told by someone else in the community that this IP reminds him of that IP in which case the work done can be just thrown away. That’s where the community plays a strong role, to help us in our quest to identify an IP.

Chen-Yu then went on with the presentation of the different ways to handle the multiple variants of an IP blocks in drivers. He said that the core logic of all IP drivers is usually presented as a library and that the different variants have a driver with their own resources, extra setup and use this library. Also, a good practice is to use booleans to select features of IP blocks instead of using the ID of each variant.
For IPs whose registers have been altered, the way to go is usually to write a table for the register offsets, or use regmaps when bitfields are also modified. When the IP block differs a bit too much, custom callbacks should be used.

He ended his talk with his return from experience on multiple IP blocks (UART, USB OTG, GMAC, EMAC and HDMI) present in Allwinner SoCs and the differences developers had to handle when adding support for them.

Read the slides and watch the video of his talk.

printk(): The Most Useful Tool is Now Showing its Age – Steven Rostedt & Sergey Senozhatsky

Talks selected by Boris Brezillon. Boris also covered the related talk “printk: It’s Old, What Can We Do to Make It Young Again?” from the same speakers.

printk(): The Most Useful Tool is Now Showing its Age – Steven Rostedt & Sergey SenozhatskyMaybe I should be ashamed of saying that but printk() is one of the basic tool I’m using to debug kernel code, and I must say it did the job so far, so when I saw these presentations talking about how to improve printk() I was a bit curious. What could be wrong in printk() implementation?
Before attending the talks, I never digged into printk()’s code, because it just worked for me, but what I thought was a simple piece of code appeared to be a complex infrastructure with locking scheme that makes you realize how hard it is when several CPUs are involved.

At its core, printk() is supposed to store logs into a circular buffer and push new entries to one or several consoles. In his first talk Steven Rostedt walked through the history of printk() and explained why it became more complex when support for multi CPU appeared. He also detailed why printk() is not re-entrant and the problem it causes when called from an NMI handler. He finally went through some fixes that made the situation a bit better and advertised the 2nd half of the talk driven by Sergey Senozhatsky.

Note that between these two presentations, the printk() rework has been discussed at Kernel Summit, so Sergey already had some feedback on his proposals. While Steven presentation focused mainly on the main printk() function, Sergey gave a bit more details on why printk() can deadlock, and one of the reasons why preventing deadlocks is so complicated is that printk() delegates the ‘print to console’ aspect to console drivers which have their own locking scheme. To address that, it is proposed to move away from the callback approach and let console drivers poll for new entries in the console buffer instead, which would remove part of the locking issues. The problem with this approach is that it brings even more uncertainty on when the logs are printed on the consoles, and one of the nice things about printk() in its current form is that you are likely to have the log printed on the output before printk() returns (which helps a lot when you debug things).

He also mentioned other solutions to address other possible deadlocks, but I must admit I got lost at some point, so if you’re interested in this topic I recommend that you watch the video (printk(): The Most Useful Tool is Now Showing its Age, sadly no video is available for the second talk) and read the slides (printk(): The Most Useful Tool is Now Showing its Age and printk: It’s Old, What Can We Do to Make It Young Again?).

More robust I2C designs with a new fault-injection driver – Wolfram Sang

Talk selected by Miquèl Raynal

More robust I2C designs with a new fault-injection driver – Wolfram SangAlthough Wolfram had a lot of troubles starting its presentation lacking a proper HDMI adaptater, he gave an illuminating talk about how, as an I2C subsystem maintainer, he would like to strengthen the robustness of I2C drivers.

He first explained some basics of the I2C bus like START and STOP conditions and introduced us to a few errors he regularly spots in drivers. For instance, some badly written drivers used a START and STOP sequence while a “repeated START” was needed. This is very bad because another master on the bus could, in this little spare idle delay, decide to grab the medium and send its message. Then the message right after the repeated START would not have the expected effect. Of course plenty other errors can happen: stalled bus (SDA or SCL stuck low), lost arbitration, faulty bits… All these situations are usually due to incorrect sequences sent by the driver.

To avoid so much pain debugging obscure situations where this happens, he decided to use an extended I2C-gpio interface to access SDA and SCL from two external GPIOs and this way forces faulty situations by simply pinning high or low one line (or both) and see how the driver reacts. The I2C specification and framework provide everything to get out of a faulty situation, it is just a matter of using it (sending a STOP condition, clocking 9 times, operate a reset, etc).

Wolfram is aware of his quite conservative approach but he is really scared about breaking users by using random quirks so he tried with this talk to explain his point of view and the solutions he wants to promote.

Two questions that you might have a hard time hearing were also interesting. The first person asked if he ever considered using a “default faulty chip” designed to do by itself this kind of fault injection and see how the host reacts and behaves. Wolfram said buying hardware is too much effort for debugging, so he was more motivated to get something very easy and straightforward to use. Someone else asked if he thought about multiple clients situation, but from Wolfram’s point of view, all clients are in the same state whether the bus is busy or free and should not badly behave if we clock 9 times.

Watch the video and grab the slides.

HDMI 4k Video: Lessons Learned – Hans Verkuil

Talk selected by Maxime Ripard

HDMI 4k Video: Lessons Learned – Hans VerkuilHaving worked recently on a number of display related drivers, it was quite natural to go see what I was probably going to work on in a quite close future.

Hans started by talking about HDMI in general, and the various signals that could go through it. He then went on with what was basically a war story about all the mistakes, gotchas and misconceptions that he encountered while working on a video-conference box for Cisco. He covered the hardware itself, but also more low-level oriented aspects, such as the clocks frequencies needed to operate properly, the various signals you could look at for debugging or the issues that might come with the associated encoding and / or color spaces, especially when you want to support as many displays as you can. He also pointed out the flaws in the specifications that might lead to implementation inconsistencies. He concluded with the flaws of various HDMI adapters, the issues that might arise using them on various OSes, and how to work around them when doable.

Watch the video and the slides.

The Serial Device Bus – Johan Hovold

Talk selected by Thomas Petazzoni

The Serial Device Bus – Johan HovoldJohan started his talk at ELCE by exposing the problem with how serial ports (UARTs) are currently handled in the Linux kernel. Serial ports are handled by the TTY layer, which allows user-space applications to send and receive data with what is connected on the other side of the UART. However, the kernel doesn’t provide a good mechanism to model the device that is connected at the other side of the UART, such as a Bluetooth chip. Due to this, people have resorted to either writing user-space drivers for such devices (which falls short when those devices need additional resources such as regulators, GPIOs, etc.) or to developing specific TTY line-discipline in the kernel. The latter also doesn’t work very well because a line discipline needs to be explicitly attached to a UART to operate, which requires a user-space program such as hciattach used in Bluetooth applications.

In order to address this problem, Johan picked up the work initially started by Rob Herring (Linaro), which consisted in writing a serial device bus (serdev in short), which consists in turning UART into a proper bus, with bus controllers (UART controllers) and devices connected to this bus, very much like other busses in the Linux kernel (I2C, SPI, etc.). serdev was initially merged in Linux 4.11, with some improvements being merged in follow-up versions. Johan then described in details how serdev works. First, there is a TTY port controller, which instead of registering the traditional TTY character device will register the serdev controller and its slave devices. Thanks to this, one can described in its Device Tree child nodes of the UART controller node, which will be probed as serdev slaves. There is then a serdev API to allow the implementation of serdev slave drivers, that can send and receive data of the UART. Already a few drivers are using this API: hci_serdev, hci_bcm, hci_ll, hci_nokia (Bluetooth) and qca_uart (Ethernet).

We found this talk very interesting, as it clearly explained what is the use case for serdev and how it works, and it should become a very useful subsystem for many embedded applications that use UART-connected devices.

Watch the video and the slides.

GStreamer for Tiny Devices – Olivier Crête

Talk selected by Grégory Clement

GStreamer for Tiny Devices – Olivier CrêteThe purpose of this talk was to show how to shrink Gstreamer to make it fit in an embedded Linux device. First, Olivier Crête introduced what GStreamer is, it was very high level but well done. Then after presenting the issue, he showed step by step how he managed to reduce the footprint of a GStreamer application to fit in his device.

In a first part it was a focus on features specific to GStreamer such as how to generate only the needed plugins. Then most of the tricks showed could be used for any C or C++ application. The talk was pretty short so there was no useless or boring part Moreover, the speaker himself was good and dynamic.

To conclude it was a very pleasant talk teaching step by step how to reduce the footprint of an application being GStreamer or not.

Watch the video and the slides.

Sysadmin 101: Patch Management

A few articles ago, I started a Sysadmin 101 series to pass down some fundamental knowledge about systems administration that the current generation of junior sysadmins, DevOps engineers or "full stack" developers might not learn otherwise. I had thought that I was done with the series, but then the WannaCry malware came out and exposed some of the poor patch management practices still more>>

Mise à jour Over-The-Air de systèmes embarqués

Avec l’expansion de l’Internet des Objets, le nombre de systèmes intelligents connectés est en constante augmentation. Suivant leur application, ces objets connectés sont souvent très nombreux et hors de notre portée. Déployer des mises à jour manuellement via un accès physique peut donc devenir un véritable challenge en terme de temps et de coût.

Or, le déploiement de mise à jour est une partie essentielle dans la vie d’un système embarqué, que ce soit pour ajouter de nouvelles fonctionnalités, corriger des bugs ou des failles de sécurité. Un des exemples de ce besoin est l’attaque Mirai Botnet découverte en août 2016, qui consistait à s’introduire dans des systèmes Linux connectés en utilisant des noms d’utilisateurs et des mots de passe très répandus dans l’industrie. Le choix des identifiants d’accès doit donc être effectué de manière sûre et sécurisée.

La distribution de logiciels Over-The-Air (OTA) offre un moyen de mettre à jour tout un parc d’appareils à distance de manière sécurisée. Dans un tel écosystème, les objets à mettre à jour ne sont pas capables de refuser une mise à jour correcte ou de l’altérer. Voici un exemple de procédure générique pour mettre à jour un système embarqué en utilisant une méthode OTA (selon :

Source :

D’après ce schéma, trois entités distinctes interviennent dans le processus de mise à jour. Nous allons trouver dans un premier temps un système de génération des différents logiciels. Ces machines disposent souvent d’une grande puissance de calcul, surtout lorsqu’il s’agit de générer des logiciels lourds tels que des images de systèmes d’exploitation. Ce système générera les différents artefacts permettant de mettre à jour les objets connectés. La compilation peut être lancée soit manuellement par un opérateur, soit automatiquement via un outil d’intégration continue. Ces artefacts sont ensuite téléchargés sur un serveur de gestion de mises à jour qui est régulièrement interrogé par les objets connectés. Une fois ces mises à jour en ligne, les objets peuvent les télécharger et les installer.

Rentrons maintenant plus en détail dans le processus d’installation. Une fois les mises à jour détectées, des tests sont effectués afin de savoir si elles sont compatibles avec les logiciels déjà présents sur l’appareil. Si ces tests sont validés, les mises à jour sont téléchargées, puis l’intégrité et l’origine des mises à jour sont vérifiées. Elles sont ensuite décompressées sur le disque de l’appareil (les paquets sont très souvent compressés afin de sauvegarder de la bande passante lors des transferts). Les nouveaux logiciels sont enfin installés et des étapes de pré/post-installation peuvent aussi être faites. Cette chaîne d’installation peut être résumée par le schéma suivant :

Source :

Nous noterons que d’après ce diagramme, tout système de mise à jour OTA doit être capable de détecter une mise à jour et la télécharger de manière sécurisée, de l’installer et vérifier si l’installation est réussie. S’il y a eu un problème lors de l’installation, le système doit pouvoir revenir à un état dans lequel une nouvelle tentative peut être effectuée. Il est avant tout nécessaire de laisser le système dans un état où il peut démarrer normalement.

Rappelons que dans la plupart des systèmes Linux, nous retrouverons les éléments suivants pouvant entrer en ligne de compte dans un contexte de mise à jour :

  • le bootloader
  • le kernel et les fichiers Device Tree (DT)
  • le système de fichiers racine (rootfs)
  • d’autres systèmes de fichiers montés après la racine
  • des logiciels spécifiques à une application

En règle générale, la mise à niveau d’un système Linux consiste à mettre à jour le kernel et le rootfs (et plus rarement le bootloader).


Stratégies de mise à jour

Mise à jour via un gestionnaire de paquets

Toutes les distributions Linux pour PC sont mises à jour avec un gestionnaire de paquets. Cependant, cette méthode comporte un certain nombre d’inconvénients quand il s’agit de systèmes embarqués. En effet, les logiciels des systèmes embarqués sont généralement prévus pour fonctionner sur une plateforme en particulier. Les images Linux s’exécutant sur ces systèmes forment donc un tout. On peut dire qu’elles constituent un ensemble indivisible. Or, en utilisant un gestionnaire de paquets, notre image ne possède plus ce caractère indivisible et devient plutôt une liste de paquets plus ou moins indépendants. Dès lors, il est plus compliqué de s’assurer qu’une librairie dans une certaine version n’engendre aucun conflit avec les autres paquets (et éventuels patchs) déjà installés. De plus, si le système redémarre au milieu de l’installation d’un paquet (coupure de courant par exemple), comment peut-on savoir que le paquet n’a pas été correctement installé pour pouvoir le réinstaller plus tard ? Tous ces inconvénients peuvent facilement rendre le système embarqué inopérationnel.


Mise à jour via un bootloader

La fonction principale d’un bootloader est de charger et démarrer un kernel. Cependant, la plupart sont dotés de fonctionnalités plus sophistiquées. Ils ont très souvent un interpréteur de lignes de commandes (shell) qui peut être utilisé via un périphérique d’entrée/sortie (liaison série par exemple). De plus, ils sont dotés d’un système de script qui permet à l’utilisateur de personnaliser leur comportement et ainsi d’implémenter un système de mise à jour compacte.

La conception d’un tel système au sein d’un bootloader peut cependant être une tâche difficile. Les bootloaders n’ont en effet qu’un support minimal des périphériques. Leur rôle principal étant de charger un kernel (qui possède en général un très bon support matériel), on consacre peu de temps au développement et à l’intégration de drivers. De plus, les drivers intégrés aux bootloaders sont peu voire pas du tout mis à jour, alors que leurs équivalents dans les kernels évoluent assez régulièrement. Certaines fonctionnalités peuvent donc présenter des failles de fonctionnement.


Mise à jour via une application

Une autre solution à envisager est de confier la responsabilité de la mise à jour à une application du système. A l’inverse d’un script exécuté par le bootloader, cette application bénéficierait de tous les services offerts par le système d’exploitation sous-jacent. Suivant le besoin du client et les ressources matérielles disponibles sur le système embarqué, plusieurs types de mise à jour peuvent être envisagés.


Mise à jour symétrique

Dans le mode de mise à jour symétrique, deux copies du rootfs, A et B, sont initialement installées. Dans un premier temps, le bootloader démarre le système contenu dans le rootfs A. Quand une mise à jour est disponible (et que tous les tests de vérification sont faits), la mise à jour est téléchargée et installée sur le rootfs B. Si l’installation se termine avec succès, l’application informe le bootloader de démarrer sur le rootfs B fraîchement mis à jour. Si par contre l’installation a échoué, le rootfs actif reste le rootfs A.

Ce système de mise à jour est extrêmement sûr : il assure qu’à tout moment le système est doté d’un logiciel fonctionnel, mais pas forcement à jour, avec toutefois la possibilité de le mettre à niveau plus tard. Des mécanismes de sécurité supplémentaires peuvent être mis en place : par exemple, si le système échoue à se mettre à jour pour la troisième fois consécutive, un opérateur est prévenu pour inspecter l’objet connecté.

Cependant, le défaut majeur de ce mode est l’espace mémoire de masse nécessaire, puisque deux rootfs complets sont constamment stockés.


Mise à jour asymétrique

Dans le mode de mise à jour asymétrique, nous disposons toujours de deux partitions. Cependant, seulement une des deux contient le rootfs. La seconde partition, généralement beaucoup plus petite, contient un système spécialisé dans la mise à jour du rootfs. Nous appellerons le système principal M (main) et le système de mise à jour U (update). Pour lancer une mise à jour du rootfs M, un redémarrage sur le système U est nécessaire. Ensuite, U télécharge la mise à jour et l’installe sur M. Une fois l’installation terminée, le système redémarre sur M.

Cette méthode possède quelques inconvénients : tout d’abord, contrairement à la mise à jour symétrique, si la mise à jour échoue, l’objet connecté n’est plus opérationnel, bien qu’il soit encore possible de le mettre à jour. Ensuite, la mise à jour requiert deux redémarrages, ce qui peut être gênant pour des applications critiques où le système embarqué ne peut rester inopérationnel qu’un court laps de temps.

D’un autre côté, la mise à jour asymétrique permet d’économiser une grande quantité de mémoire. Le kernel et le rootfs du système U sont généralement petits et peuvent être chargés intégralement en RAM via un initrd ou un initramfs. Il est également possible de compresser le kernel et le rootfs U ensemble, ce qui peut augmenter considérablement le ratio de compression et donc économiser encore plus d’espace.


Problématiques de sécurité

Dans beaucoup de domaines, la sécurité est un enjeu majeur, et la mise à jour de systèmes connectés ne fait pas exception. Cette application requiert d’ailleurs une attention toute particulière au niveau des moyens utilisés pour assurer la sécurité des mises à jour. Les objets connectés sont en effet très souvent connectés à un réseau, voire à Internet. Les paquets circulant sur ce réseau peuvent donc être interceptés, ce qui inclut les données échangées lors du processus de mise à jour. Il est donc impératif d’utiliser des outils de mise à jour et une infrastructure qui interdit à toute entité non-autorisée de venir lire et modifier les paquets de mise à jour. Ceci peut être effectué de deux manières : utiliser un canal de communication sécurisé pour transmettre les mises à jour (connexion HTTPS par exemple) et/ou signer les mises à jour pour que l’objet valide leur source. Il est bien entendu plus sûr de combiner ces deux méthodes afin de réduire les risques de piratage.

Nous nous intéresserons particulièrement au mécanisme de signature des mises à jour. Une signature numérique permet de garantir l’intégrité d’un document et d’en authentifier l’auteur. Le processus de signature est le suivant :

  • les données à signer sont passées dans une fonction de hachage. Il en ressort une empreinte binaire
  • cette empreinte est ensuite chiffrée en utilisant une clé privée conservée par le signataire, l’empreinte chiffrée est appelée signature
  • cette signature est adjointe aux données puis envoyée au destinataire
  • une fois les données reçues, le destinataire calcule leur empreinte en utilisant une fonction de hachage
  • parallèlement, il déchiffre la signature avec la clé publique que le signataire lui a confiée, pour obtenir l’empreinte envoyée par l’émetteur
  • si les deux empreintes sont les mêmes, l’intégrité et l’origine des données sont confirmées

Le process peut être illustré par la figure suivante :


Plusieurs algorithmes peuvent être utilisés dans ce type de mécanisme, selon la fonction à réaliser et les performances souhaitées. Ainsi, pour le hachage des données nous pourrons utiliser SHA-2 ou SHA-3 (Secure Hash Algorithm), il est déconseillé d’utiliser SHA-1 étant donné que cet algorithme présente des failles de sécurité connues. Pour le chiffrement, il est possible d’utiliser RSA avec des clés d’une longueur de 2048 bits ou plus. Pour ce qui est de la confiance dans les clés échangées, il existe deux types de méthodes : des méthodes décentralisées comme PGP (Pretty Good Privacy) basées sur la transitivité de la confiance (les amis de mes amis sont mes amis) où les clés sont échangées de proche en proche, et les méthodes centralisées dites PKI (Public Key Infrastructure) dans lesquelles les certificats seront attribués par des autorités spécifiques, capables de signer et révoquer les certificats.


Comparatif de trois solutions de mise à jour

Un certain nombre de solutions de mise à jour OTA ont été conçues ces dernières années. Nous nous intéresserons dans cette partie à trois d’entre elles, qui semblent faire partie des solutions open-source les plus populaires.



Comme l’indique l’équipe de Mender sur son site web, le but de ce projet est de participer à la sécurisation des objets connectés en leur fournissant un processus de mise à jour simple et robuste. Dans son utilisation, Mender est en effet assez simple. L’intégrateur aura seulement besoin d’ajouter sa couche BSP (Board Support Package) spécifique au matériel utilisé, ainsi que la configuration du client de mise à jour. La compilation nécessite cependant l’utilisation de Yocto, ce qui peut perturber les non-initiés (la compilation reste possible sans Yocto mais semble plus complexe).

Mender est livré avec un mécanisme de rollback intégré (retour en arrière lorsqu’une installation échoue) ce qui est un véritable avantage pour ce système. Généralement, cette fonctionnalité requiert un moyen de communiquer avec le bootloader, et à l’heure actuelle Mender ne supporte que le bootloader U-boot.

Un serveur est également fourni par Mender. Il implémente tout le mécanisme de transmission des mises à jour. En utilisant ce serveur, la sécurité est aussi renforcée puisque la communication entre le client et le serveur ne peut se faire qu’en utilisant le protocole HTTPS. Il est également possible de recevoir les mises à jour depuis d’autres sources telles qu’un système de fichier local (clé USB par exemple) ou depuis une URL. Mender insistant grandement sur la sûreté de leur mise à jour, il ne propose qu’un mécanisme de mise à jour symétrique, ce qui permet d’offrir la fonctionnalité de rollback.

D’autre part, la structure de Mender impose un minimum de 4 partitions sur le disque du client : une partition de démarrage, 2 partitions rootfs (mise à jour symétrique), et une partition de données pour les fichiers de configuration de Mender notamment. Il est aussi nécessaire de réserver un espace mémoire supplémentaire pour stocker les rootfs reçus lors des mises à jour.



Swupdate est également un projet offrant à des appareils embarqués exécutant un système Linux la capacité de se mettre à jour. A l’inverse de Mender, Swupdate est considéré comme un framework, apportant tous les outils nécessaires pour effectuer des mises à jour, dans lequel d’autres protocoles d’installation peuvent être ajoutés afin de personnaliser le processus et le faire correspondre plus facilement à nos besoins. Il peut être utilisé avec Yocto, Buildroot, ou bien compilé et installé sur un rootfs manuellement.

Comme pour Mender, les mises à jour peuvent être récupérées depuis un serveur distant (avec une connexion sécurisée type HTTP(s)) ou depuis un média connecté localement. Swupdate est capable d’interagir avec un logiciel d’interface permettant de communiquer avec un serveur Hawkbit (serveur de mise à jour écrit en Java faisant partie du projet Eclipse). Swupdate embarque également un serveur Web (optionnel) sur lequel il est possible de se connecter pour transférer les mises à jour et les installer. Les deux stratégies de mises à jour asymétrique et symétrique présentées plus haut sont toutes les deux nativement supportées. Il est aussi possible de ne mettre à jour qu’un seul fichier parmi tout le système de fichier, là où Mender nous oblige à écraser tout un rootfs. De plus, Swupdate supporte les bootloaders GRUB et U-boot.

Comme mentionné plus haut, il est possible de personnaliser l’installation des mises à jour. Ceci est effectué de deux manières : avec des scripts de pré/post-installation, ainsi qu’avec des scripts plus spécifiques, appelés ‘handlers’ permettant d’ajouter un installateur pour un type d’image ou de matériel non supporté nativement (par exemple mettre à jour un microcontrôleur via une liaison série).

Ainsi, Swupdate offre une certaine flexibilité mais apporte en contrepartie quelques difficultés d’intégration. L’un des points notables est la nécessité de concevoir soi-même le mécanisme de retour en arrière (rollback) qui n’est pas intégré par défaut. Swupdate propose sur leur dépôt Github un ensemble de recettes Yocto pour Raspberry Pi 3 et BeagleBone incluant un exemple de script shell assurant la fonctionnalité de rollback.



Rauc, au même titre que Swupdate, se veut être un cadre de travail sur lequel on vient greffer les éléments que l’on désire. Dans cette optique, Rauc va assez loin puisqu’il propose une totale personnalisation du logiciel et ce via plusieurs aspects.

Premièrement, Rauc possède un module d’interface pour les bootloaders les plus courants (U-boot, Grub, Barebox) que l’on peut facilement remplacer par une interface personnalisée. Il est ainsi possible de supporter n’importe quel bootloader du moment que le système d’exploitation est capable de discuter avec lui. Rauc supporte les mises à jour asymétrique et symétrique, et le partitionnement du disque est totalement libre (choix du nombre de rootfs, partitions data indépendantes ou rattachées à un rootfs, etc).

Deuxièmement, il est possible de modifier le comportement de Rauc au niveau de la mise à jour en ajoutant des scripts de pré/post-installation comme Swupdate, mais aussi des scripts d’installation, ce qui a comme conséquence de totalement modifier la procédure de mise à jour. Ces scripts sont appelés ‘handlers’. Ils sont stockés sur le client et exécutés pour toutes les mises à jour reçues.

Enfin, le dernier niveau de personnalisation se fait au niveau des paquets des mises à jour. Rauc offre la possibilité d’y insérer des scripts appelés cette fois ‘hooks’ (crochets) qui s’appliquent donc pour une mise à jour spécifique. Il est aussi possible de concevoir des ‘hooks’ s’exécutant pour un ‘slot’ en particulier (un ‘slot’ étant un emplacement mémoire susceptible d’être mis à jour).

Les sources des mises à jour sont multiples, allant du média local au serveur distribuant les paquets de mises à jour. Rauc dispose d’ailleurs d’une interface D-Bus, qu’il est possible d’utiliser depuis des clients chargés de communiquer avec un serveur spécifique. Rauc met à disposition un client Hawkbit utilisant cette interface D-Bus. Cependant, il est écrit en python et nécessite d’embarquer l’interpréteur sur le système de fichiers, ce qui est assez coûteux en terme d’espace mémoire. Il est cependant possible de réécrire ce client aisément en C/C++. Si cette interface-là n’est pas utilisée, Rauc est le système de mise à jour le plus léger et le plus flexible parmi les trois étudiés. Son intégration peut être effectuée avec Yocto, PTXDist ou bien manuellement. Avec Yocto, l’intégrateur aura à ajouter sa couche BSP bien sûr, mais aura aussi à écrire quelques recettes supplémentaires et notamment une recette de configuration de Rauc et une recette de création des paquets de mise à jour (bundles). Contrairement à Swupdate et Mender, il n’existe pas à ce jour de meta-layer d’exemple pour Rauc.


Tableau comparatif

Le tableau ci-dessous récapitule les différentes fonctionnalités proposées par chacun de ces trois systèmes de mise à jour OTA. Une colonne est aussi réservée pour OSTree, un autre système d’OTA dont l’utilisation est similaire à celle de Git.

Comparatif Systèmes OTA
  Mender Swupdate Rauc OSTree (non testé)
Site web
License Apache-2.0 GPL-2.0 LGPL-2.1 LGPL-2.0
Système de build Yocto (meta-mender) Yocto (meta-swupdate, meta-swupdate-boards)
Yocto (meta-rauc)
Yocto (meta-updater)
Type de mise à jour supporté Symétrique Symétrique et asymétrique Symétrique et asymétrique  Symétrique
Origine de la mise à jour Locale (ex : clé USB)
Distante (depuis une URL ou le serveur ‘mender-integration’)
Locale (ex : clé USB)
Distante (requête HTTP(S) ou un serveur dédié comme Hawkbit)
Locale (ex : clé USB)
Distante (depuis une URL ou un serveur dédié comme Hawbit)
Dépôt local et distant
Fichiers à mettre à jour Tout (rootfs+kernel) Flexible Flexible Tout (rootfs+kernel)
Structure du disque Au moins 4 partitions (boot, rootfsA, rootfsB, data) Flexible (rootfs A/B, initramfs, partition de recovery …) Flexible (rootfs A/B, initramfs, partition de recovery …) Flexible
Taille du binaire du client (Rpi) 4400ko 400ko 102ko 650ko
Bootloaders supportés U-boot Grub
Sécurité (installation) Rollback intégré Pas de rollback intégré (exemple disponible pour U-boot dans meta-swupdate-boards) Pas de rollback intégré (exemple disponible pour U-boot et Grub sur le dépôt de Rauc) Rollback intégré
Sécurité (communication) HTTPS obligatoire HTTPS possible HTTPS, SSH, … (tous ceux supportés par libcurl)  HTTPS possible
Sécurité (images) Images signées (RSA 3072+, ECDSA avec P-256) Images signées (RSA, CMS) et cryptées (AES-256/CBC) Images signées (x509) Commits signés (GPG)
Difficulté d’intégration Facile (support
BSP et config
de mender)
Moyenne (à faire avec yocto : BSP, recette pour intégrer le rollback, recette pour créer les packages de mise à jour) moyenne (à faire avec yocto : BSP, recette pour intégrer le rollback, recette pour créer les packages de mise à jour, recette pour intégrer Rauc-Hawkbit si utilisé)  N/A
Modularité Pre/post-install scripts
State scripts (plus flexibles)
Pre/post-install scripts
Handlers (ajout de support pour l’installation d’image)
Handlers (pre-install, install, post-install)
Hooks (applicables à toute les phases du process de màj)
API coté serveur Requêtes HTTPS (RESTful API) Dépend du serveur
Avec hawkbit : librairies en Java
Dépend du serveur
Avec hawkbit : librairies en Java
Avec le projet pulp (plugin dispo pour ostree)
API coté client Requêtes HTTPS (RESTful API) Librairie en C utilisant les sockets UNIX Outil CLI ou interface D-Bus Outil CLI ressemblant à git ou librairie en C
Support!forum/mender!forum/swupdate  N/A


Exemple de configuration de système de mise à jour OTA

Afin d’avoir un exemple d’utilisation d’un système de mise à jour OTA, lançons-nous dans un petit cas d’étude. Nous allons mettre au point une petite application ‘Hello World’ qui se contentera d’afficher dans un terminal le message ‘Hello world from X.Y’ où X.Y représente la version actuelle du logiciel. Afin de déployer la mise à jour, nous nous appuierons sur un client Rauc ainsi que sur un serveur Hawkbit. Nous utiliserons le projet Yocto/OpenEmbedded pour compiler nos images. La plateforme utilisée dans ce déploiement est une Raspberry Pi modèle 1 B+. Le système de mise à jour devra être symétrique, l’image devra donc contenir deux rootfs et les mettre à jour alternativement. Un rootfs sera sur la partition /dev/mmcblk0p2 et l’autre sur /dev/mmcblk0p3.

Avant de rentrer dans le vif du sujet, il est important de dire quelques mots sur le projet Yocto. Sur le site, Yocto est défini comme étant un projet open-source collaboratif qui met a disposition des templates, des outils et des méthodes pour créer des distributions logicielles basées sur Linux destinées aux systèmes embarqués.

Dans un projet utilisant Yocto, les différents composants formant le système Linux sont définis par des recettes (‘recipes’) qui définissent comment les compiler et les installer sur le système de fichier cible. Ces recettes sont ensuite regroupées en couche (‘layers’) en fonction de leur champ d’application. Par exemple, le layer meta-raspberrypi contient toutes les recettes nécessaires à l’exécution du système Linux sur Raspberry Pi. Afin de générer le système, nous faisons appel à Bitbake. Ce logiciel écrit en Python représente le ‘chef cuisinier’ de Yocto : il examine toutes les recettes incluses dans notre projet, puis construit et installe les paquets correspondants. L’avantage principal de Yocto est qu’il gère la compilation croisée ainsi qu’une multitude de plateformes cibles.

Pour avoir plus d’informations à propos de Yocto, n’hésitez pas à consulter l’article ‘Yocto : comprendre BitBake’ sur le blog Linux Embedded.


Application de test

Notre application ‘Hello world’ est très simple. Elle peut être écrite sous la forme suivante :

#include <stdio.h>

int main(void) { 
    printf("Hello world v1.0 !\r\n"); 
    return 0; 

Pour simuler une mise à jour du logiciel, nous viendrons juste modifier le numéro de version affiché.
Pour intégrer ce programme dans Yocto, il faut simplement fournir une recette indiquant comment compiler et installer le binaire :

do_compile() { 
    ${CC} ${THISDIR}/files/helloworld.c -o hello ${LDFLAGS}  

do_install() { 
    install -d ${D}${bindir} 
    install -m 0755 hello ${D}${bindir} 


Configuration de Rauc

La configuration de Rauc se fait par un fichier appelé system.conf. Ce fichier doit contenir un certain nombre d’entrées. Pour notre cas d’utilisation, le fichier présenté ci-dessous est suffisant :






Notre image sera identifiée par la chaîne contenue dans l’entrée ‘compatible’. Ainsi, une mise à jour de type ‘RpiHello’ ne pourra être effectuée que sur des systèmes compatibles ‘RpiHello’. Nous affectons aussi le bootloader à la valeur ‘uboot’.

Dans la section ‘keyring’ se trouve le chemin vers le certificat une fois installé sur la cible.

Les deux partitions à mettre à jour sont décrites par des sections ‘slots’. Chaque slot doit contenir le nom de l’appareil, son type (nous choisissons ici le format ext4) ainsi qu’un nom qui sera utilisé dans un script s’occupant de faire le basculement de rootfs.

Afin que ce fichier system.conf soit pris en compte par Yocto, vous devrez faire une recette dans votre layer (dans recipes-core) comportant notamment les éléments suivants :

├── files/
│   ├── ca.cert.pem
│   ├──
│   └── system.conf
└── rauc_%.bbappend

Le fichier rauc_%bbappend devra contenir l’emplacement des différents fichiers contenus dans files/ et ajouter leur installation sur le système de fichier :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI_append := "file://system.conf \
                   file://ca.cert.pem \
                   file:// \

do_install_append () {
install -d ${D}${libdir}/rauc
install -m 0755 ${WORKDIR}/ ${D}${libdir}/rauc/

Par défaut Rauc ne redémarre pas le système à la fin d’une mise à jour. Il est donc nécessaire de faire appel à un script de post-installation dans lequel nous programmons un redémarrage système.

La génération du fichier ca.cert.pem sera expliquée dans la partie suivante.


Génération des clés et des certificats

Afin d’assurer la sécurité de nos mises à jour, il est nécessaire d’utiliser un système de certificat qui permet de vérifier l’intégrité et l’authenticité des données transmises avec les mises à jour. Dans ce but Rauc dispose d’un script,,  qui s’occupe de générer les différents certificats et clés de chiffrement. Vous trouverez ce script dans meta-rauc/scripts/.

Pour l’exécuter, créez un dossier à l’emplacement de votre choix (pas nécessairement dans Yocto), puis exécutez ce script depuis ce dossier. Un sous-dossier ‘openssl-ca/’ est généré avec l’arborescence suivante :

├── dev/
│   ├── ca.cert.pem
│   ├── ca.csr.pem
│   ├── certs/
│   │   ├── 01.pem
│   │   └── 02.pem
│   ├── development-1.cert.pem
│   ├── development-1.csr.pem
│   ├── index.txt
│   ├── index.txt.attr
│   ├── index.txt.attr.old
│   ├── index.txt.old
│   ├── private/
│   │   ├── ca.key.pem
│   │   └── development-1.key.pem
│   ├── serial
│   └── serial.old
└── openssl.cnf

Les fichiers qui nous intéressent sont en rouge.

Afin de pouvoir signer et vérifier les mises à jour, vous aurez à :

  • Copier le certificat ‘ca.cert.pem’ dans le dossier ‘recipes-core/rauc/files/’
  • Créer une autre recette appelée ‘bundles’ qui permettra de générer les archives contenant tous les fichiers/rootfs mis à jour et y copier les fichiers development-1.cert.pem et private/development-1.key.pem. Vous devrez avoir les fichiers suivants dans cette recette :
    ├── files/
    │   ├── development-1.cert.pem
    │   └── development-1.key.pem

    Le fichier doit définir au minimum les variables suivantes :

    inherit bundle
    RAUC_BUNDLE_SLOTS = "rootfs"
    RAUC_SLOT_rootfs = "core-image-minimal"
    RAUC_SLOT_rootfs[fstype] = "ext4"
    RAUC_KEY_FILE = "${THISDIR}/files/development-1.key.pem"
    RAUC_CERT_FILE = "${THISDIR}/files/development-1.cert.pem"


Configuration du client Rauc-Hawkbit

Pour que le client Rauc puisse communiquer avec un serveur Hawkbit, il est nécessaire de mettre en place une passerelle entre ces deux systèmes. Ce logiciel est fournit par Rauc et téléchargeable à l’adresse Il est écrit en python (3.x) et nécessite donc d’inclure l’interpréteur python sur le système embarqué. Cependant, ce client Hawkbit ne fait que se servir de l’interface dbus de Rauc et envoyer des requêtes HTTP(s) au serveur. Il est donc possible de le réécrire en C/C++ si la taille mémoire est un enjeux important dans votre application.

Configurer ce client n’est pas chose aisée. Il n’existe aucun layer ou recette Yocto qui nous faciliterait son intégration. Si vous voulez l’utiliser dans votre projet, il va vous falloir concevoir quelques recettes. Voici les étapes les plus importantes :

  • créer une recette héritant de setuptool3 (pour installer des modules python3), qui télécharge Rauc-Hawkbit depuis Github et qui installe sur l’image le fichier de configuration du client Hawkbit :
    hawkbit_server = votre_ip:votre_port
    ssl = false
    ca_file =
    tenant_id = DEFAULT
    target_name = test-target
    auth_token = ahVahL1Il1shie2aj2poojeChee6ahShu
    mac_address = ff:ff:ff:ff:ff:ff
    bundle_download_location = /tmp/bundle.raucb
    log_level = debug

    Un point important à noter est que Hawkbit requiert un identifiant unique (target_name) pour chaque appareil. Or au moment de la compilation de l’image, nous ne sommes pas en mesure de donner un quelconque identifiant (il en va de même pour l’adresse mac qui est fixée à ff:ff:ff:ff:ff:ff). En effet, l’image peut être potentiellement flashée sur des milliers de systèmes embarqués. Si nous fixions les identifiants maintenant, ils seraient les mêmes pour tous ces systèmes.
    Un moyen de contourner ce problème est d’exécuter un script au démarrage de la machine qui construit un identifiant unique (en utilisant l’adresse MAC de l’interface eth0 par exemple), puis remplace dans le fichier de configuration l’identifiant par défaut par l’identifiant tout juste construit. Voici un exemple de script qui pourrait remplir ce rôle :

    MAC=$(echo $(ip addr show eth0 | grep link/ | awk '{ print $2}'))
    grep -l 'target_name = *' /etc/rauc-hawkbit.cfg | xargs sed -i "s/test-target/rpihello_$MAC/"
  • créer une recette pour intégrer gbulb à Yocto. Gbulb est un module python qui, à la date de rédaction de cet article, ne dispose pas de recette Yocto. Cette recette pourrait être organisée de la manière suivante :
    └── python/

    Avec les fichiers suivants :

    recipes-devtools/python/ :

    SUMMARY = "Gbulb"
    HOMEPAGE = ""
    LICENSE = "Apache-2.0"
    LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/Apache-2.0;md5=89aea4e17d99a7cacdbeed46a0096b10"
    inherit pypi
    SRC_URI[md5sum] = "bf3f2f1de2606f1310111e3479cc52d2"
    SRC_URI[sha256sum] = "5e40bf0354f3fc31d1a5e701dae6afc96f1a1bb432ce44de2d2ad3e62ce6e173"
    RDEPENDS_${PN} += " \
                       ${PYTHON_PN}-asyncio \
                       ${PYTHON_PN}-pygobject \

    recipes-devtools/python/ :

    inherit setuptools3
  • créer un service systemd pour que le client Hawkbit s’exécute au démarrage du système. Pour cela, il est nécessaire de créer une recette qui hérite de systemd et qui se charge d’installer deux fichiers sur l’image : le script à exécuter ainsi que le ‘unit file’ (fichier *.service). Il serait même approprié de mettre dans le script de démarrage les quelques lignes de code qui permettent de déterminer un identifiant unique.


Déploiement de la mise à jour

Une fois toutes les recettes créées, vous pouvez compiler l’image et la flasher sur votre système embarqué. Comme mentionné plus haut, pour faire une mise à jour de notre application de test, nous incrémentons le numéro de version affiché. Il suffit alors de recompiler l’image et de télécharger le bundle généré par Rauc (fichier *.raucb) sur votre serveur Hawkbit. Ce transfert peut se faire directement depuis l’interface graphique dont voici un aperçu :

Avant le téléchargement, il vous est demandé de créer un ‘Software module’. On peut créer autant de modules que l’on a de logiciels différents à mettre à jour. Dans le cadre de notre étude, nous nous contentons de créer un seul module dont le logiciel à mettre à jour est le rootfs entier. Il vous faut aussi créer une distribution à laquelle vous affectez tous les software modules représentant les logiciels appartenant à cette distribution.

Les cibles à mettre à jour peuvent être sélectionnées via un système de filtres. Dans notre cas, nous pouvons avoir un parc de Raspberry Pi dotées de l’application Hello dont l’identifiant est de la forme rpihello_<adresse_mac>. Ainsi, nous créons un filtre qui donne les appareils dont le nom est de la forme ‘rpihello_*’.

Une fois cela fait, il suffit d’aller dans l’onglet ‘Rollout’ pour créer un nouveau déploiement. Sélectionnez la nouvelle distribution à flasher, le filtre, les différents modes de mise à jour (instantanée, action requise sur le client, planification, etc).



Utilisés depuis plusieurs années dans la téléphonie mobile, les mécanismes de mise à jour Over-The-Air deviennent de plus en plus utilisés dans les domaines des systèmes embarqués et de l’Internet des Objets. Les problématiques de fiabilité et de sécurité en sont les enjeux majeurs. Concernant la mise à jour de systèmes Linux, plusieurs solutions existent. Chacune d’elle apporte ses avantages et ses inconvénients, offrant ainsi une plus ou moins grande flexibilité au prix d’une certaine complexité dans la configuration de ce système. Il est important de choisir sa solution en faisant attention à toutes ses fonctionnalités, afin qu’elle réponde au mieux aux besoins de notre application.

pfSense: Not Linux, Not Bad

Through the years, I've used all sorts of router and firewall solutions at home and at work. For home networks, I usually recommend something like DD-WRT, OpenWRT or Tomato on an off-the-shelf router. For business, my recommendations typically are something like a Ubiquiti router or a router/firewall solution like Untangled or ClearOS. more>>

NETGEAR 48-Port Gigabit Smart Managed Plus Switch (GS750E)

More than ever, small to mid-sized businesses demand and rely on their networks to carry out mission-critical business activities. As always, however, budgets and expertise constrain these companies from using complex managed switches to run their networks. more>>

La CAO ou routage de cartes électroniques : des recommandations, des outils - Talence (33) Le 7 décembre 2017

La CAO (conception assisté par ordinateur) est devenue nécessaire dans tous les domaines pour modéliser numériquement un objet. En électronique, on parle de routage de cartes pour la conception d'un circuit imprimé ou PCB (Printed Circuit Board).
Après une présentation qui abordera les bonnes pratiques et les « règles de routage », des logiciels vous seront présentés : un gratuiciel, Kicad distribué par RS et deux logiciels professionnels, Altium aux possibilités énormes, et enfin Ultiboard/Mulstisim.

La rencontre aura lieu à l'amphithéâtre de l'IMS sous la forme d'un exposé/question de manière interactive, il n'y aura pas de TP mais des démonstrations et les pauses auront lieu à l'IMS.

Cette journée s'articulera autour d'un exemple commun aux 3 outils comportant :
- La création d'un composant,
- La saisie de l'empreinte,
- Le contournement du PCB et le routage.

Des spécialistes vous exposeront les points forts et les faiblesses de ces outils pour que vous puissiez choisir le plus adapté à vos besoins et à vos moyens.


14:00 - 1h : Présentation par Philippe Simon de SERMA Technologies
- Quelques conseils et recommandations sur le routage de cartes électroniques afin de réussir la fabrication de la carte et l'industrialisation.

15:00 - 45mn : Logiciel ALTIUM (Olivier NEGRO)
- Présentation de l'environnement (schéma + PCB)

15 :45 - 45mn : Logiciel MULTISIM (Martial LEYNEY)
- Présentation de l'environnement (schéma + PCB)

16 :30 - 15mn : Café

16 :45 - 45mn : Logiciel KICAD (Jacques BAILLARGEAT)
- Présentation de l'environnement (schéma + PCB)

17 :30 - Bilan et besoins en journée thématiques

CIF et Radiospares pour une Tombola à la clôture de la journée


Personnes concernées : Ingénieurs, concepteurs de cartes électroniques

Lieu : IMS – Amphithéâtre - Bât A31 - 351 Cours de la Libération - 33405 TALENCE CEDEX

Date : Jeudi 07 décembre 2017 de 14h00 à 17h30

Prix : Gratuit - les frais liés à l'organisation de ce séminaire sont pris en charge par CAP'TRONIC.

Contact : Thierry ROUBEIX - -

Inscription obligatoire

Hackable n°21 est chez votre marchand de journaux !

La rentrée est passée, les vacances sont loin, et le froid fait son retour… Quoi de mieux alors que de se réchauffer à la douce chaleur du fer à souder et de faire travailler son cerveau tout en découvrant de nouveaux horizons ? Pour ce faire, voici donc venir votre dose régulière de nutriments pour vos neurones et vos petits doigts agiles sous la forme du dernier numéro de Hackable.

Le sujet principal de cette 21ème édition concernera le fabuleux ESP8266, ce petit module disposant d’une connectivité Wifi et fonctionnant peu ou prou comme une carte Arduino super-vitaminée. Longtemps révolu est le temps où il fallait bidouiller pour charger un croquis dans la mémoire des premières versions de ces modules (les ESP-01). Il est, depuis quelque temps,  possible de trouver ces cartes pour quelques euros, incluant tout le nécessaire pour rapidement les mettre en oeuvre et les programmer via l’environnement Arduino, tout aussi facilement que n’importe quelle autre carte (UNO, Zero, Mini, Mega, etc.).

La connectivité Wifi ouvre des possibilités furieusement intéressantes et, avec un peu d’imagination, des approches « exotiques » à certains problèmes peuvent être envisagées. C’est précisément le cas qui est traité en choisissant de considérer un lieu physique comme un site web. À travers l’utilisation d’un capteur de mouvement infrarouge (PIR), cet article détaille comment détecter la présence de personnes (voire d’animaux) et envoyer cette information à une solution de suivi de trafic pour un site : Google Analytics.

Nombre de détections, heures d’affluence, zones plus fréquentées que d’autres… deviennent ainsi des informations très similaires à celles d’un site web ou d’une boutique en ligne et peuvent être gérées et présentées de la même façon.

Mais ce numéro ne se résume, bien entendu pas à ce simple article, nous y parlerons également de tests de composants (ou plutôt de tests de testeur de composants), de bidouilles vestimentaires, de protocoles réseaux, l’alimentation par couplage inductif pour vos projets, d’anciennes technologies ou encore de descente en pratique dans les méandre du fonctionnement d’un ordinateur 8 bits.

  • Équipement
    • p. 04 Un testeur universel de composants pour 15€ ?
  • Ardu’n’co
    • p. 04 Utilisez un Minitel comme écran pour votre Arduino
    • p. 26 Fabriquez votre T-shirt interactif avec un Lilypad Arduino
    • p. 38 OTA : programmez votre ESP8266 en Wifi !
  • En couverture
    • p. 48 Utilisez Google Analytics pour la surveillance physique
  • Embarqué & Informatique
    • p. 60 mDNS ou comment retrouver facilement votre Pi
  • Tensions & Courants
    • p. 72 Utilisez une alimentation sans fil pour vos projets
  • Démontage, Hacks & Récup
    • p. 82 Créez votre ordinateur 8 bits sur platine à essais : la mémoire

Ce numéro 21 de Hackable est d’ores et déjà disponible chez votre marchand de journaux et dans notre boutique en ligne. Le sommaire du numéro (et l’édito) sont par ici.

New Hope for Digital Identity

Identity is personal. You need to start there.

In the natural world where we live and breathe, personal identity can get complicated, but it's not broken. If an Inuit family from Qikiqtaaluk wants to name their kid Anuun or Issorartuyok, they do, and the world copes. If the same kid later wants to call himself Steve, he does. Again, the world copes. So does Steve. more>>

DivvyCloud Platform for VMware Cloud on AWS

DivvyCloud's unique niche in the IT ecosystem is helping organizations automate and manage their multi-cloud infrastructure at scale. more>>

Slicing Scientific Data

I've covered scientific software in previous articles that either analyzes image information or actually generates image data for further analysis. In this article, I introduce a tool that you can use to analyze images generated as part of medical diagnostic work. more>>

Linux Journal November 2017

Arrogance, the Biggest Linux Security Problem

Linux is no longer an obscure platform avoided by those with malicious intent. more>>

PoE, PoE+ and Passive POE

I've been installing a lot of POE devices recently, and the different methods for providing power over Ethernet cables can be very confusing. There are a few standards in place, and then there's a method that isn't a standard, but is widely used.

802.3af or Active PoE: more>>

Professionnels, consultez en ligne les derniers numéros de vos magazines favoris et leurs archives !

CONNECT est la plateforme de lecture en ligne des Éditions Diamond. Les magazines GNU/Linux MagazineMISCLinux Pratique et Hackable, disponibles en kiosque et sur y ont chacun leur propre univers dans lequel sont publiés leurs derniers numéros et hors-séries thématiques.

La page d’accueil de CONNECT affiche par défaut les articles des publications actuellement en kiosque.

Plusieurs milliers d’articles

Avec GNU/Linux MagazineMISCLinux Pratique et Hackable, CONNECT réunit le meilleur de la documentation technique liée à l’open source, Linux, la programmation, la sécurité informatique, l’électronique ou encore l’embarqué… La plateforme rassemble à ce jour plusieurs milliers d’articles issus aussi bien de nos publications actuellement en kiosque que de nos archives.

Un affichage par numéro

Dernière fonctionnalité en date : l’accès par numéro qui permet de retrouver en un rien de temps tout le contenu publié à la périodicité de son choix avec le sommaire des articles et la couverture du numéro en question.

CONNECT permet d’accéder en un clic aux articles publiés dans le numéro de son choix. On retrouve ici la date de publication du titre, sa couverture ainsi qu’un sommaire cliquable des articles le composant.

Le bloc « Accès par numéro » affiche sous forme d’infobulle la principale thématique (sujet des hors-séries et de l’article en couverture des numéros standards) traitée par chaque numéro au survol de la souris.

Une infobulle s’affiche au survol de la souris sur chaque numéro permettant de consulter le sujet principal traité dans le magazine.

Un accès par domaine

CONNECT permet en un clic d’afficher les articles couvrant un domaine en particulier.

CONNECT propose un affichage des articles par domaine. Dans notre exemple, nous avons choisi d’afficher les articles catégorisés dans le domaine « embarqué ».

Parmi les thématiques qu’il est possible d’approfondir ainsi, on peut trouver la sécurité informatique, le code, l’électronique, l’embarqué, le réseau, les tests et prises en main, l’intelligence artificielle, le système, le droit, les témoignages, etc.

Le bloc « Accès par domaine » est accessible depuis les pages d’accueil de toutes les publications et permet de filtrer l’affichage des articles selon la thématique de son choix. Les domaines catégorisés dans les articles sont également cliquables.

Un filtrage par auteur

Sur CONNECT, les auteurs de chaque article sont cliquables, ce qui permet de retrouver facilement le style et l’expertise de ses auteurs favoris dans tous les contenus qu’ils ont rédigés.

Un clic sur un auteur va lister l’ensemble des articles qu’il a rédigé.

Un outil de recherche

CONNECT propose évidemment un outil de recherche qui permettra de trouver tous les articles correspondant au plus près à ses besoins. Les recherches effectuées pourront porter sur l’ensemble des publications ou uniquement sur celle(s) de son choix. Les résultats pourront également être ciblés par domaines et dans certains cas par tags.

Les résultats des recherches – l’exemple porte ici sur le mot-clé « VPN » –, peuvent être filtrés par publication, domaine et tag.

Et bien plus encore…

Profiter d’un sommaire cliquable de chaque article, copier-coller du code, afficher dans un nouvel onglet les sites référencés dans les articles ou encore pouvoir évaluer ces derniers, comptent au nombre des autres fonctionnalités disponibles.

Bon à savoir : l’abonnement à la plateforme de lecture en ligne CONNECT pourra être personnalisé en fonction du nombre de personnes composant son équipe grâce à nos diverses formules.

Comment ça marche ?

Galit Shmueli et al.'s Data Mining for Business Analytics (Wiley)

The updated 5th edition of the book Data Mining for Business Analytics from Galit Shmueli and collaborators and published by Wiley is a standard guide to data mining and analytics that adds two new co-authors and a trove of new material vis-á-vis its predecessor. more>>

Back from Kernel Recipes: slides and videos

As we announced previously, we participated to the Embedded Recipes and Kernel Recipes conferences in September in Paris. Three people from Free Electrons attended the event: Free Electrons CEO Michael Opdenacker, and Free Electrons engineers Mylène Josserand and Maxime Ripard.

Introduction to Yocto Project / OpenEmbedded, by Mylène Josserand

Mylène Josserand gave an Introduction to the Yocto Project / OpenEmbedded-core. The slides are available in PDF or as LaTeX code.

An introduction to the Linux DRM subsystem, by Maxime Ripard

Maxime Ripard gave an Introduction to the Linux DRM subsystem. The slides are available in PDF or as LaTeX code.

Other videos and slides

The slides of all talks are available on the Embedded Recipes and Kernel Recipes conference websites. Youtube playlists are available for Embedded Recipes 2017 and Kernel Recipes 2017 as well.


With its special one track format, an attendance limited to 100 people, excellent choice of talks and nice social events, Kernel Recipes remains a very good conference that we really enjoyed. Embedded Recipes, which was in its first edition this year, followed the same principle, with the same success. We’re looking forward to attending next year editions, and hopefully contributing a few talks as well. See you all at Embedded and Kernel Recipes in 2018!

Sécurisez votre infrastructure Linux !

La sécurité est au coeur du nouveau hors-série de GNU/Linux Magazine ! Vous découvrirez en effet dans ce numéro spécial quels moyens mettre en oeuvre pour sécuriser votre infrastructure Linux. Au menu des différents chapitres proposés : la protection de votre réseau, le renforcement de la protection de votre système, le filtrage de vos accès web ainsi que les tests de sécurité et réactions en cas d’incident. Ce guide vous attend dès à présent en kiosque, sur la boutique et sur notre plateforme de lecture en ligne Connect.

Au sommaire

Débutez : Protégez votre réseau avec un firewall nftables ou ModSecurity

p. 08 Filtrez votre réseau avec nftables

p. 22 Protégez-vous avec ModSecurity, le pare-feu web open source

Système : Durcissez la protection de votre système avec OpenSCAP et AuditD

p. 36 Sécuriser un serveur CentOS dès l’installation : une histoire de serpent et de SCAL^HP

p. 54 Journalisez les actions de vos utilisateurs avec AuditD

Infrastructure serveur : Filtrez les accès web avec Dansguardian et vos mails avec MailScanner

p. 74 Créez votre passerelle anti-SPAM multicouche avec Postfix, Postgrey, et MailScanner

p. 94 Filtrez et limitez l’accès au Web avec Dansguardian

Audit / Pentest : Effectuez des tests de sécurité et apprenez à réagir en cas d’incident

p. 112 Petit cours de R.I.E.N.

p. 110 Utilisez des scanners de réseau et de vulnérabilités

Sécurisez votre infrastructure Linux !

La sécurité est au coeur du nouveau hors-série de GNU/Linux Magazine ! Vous découvrirez en effet dans ce numéro spécial quels moyens mettre en oeuvre pour sécuriser votre infrastructure Linux. Au menu des différents chapitres proposés : la protection de votre réseau, le renforcement de la protection de votre système, le filtrage de vos accès web ainsi que les tests de sécurité et réactions en cas d’incident. Ce guide vous attend dès à présent en kiosque, sur la boutique et sur notre plateforme de lecture en ligne Connect.

Au sommaire

Débutez : Protégez votre réseau avec un firewall nftables ou ModSecurity

p. 08 Filtrez votre réseau avec nftables

p. 22 Protégez-vous avec ModSecurity, le pare-feu web open source

Système : Durcissez la protection de votre système avec OpenSCAP et AuditD

p. 36 Sécuriser un serveur CentOS dès l’installation : une histoire de serpent et de SCAL^HP

p. 54 Journalisez les actions de vos utilisateurs avec AuditD

Infrastructure serveur : Filtrez les accès web avec Dansguardian et vos mails avec MailScanner

p. 74 Créez votre passerelle anti-SPAM multicouche avec Postfix, Postgrey, et MailScanner

p. 94 Filtrez et limitez l’accès au Web avec Dansguardian

Audit / Pentest : Effectuez des tests de sécurité et apprenez à réagir en cas d’incident

p. 112 Petit cours de R.I.E.N.

p. 110 Utilisez des scanners de réseau et de vulnérabilités

Analyzing Song Lyrics

I was reading about the history of The Beatles a few days ago and bumped into an interesting fact. According to the author, The Beatles used the word "love" in their songs more than 160 times. At first I thought, "cool", but the more I thought about it, the more I became skeptical about the figure. In fact, I suspect that the word "love" shows up considerably more than 160 times. more>>

Back from ELCE 2017: slides and videos

Free Electrons participated to the Embedded Linux Conference Europe last week in Prague. With 7 engineers attending, 4 talks, one BoF and a poster at the technical showcase, we had a strong presence to this major conference of the embedded Linux ecosystem. All of us had a great time at this event, attending interesting talks and meeting numerous open-source developers.

Free Electrons team at the Embedded Linux Conference Europe 2017

Free Electrons team at the Embedded Linux Conference Europe 2017. Top, from left to right: Maxime Ripard, Grégory Clement, Boris Brezillon, Quentin Schulz. Bottom, from left to right: Miquèl Raynal, Thomas Petazzoni, Michael Opdenacker.

In this first blog post about ELCE, we want to share the slides and videos of the talks we have given during the conference.

SD/eMMC: New Speed Modes and Their Support in Linux – Gregory Clement

Grégory ClementSince the introduction of the original “default”(DS) and “high speed”(HS) modes, the SD card standard has evolved by introducing new speed modes, such as SDR12, SDR25, SDR50, SDR104, etc. The same happened to the eMMC standard, with the introduction of new high speed modes named DDR52, HS200, HS400, etc. The Linux kernel has obviously evolved to support these new speed modes, both in the MMC core and through the addition of new drivers.

This talk will start by introducing the SD and eMMC standards and how they work at the hardware level, with a specific focus on the new speed modes. With this hardware background in place, we will then detail how these standards are supported by Linux, see what is still missing, and what we can expect to see in the future.

Slides [PDF], Slides [LaTeX source]

An Overview of the Linux Kernel Crypto Subsystem – Boris Brezillon

Boris BrezillonThe Linux kernel has long provided cryptographic support for in-kernel users (like the network or storage stacks) and has been pushed to open these cryptographic capabilities to user-space along the way.

But what is exactly inside this subsystem, and how can it be used by kernel users? What is the official userspace interface exposing these features and what are non-upstream alternatives? When should we use a HW engine compared to a purely software based implementation? What’s inside a crypto engine driver and what precautions should be taken when developing one?

These are some of the questions we’ll answer throughout this talk, after having given a short introduction to cryptographic algorithms.

Slides [PDF], Slides [LaTeX source]

Buildroot: What’s New? – Thomas Petazzoni

Thomas PetazzoniBuildroot is a popular and easy to use embedded Linux build system. Within minutes, it is capable of generating lightweight and customized Linux systems, including the cross-compilation toolchain, kernel and bootloader images, as well as a wide variety of userspace libraries and programs.

Since our last “What’s new” talk at ELC 2014, three and half years have passed, and Buildroot has continued to evolve significantly.

After a short introduction about Buildroot, this talk will go through the numerous new features and improvements that have appeared over the last years, and show how they can be useful for developers, users and contributors.

Slides [PDF], Slides [LaTeX source]

Porting U-Boot and Linux on New ARM Boards: A Step-by-Step Guide – Quentin Schulz

May it be because of a lack of documentation or because we don’t know where to look or where to start, it is not always easy to get started with U-Boot or Linux, and know how to port them to a new ARM platform.

Based on experience porting modern versions of U-Boot and Linux on a custom Freescale/NXP i.MX6 platform, this talk will offer a step-by-step guide through the porting process. From board files to Device Trees, through Kconfig, device model, defconfigs, and tips and tricks, join this talk to discover how to get U-Boot and Linux up and running on your brand new ARM platform!

Slides [PDF], Slides [LaTeX source]

BoF: Embedded Linux Size – Michael Opdenacker

This “Birds of a Feather” session will start by a quick update on available resources and recent efforts to reduce the size of the Linux kernel and the filesystem it uses.

An ARM based system running the mainline kernel with about 3 MB of RAM will also be demonstrated.

If you are interested in the size topic, please join this BoF and share your experience, the resources you have found and your ideas for further size reduction techniques!

Slides [PDF], Slides [LaTeX source]

Testing the Waters: How to Perform Internal Phishing Campaigns

Phishing is one of the most dangerous threats to modern computing. Phishing attacks have evolved from sloppily written mass email blasts to targeted attacks designed to fool even the most cautious users. No defense is bulletproof, and most experts agree education and common sense are the best tools to combat the problem. more>>

Free Electrons at NetDev 2.2

NetDev 2.2Back in April 2017, Free Electrons engineer Antoine Ténart participated to NetDev 2.1, the most important conference discussing Linux networking support. After the conference, Antoine published a summary of it, reporting on the most interesting talks and topics that have been discussed.

Next week, NetDev 2.2 takes place in Seoul, South Korea, and this time around, two Free Electrons engineers will be attending the event: Alexandre Belloni and Antoine Ténart. We are getting more and more projects with networking related topics, and therefore the wide range of talks proposed at NetDev 2.2 will definitely help grow our expertise in this field.

Do not hesitate to get in touch with Alexandre or Antoine if you are also attending this event!

The Wire

In the US, there has been recent concern over ISPs turning over logs to the government. During the past few years, the idea of people snooping on our private data (by governments and others) really has made encryption more popular than ever before. One of the problems with encryption, however, is that it's generally not user-friendly to add its protection to your conversations. more>>

Buildroot training course updated to Buildroot 2017.08

BuildrootBack in June 2015, we announced the availability of a training course on Buildroot, a popular and easy to use embedded Linux build system. A year later, we updated it to cover Buildroot 2016.05. We are happy to announce a new update: we now cover Buildroot 2017.08.

The most significant updates are:

  • Presentation of the Long Term Supported releases of Buildroot, a topic we also presented in a previous blog post
  • Appearance of the new top-level utils/ directory, containing various utilities directly useful for the Buildroot user, such as test-pkg, check-package, get-developers or scanpypi
  • Removal of $(HOST_DIR)/usr/, as everything has been moved up one level to $(HOST_DIR), to make the Buildroot SDK/toolchain more conventional
  • Document the new organization of the skeleton package, now split into several packages, to properly support various init systems. A new diagram has been added to clarify this topic.
  • List all package infrastructures that are available in Buildroot, since their number is growing!
  • Use SPDX license codes for licensing information in packages, which is now mandatory in Buildroot
  • Remove the indication that dependencies of host (i.e native) packages are derived from the dependencies of the corresponding package, since it’s no longer the case
  • Indicate that the check for hashes has been extended to also allow checking the hash of license files. This allows to detect changes in the license text.
  • Update the BR2_EXTERNAL presentation to cover the fact that multiples BR2_EXTERNAL trees are supported now.
  • Use the new relocatable SDK functionality that appeared in Buildroot 2017.08.

The practical labs have of course been updated to use Buildroot 2017.08, but also Linux 4.13 and U-Boot 2017.07, to remain current with upstream versions. In addition, they have been extended with two additional steps:

  • Booting the Buildroot generated system using TFTP and NFS, as an alternative to the SD card we normally use
  • Using genimage to generate a complete and ready to flash SD card image

We will be delivering this course to one of our customers in Germany next month, and are of course available to deliver it on-site anywhere in the world if you’re interested! And of course, we continue to publish, for free, all the materials used in this training session: slides and labs.

L’édito de GNU/Linux Magazine n°209 !

Python, on aime ou on n’aime pas, mais le langage ne laisse pas indifférent. Il y a les fans, ceux qui ne jurent que par ce langage et qui vont jusqu’à l’extrémisme en oubliant tous les autres langages qui ne sont pas pour autant à jeter à la poubelle et il y a les opposants farouches, eux aussi sombrant souvent dans l’extrémisme et dénigrant un « pseudo-langage » qui n’est même pas compilé et qui envahit de plus en plus les magazines et les articles sur le net.

Python n’est certes pas compilé, mais il permet de développer rapidement, sans se préoccuper de la gestion de la mémoire. D’un autre côté, suivant les développements, son aspect de langage semi-interprété est pénalisant, car entraînant un gaspillage de mémoire et une lenteur des programmes. Alors, puisque nous ne pourrons départager les « pros » des « antis », essayons de comprendre avec les outils qui sont à notre disposition pourquoi on parle tant de Python. Utilisons par exemple les tendances de questions sur StackOverflow :

On peut constater que Python vient de dépasser Java et n’est plus devancé que par JavaScript. Ceci s’explique par le nombre de sites web contenant du JavaScript, mais montre que malgré les développements d’applications Android en Java, les questions sont plus nombreuses sur Python. Les mauvaises langues pourront bien sûr arguer du fait que s’il y a beaucoup de questions, c’est que le langage n’est pas clair… passons et retenons seulement la croissance imbattable sur les deux dernières années.

Pour confirmer cela, penchons-nous sur d’autres données. Sur Google Trends, les recherches comme « python » ou « java » sont parasitées par d’autres significations que des langages de programmation, mais le projet PYPL (PopularitY of Programming Language sur l’utilise néanmoins en se basant sur les recherches de tutoriels. Je vous invite à consulter le site et à utiliser les langages qui vous intéressent, pour moi ce seront les mêmes que les précédents.

Cette fois Python ne dépasse pas Java, mais sa croissance de 9,5 % sur les dix dernières années est là encore remarquable et l’étude des données fournies par GitHub ( fournira là encore la même tendance.

Ces informations montrent donc qu’il y a un engouement de plus en plus fort pour ce langage et qu’on le veuille ou non, il faudra le connaître un minimum pour comprendre, pouvoir interagir avec les futurs développements. Donc oui, Python est de plus en plus utilisé, et vous découvrirez même dans ce numéro comment vous en servir pour envoyer/recevoir des SMS, interagir avec Google Calendar et mettre en place une authentification deux facteurs, mais dans GNU/Linux Magazine nous n’en oublions pas pour autant les autres langages et vous pourrez ainsi trouver par exemple dans ce numéro également du C et du Go (oui, le bon dernier de toutes les tendances si l’on ne tient pas compte des langages « exotiques »).

Surtout, n’oubliez pas que ce n’est pas parce qu’un langage est populaire qu’il est le meilleur. Le meilleur langage est celui le plus adapté à la tâche que vous devez réaliser ! Sur ce, bonne lecture !

Tristan Colombo

-> Découvrir/acheter ce numéro :

-> S’abonner :


What is ephemeral data, you ask? InfluxData can supply the answer, because handling it is the business of the company's InfluxData open-source platform that is custom-built for metrics and events. more>>

Maîtrisez la gestion avancée de SMS sans vous ruiner !

Avec l’article phare de ce nouveau numéro de GNU/Linux Magazine, vous apprendrez à envoyer des SMS sans vous ruiner à l’aide de votre PC et de votre Raspberry Pi. Pour ce faire, vous découvrirez comment configurer votre modem USB 3G, utiliser Gammu pour l’envoi de SMS, interfacer votre système avec Google Calendar, gérer la réception de SMS et enfin, mettre en place une authentification 2 facteurs. Pour vous occuper durant ce mois de novembre, vous apprendrez aussi avec ce nouveau numéro à réaliser une API REST en Go, à analyser statiquement et dynamiquement du code ou encore à faire vos premiers pas avec l’environnement de développement OpenSTM32 sur Steval-3DP001. Retrouvez GNU/Linux Magazine chez votre marchand de journaux, sur notre boutique ainsi que sur notre plateforme de lecture en ligne Connect !

Au sommaire

Actus & humeur

p.06 Petite leçon fictive de social engineering

IA, Robotique et Science

p.12 Le code Phase-Out : l’autre code binaire tronqué

Système & Réseau

p.34 Un système de fichiers haute disponibilité avec GlusterFS !

p.32 Mise en place d’une IP virtuelle avec Corosync et Pacemaker

p.36 InfluxDB, Grafana et Glances, le monitoring qui brille

IoT & Embarqué

p.46 Présentation et utilisation de la carte STEVAL-3DP001 pour le pilotage des imprimantes 3D

Hack & Bidouille

p.58 Vous donnez des rendez-vous et on vous oublie ? Envoyez automatiquement des SMS de rappel !

Libs & Modules

p.74 Réaliser une API REST avec Go

Mobile & Web

p.82 Démystifier l’injection de dépendances en PHP

Sécurité & Vulnérabilité

p.92 La trilogie du reverse engineering

Initiez-vous aux bitcoins & crypto-monnaies !

Le nouveau Linux Pratique vous propose de vous pencher sur le bitcoin et ses alternatives. Au menu de ce numéro : principes, usages et mode d’emploi des crypto-monnaies, mais pas uniquement… Il y sera également question de protéger votre vie numérique avec une clé USB libre, créer votre système de surveillance maison à l’aide d’une Raspberry Pi et d’une caméra, installer votre miroir de dépôts sur votre réseau local, mettre en place une surveillance des certificats numériques de vos sites web ou encore faire vos premiers pas en programmation 3D à l’aide de Processing. Linux Pratique n°104 est disponible en kiosque, sur notre boutique ainsi que sur notre plateforme de lecture en ligne Connect.

Au sommaire

Actualités & Nouveautés

p. 06 Brèves & agenda novembre-décembre 2017

Logithèque & Applicatif

p. 08 Passez à Firefox Nightly

p. 12 Komorebi : votre gestionnaire de fonds d’écran à effets spéciaux

p. 13 Openshot : un logiciel de montage vidéo simple à prendre en main

p. 14 Créez votre disque externe multi-usages

Système & Personnalisation

p. 23 Tectonique de la pâte thermique

p. 28 Installer son miroir de dépôts Debian Stretch sur son réseau local

Web & Réseau

p. 34 Se faire son propre outil de curation

p. 41 Sécurisez votre vie numérique : une clé usb pour chiffrer et signer vos données

Programmation & Scripts

p. 50 Entrez dans la troisième dimension de Processing

Entreprise & Organisation

p. 60 Surveillez vos certificats numériques

Réflexion & Société

p. 68 Monnaies cryptographiques : du Bitcoin au lhc@home

p. 80 Installer un portefeuille Bitcoin et effectuer un paiement

Mobilité & Objets connectés

p. 86 Firefox Focus : un navigateur web destiné à préserver votre vie privée

p. 87 Data Respect : découvrez comment et qui utilise vos données personnelles

Cahier Raspberry Pi

p. 88 Réalisez votre propre caméra de surveillance

p. 94 6 astuces pour profiter au mieux de votre console de jeu rétrogaming multiplateforme