Mise en service d’une carte Linux : de l’alimentation à l’application

Une carte Linux personnalisée n’est pas mise en service simplement parce qu’une invite de connexion apparaît. Le jalon utile est une chaîne reproductible allant d’une alimentation et d’un reset corrects à une image vérifiée, des pilotes fonctionnels et une application capable de récupérer après ses pannes prévues.

Ce guide propose une mise en service par étapes pour les cartes Linux embarquées utilisant Device Tree, notamment ARM et AArch64. La ROM du SoC, le circuit de gestion d’alimentation, l’initialisation DDR et le BSP du fournisseur déterminent la séquence exacte. Les tests proposés sont des vérifications techniques, pas des résultats mesurés sur un produit particulier.

1. Préparer les preuves et la récupération

Avant la mise sous tension, réunissez schémas, révision d’assemblage, substitutions de composants, arbre d’alimentation, topologie DDR, straps de démarrage et brochages. Comparez la carte assemblée au schéma de référence plutôt que supposer l’équivalence électrique du routage. Confirmez les broches de débogage encore accessibles après assemblage.

Préparez une alimentation limitée en courant adaptée, des instruments correctement dimensionnés, un adaptateur série vérifié et le mode de récupération du fournisseur. Un UART TTL doit correspondre au domaine de tension ; un adaptateur RS232 n’est pas interchangeable. Débranchez les charges non maîtrisées et recherchez les alimentations involontaires via USB ou débogage.

Classez le journal de mise en service par numéro de carte, révision et hash d’image. Capturez la console depuis l’application de l’alimentation. Notez cavaliers et nature du redémarrage : démarrage réellement froid ou reset logiciel. Un état périphérique conservé ne doit pas être confondu avec une initialisation réussie.

2. Vérifier alimentation, reset et horloges

Avant d’alimenter, vérifiez résistances et défauts d’assemblage évidents selon la procédure matérielle. Ensuite, mesurez niveaux et séquencement des rails selon les composants choisis. Capturez la libération du reset par rapport à la stabilisation des tensions et aux horloges. Une lecture au multimètre ne démontre pas la séquence et n’exclut pas un bref transitoire.

Si le courant est inattendu, arrêtez et enquêtez avant de multiplier les démarrages. Sans console, vérifiez niveaux, hypothèses de multiplexage, débit série et source de démarrage. Certaines ROM n’émettent aucune bannière. Utilisez l’énumération de récupération documentée ou un autre indicateur fournisseur pour distinguer « ROM active » de « UART silencieux ».

Ne masquez pas un problème électrique par des délais logiciels arbitraires. Un délai peut aider à localiser un défaut de séquence, mais l’exigence finale doit nommer la dépendance réelle et son timing admissible.

3. Prouver le premier chargeur, la DDR et le stockage

Identifiez toutes les étapes exécutables. Selon la plateforme, la ROM peut charger SPL, initialisation DDR propriétaire, firmware sécurisé puis U-Boot. Notez versions et positions dans le paquet. Une panne apparemment Linux peut provenir d’un mauvais composant d’entraînement DDR inclus dans l’image.

Avant de charger l’application, suivez la validation DDR du fournisseur et des tests mémoire sûrs. Évitez toute écriture destructive sur le chargeur actif, les zones réservées au firmware ou les buffers de diagnostic. Répétez les démarrages froids dans les conditions convenues. Un démarrage chaud réussi ne valide pas l’initialisation DDR froide.

Pour eMMC, SD ou autre stockage, vérifiez détection, capacité, réglages de bus et partitions. Comparez la relecture à l’image programmée par une méthode non destructive documentée. Si l’échec n’apparaît qu’en mode rapide, examinez intégrité du signal, commutation de tension, timings et pilote avant d’accepter un débit définitivement réduit comme solution.

4. Transmettre la bonne description matérielle à Linux

Device Tree décrit topologie et ressources ; il ne crée pas un pilote absent et ne corrige pas le câblage. Horloges, régulateurs, resets, interruptions et broches doivent correspondre à la carte. Le modèle d’utilisation Linux de Device Tree explique son rôle dans l’identification, la configuration et la création des périphériques.

Versionnez ensemble noyau, DTB, modules et firmwares. Un DTB de carte de référence peut démarrer tout en décrivant une mauvaise alimentation ou interruption. Validez avec les schémas disponibles dans l’arbre choisi. La documentation des bindings distingue la vérification des schémas de celle des données DT.

# Run in the configured kernel source tree with its required tooling.
make dt_binding_check
make dtbs_check

Ces vérifications détectent des erreurs structurelles et de bindings, sans prouver la correspondance au câblage. Un noyau fournisseur peut comporter des schémas anciens ou des extensions non documentées. Consignez les différences plutôt que supprimer les avertissements sans comprendre.

Pour AArch64, la transition du chargeur impose aussi des conditions d’emplacement des images, de Device Tree et d’état processeur. Consultez le protocole de démarrage AArch64 du noyau choisi plutôt que copier les adresses d’une autre carte.

5. Distinguer noyau prêt et système racine prêt

Si le noyau démarre sans monter la racine, vérifiez identifiant de racine, disponibilité du pilote de stockage, support du système de fichiers et hypothèses d’initramfs. Un pilote uniquement en module ne peut monter le système qui le contient, sauf s’il est chargé par une étape utilisateur antérieure. Conservez la première erreur, pas seulement le panic final.

Après le démarrage utilisateur, confirmez processus init attendu, emplacements inscriptibles, permissions des périphériques, initialisation de l’heure et dépendances des services. Vérifiez noyau, modules et application actifs par rapport au manifeste. Une connexion SSH ne prouve pas toutes les exigences de stockage, réseau ou périphériques.

6. Mettre en service un chemin périphérique à la fois

Établissez une table reliant étiquettes des connecteurs, noms Linux, pilotes et rôles applicatifs. Pour chaque appareil, testez détection, fonction élémentaire, charge prévue, déconnexion lorsqu’elle est possible et redémarrage. Un écran exige timings de dalle et rétroéclairage ; le contrôleur tactile nécessite sa propre validation des interruptions et coordonnées. Le fonctionnement de l’un ne valide pas l’autre.

Lorsqu’un périphérique ne s’initialise pas, cherchez la première dépendance en erreur : régulateur, horloge, reset ou firmware manquant peut produire des symptômes ultérieurs évoquant un défaut de pilote. Activez des traces ciblées. Le dynamic debug Linux sélectionne les points pris en charge par module, fichier ou fonction lorsque le noyau est configuré pour cela.

7. Tester la récupération avant livraison de l’application

• Démarrez avec un périphérique optionnel volontairement absent et vérifiez que les services requis atteignent leur état prêt défini.
• Coupez le réseau d’essai pendant l’application, puis vérifiez reprises bornées et récupération sans commandes dupliquées.
• Utilisez une partition de test contrôlée pour simuler le stockage plein. Les logs ne doivent pas consommer tout l’espace nécessaire à l’application.
• Sur une unité de laboratoire récupérable, testez mises à jour interrompues et images corrompues convenues, sans écraser l’unique voie de récupération.
• Répétez démarrages froids, resets chauds et cycles veille/réveil requis, en consignant conditions exactes et échecs.

Si le diagnostic persistant utilise ramoops, réservez la mémoire adéquate et vérifiez sa conservation par le reset choisi. Ramoops ne garantit pas la conservation lors d’une coupure d’alimentation ; voir sa documentation noyau. Les preuves de réception doivent distinguer données capturées et conditions non testées.

Un périmètre concret de mise en service

La configuration de projet de terminal RK3566 et d’adaptation BSP d’Obeita décrit un terminal lié à une dalle particulière avec périphériques FPC. Elle distingue explicitement interfaces routées et interfaces exigeant une révision matérielle. C’est une limite pertinente, plutôt que présumer disponibles toutes les fonctions du SoC sur le produit assemblé.

Pour une évaluation Diagnostic firmware et BSP, fournissez révision, schéma, journal de démarrage froid complet, manifeste et première étape en échec. Une frontière précise offre généralement un meilleur point de départ que « Linux ne fonctionne pas ».