Remplacer un module Wi-Fi : valider pilote Linux et Device Tree

Remplacer un module Wi-Fi sur un produit Linux modifie matériel, pilote, firmware et politique de fonctionnement. Un module adapté à l’empreinte peut demander une autre séquence d’alimentation, un autre fichier firmware, des réglages de bus ou des fonctions utilisateur différentes. Réussir un scan n’est que le premier jalon.

Ce guide traite la validation technique des produits Linux embarqués avec Wi-Fi SDIO, USB ou PCIe. Il ne suppose ni pile sans fil ni modèle Device Tree identiques pour tous les modules. Les essais constituent un plan de réception, pas une mesure de débit, une homologation ni une garantie de substitution directe.

1. Créer une matrice de substitution avant de modifier le logiciel

Comparez ancien et nouveau modules par référence de commande exacte et révision. Notez interface hôte, alimentations, tension E/S, reset, activation, horloges, interruptions ou réveil, antennes et coexistence. Vérifiez chaque fonction de broche. Une forme et un connecteur compatibles ne prouvent pas la compatibilité électrique.

Listez les rôles requis : station, point d’accès, interfaces simultanées, veille/réveil, itinérance et coexistence Bluetooth si nécessaire. Un pilote capable de s’associer en station ne prend pas forcément en charge le mode AP ou la combinaison d’interfaces demandée. Identifiez noyau et branche BSP avant d’évaluer les pilotes.

Obtenez les documents d’intégration et conditions de redistribution du firmware auprès du fournisseur. Identifiez calibration et configuration non volatile propres à la carte, ainsi que leur association au montage. Ne réutilisez pas la calibration d’un autre produit au seul motif que le chipset porte le même nom.

2. Établir une référence pilote et firmware

Identifiez si le pilote est dans l’arbre noyau retenu, fourni par le BSP ou maintenu séparément. Notez commit exact, configuration, identifiants pris en charge et dépendances. Un module externe compilé pour un autre noyau peut échouer à cause des API, réglages ou versions de modules ; copier son binaire n’est pas une stratégie de portage.

Distinguez pilote hôte et firmware exécuté dans la radio. L’API de chargement Linux demande des firmwares nommés, mais fichiers corrects et données de carte restent spécifiques au pilote et au matériel. Voir la documentation de demande de firmware. Capturez noms demandés et premières erreurs plutôt que renommer des fichiers sans rapport jusqu’à disparition d’un avertissement.

Créez un manifeste comprenant noyau, modules, DTB, firmware radio, données de carte et configuration réseau utilisateur. Vérifiez les fichiers effectivement installés. Un système de développement fonctionnel peut masquer une dépendance absente de l’image de production propre.

3. Ne changer que la description matérielle applicable

Pour SDIO, vérifiez contrôleur hôte, largeur du bus, références d’alimentation, broches, séquencement, hypothèses de support amovible et câblage d’interruption ou de réveil hors bande. Employez les bindings de l’arbre réel. Une propriété comprise par un pilote fournisseur n’a pas automatiquement de sens pour un autre.

USB et PCIe détectent généralement les appareils par leur bus, mais alimentation, reset ou ressources du contrôleur de carte peuvent encore nécessiter une description. N’ajoutez pas un nœud Wi-Fi arbitraire pour forcer un pilote USB. Déterminez d’abord si le bus voit le périphérique et si ses identifiants correspondent.

Compilez et validez le Device Tree modifié avec les outils de l’arbre retenu. Le guide des schémas de bindings Linux décrit notamment dtbs_check. Un contrôle propre prouve une cohérence structurelle avec les bindings disponibles, pas la polarité du reset, la tension ni la connexion PCB.

Conservez un diff revu reliant chaque nœud changé au réseau du schéma ou à l’exigence fournisseur. Si le module impose une modification de carte, déclarez-la explicitement au lieu de présenter le remplacement comme purement logiciel.

4. Diagnostiquer dans l’ordre : bus, pilote, radio, réseau

Commencez par l’énumération. Si le périphérique est absent, vérifiez alimentation, reset, horloge et contrôleur avant l’authentification. S’il est visible sans pilote attaché, examinez identifiants, configuration et disponibilité du module. Si le pilote s’attache mais ne charge pas le firmware, contrôlez noms, paquets et sélection des données de carte.

Une fois l’interface créée, vérifiez capacités et liaison active. Pour un pilote exposant nl80211, les commandes de lecture suivantes sont utiles ; remplacez le nom d’interface par le bon. Certains pilotes propriétaires exigent leurs propres outils pris en charge.

uname -r
ip link show
iw dev
iw phy
# Example interface name only:
iw dev wlan0 link
iw reg get

La documentation Linux Wireless de iw explique ces inspections. Une capacité annoncée ne prouve pas que l’antenne montée ou l’application satisfait ses performances.

Séparez ensuite association, adressage, routage, DNS et connexion applicative. Un lien radio réussi peut coexister avec un échec DHCP. Un ping local ne garantit ni l’accès au service TLS requis ni une heure correcte pour les certificats.

5. Valider les rôles réellement utilisés

Utilisez les modèles de points d’accès et modes de sécurité prévus. Testez chaque bande et largeur de canal requise lorsque c’est légal et pris en charge. En AP, vérifiez association, reconnexion et combinaisons d’interfaces. En itinérance, mesurez interruption applicative et comportement des paquets plutôt que seulement le changement d’adresse du point d’accès.

Mesurez ensemble débit, latence, pertes, charge CPU et puissance dans des conditions définies de distance, orientation, environnement radio, direction du trafic et équipement distant. Notez outil et version. Séparez une référence filaire reproductible du chemin radio afin de ne pas attribuer à la radio la lenteur d’un serveur.

Si Bluetooth partage module ou antenne, incluez l’usage simultané demandé. Un test Wi-Fi seul ne prouve pas la coexistence. Ne publiez pas de débit ou de portée sans conditions et preuves réelles.

6. Inclure récupération et tests négatifs

• Disparition du point d’accès : vérifiez reprises bornées, délais applicatifs et récupération à son retour.
• Identifiants invalides : fournissez un état exploitable sans boucle de reconnexion rapide infinie ni secret dans les logs.
• Service d’adressage absent : distinguez association et DHCP indisponible, et vérifiez le secours documenté.
• Firmware absent : sur une image jetable, vérifiez que le diagnostic nomme la dépendance manquante.
• Veille et reprise : testez chaque source de réveil requise et la récupération de l’interface comme de l’application.
• Démarrage froid et chaud : testez les deux ; une radio restant alimentée peut cacher une séquence froide incomplète.

Effectuez ces essais sur un réseau autorisé et gardez une voie de récupération filaire ou physique. Ne déchargez pas un pilote et ne remplacez pas le firmware sur l’unique accès distant sans plan de restauration.

7. Traiter la réglementation comme une exigence distincte

Pays d’utilisation, canaux permis, antenne et restrictions du fournisseur influencent le produit final. La configuration réglementaire Linux limite le fonctionnement ; elle ne vaut pas certification. Ne forcez ni canal ni puissance non pris en charge pour réussir un essai. La documentation réglementaire Linux Wireless explique la gestion des informations, tandis que fournisseur et spécialistes compétents doivent établir les obligations propres au produit.

Les preuves pour décider du remplacement

Livrez matrice de substitution, différences de schéma et Device Tree, manifeste pilote/firmware, logs, essais par rôle, résultats en défaut et limites connues. Pour comparer les modules, utilisez même montage et même charge et explicitez toute différence inévitable.

La configuration de passerelle Linux RK3528 d’Obeita mentionne une orientation radio AP6275S et des chemins logiciels distincts station/AP et Bluetooth. C’est un exemple de périmètre, pas la preuve qu’un module alternatif est compatible. Consultez Diagnostic firmware et BSP avec les deux références exactes, le schéma, la version noyau/BSP et les rôles requis.