Christophe Blaess

L’éco-système « The Yocto Project » est assez touffu. En effet, Yocto Project chapeaute plusieurs sous-projets pour lesquels il fournit des ressources de développement : Bitbake, Open Embedded, Poky, les layers des sponsors « platiniums » ainsi que l’hébergement de nombreux layers supportant diverses plateformes matérielles.

Depuis plus d’une décennie, la mise en route d’un projet Yocto passait par l’utilisation d’un starter pack contenant les outils de base et les recettes minimales pour produire une image. Cet environnement se nommait Poky.

Pas de commentaires»

Le Raspberry Pi 5 dispose d’une interface de debug spécifique basée sur un connecteur JST 1mm. Toutefois, il est souvent préférable lorsqu’on veut se connecter en utilisant une console série, d’utiliser le port d’extension habituel, avec ses broches 6 (GND), 8 (TX) et 10 (RX) comme les précédents modèles de Raspberry Pi.

Cela permet de faire facilement communiquer deux cartes entre elles (simplement en croisant TX et RX) ou d’utiliser une console de debug (par exemple sur un PC) avec un petit connecteur USB-Serie.

Pas de commentaires»

Lorsqu’on réalise un build pour un système Linux embarqué avec Yocto Project, de nombreux fichiers sont parcourus par l’outil Bitbake. Il n’est pas toujours simple de savoir dans quel ordre ces fichiers de configuration sont examinés, mais c’est pourtant une clé pour la bonne compréhension des opérations réalisées.

Nous allons nous intéresser ici aux fichiers de configuration et de données (distro, machine, image, recettes, etc.) pas aux fichiers python internes de Bitbake, ni aux fichiers sources, objets ou exécutables obtenus lors de la compilation des packages.

Bien sûr nous regarderons certains fichiers directement livrés avec Yocto, mais ce qui m’intéresse avant tout, c’est la connaissance des fichiers sur lesquels nous avons la possibilité d’agir, ceux que nous pouvons personnaliser avant de lancer le build.

Pas de commentaires»