Expérience dans la création d'assemblages Linux pour les mises à jour sur une seule carte avec prise en charge

image

Présentation


À l'heure actuelle, le marché propose une large gamme de payeurs uniques pour tous les goûts à un prix abordable.

En règle générale, divers assemblages de fabricants sont conçus pour évaluer la plate-forme et sont le point de départ d'un nouveau projet, ils ne conviennent donc pas toujours à des tâches spécifiques. Dans les tâches où une haute fiabilité est requise, le développeur pose la question de savoir comment modifier le kit de distribution et ensuite ne pas le payer avec une révision complète de l'image et du système de mise à jour.

Sur Internet, il n'y a presque aucune information sur ce que la version devrait être et comment implémenter sa mise à jour, donc le développeur est obligé de proposer un «vélo» ou d'utiliser ses propres développements, qui ne sont pas toujours testés à 100%.

Étant donné que je participe au développement de logiciels pour différents appareils Linux (mon portfolio peut être google par le mot develinux) et que je suis également l'auteur du projet en 11 parties, je dois régulièrement m'occuper non seulement de construire des assemblages, mais aussi de développer des mécanismes de mise à jour via WEB ou USB flash.

Dans cet article, je souhaite partager mon expérience et mes connaissances dans des domaines pertinents.

Exigences d'assemblage


Dans le processus de développement d'assemblages et de mises à jour pour divers appareils, j'ai identifié plusieurs exigences pour moi-même:

  • l'ensemble ne doit pas être endommagé lorsque l'alimentation est coupée soudainement;
  • l'assemblage doit se charger rapidement;
  • le chargeur de démarrage devrait fonctionner parfaitement;
  • l'assembly doit prendre en charge la mise à jour.

J'essaierai d'expliquer ces exigences plus en détail ci-dessous, puis je décrirai 3 approches dans la division des images en sections et leurs mises à jour.

L'ensemble ne doit pas être endommagé lorsque l'alimentation est coupée soudainement.


Qui a besoin d'un appareil qui ne fonctionne plus après un dixième redémarrage? À personne! Si vous prenez des distributions prêtes à l'emploi (et il y en a très peu pour les incorporées), alors sans un fichier de la boîte, elles sont toutes très peu fiables à cet égard. Je me souvenais très bien du projet où j'utilisais ubuntu sous imx6, les systèmes de fichiers sur la carte étaient endommagés, parfois à partir du dixième redémarrage, parfois à partir de la quarantième, cela dépendait des étoiles dans le ciel. Le projet a sauvé FS aufs. Le fait est que ubuntu n'est pas conçu pour être en lecture seule et qu'il doit toujours écrire quelque chose. Je me souviens d'une situation similaire dans un autre projet où yocto était utilisé sur une carte SD. En général, notez donc que les cartes SD sont le type de lecteur le plus laid qui plante le plus rapidement, beaucoup plus fiable que emmc et nand. Si vous utilisez une carte SD, il est conseillé de lui écrire le moins possible pendant le fonctionnement, les algorithmes de transfert en arrière-plan pour les secteurs sont très imprévisibles, j'ai travaillé avec des dizaines de cartes SD différentes de marques mondiales et je n'ai pas trouvé une seule carte que je pourrais recommander.
Mais les cartes SD ont plusieurs avantages, elles sont abordables, peu coûteuses et pratiques pour le débogage des logiciels.

Pourquoi suis-je ... Et, voici le problème - le FS racine doit être en lecture seule, il ne doit y avoir aucune entrée pendant le fonctionnement. Vous penserez probablement: comment cela? Des millions d'appareils Android écrivent toujours quelque chose et n'échouent pas. C'est vrai, mais c'est tout parce que la plupart des appareils Android, d'une part, ont une batterie, et d'autre part, la racine FS est encadrée comme un disque virtuel et la partition système est en lecture seule.

Si le système doit être fiable, alors toutes sortes de choses avec l'installation de packages dans la racine FS peuvent gâcher beaucoup. Je recommande squashfs comme système de fichiers. Il fonctionne rapidement, ne peut rien écrire, économise de l'espace grâce à la compression ...

Mais qu'en est-il de l'enregistrement des configurations, du téléchargement de fichiers, etc. demandez-vous?
Mais pour cela, vous devez créer des partitions RW distinctes. Si vous prévoyez d'écrire en NAND, je recommande une option éprouvée - UBIFS. Si dans NOR, alors jffs2. Si j'écris sur un autre lecteur, je recommande ext4, btrfs, ReiserFS, je ne peux pas indiquer le meilleur FS parmi eux, car il y avait divers problèmes avec tout le monde.

Dans ce cas, toujours avant de monter des partitions rw, assurez-vous de vérifier les partitions pour les erreurs en utilisant des utilitaires de type fsck.

L'assemblage doit se charger rapidement


Les vitesses de téléchargement des appareils affectent la convivialité globale. Dans certaines tâches, le temps de chargement ne dépasse pas 30 secondes, dans certaines, 5 minutes sont autorisées. Pour moi, j'ai travaillé jusqu'à 1 minute, moins c'est mieux. Attendez le téléchargement pendant plus d'une minute pendant trop longtemps, il peut sembler que l'appareil s'est bloqué, donc si vous pouvez réduire le temps, il est préférable de l'utiliser.

Le chargeur de démarrage doit fonctionner correctement


Le chargeur est ce sans quoi l'assemblage ne commencera pas. Récemment, j'observe souvent comment les fabricants de cartes simples facilitent le développement en téléchargeant une démo pour une carte SD avec une description de la façon d'enregistrer un chargeur de démarrage ou une image finie avec un chargeur de démarrage, qui est simplement remplie avec la commande dd. Mais que faire si la carte SD se fige? La même chose n'est pas rare. Personnellement, dans ma pratique, les cartes tombaient souvent. C’est ainsi que vous travaillez pour plusieurs heures pendant des heures, vous écrivez des logiciels, bam et c’est tout ... des erreurs dans le noyau commencent à couler, la carte est tombée. Mais que faire si c'est un appareil qui devrait fonctionner sur le terrain sans redémarrer? Et au fait, le redémarrage, y compris le chien de garde, ne fait pas toujours revivre une carte bloquée, la carte n'a pas de signal de réinitialisation, ce n'est pas emmc, bien sûr, c'est plus une question pour les circuits de la carte, si la carte a une réinitialisation de la puissance de la carte, cela économisera, mais ce n'est pas partout. Sur certaines cartes, seule une distorsion de l'alimentation ou de la carte est utile. D'après mon expérience, je ne recommande pas de stocker le chargeur de démarrage sur le lecteur avec l'ensemble principal si l'enregistrement est effectué sur le lecteur pendant le fonctionnement. Si le système n'écrit rien sur le lecteur avec le chargeur de démarrage, et cela se produit rarement, alors s'il vous plaît. D'après mon expérience, en mode lecture seule, le système de fichiers a été déformé uniquement en raison d'erreurs matérielles, mais pas d'erreurs logicielles.

Le chargeur de démarrage doit être stocké dans un endroit sûr, sur un lecteur fiable, par exemple, dans une puce NOR ou EEPROM distincte. Voici un exemple de module basé sur la puce imx6ull, avec SPI NOR pour stocker le chargeur de démarrage.

image

La version doit prendre en charge la mise à niveau


Sans mise à jour, nulle part ... J'ai participé à de nombreux projets et je n'ai jamais obtenu le logiciel parfait pour la livraison du travail. Une erreur est toujours détectée ou une amélioration fonctionnelle est requise. Vous devez comprendre que pendant que les gens écrivent des logiciels, ils feront des erreurs, tandis que les gens utiliseront l'appareil, ils en voudront un peu plus. Dans 90% des cas, l'absence d'un système de mise à jour bien pensé peut conduire à la fois à un casse-tête pour le constructeur et à l'effondrement de l'ensemble du projet. Par exemple, un système de vidéosurveillance a été développé pour le transport, le système a été installé dans toute la Russie, et il s'avère que les spécialistes du marketing ont sous-estimé le marché et n'ont pas fourni de streaming, et d'ailleurs, plusieurs erreurs ont été trouvées dans le firmware, plus le consommateur commence à regarder dans la direction des concurrents, car ils ont il y a juste quelque chose qui n'est pas dans l'appareil acheté ... Oui, oui, dans un jardin étrange, les fraises sont plus savoureuses et le temps est meilleur (psychologie).
Que faire dans une telle situation? Si la mise à jour est prise en charge, il existe de nombreuses solutions, des erreurs peuvent être corrigées, la diffusion de flux peut être améliorée et la fonctionnalité peut être personnalisée pour le consommateur, donner au micrologiciel du consommateur des instructions et c'est tout. Mais si ce n'est pas pris en charge, le fabricant aura de grandes aventures avec des voyages d'affaires d'ingénieurs de service jusqu'au remplacement des appareils.

Le système de mise à jour de l'appareil doit être pensé dans les moindres détails et testé à 100%. Une erreur dans cette partie transformera le fer en brique, il ne devrait donc pas y avoir de tolérances et d'exceptions.

Le processus de mise à jour doit être résistant à la mise hors tension et ne doit en aucun cas gâcher l'appareil.

Un aperçu des approches de partitionnement pour les futures mises à jour


Parmi les nombreuses approches, je peux recommander 3 types que j'ai personnellement mis en œuvre. Ce ne sont pas toutes des approches; leur portée dépasse le cadre de cet article. Les 3 types ont des défauts et sont loin d'être idéaux, mais, comme il me semble, sont proches du juste milieu du bon sens.

Approche n ° 1


image

Le moyen le plus simple et le plus abordable:
Une image est placée sur un lecteur, par exemple une carte SD, qui est flashée depuis u-boot dans le lecteur intégré de l'appareil, par exemple, le flash NAND.
Dans u-boot, vous devez préparer des scripts pour cela.
Parmi les avantages, il s'agit du type de mise à jour le plus simple, dont le développement prendra au maximum 1 jour.
Les inconvénients de cette approche sont le manque de visualisation du processus et les capacités très limitées du chargeur de démarrage, c'est-à-dire pas de logique compliquée avec des outils standard, à moins bien sûr de trouver votre propre commande u-boot (mais c'est un autre type de mise à jour, C est une grande force). Cette méthode n'est pas destinée aux mises à jour via WEB - il est problématique de contrôler l'intégrité de l'image du firmware; dans certains cas, la taille de l'assemblage ne doit pas dépasser la taille de la RAM.
De plus, dans certaines tâches, il est nécessaire d'enregistrer les paramètres pendant la mise à niveau, et cela, avec cette approche, n'est pas facile à mettre en œuvre.

Approche n ° 2


image


La méthode la plus fiable et la plus protégée des envisagées, mais la plus difficile. Je recommande que cette méthode soit utilisée dans des développements particulièrement responsables, Il protège à la fois des images cassées et des dommages physiques du lecteur principal, car le circuit en utilise un autre.

L'approche utilise une construction minimale (taille du disque virtuel de 8 à 16 Mo) et la principale. Ramdisk est une archive compressée, donc une construction de 16 Mo sera physiquement plusieurs fois plus petite.
Le but d'un assemblage minimal est d'évaluer l'assemblage principal et de le charger.
Ramdisk est hébergé avec le noyau et les scripts u-boot dans une image FIT.

Pourquoi l'image FIT et que donne-t-elle? L'image FIT est un format pris en charge par u-boot. Il assure l'intégrité de tous les composants (noyau, dts, ramdisk, scripts). Le déballage de l'image FIT s'effectue en u-boot, et si la somme de contrôle ne converge pas, u-boot refusera de la charger. C'est pratique, c'est-à-dire pas besoin de s'occuper du contrôle d'intégrité par vous-même, pas besoin d'écrire plusieurs fichiers séparément ou d'inventer vos propres images, tout se fait par image FIT. Habituellement, une image FIT occupe 7 à 20 Mo, elle doit être écrite sur un lecteur distinct hautement fiable, par exemple, en qspi ni en flash. L'ensemble principal peut être stocké dans une mémoire moins chère et peu fiable, par exemple, un flash NAND. Puisque les travaux principaux auront lieu dans l'ensemble principal, c'est précisément lui qui sera le premier endommagé. Dans ce cas, un lecteur séparé avec un minimum de rootfs viendra à la rescousse.

Processus de démarrage.

u-boot télécharge un script qui essaie d'utiliser les mises à jour FIT (FIT2), puis le firmware d'usine FIT (FIT1).

Si FIT2 n'est pas présent ou que son intégrité est violée, le test d'ajustement échouera et u-boot chargera le premier FIT (FIT1). S'il y a des mises à jour FIT (FIT2), et qu'il n'est pas cassé, alors son ramdisk est chargé qui vérifie les mises à jour rootfs (Rootfs2).

Si Rootfs2 est cassé, les scripts supprimeront les mises à jour FIT (FIT2), puis après le redémarrage, l'image d'usine composée de FIT (FIT1) et Rootfs1 sera téléchargée.

Processus de mise à jour.

L'image de mise à jour contient FIT, rootfs et diverses informations d'assemblage, y compris les sommes de contrôle de tous ses composants. Les informations d'assemblage sont utilisées pendant la mise à niveau pour surveiller l'intégrité et la compatibilité.

Mettre à jour la progression par étapes:

  • vérifier la compatibilité de l'image avec le matériel et les logiciels,
  • vérifier l'intégrité de l'image dans le fichier de mise à jour,
  • copier Rootfs2 du fichier de mise à jour dans une section préalablement préparée,
  • vérification de l'intégrité de l'image copiée dans la section,
  • copier FIT2 dans la section appropriée,
  • redémarrer.

Si le processus échoue, l'absence ou l'endommagement de FIT2 ne ruinera pas le système, comme u-boot refusera simplement de l'utiliser et chargera l'image d'usine. Par conséquent, pendant la mise à niveau, l'intégrité de FIT2 n'est pas vérifiée.

Après la mise à jour, le nouvel assemblage sera placé sur le lecteur principal sous la forme de FIT2 et Rootfs2.

Cette méthode résiste aux dommages mécaniques du variateur et aux erreurs FS.

En cas de dysfonctionnements critiques, l'image d'usine démarrera, où le logiciel de récupération fonctionnera, qui, par exemple, peut revérifier NAND, télécharger le micrologiciel à partir du réseau en utilisant le protocole SSH, puis l'enregistrer.

J'ai donné juste un exemple de récupération, il existe de nombreuses options. Dans cette approche, le processus de récupération est piloté par un Linux à part entière, qui peut tout faire ... et non par le chargeur de démarrage comme dans la première version.

Approche n ° 3


image


Ce type de mise à jour est utilisé dans presque tous les projets en 11 parties, car il a très bien fonctionné.

La mise à jour convient à toutes les tailles d'assemblage, à tous les types de lecteurs. Contrairement au type précédent, ici SPI NOR n'est utilisé que pour le u-boot, il a donc une taille plus petite et un coût inférieur, 1 Mo suffit.

Ce type de mise à jour ne nécessite pas de build séparé de ramdisk, ce qui signifie que le temps de programmation est économisé pour son développement et son support à l'avenir.

L'exemple utilise un lecteur de carte SD, mais il peut également être NAND en utilisant UBIFS, aucune différence. Dans cette approche, il n'y a pas de contrôle de Rootfs RO avant le chargement, si l'ensemble est endommagé, le système ne saura pas qu'il a été endommagé et le chargera en cercle. Ici, il est supposé que les données de la section RO ne peuvent en aucun cas être modifiées, cette approche élimine le dysfonctionnement physique du variateur. Si le lecteur n'est pas physiquement sain, l'appareil doit être transporté dans un centre de service, aucune auto-guérison n'est fournie. C'est le prix à payer pour augmenter la vitesse de développement, un support moins cher et une base élémentaire moins chère, mais c'est justifié. Pourquoi s'assurer contre quelque chose qui n'arrive presque jamais.

La logique de téléchargement et de mise à jour est la même que dans l'approche précédente.

Dans le cas du chargement, u-boot télécharge d'abord les mises à jour FIT (FIT2), s'il n'y est pas ou que l'intégrité est violée, u-boot charge le premier FIT (FIT1), l'assemblage qui a été cousu en usine démarre, et ainsi de suite jusqu'à la mise à jour du système. Lorsque le système est mis à jour, FIT2 et Rootfs2 apparaissent. Dans ce cas, au démarrage de l'appareil, la mise à jour FIT (FIT2) démarre en premier. Dans les scripts u-boot qui sont stockés dans chaque FIT, il doit être écrit quels rootfs monter.

Partition partagée RW


Sur les graphiques, il y a un bloc de partition partagé partout, c'est un groupe de sections pour l'écriture. Toutes les entrées sont faites uniquement là-bas. La partition partagée est présentée comme une partition pour plus de clarté. En fait, il y en a 3: deux petits pour les configurations fonctionnant dans le miroir et un grand pour tout le reste. De plus, je vous recommande de conserver certaines configurations lors de la mise à jour, ce qui est pratique, par exemple, si vous configurez le réseau et effectuez une mise à niveau, vous n'aurez pas besoin de reconfigurer les paramètres réseau.

Pour résumer


L'article décrit trois types d'assemblages avec prise en charge des mises à jour, tous vérifiés par moi personnellement, vous pouvez les utiliser en toute sécurité dans les projets.

Pour le moment, je n'utilise que les deux derniers, car ils conviennent le mieux aux exigences. Pour plus de clarté, vous pouvez voir des exemples d'appareils où ces types de mises à jour sont utilisés (détails dans la gamme de 11 pièces):

  • Répéteur RS485 via 4G / WiFi / LAN,
  • Carte de commande de contrôleur d'affichage industriel 4K V-By-One,
  • système de climatisation intégré au hangar,
  • Contrôleur vidéo d'affichage industriel 2DisplayPort-LVDS,
  • système de contrôle de ligne
  • Passerelle VPN.

Si mon article est utile et intéressant, je suis prêt à partager mon expérience et mes solutions techniques éprouvées dans le domaine du Linux embarqué sur ce site.

Merci à tous.
Gorchakov Ilya
télégramme: develinux

Source: https://habr.com/ru/post/fr470519/


All Articles