Réception d’un portage U-Boot : supports, environnement et récupération

Un portage U-Boot doit être réceptionné comme un système de démarrage et de récupération, pas simplement comme une console fonctionnelle. Il doit sélectionner la source prévue, charger le bon ensemble logiciel, traiter un état persistant invalide et fournir un retour documenté lorsque l’image principale ne démarre plus.

Cette liste vise les produits utilisant U-Boot dans une chaîne Linux embarquée. Commandes, stockage de l’environnement, premiers chargeurs et fonctions de sécurité varient selon version et carte. Les exemples sont des conceptions de réception, sans prétendre qu’une carte Obeita particulière les a réussies.

1. Définir ce que comprend le portage

Listez ROM du SoC, SPL ou premier chargeur fournisseur éventuel, initialisation DDR, firmware de confiance, U-Boot principal et passage à Linux. Attribuez responsable et version à chaque composant. Si un binaire DDR propriétaire est nécessaire, précisez son mode de redistribution autorisé et sa configuration mémoire exacte.

Définissez révisions matérielles et supports de démarrage acceptés. « Compatible eMMC et SD » ne dit pas si SD sert au développement, au secours automatique ou à la récupération autorisée sur site. Décrivez l’interaction des straps, supports amovibles et paramètres logiciels. Distinguez le choix de support par la ROM de la sélection ultérieure d’un noyau ou bootflow par U-Boot.

Convenez de l’inclusion éventuelle du démarrage sécurisé, des mises à jour signées, de l’anti-retour et des restrictions console. Ces fonctions exigent une conception de bout en bout ; une option de compilation ne crée pas seule une chaîne de confiance complète.

2. Tester la politique des supports avec des entrées contradictoires

Pour chaque support, documentez contrôleur, numérotation, partitions, offsets d’image et système de fichiers. Capturez le périphérique détecté dans le journal. Ne supposez pas une correspondance permanente entre numéros U-Boot et noms Linux.

Testez support normal seul, support de récupération seul, les deux présents et aucun contenant une application valide. Utilisez deux compilations visiblement distinctes pour vérifier la priorité ; sinon, un démarrage depuis le mauvais support peut sembler réussi. Confirmez après démarrage froid et reset chaud.

Avec U-Boot Standard Boot, documentez périphériques, méthodes activées et ordre de recherche voulu. C’est un cadre configurable, pas une garantie de prise en charge de tout support et format dans chaque compilation. Consultez la documentation Standard Boot de la version choisie.

Un inventaire en lecture seule peut utiliser les commandes suivantes lorsqu’elles existent dans le portage. Sélection des périphériques et inspection détaillée du stockage restent spécifiques à la carte.

version
bdinfo
printenv bootcmd bootargs bootdelay
mmc list

Conservez la sortie avec le dossier de version. Ne copiez pas de commandes d’effacement, d’écriture ou de réinitialisation d’environnement d’une autre carte : un mauvais offset peut détruire l’unique copie amorçable.

3. Faire de l’environnement une interface maîtrisée

Décrivez emplacement, taille, redondance éventuelle, contraintes d’unité d’effacement et lien avec les partitions. Distinguez valeurs intégrées, valeurs actuellement chargées et valeurs réellement enregistrées en mémoire non volatile. Dans U-Boot, modifier en mémoire et sauvegarder sont deux opérations distinctes ; voir la documentation de l’environnement.

Classez les variables en politique de démarrage, facilités de développement et identité propre à l’unité. Un retour usine ne doit pas dupliquer ou effacer par accident identité unique, calibration ou provisionnement. Définissez ce qu’un technicien peut modifier et comment les valeurs non prises en charge sont refusées ou récupérées.

Sur des unités récupérables, testez environnement absent, contrôle d’intégrité invalide et mise à jour interrompue. Le résultat attendu doit nommer les valeurs par défaut ou la copie redondante sélectionnée et leur identification par l’opérateur. La redondance n’aide que si le stockage et l’ordre des écritures soutiennent réellement le comportement attendu en cas de coupure.

Testez aussi la migration depuis un ancien environnement valide. Un nouveau binaire peut continuer à charger une ancienne commande et contourner silencieusement les nouvelles valeurs par défaut. Intégrez schéma ou politique de migration au processus de version, sans supposer que reflasher U-Boot efface l’état persistant.

4. Vérifier le passage complet à Linux

Conservez ensemble les identités du noyau, du Device Tree, de l’initramfs éventuel et de la racine. Vérifiez l’absence de chevauchement des adresses entre elles, avec les régions réservées ou avec les besoins de décompression. Recommencez avec la plus grande image autorisée, pas seulement la petite image de développement.

Vérifiez que la ligne de commande finale sélectionne racine et console prévues, ainsi que l’identité de carte et la mémoire transmises. Le succès doit atteindre l’état applicatif prêt défini ; un premier message noyau ne valide ni système de fichiers ni application.

Pour une conception signée, testez une image autorisée valide et des modifications volontaires du contenu protégé avec un plan de récupération de laboratoire. La documentation Verified Boot décrit la vérification des signatures dans une chaîne de confiance. Une somme de contrôle détecte une corruption accidentelle, sans remplacer l’authentification ; une signature seule ne garantit pas l’anti-retour.

5. Définir comptage des échecs et signal de succès

Un compteur de tentatives doit correspondre au stockage et au reset. Décidez quels échecs l’incrémentent, quand il persiste et quand il s’efface. La documentation Boot Count décrit limite et démarrage alternatif, avec des détails de persistance propres aux implémentations. Vérifiez la compilation exacte au lieu d’inférer le comportement du nom d’une variable.

N’effacez l’état de tentative de mise à jour qu’après le contrôle de santé requis. Déclarer le succès dès init peut valider une image dont l’application ne peut pas ouvrir ses appareils. Inversement, exiger un serveur externe indisponible peut provoquer le retour d’un système local sain. Définissez le succès selon le produit, en séparant disponibilité locale et réseau optionnel.

Choisissez une récupération bornée : emplacement connu comme bon, image dédiée ou procédure de maintenance documentée. Évitez une boucle sans fin qui détruit les preuves ou use le stockage sans produire un appareil utilisable.

6. Exécuter une matrice explicite de défauts

• Noyau absent : le chemin de démarrage donne une cause reconnaissable et prend le secours convenu.
• DTB erroné ou endommagé : les combinaisons incompatibles sont refusées si la conception permet leur validation, ou échouent vers un chemin récupérable.
• Racine inutilisable : la mise à jour n’est pas déclarée réussie simplement parce que le noyau a démarré.
• Mise à jour interrompue : une image saine ou une restauration reste disponible à tous les points d’interruption convenus.
• Réseau indisponible : démarrage réseau de développement et secours de production possèdent des limites temporelles.
• Commande de récupération : l’opérateur autorisé peut l’utiliser avec le boîtier et le câblage définitifs.

N’écrasez pas toutes les copies redondantes simultanément, sauf si la perte totale du support est explicitement prévue et la restauration externe prouvée. Documentez nombre d’échantillons, points d’interruption et résultats. Réussir certains tests ne prouve pas la tolérance à toute coupure possible.

7. Livrer de quoi restaurer la carte

Le dossier doit inclure révisions sources, defconfig, correctifs, outils, images empaquetées et hashes, plan de stockage, politique d’environnement, preuves et procédure détaillée de restauration. Indiquez les étapes nécessitant accès physique, outils fournisseur ou service de signature distinct. Ne placez jamais les clés privées de signature dans une archive ordinaire.

La configuration de projet de passerelle Linux RK3528 d’Obeita évoque explicitement accès de récupération et séparation alimentation/OTG. C’est un exemple de périmètre, pas l’affirmation que tous les mécanismes décrits sont implémentés. Pour une revue, consultez Diagnostic firmware et BSP et préparez journal actuel, carte du stockage et procédure de restauration.