Un bouton d’alimentation pour Raspberry Pi, grâce aux superpositions d’arborescence de périphériques

En tant que fonctionnalité standard du noyau Linux, les superpositions d’arborescence de périphériques (DTO) permettent une activation et une configuration faciles des fonctionnalités et des pilotes, tels que ceux contenus dans le micrologiciel standard d’un système Raspberry Pi. En utilisant ces DTO, il est facile de configurer des fonctionnalités telles qu’un bouton de mise hors tension logicielle, de déclencher une alimentation externe et d’activer les pilotes pour tout, d’une horloge externe en temps réel (RTC) à divers écrans, capteurs et appareils audio, le tout sans modification. le système d’exploitation ou à l’aide de scripts personnalisés.

Il est également possible d’ajouter vos propres DTO pour créer une superposition personnalisée qui combine plusieurs commandes DTO en une seule, ou de créer un binaire d’arborescence de périphériques (DTB) personnalisé pour le matériel cible. Essentiellement, ce DTB est chargé par le noyau Linux au démarrage pour lui faire savoir quels périphériques sont connectés et leurs paramètres de configuration, très similaires à ce que le composant BIOS avec les architectures basées sur x86 gère automatiquement.

En fin de compte, le concept DTB et l’utilisation de superpositions permettent une configuration facile de ces périphériques optionnels et des paramètres de broche GPIO, en particulier lorsqu’ils sont configurables via un simple fichier texte comme sur la plate-forme Raspberry Pi SBC.

L’arborescence des périphériques Linux

Liste des fichiers, y compris les binaires d'arborescence de périphériques (DTB) spécifiques à la carte pour un Raspberry Pi SBC.
Liste des fichiers, y compris les binaires d’arborescence de périphériques (DTB) spécifiques à la carte pour un Raspberry Pi SBC.

Comme indiqué précédemment, l’arborescence des périphériques est compilée dans un binaire qui est transmis au noyau au démarrage. Cette arborescence de périphériques contient la liste des périphériques connectés, leur pilote et d’autres paramètres pertinents. Sur les plates-formes qui n’utilisent pas un système de type BIOS pour détecter automatiquement les périphériques, comme les cartes graphiques et les cartes réseau, et pour les périphériques qui n’ont pas d’option de détection automatique et de configuration automatique comme les périphériques I2C et SPI, l’arborescence des périphériques a être construit de cette manière.

L’utilisation d’une telle arborescence de périphériques externes évite d’avoir à recompiler le noyau à chaque changement de matériel, avec un fichier DTB central pour la configuration des périphériques système, comme ceux fournis pour les SBC Raspberry Pi. Recompiler ce DTB pour tout périphérique nouvellement ajouté ou modifié serait aussi compliqué que de recompiler le noyau entier. C’est là que les superpositions entrent en jeu.

Une fois le DTB chargé par le noyau, les DTO sont appliqués, conformément à la documentation du noyau Linux sur les DTO. La superposition elle-même est spécifiée en tant que source d’arborescence de périphériques, compilée à l’aide du compilateur d’arborescence de périphériques dans un fichier de superposition binaire d’arborescence de périphériques (DTBO). Pour le Raspberry Pi, ces DTBO peuvent être trouvés tout comme les DTB sur le compte Raspberry Pi GitHub.

Sur le blog Bootlin, un excellent article explique comment écrire vos propres superpositions et les appliquer à l’aide de la plate-forme BeagleBone Black. Cela montre comment charger les DTBO à partir du chargeur de démarrage U-Boot, qui est un processus un peu plus complexe que celui proposé par d’autres plates-formes.

Avec Armbian par exemple, les DTO peuvent être définis et modifiés depuis le armbianEnv.txt fichier, en supposant que l’on utilise une image pour une plate-forme prenant en charge cette fonctionnalité. En supposant qu’il s’agit d’une fonctionnalité prise en charge sur l’image Armbian utilisée, il suffit de modifier le /boot/armbianEnv.txt pour ajouter les noms de superposition requis et leurs paramètres. Cette approche rappelle fortement l’approche choisie sur la plate-forme Raspberry Pi SBC, avec un fichier texte similaire chargé à partir de /boot/config.txt.

Bouton d’alimentation douce

Commutateur NO momentané installé sur un Raspberry Pi 2B.

Comme exemple simple mais plutôt utile de ce que les DTO sur les SBC Raspberry Pi peuvent accomplir, examinons comment implémenter un bouton marche/arrêt progressif en utilisant uniquement une image par défaut du système d’exploitation Raspberry Pi, un interrupteur momentané (normalement ouvert) et un peu de câblage pour connecter ce commutateur à deux broches sur l’en-tête GPIO, comme dans l’image de droite.

Pour que cela fonctionne, il y a deux composants en jeu ici. Le premier concerne le soft power on. Sur les cartes Raspberry Pi, lorsque le processeur est à l’état d’arrêt (alimenté, mais le processeur ne fonctionne pas), GPIO3 est maintenu à l’état haut en raison d’une résistance pull-up externe. Chaque fois que GPIO3 est tiré vers le bas dans cet état, le CPU est repris.

Ceci est accompli en mettant notre interrupteur NO sur GPIO3 et une broche de masse (GND). Lorsque le système entre en état d’arrêt et que nous appuyons sur le bouton, GPIO3 est tiré vers le bas et le système reprend.

Pour une mise hors tension douce, nous devons utiliser la première superposition. Étant donné que nous utiliserons également GPIO3 pour éteindre le système, nous ajouterons la superposition d’arborescence de périphériques suivante (dtoverlay) à /boot/config.txt:


dtoverlay=gpio-shutdown,gpio_pin=3,active_low=1,debounce=1500

le gpio-shutdown DTO est décrit dans le fichier README superposé :

Name: gpio-shutdown
Info: Initiates a shutdown when GPIO pin changes. The given GPIO pin
is configured as an input key that generates KEY_POWER events.
This event is handled by systemd-logind by initiating a
shutdown.


Si le système est démarré lorsque nous déclenchons cet événement, il agira donc comme si nous appuyions sur le bouton « Power » d’un système de bureau, éteignant le système et arrêtant le CPU.

Au-delà du numéro de broche GPIO, nous pouvons également configurer l’état de la broche lorsqu’elle doit déclencher l’événement (ici lorsqu’elle est tirée vers le bas), et puisque nous utilisons un commutateur mécanique, nous aimerions avoir un délai anti-rebond intégré avant le événement est déclenché.

Bien sûr, puisque nous pouvons configurer la broche GPIO ici, nous n’avons pas nécessairement besoin d’utiliser GPIO3 ici, ce qui peut être souhaitable puisque GPIO3 est également la broche I2C1 SCL (non remappable), et perdre l’accès au bus I2C primaire pourrait être un problème. Au lieu de cela, une autre broche GPIO (comme 17) pourrait être utilisée, avec la complication que l’utilisation d’un seul commutateur momentané comme dans l’exemple précédent ne serait plus possible sans sauter à travers quelques cerceaux supplémentaires.

Une autre superposition intéressante liée à la puissance est la gpio-poweroff une:

Name: gpio-poweroff
Info: Drives a GPIO high or low on poweroff (including halt). Using this
overlay interferes with the normal power-down sequence, preventing the
kernel from resetting the SoC (a necessary step in a normal power-off
or reboot). This also disables the ability to trigger a boot by driving
GPIO3 low.

Lors de l’utilisation d’un module d’alimentation externe, ce signal est utilisé pour couper l’alimentation du SBC et probablement arrêter l’alimentation elle-même jusqu’à ce qu’elle soit à nouveau réveillée par un autre signal. Cela pourrait éventuellement être utile dans des sites industriels et éloignés où un certain niveau d’automatisation et/ou d’économies d’énergie serait souhaitable.

Horloge en temps réel

Module d'horloge en temps réel (RTC) basé sur PCF8523.
Module d’horloge en temps réel (RTC) basé sur PCF8523.

Une fonctionnalité cruellement manquée sur les SBC Raspberry Pi est une horloge en temps réel (RTC), car cela signifie que sans accès à Internet, l’heure système n’aura pratiquement aucun sens. Heureusement, il est assez facile d’installer un certain nombre de modules RTC, tels que les omniprésents PCF8253, DS1307, DS3231 et les options haut de gamme.

La plupart de ces modules RTC communiquent en utilisant le bus I2C, ce qui signifie câbler 3,3 V, GND et les lignes I2C SCL/SDA. Notez que nous aurions déjà un conflit potentiel ici si nous utilisions la fonction de mise hors tension logicielle, car par défaut, il est supposé que nous utilisons le principal (i2c_arm) Bus I2C. Après cela, nous devons activer la superposition appropriée pour le module que nous utilisons.

Selon la documentation de superposition :

Name: i2c-rtc Info: Adds support for a number of I2C Real Time Clock devices Load: dtoverlay=i2c-rtc,<param>=<val>

Avec comme repli l’option logicielle I2C si on ne peut pas utiliser le bus I2C primaire :

Name: i2c-rtc-gpio
Info: Adds support for a number of I2C Real Time Clock devices
using the software i2c controller
Load: dtoverlay=i2c-rtc-gpio,<param>=<val>

Avec tout cela en place, nous n’avons qu’à nous occuper de la fausse horloge matérielle (fake-hwclock) qui est utilisée par défaut, sinon nous devrons régler manuellement la (fausse) heure hwclock à partir du RTC. Par exemple sur les systèmes d’exploitation basés sur Debian comme Raspberry Pi OS :

sudo apt-get -y remove fake-hwclock 
sudo update-rc.d -f fake-hwclock 
sudo remove systemctl disable fake-hwclock

Juste le commencement

Certains des fichiers DTBO (Device Tree Binary Overlay) qui font partie d'une image du système d'exploitation Raspberry Pi.
Certains des fichiers DTBO (Device Tree Binary Overlay) qui font partie d’une image du système d’exploitation Raspberry Pi.

Certains ont peut-être remarqué à ce stade que cette procédure avec des superpositions semble familière s’ils ont déjà installé quelque chose comme une carte son I2S sur un système Raspberry Pi. La raison en est que les DTBO de ces périphériques sont déjà présents et peuvent donc être chargés au démarrage sans autres modifications nécessaires.

Bien qu’une grande partie de cette fonctionnalité puisse être dupliquée par divers scripts shell et python dans le système d’exploitation lui-même, il est généralement plus simple de le faire sous la forme d’une superposition d’arborescence de périphériques, ne serait-ce que parce que tout ce qui est requis fait déjà partie du image du système d’exploitation par défaut. Cela signifie qu’il est également garanti de continuer à fonctionner, même lors des mises à niveau du noyau Linux et des packages.

Un simple coup d’œil aux fichiers DTBO fournis avec une image Raspberry Pi OS ou similaire donne une bonne idée du nombre de superpositions. Tout, depuis les DAC, les encodeurs rotatifs, divers écrans (LCD, OLED), les appareils Raspberry Pi officiels comme le PoE HAT, les cartes son et d’innombrables fonctionnalités et appareils liés aux GPIO, SPI et I2C.

Dans cet esprit, il semble judicieux de lire les superpositions README pour avoir une idée de ce qui est pris en charge et de le référencer avant de se lancer dans un nouveau projet sur un Raspberry Pi SBC. De même, il ne peut pas faire de mal de vérifier les superpositions disponibles sur d’autres plates-formes (ARM). Pour autant que vous le sachiez, la fonctionnalité que vous aimeriez avoir est une simple bascule de superposition.

François Zipponi
Je suis François Zipponi, éditorialiste pour le site 10-raisons.fr. J'ai commencé ma carrière de journaliste en 2004, et j'ai travaillé pour plusieurs médias français, dont le Monde et Libération. En 2016, j'ai rejoint 10-raisons.fr, un site innovant proposant des articles sous la forme « 10 raisons de... ». En tant qu'éditorialiste, je me suis engagé à fournir un contenu original et pertinent, abordant des sujets variés tels que la politique, l'économie, les sciences, l'histoire, etc. Je m'efforce de toujours traiter les sujets de façon objective et impartiale. Mes articles sont régulièrement partagés sur les réseaux sociaux et j'interviens dans des conférences et des tables rondes autour des thèmes abordés sur 10-raisons.fr.