Mise en service d’une caméra sous Linux sur RK3576 : du pilote de capteur à l’affichage de la première image

Le RK3576 est un processeur développé par Rockchip pour les applications industrielles de vision, la sécurité intelligente et les terminaux de vision IA. Il intègre un processeur de signal d’image (ISP) V3.9 (pouvant traiter jusqu’à 16 MP) et trois modules récepteurs MIPI CSI-2 (deux modules D-PHY V2.0 et un module C/D-PHY). Chaque voie D-PHY prend en charge un débit maximal de 4,5 Gbps, chaque trio C-PHY atteint 2,5 Gsps, et chaque port CSI prend en charge quatre canaux virtuels.

La solution caméra RK3576 repose sur le cadre multimédia Linux et le modèle de sous-périphérique V4L2-subdev. Le chemin complet des données est le suivant : capteur d’image → contrôleur récepteur MIPI CSI → unité de capture vidéo VICAP → ISP V3.9. Le capteur fonctionne comme un sous-périphérique indépendant et interagit avec les composants MIPI CSI, VICAP et l’ISP afin de former une chaîne complète d’acquisition d’images.

Bien que le RK3576 fournisse trois canaux récepteurs MIPI CSI et que le VICAP puisse recevoir simultanément plusieurs flux d’images, l’ISP V3.9 est un composant matériel mono-canal et ne peut exécuter le traitement algorithmique ISP que sur un seul flux d’images à la fois.

Pendant le débogage du projet, des problèmes peuvent survenir, tels qu’une communication I2C anormale, un lien MIPI instable ou un échec de mise en place du pipeline Media, empêchant ainsi la sortie de la première trame d’image. Cet article présente une démarche complète de débogage du point de vue de l’implémentation technique et peut servir de référence pour le débogage embarqué de systèmes de vision.

1. Préparation matérielle et noyau : éliminer les problèmes matériels de bas niveau avant le débogage

Lors du débogage d’un pilote, la plupart des problèmes que nous rencontrons ne sont pas causés par le code du pilote lui-même, mais par des problèmes de bas niveau tels que le câblage matériel, la séquence d’alimentation ou une configuration manquante du noyau. Par conséquent, avant de commencer le développement d’un pilote de capteur, il convient d’abord de vérifier et de valider le matériel sous-jacent et l’environnement noyau.

Les vérifications matérielles essentielles portent sur les rails d’alimentation du capteur, le bus I2C, les liaisons différentielles MIPI et les broches GPIO de réinitialisation et de commande d’alimentation.

La séquence de mise sous tension du capteur constitue l’une des étapes les plus critiques du débogage. Plusieurs rails d’alimentation, tels que AVDD, DOVDD et DVDD, doivent strictement respecter la séquence de mise sous tension spécifiée par le capteur. Un écart excessif de la tension d’alimentation ou un chronogramme incorrect de mise sous tension ou de mise hors tension peut directement provoquer des défaillances de communication I2C et un fonctionnement anormal du capteur.

Bus I2C : vérifier la configuration du multiplexage des broches et l’adresse esclave du capteur, et confirmer que les résistances de rappel I2C sont correctement installées.

MIPI : Confirmer le canal CSI utilisé par le matériel, le nombre de voies MIPI et l’adaptation d’impédance sur les lignes de signal différentiel. Vérifier également que l’horloge de référence du capteur (XVCLK) émise par le RK3576 fonctionne correctement.

Broches de contrôle de réinitialisation/mise en veille : Déterminer la logique de niveau actif (actif haut/actif bas) et s’assurer que la configuration GPIO correspond au schéma.

Configuration du noyau : Vérifier les options du noyau relatives au sous-système Media, aux sous-périphériques V4L2-subdev, aux pilotes du contrôleur et du PHY MIPI CSI, au VICAP et à l’ISP V3.9. Si un composant requis n’est pas intégré au noyau ou est compilé sous forme de module mais ne se charge pas correctement, le pipeline Media ne pourra pas identifier le matériel de la caméra. Une fois le noyau compilé et flashé, vérifier d’abord l’état de chargement de chaque module pilote. Examiner le journal dmesg et confirmer qu’aucune erreur (comme modules manquants ou échecs d’initialisation) n’est présente.

2. Configuration de l’arbre de périphériques (DTS) : Établissement des connexions entre les périphériques

Arborescence des périphériques caméra RK3576 : elle décrit les ressources matérielles et utilise des nœuds de port et de point de terminaison pour établir les liaisons du pipeline d’images entre le capteur, le MIPI CSI, le VICAP et l’ISP.

Le nœud du capteur est rattaché au nœud correspondant du bus I2C et définit l’adresse esclave I2C, la broche de réinitialisation, la broche de commande de mise en veille et l’horloge de référence du capteur. Des propriétés peuvent être configurées afin de retarder l’initialisation du capteur jusqu’à ce que le matériel PHY CSI soit prêt, évitant ainsi des conflits temporels dus à un PHY non prêt. Le point de terminaison situé dans le nœud de port du capteur fait référence à l’entrée MIPI CSI et précise le nombre de voies de données MIPI.

Le nœud du contrôleur MIPI CSI comporte deux ports : l’entrée est connectée au capteur d’image, et la sortie est reliée à l’unité VICAP. VICAP transmet ensuite les données d’image à l’ISP V3.9. Notez que les points de terminaison doivent se faire référence mutuellement de façon bidirectionnelle, et que les propriétés remote-endpoint aux deux extrémités doivent correspondre un-à-un. Si la liaison bidirectionnelle ne correspond pas, le cadre Media ne peut pas reconnaître le chemin de données complet. Après avoir modifié, compilé et flashé le DTS, examinez d’abord le journal dmesg afin de confirmer que tous les nœuds de périphérique sont dans un état normal et qu’aucune erreur persistante de probe différé ne se produit. Des tentatives répétées de probe différé indiquent généralement une configuration incorrecte d’une GPIO, d’une horloge ou d’une ressource d’alimentation.

3. Développement du pilote sous-périphérique capteur : modèle V4L2-subdev

Le pilote de capteur de la plateforme RK3576 est développé sur la base du cadre V4L2-subdev. Ce pilote de capteur ne crée pas de nœud /dev/video ; il existe uniquement en tant qu’entité de sous-périphérique multimédia. Ses principales responsabilités comprennent la configuration des registres du capteur, la gestion de l’alimentation et de la réinitialisation, la configuration du format d’image, ainsi que la commande de démarrage/arrêt du flux.

Le pilote est principalement divisé en cinq modules : détection I2C, commande de l’alimentation/réinitialisation, tables de registres de mode, configuration du format de pad et commande de démarrage/arrêt du flux.

Pendant la phase de détection du pilote, l’identifiant de la puce du capteur est lu via le bus I2C afin de vérifier que la puce est correctement reconnue. En cas d’échec de cette lecture, le dépannage peut se concentrer directement sur les défauts matériels liés à I2C, à l’alimentation et à la remise à zéro. Les fonctions d’alimentation et de réinitialisation exécutent intégralement la séquence de mise sous tension et de mise hors tension du capteur : lors de la mise sous tension, chaque rail d’alimentation est activé séquentiellement, la broche de réinitialisation est actionnée pendant le délai spécifié, puis la réinitialisation est relâchée et le capteur se voit accorder un délai permettant de se stabiliser en interne. La séquence de mise hors tension effectue les opérations inverses.

Les tables d’enregistreurs de mode stockent des configurations complètes des registres du capteur pour différentes résolutions, fréquences d’images et débits MIPI. Lorsque la couche supérieure modifie les paramètres de capture, le pilote écrit l’ensemble complet correspondant de registres. L’interface de format de broche configure le format d’image du bus multimédia, qui doit correspondre strictement au format Bayer généré par le capteur (par exemple BGGR ou RGGB). Une configuration incorrecte provoque directement des erreurs de couleur sur l’image. L’interface de contrôle de flux utilise stream_on pour écrire des commandes de registres activant la sortie d’images MIPI du capteur, tandis que stream_off arrête la transmission d’images. Une fois le pilote implémenté, des options de compilation sont ajoutées au fichier Kconfig et au fichier Makefile du noyau afin que le pilote puisse être soit intégré directement au noyau, soit compilé sous forme de module noyau chargable dynamiquement.

4. Débogage progressif : obtenir la première image étape par étape

Il n’est pas recommandé de tenter immédiatement la capture d’images. Adoptez une approche de dépannage en couches, en trois étapes : confirmez que la détection du pilote s’effectue avec succès → vérifiez que le pipeline Media est entièrement connecté → capturez des images brutes à l’aide de V4L2.

Étape 1 : Vérifiez que le pilote du capteur se détecte correctement

Après le démarrage du système, examinez les messages dmesg et recherchez les journaux imprimés par le pilote du capteur. Utilisez i2cdetect pour analyser le bus I2C correspondant et confirmez si l’adresse esclave du capteur est détectée.

• Si aucun périphérique I2C n’est détecté : vérifiez l’alimentation du capteur, la logique de réinitialisation, la soudure matérielle I2C et le multiplexage des broches.
• Si l’adresse I2C est détectée mais que la lecture de l’identifiant de puce (Chip ID) est anormale : le chemin matériel I2C fonctionne correctement, et le problème provient probablement d’une adresse de registre incorrecte ou d’un désaccord entre le modèle de capteur et celui attendu.

Étape 2 : Vérifiez le pipeline du cadre Media

Utilisez media-ctl pour afficher la liste des entités de périphérique multimédia. Dans des conditions normales, les entités de sous-périphérique telles que le capteur, mipi_csi, vicap et isp39 doivent être visibles, chaque port de pad étant correctement reconnu.

• Si l’entité du capteur n’est pas visible, cela signifie que l’initialisation du pilote du capteur a échoué.
• Si les entités existent mais que le lien est déconnecté, la paire bidirectionnelle de points de terminaison dans le fichier DTS est incorrecte.

Pendant le débogage, media-ctl peut être utilisé pour configurer manuellement l’ensemble du pipeline : établir des liens entre les entités et définir le format d’image, la résolution et la configuration des voies (lanes) à chaque étape du sous-périphérique. Les erreurs renvoyées par media-ctl sont généralement dues à un nombre de voies (lanes), à un format media-bus ou à un paramètre de résolution dépassant les capacités matérielles du capteur. Une configuration réussie de media-ctl indique que le chemin logiciel allant du capteur à l’ISP a été établi.

Étape 3 : Capturer une image avec V4L2 et obtenir la première trame brute

VICAP/ISP génère le nœud /dev/video, qui sert de point d'entrée pour la capture d'images depuis l'espace utilisateur. Utilisez v4l2-ctl pour définir le format de pixel de l'image, capturer une seule trame via mmap et enregistrer les données brutes Bayer RAW. Si la taille du fichier RAW généré correspond à l'attente théorique, la première trame d'image a été capturée avec succès. Ce fichier RAW peut ensuite être ouvert à l'aide d'un outil professionnel d'analyse d'images afin d'examiner l'image Bayer originale.

5. Approches courantes de dépannage

• media-ctl signale une erreur lors de la configuration du lien : vérifiez d'abord la liaison bidirectionnelle des points de terminaison dans le DTS, puis confirmez le format media-bus, la résolution et le nombre de voies (lane-count).
• La capture de trame V4L2 expire sans sortie de données d'image : assurez-vous que l'appel stream_on est correctement exécuté au sein du pilote, que le PHY CSI a bien atteint le verrouillage d'horloge (clock lock) et que le capteur émet effectivement un flux de données MIPI.
• Images corrompues ou bruit en bandes : les causes possibles incluent un taux d’horloge MIPI incorrect, un nombre de voies incorrect, une inadéquation du motif Bayer ou une ondulation excessive sur l’alimentation du capteur.
• Sortie d’images intermittente ou pertes de trames sporadiques : le chronogramme de démarrage/réinitialisation du capteur pourrait ne pas respecter les exigences, ou l’alimentation matérielle pourrait manquer de stabilité.

Nous disposons d’une solution RK3576 éprouvée ainsi que de compétences professionnelles en développement sur mesure, adaptation matérielle et mise en œuvre à grande échelle. Pour différents capteurs d’image et divers besoins en résolution/débit d’images, nous pouvons fournir des révisions matérielles, le débogage des pilotes et une optimisation complète du système afin de soutenir efficacement des projets personnalisés dans les domaines de la vision industrielle, de la sécurité intelligente, des terminaux de vision IA et d’autres applications. Contactez-nous à [email protected].