Logs
Consultez les logs.
OK
Liste des données
Consultez la liste des données.
OK
Loading...
Formulaire
Saisissez vos données.
Enregistrer
Annuler
ReadyDev
Présentation
Admin
Linux est utilisé depuis toujours dans des produits de pointe, et les systèmes embarqués font partie intégrante du portefeuille technologique de l'humanité. Le projet Yocto est idéalement placé pour être le choix idéal pour vos projets. Il fournit un ensemble complet d'outils pour vous aider à optimiser votre énergie et vos ressources dans le développement de vos produits, au lieu de réinventer la roue. Les tâches et exigences habituelles des produits et des équipes de développement basés sur Linux embarqué sont résumées dans ce tutoriel, qui se veut aborder chaque sujet avec une approche pratique et directe, afin de constituer un tremplin pour votre apprentissage dans ce domaine. Ce tutoriel a été élaboré pour refléter les modifications apportées à la version 4.0 du support à long terme du projet Yocto (nom de code Kirkstone). Ce tutoriel démarre avec l'utilisation de QEMU pour accélérer le développement de produits grâce à l'émulation d'architecture matérielle.
Définitions
Outils :
Yocto est un projet de développement de système Linux embarqué.
Poky est la distribution de référence du projet Yocto.
QEMU est un émulateur d'architecture matérielle.
runqemu est un wrapper pour l'utilisation de QEMU.
Toaster est une interface web supportée par Python pour les builds Yocto.
Django est un framework web pour Python.
pip est un gestionnaire de packages pour Python.
Concepts :
BSP (Board Support Packages) est un ensemble de couches logicielles et d'images de référence supportées par le projet Yocto.
Image Recipes (Recettes d'images) est un ensemble d'images prédéfinies et prêtes à être déployées dans le cadre d'un projet Yocto.
Création de notre premier système basé sur Poky
Packages de base Linux
On exécute la commande suivante pour installer les outils de base nécessaires au développement d'un système Linux Embarqué sous le système (Ubuntu).
... $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3- pexpect xz-utils debianutils iputils-ping python3-git python3- jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd liblz4-tool ...
On exécute la commande suivante pour installer les outils de base nécessaires au développement d'un système Linux Embarqué sous le système (Fedora).
... $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel perl- FindBin perl-File-Compare perl-File-Copy perl-locale zstd lz4 ...
Distribution de référence Poky
On exécute la commande (git, clone, b) pour cloner le dépôt (poky) et basculer sur la branche (kirkstone).
On note que :
On note que :
L'expression (kirkstone) est le nom de code de la version (4.0) du projet (Yocto).
... $ git clone https://git.yoctoproject.org/poky -b kirkstone ...
On exécute la commande (ls, l) pour lister le contenu du dépôt (poky).
... ls -l ...
Configuration du build (oe-init-build-env)
On exécute la commande (source, oe-init-build-env) pour initialiser les variables d'environnement et le répertoire de construction (BUILD_DIRECTORY) nécessaires au développement du système Linux Embarqué.
On note que :
On note que :
Le script d'initialisation (oe-init-build-env) est stocké à la racine du dépôt (poky).
Il est très pratique d'utiliser différents répertoires de build afin de pouvoir travailler sur des projets distincts en parallèle ou des configurations expérimentales sans affecter nos autres builds.
... $ source oe-init-build-env BUILD_DIRECTORY ... $ source oe-init-build-env build ...
On ouvre le fichier de configuration du build (build/conf/local.conf) pour identifier la valeur par défaut (qemux86-64) attribuée à la variable (MACHINE) correspondant au nom de la machine cible pour laquelle on construit le système Linux Embarqué.
On note que :
On note que :
Le fichier de configuration du build est un moyen très puissant de configurer presque tous les aspects du processus de build. Il permet définir la machine cible, la chaîne d'outils de l'architecture hôte, les options d'optimisation pour une réduction maximale du temps de build, etc.
... # build/conf/local.conf ... MACHINE ??= "qemux86-64" ...
On jette un coup d'oeil sur la liste suivante pour prendre connaissance des couches BSP supportées par le projet Yocto.
On note que :
On note que :
Le projet Yocto prend en charge un grand nombre de systèmes d'architecture matérielle et d'émulation matérielle (QEMU).
On note que :
On note que :
Une couche BSP est associée à un système d'architecture matérielle donnée et permet ainsi au projet Yocto de construire le système Linux Embarqué pour la machine cible correspondante.
... Quelques systèmes d'architecture matérielle ... beaglebone-yocto----: Pour la machine, BeagleBone, ARM, 32 bits genericx86----------: Support générique pour les machines, x86, 32 bits genericx86-64-------: Support générique pour les machines, x86, 64 bits edgerouter----------: Pour le routeur, EdgeRouter Lite, MIPS, 64 bits ... Quelques systèmes d'émulation matérielle (QEMU) ... qemuarm-------------: Pour l'émulation QEMU ARMv7 qemuarmv5-----------: Pour l'émulation QEMU ARMv5 qemuarm64-----------: Pour l'émulation QEMU ARMv8 qemumips------------: Pour l'émulation QEMU MIPS qemumips64----------: Pour l'émulation QEMU MIPS64 qemuppc-------------: Pour l'émulation QEMU PowerPC ...
On exécute la commande (ls, meta, recipes, images) pour consulter la liste des recettes d'images disponible dans le cadre du projet Yocto.
...
$ ls meta*/recipes*/*images/*.bb
...
core-image-minimal----------: Pour tests, développement du noyau
et du chargeur de démarrage.
core-image-base-------------: Support matériel de base
pour la machine cible.
core-image-weston-----------: Pour protocole Wayland
et compositeur Weston de référence.
core-image-x11--------------: Pour X11 de base avec un terminal.
core-image-sato-------------: Pour Sato, environnement mobile X11, terminal,
éditeur, gestionnaire de fichiers, lecteur
multimédia, etc.
core-image-full-cmdline-----: Pour console et fonctionnalités Linux
plus complètes installées.
...Génération d'une image binaire (bitbake)
On exécute la commande (bitbake) pour générer une image binaire à partir d'une recette d'image (IMAGE_RECIPE) pour la machine cible pointée par la variable (MACHINE) du fichier de configuration (build/conf/local.conf).
On note que :
On note que :
On utilisera la machine cible par défaut pour ce build. Dans ce cas, on effectue cette configuration (MACHINE=qemux86-64) dans le fichier (build/conf/local.conf).
... $ bitbake IMAGE_RECIPE ... $ bitbake core-image-full-cmdline ...
Utilisation de l'image binaire sous QEMU
On peut exécuter la commande (runqemu) pour démarrer l'émulateur QEMU à partir des informations sur l'architecture matérielle (MACHINE, qemux86-64), l'emplacement de l'image binaire (IMAGE, /path/to/ bzImage-qemux86-64.bin), le nom du fichier système (FILESYSTEM, ext4).
On note que :
On note que :
L'émulation matérielle avec QEMU permet d'accélérer le processus de développement en offrant la possibilité d'effectuer des tests sans matériel réel.
Heureusement, la plupart des projets ne dépendent que très peu du matériel.
... $ runqemu MACHILE IMAGE FILESYSTEM ...
On exécute la commande (runqemu) pour démarrer l'émulateur QEMU à partir des informations sur l'architecture matérielle (MACHINE, qemux86-64), la recette d'image (IMAGE_RECIPE, core-image-full-cmdline).
On note que :
On note que :
Tous les paramètres (IMAGE, FILESYSTEM) de l'appel précédent à la commande (runqemu) sont facultatifs.
L'exécution de la commande (runqemu, MACHINE, IMAGE_FILE) suffit à lancer l'image binaire dans le shell où l'environnement de compilation est configuré, car il reprendra automatiquement les paramètres par défaut de l'environnement de compilation.
On note que :
On note que :
Le système se comporte comme une machine normale, même lorsqu'il est exécuté dans QEMU.
En réalité, le processus de déploiement d'une image sur un matériel réel varie selon le type de stockage utilisé, le chargeur de démarrage, etc. Cependant, le processus de génération de l'image est le même.
... $ runqemu MACHINE IMAGE_RECIPE ... $ runqemu qemux86-64 core-image-full-cmdline ...
Utilisation de Toaster pour créer une image
Dépendances Toaster
On exécute la commande (pip3, install, user) pour installer les dépendances Python nécessaires à l'utilisation de Toaster dans le répertoire de base de l'utilisateur courant.
On note que :
On note que :
Toaster utilise le framework Python (Django). Le moyen le plus simple de l'installer est d'utiliser l'utilitaire Python (pip) déjà installé lors de la configuration des packages de base.
... $ pip3 install --user -r bitbake/toaster-requirements.txt ...
Démarrage du serveur Toaster
On exécute la commande (source, oe-init-build-env) pour initialiser les variables d'environnement de build.
On exécute la commande (source, toaster, start) pour démarrer le serveur Toaster.
On note que :
On note que :
Le serveur Toaster démarre sur le port (8000) par défaut.
... $ source oe-init-build-env $ source toaster start ...
On peut exécuter la commande (source, toaster, start, webport) pour démarrer le serveur Toaster sur un autre port (PORT, 8400).
... source toaster start webport=PORT ... source toaster start webport=8400 ...
On accède à l'adresse suivante dans un navigateur Web pour afficher l'interface Web de Toaster à partir de son port (PORT) de démarrage.
... http://127.0.0.1:PORT ... http://127.0.0.1:8000 ...
Création d'un projet Toaster
On exécute l'opération suivante pour créer un nouveau de projet de build sous Toaster avec un nom de projet (my-first-project), un type de projet (New Project), une version du projet Yocto (Yocto Project 4.0 "Kirkstone").
On jette un coup d'oeil sur la figure suivante pour visualiser l'écran principal du projet (my-first-project) sous Toaster.
On exécute l'opération suivante pour configurer la machine cible (qemux86-64) du projet (my-first-project) sous Toaster.
On exécute l'opération suivante pour configurer la recette d'image (core-image-full-cmdline) du projet (my-first-project) sous Toaster.
Build d'une image binaire sous Toaster
On jette un coup d'oeil sur la figure suivante pour visualiser l'écran du processus de build du projet (my-first-project) sous Toaster.
On jette un coup d'oeil sur la figure suivante pour visualiser l'écran du résumé de build du projet (my-first-project) sous Toaster.
On jette un coup d'oeil sur la figure suivante pour visualiser l'écran des répertoires et fichiers inclus dans l'image binaire générée par le projet (my-first-project) sous Toaster.
Utilisation de l'image binaire sous QEMU
On exécute la commande (runqemu) pour démarrer l'émulateur QEMU à partir des informations sur l'architecture matérielle (MACHINE, qemux86-64), la recette d'image (IMAGE_RECIPE, core-image-full-cmdline).
On note que :
On note que :
Vous devez revenir au terminal où vous avez démarré Toaster pour exécuter la commande (runqemu, MACHINE, IMAGE_RECIPE).
... $ runqemu MACHINE IMAGE_RECIPE ... $ runqemu qemux86-64 core-image-full-cmdline ...
