Vérifier les modifications de device tree assistées par IA : du démarrage au périphérique réel

Une modification de device tree assistée par IA est une proposition de description matérielle. Une compilation réussie signifie que le source peut être traduit ; elle ne prouve ni que le chargeur a chargé cet arbre, ni que le bon pilote est associé, ni que le périphérique fonctionne correctement. La revue doit relier le diff généré au schéma de la carte, au noyau actif et à une transaction observable du périphérique.

L’exemple TMP102 suivant utilise une carte hypothétique et des extraits construits dans le style d’un code généré. Aucune exécution d’IA, aucun démarrage de carte ni aucune mesure de capteur ne sont revendiqués. Le fragment corrigé est volontairement incomplet et n’est pas une description de carte directement utilisable.

1. Fournir les preuves de la carte à l’assistant de rédaction

Indiquez les révisions exactes de carte et d’assemblage, le SoC, le commit du noyau, les correctifs fournisseur, la chaîne d’inclusion DTS/DTSI et le mécanisme de sélection du chargeur. Joignez les pages du schéma montrant bus, straps d’adresse, alimentation, résistances de tirage et interruption éventuelle. Fournissez aussi binding et pilote issus de l’arbre noyau effectivement compilé. La documentation amont guide la revue, mais un noyau fournisseur peut différer.

Pour cet exemple pédagogique, supposons qu’un TMP102 soit relié au contrôleur étiqueté i2c2, configuré à l’adresse sur sept bits 0x48, alimenté par une source nommée et que sa sortie ALERT ne soit pas connectée. Supposons un débit initial revu de 100 kHz. Ce sont des entrées explicites du scénario, pas des propriétés déduites d’une carte Obeita existante.

Demandez le plus petit correctif du fichier de carte, l’explication de chaque propriété ajoutée, les dépendances et un plan de vérification. Interdisez d’inventer groupes pinctrl, numéros GPIO et chaînes compatible. Si l’arbre SoC inclus définit déjà horloges ou resets du contrôleur, le brouillon doit conserver cette organisation, sans la dupliquer depuis un exemple sans rapport.

2. Comprendre pourquoi un brouillon plausible reste erroné

/* Deliberately flawed draft for an illustrative board. */
&i2c2 {
    status = "okay";
    clock-frequency = <1000000>;
    sensor@90 {
        compatible = "ti,tmp102";
        reg = <0x90>;
        interrupt-parent = <&gpio1>;
        interrupts = <7 2>;
    };
};

L’adresse illustre une erreur classique de représentation : 0x90 est l’octet d’adresse en écriture correspondant à l’adresse sur sept bits 0x48, mais la propriété reg de l’enfant doit employer la représentation exigée par le binding du bus. Copier un octet de transaction de la fiche technique dans le nœud décrit discrètement une autre adresse. L’adresse unitaire et reg concordent ; cette concordance seule est donc une preuve faible.

Le débit de 1 MHz n’est pas justifié par les données du projet. Les propriétés d’interruption ont été devinées malgré ALERT non connecté. Les indicateurs d’interruption numériques masquent aussi leur sens et peuvent relever d’un autre binding de contrôleur. L’absence d’informations pinctrl ou d’alimentation peut être tout aussi importante, même si certaines cartes héritent légitimement de réglages ailleurs. Il faut inspecter la chaîne d’inclusion avant de déclarer une propriété universellement obligatoire.

Le binding TMP102 amont fournit une référence concrète pour compatible, reg, l’interruption optionnelle, label et vcc-supply. Il ne décrit pas le câblage de cette carte. Cette distinction empêche qu’une réponse d’IA syntaxiquement soignée devienne un schéma inventé.

3. Examiner un fragment corrigé minimal

/* Partial teaching patch. Labels must exist in the board tree. */
&i2c2 {
    pinctrl-names = "default";
    pinctrl-0 = <&i2c2_board_pins>;
    clock-frequency = <100000>;
    status = "okay";

    temperature-sensor@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
        vcc-supply = <&sensor_vcc>;
        label = "board-ambient";
    };
};

Le fragment respecte le scénario : adresse sur sept bits, débit initial choisi explicitement, référence d’alimentation et aucune interruption fictive. Les labels pinctrl et régulateur représentent des définitions de carte existantes et revues. Avant usage, confirmez tension, responsabilité d’utilisation, polarité d’activation et séquencement. Si ces définitions n’existent pas, leur ajout demande une modification distincte justifiée par le matériel.

La correction peut être encore plus petite. Si l’inclusion de carte fournit déjà le bon état pinctrl ou clock-frequency, il peut être préférable de le conserver. Évitez un nettoyage généré qui réorganise d’autres contrôleurs, change des alimentations partagées ou introduit des overlays simplement pour activer un capteur. Un diff ciblé facilite le lien de cause à effet.

4. Valider le noyau choisi, puis l’artefact réellement démarré

Exécutez la validation des schémas dans le véritable arbre noyau. Le guide de validation des bindings distingue dt_binding_check pour les schémas et dtbs_check pour les arbres, et précise que dtbs_check peut ignorer les schémas invalides. Si un binding change, validez-le aussi. Gardez les journaux complets et séparez nouveaux échecs et problèmes préexistants.

# Proposed checks in the exact configured kernel source tree:
make ARCH=<target-arch> CROSS_COMPILE=<tool-prefix> dtbs_check   DT_SCHEMA_FILES=hwmon/ti,tmp102.yaml

# On a target that exposes its live tree, with appropriate access:
dtc -I fs -O dts /sys/firmware/devicetree/base > running.dts
# Review the actual controller path, compatible, reg and supply.
# Discover the matching hwmon device; do not assume hwmon0.

Les commandes sont des étapes proposées, pas un compte rendu d’exécution. Remplacez les paramètres d’architecture et de chaîne d’outils par ceux du projet. Un contrôle filtré par schéma est utile en revue, mais ne valide pas toutes les interactions de l’arbre de carte. Complétez-le par les contrôles DT et les exigences de compilation plus larges du projet. Conservez la configuration noyau qui active les pilotes du contrôleur et du capteur.

Notez nom et empreinte du DTB produit, étape d’assemblage de l’image, configuration du chargeur et emplacement déployé. Sur la cible, examinez les propriétés utiles de l’arbre actif. Le nom du fichier source ne prouve pas ce qui a démarré. N’exigez pas non plus une empreinte identique si le chargeur modifie légitimement des propriétés. Expliquez les modifications attendues et comparez les nœuds matériels pertinents.

5. Localiser la couche en défaut avec les journaux de démarrage

Collectez le journal série complet avant filtrage. Confirmez identités du noyau et de la carte, enregistrement du contrôleur, disponibilité des pilotes et erreurs éventuelles de régulateur ou pinctrl. Un probe différé peut signaler un fournisseur de ressource non prêt ; ce n’est pas automatiquement une chaîne compatible erronée. La documentation du modèle de pilotes du noyau décrit le probe différé lorsqu’une ressource nécessaire manque.

N’exigez pas un message de succès particulier : un pilote sain peut être silencieux. Vérifiez l’association périphérique–pilote et retrouvez la bonne instance hwmon par son nom et sa relation avec le périphérique. Les indices numériques d’adaptateur et hwmon peuvent changer. La documentation du pilote TMP102 décrit l’entrée de température et les autres attributs exportés. Vérifiez les unités dans la documentation d’interface applicable avant d’interpréter les valeurs.

6. Vérifier le vrai périphérique, y compris ses réactions aux défauts

• Identité et chemin : démontrez que nœud actif, bus physique et pilote associé correspondent au capteur voulu. Un répertoire dans sysfs ne suffit pas à prouver des mesures utiles.
• Entrée contrôlée : comparez les lectures à une référence indépendante appropriée en régime stable, puis appliquez une variation de température sûre et contrôlée. Définissez avant l’essai tolérance et temps d’établissement selon les exigences du projet et les spécifications du capteur.
• Comportement électrique : si la communication échoue, examinez tension d’alimentation, reset ou activation si applicables, et signaux du bus avec un équipement adapté. Une capture logique doit établir adresse, comportement ACK et timing ; elle ne prouve pas à elle seule la précision des mesures.
• Cycle de vie : prévoyez des démarrages à froid répétés, redémarrages à chaud et cycles de suspension/reprise pris en charge. Notez si le capteur est systématiquement détecté et revient dans le délai convenu.
• Gestion des défauts : sur un montage sûr, simulez une alimentation indisponible ou un capteur absent. La réception doit exiger une erreur visible et une politique de reprise, plutôt qu’une ancienne valeur plausible présentée comme fraîche.

Évitez les scans indiscriminés sur du matériel inconnu et les transactions I2C brutes concurrentes d’un pilote noyau déjà associé. Utilisez l’interface prévue et une procédure de diagnostic contrôlée. Gardez le DTB de référence et une procédure de récupération documentée avant les essais de démarrage.

7. Contenu de la revue finale

Livrez petit diff DTS, correspondance schéma–propriétés, entrées exactes de compilation, journaux de validation, identité du déploiement, journal de démarrage complet et preuves des essais du périphérique. Tout test proposé reste indiqué comme en attente tant qu’il n’a pas été exécuté. L’accord de deux brouillons d’IA ne remplace pas une preuve du câblage ou du fonctionnement.

Le service de diagnostic firmware et BSP d’Obeita convient à cette démarche de mise en route. Le projet de terminal embarqué RK3566 offre un contexte voisin d’intégration BSP et périphériques ; il ne prouve pas que ce correctif TMP102 hypothétique faisait partie du projet.