Journal La distribution buildroot (pt 1)

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
28
14
déc.
2023

Dans les derniers commentaires, il m’a été demandé de faire un petit journal sur la distribution buildroot. Cela tombe bien, c’est quelque chose que j’avais en tete depuis un moment sans avoir vraiment pris le temps de m’y mettre. Je vais essayer de le faire en deux parties pour me laisser un peu de temps, tout en ayant déjà quelque chose qui me pousse à continuer :) (c’est plus facile comme ça !) Je vous propose dans cette première partie de faire un petit tour général, puis de voir dans un deuxième journal comment construire son image


Buildroot est une distribution linux source destinée aux ordinateurs monocarte (traduction de SBC). C'est à dire que vous ne trouverez pas d'image à télécharger, mais un ensemble de script permettant de construire sa propre image.

Pour quel usage ?

Il ne s'agit pas d'une distribution générique, la cible est clairement les petits ordinateurs sans grande puissance, type raspberryPi. Ces ordinateurs ont tous des caractéristiques particulières, ne suivent pas le standard PC (pas de bios, architecture spécifique) et chaque constructeur suit son propre standard. Buildroot propose une solution pour uniformiser tout ça, avec un cadre unique permettant de construire les images à copier vers la carte.

Attention, il s'agit d'une distribution pour utilisateur avancés, qui nécessite de connaître déjà l'écosystème Gnu/Linux pour pouvoir s'en sortir.

Le choix de cibler les petites cartes oblige à faire des choix, c'est pourquoi vous ne pourrez pas compiler de compilateur par exemple.

Organisation de la distribution

Le code de la distribution est facile à suivre et comprendre, puisqu'il s'agit d'un ensemble de script bash et de fichiers de configurations. Je propose un petit tour de piste de l'arborcence, pour comprendre un peu comment celle-ci se construit :

/board

Il s'agit de la liste des cartes prises en charge, elles sont triées par constructeur. On peut noter qu'il y a une meme une carte qemu, qui permet de construire une image pouvant tourner dans la machine virtuelle !

/package

L'arborcence contient la liste des paquets qu'il est possible d'installer sur la distribution. Enfin plutot compiler, car il s'agit de règle de compilation. La liste est longue, allant de dhcpcd à kodi (pour prendre deux paquets qui se situent à des niveaux différents dans la pile de l'OS).

/config

Il s'agit des paquets qui sont fourni par défaut et adaptés aux cartes en questions. Par exemple, la configuration pour le raspberrypi0w va charger le noyau adapté à la carte, alors que celui de la carte orangepi_zero reste sur le noyau standard.

Compilation d'une image

Celle-ci se fait en deux étapes : la compilation des paquets dans un premier temps, puis la configuration du système.

Sélection et création des paquets

Buildroot offre une commande bien connue : make menuconfig (bien connue car c'est avec cette commande que l'on peut construire son noyau linux). Un menu permet de sélectionner les paquets que l'on veut sélectionner et intégrer.

Les pré-requis sont géres, autant sur la chaine de compilation que sur les dépendances logicielles, et des sous-menus permettent de sélectionner les options de compilation pour un paquet.

Attention, par défaut, l'image ne contient que le minimum pour lancer le système. Si vous souhaitez vous connecter au réseau, il vous faudra probablement choisir les paquets de base (client dhcp, wifi…). Sur ce point, il est nécessaire de connaître l'organisation des paquets dans une distribution linux car Buildroot ne vous aidera pas à faire les choix à votre place (il n'y a pas de tasksel permettant d'avoir des configurations toutes prêtes !)

Pour configurer ses paquets de manière plus modulable, il est possible d'utiliser le script merge_config.sh qui permet de combiner plusieurs fichiers de configuration en un seul. Très utile pour surcharger la configuration par défaut d'une carte avec celle venant de la pile logiciel que l'on souhaite constituer.

  • # Intéressant !

    Posté par  . Évalué à 3.

    Super merci à toi, je suis en train de m'y intéresser, et je voudrais ton avis:
    - buildroot vs yocto ? en termes de pérennité et de plateformes supportées, en recommanderait plutot l'un ou l'autre ? Les aspects philosophiques m'intéressent également :D
    - un retex d'utilisation sur un MCU type STM32H7 ?
    - un retex sur la facilité d'utiliser les périphériques via /sys ? comme sur un RPi ou il manque souvent des drivers ?

    Merci, ça fait des années que je me dis qu'il me faudrait voir ce que ca pourrait m'apporter d'avoir un kernel sur un MCU plutot que FreeRTOS ou Zephyr…. et la plateforme la plus petite pour faire tourner ça.

    • [^] # Re: Intéressant !

      Posté par  (site web personnel) . Évalué à 6.

      • buildroot vs yocto ? en termes de pérennité et de plateformes supportées, en recommanderait plutot l'un ou l'autre ? Les aspects philosophiques m'intéressent également :D

      Les deux projets sont proches tout en étant très différents.
      Il faut voir plutôt buildroot comme un outil pour générer un firmware quand Yocto permet de gérer sa propre distribution et son propre écosystème.

      buildroot est de fait plus minimaliste et simple d'approche. Du coup l'apprentissage et la compréhension des étapes est plutôt simple ce qui permet rapidement d'avoir un résultat probant. Si tu veux par exemple générer une image simple pour une machine cible, c'est parfait.

      Yocto est de fait très complexe mais bien plus complet et puissant. Il est vraiment conçu pour réutiliser au maximum les composants et ses propres changements pour plusieurs cibles à la fois. Donc si tu as plusieurs projets proches cela devient rapidement incontournable. Il y a pas mal d'éléments qui permettent d'améliorer la qualité du résultat mais cela a un coût en ressources matérielles comme temporelles. On peut vite s'y perdre dans sa complexité interne en comparaison.

      Yocto semble avoir à ce jour une meilleur adoption par les industriels mais buildroot se défend bien.

  • # Merci pour le journal

    Posté par  . Évalué à 2.

    Super idée qui nul doute va donner des idées à plusieurs d'entre nous.

    Petite question par rapport à la puissance du RPI Zero. Est-ce que la carte est suffisamment puissante pour y installer et faire tourner correctement Syncthing ?

    D'après deux ou trois sites que j'ai pu consulter, la réponse est oui, mais j'ai du mal à trouver de la doc pour l'installer. Syncthing n'y est pas dans le dossier /package, mais il existe une version Linux pour ARM64 à télécharger directement sur le site des développeurs. Par contre, la plupart des sources montrent comment installer Syncthing sur Raspberry Pi standard, et encore c'est sur Raspbian via apt. L'installation de la version originale sur RPI Zero n'est pas claire.

    Nec spe, nec metu

    • [^] # Re: Merci pour le journal

      Posté par  . Évalué à 2.

      Petite remarque : tous les RPI Zero ne gèrent pas le jeu d'instructions ARM64. D'après https://fr.wikipedia.org/wiki/Raspberry_Pi#Tableau_comparatif, uniquement le modèle Zero 2 W permet de faire du ARM64, les autres modèles sont en armv6.

      Du coup, en fonction de ton modèle de RPI Zero, tu devras peut-être choisir le package Syncthing "linux-arm" plutôt que "linux-arm64".

      • [^] # Re: Merci pour le journal

        Posté par  . Évalué à 1.

        C'est bien le Zero 2 W qui m'intéresse (plus récent et vendu à 25€ sans boîtier).

        Nec spe, nec metu

    • [^] # Re: Merci pour le journal

      Posté par  . Évalué à 2.

      Par expérience, il est généralement plus simple/sain/efficace de créer un nouveau package et de le compiler grâce à la toolchain mise en place par Buildroot, plutôt que de prendre une version pré-compilé. La façon de faire ça est assez bien décrite dans la documentation

      A part ça, Buildroot est un projet fantastique qui a révolutionné ma façon de construire des firmwares aussi bien pour RPI que pour PC !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.