Avvio della telecamera su RK3576 Linux: dal driver del sensore al primo fotogramma

RK3576 è un processore sviluppato da Rockchip per applicazioni industriali di visione, sistemi intelligenti di sicurezza e terminali di visione artificiale. Integra un processore di segnale d’immagine (ISP) V3.9 (con supporto fino a 16 MP) e tre moduli riceventi MIPI CSI-2 (due moduli D-PHY V2.0 e un modulo C/D-PHY). Ogni lane D-PHY supporta una velocità massima di 4,5 Gbps, ogni trio C-PHY supporta 2,5 Gsps e ogni porta CSI supporta quattro canali virtuali.

La soluzione camera RK3576 è progettata intorno al framework Linux Media e al modello di sottodispositivo V4L2-subdev. Il percorso completo dei dati è il seguente: sensore d’immagine → controller ricevitore MIPI CSI → unità di acquisizione video VICAP → ISP V3.9. Il sensore opera come un sottodispositivo indipendente e collabora con MIPI CSI, VICAP e l’ISP per formare una pipeline completa di acquisizione d’immagini.

Anche se il RK3576 fornisce tre canali riceventi MIPI CSI e il VICAP può ricevere contemporaneamente più flussi di immagini, l’ISP V3.9 è un hardware a canale singolo e può eseguire l’elaborazione dell’algoritmo ISP su un solo flusso di immagini alla volta.

Durante il debug del progetto, i problemi riscontrati potrebbero includere una comunicazione I2C anomala, un collegamento MIPI instabile o un mancato avvio della pipeline Media, impedendo infine l’output del primo fotogramma d’immagine. Questo articolo illustra un approccio completo al debug dal punto di vista dell’implementazione ingegneristica ed è utilizzabile come riferimento per il debug della visione embedded.

1. Preparazione hardware e kernel: eliminare i problemi hardware a basso livello prima del debug

Durante il debug del driver, la maggior parte dei problemi che incontriamo non è causata dal codice del driver stesso, ma da problemi a basso livello, come cablaggio hardware, sequenza di alimentazione o configurazione mancante del kernel. Pertanto, prima di iniziare lo sviluppo del driver del sensore, l’hardware sottostante e l’ambiente kernel devono essere controllati e verificati per primi.

I controlli hardware principali includono le linee di alimentazione del sensore, il bus I2C, i collegamenti differenziali MIPI e i pin GPIO di reset/controllo dell’alimentazione.

La sequenza di accensione del sensore è una delle parti più critiche del processo di debug. Più linee di alimentazione, come AVDD, DOVDD e DVDD, devono seguire rigorosamente la sequenza di accensione specificata dal sensore. Deviazioni eccessive della tensione di alimentazione o un timing errato di accensione/spegnimento possono causare direttamente errori di comunicazione I2C e un funzionamento anomalo del sensore.

Bus I2C: verificare la configurazione della multiplexazione dei pin e l’indirizzo slave del sensore, e confermare che i resistori di pull-up I2C siano correttamente montati.

MIPI: Confermare il canale CSI utilizzato dall'hardware, il numero di lane MIPI e l'adattamento dell'impedenza sulle linee di segnale differenziale. Verificare inoltre che l'orologio di riferimento del sensore (XVCLK) in uscita dal RK3576 funzioni correttamente.

Pin di controllo reset/standby: Determinare la logica del livello attivo (attivo alto/attivo basso) e assicurarsi che la configurazione GPIO corrisponda allo schema elettrico.

Configurazione del kernel: Controllare le opzioni del kernel relative al sottosistema Media, ai dispositivi V4L2-subdev, ai driver del controller e della PHY MIPI CSI, a VICAP e all'ISP V3.9. Se un componente richiesto non è integrato nel kernel oppure è compilato come modulo ma non viene caricato correttamente, la pipeline Media non sarà in grado di riconoscere l'hardware della fotocamera. Dopo aver compilato e flashato il kernel, verificare innanzitutto lo stato di caricamento di ciascun modulo driver. Esaminare il log dmesg e confermare l'assenza di errori quali moduli mancanti o errori di inizializzazione.

2. Configurazione del Device Tree (DTS): Stabilire le connessioni tra i dispositivi

Albero dei dispositivi della telecamera RK3576: descrive le risorse hardware e utilizza nodi di porta ed endpoint per collegare la pipeline dell'immagine tra sensore, MIPI CSI, VICAP e ISP.

Il nodo del sensore è collegato al corrispondente nodo del bus I2C e definisce l'indirizzo slave I2C, il pin di reset, il pin di controllo per l'arresto dell'alimentazione e l'orologio di riferimento del sensore. Le proprietà possono essere configurate per ritardare l'inizializzazione del sensore fino a quando l'hardware PHY CSI è pronto, evitando condizioni di gara temporali causate da un PHY non ancora pronto. L'endpoint all'interno della porta del nodo del sensore punta all'ingresso MIPI CSI e specifica il numero di corsie dati MIPI.

Il nodo del controller MIPI CSI contiene due porte: l'ingresso è collegato al sensore d'immagine e l'uscita è collegata all'unità VICAP. VICAP invia quindi i dati dell'immagine all'ISP V3.9. Si noti che gli endpoint devono fare riferimento l'uno all'altro in entrambe le direzioni e che le proprietà remote-endpoint su entrambi i lati devono corrispondersi una a una. Se il collegamento bidirezionale non corrisponde, il framework Media non riesce a riconoscere il percorso dati completo. Dopo aver modificato, compilato e flashato il DTS, esaminare innanzitutto il log dmesg per verificare che tutti i nodi del dispositivo siano nello stato normale e che non si verifichino errori persistenti di deferred-probe. Il ripetersi di probe differiti indica generalmente una configurazione errata di GPIO, clock o risorse di alimentazione.

3. Sviluppo del driver della sottoperiferica sensore: modello V4L2-subdev

Il driver del sensore per la piattaforma RK3576 è sviluppato sulla base del framework V4L2-subdev. Il driver del sensore non crea un nodo /dev/video; esiste esclusivamente come entità di sottodispositivo multimediale. Le sue principali responsabilità includono la configurazione dei registri del sensore, la gestione dell’alimentazione e del reset, la configurazione del formato immagine e il controllo dell’avvio/arresto del flusso.

Il driver è suddiviso principalmente in cinque moduli: rilevamento I2C, controllo dell’alimentazione/reset, tabelle dei registri delle modalità, configurazione del formato pad e controllo dell’avvio/arresto del flusso.

Durante la fase di rilevamento del driver, l’ID del chip del sensore viene letto tramite I2C per verificare che il chip venga riconosciuto correttamente. Se la lettura dell’ID non riesce, la risoluzione dei problemi può concentrarsi direttamente su guasti hardware relativi a I2C, alimentazione e reset. Le funzioni di alimentazione/reset implementano l’intera sequenza di accensione e spegnimento del sensore: durante l’accensione, ogni linea di alimentazione viene abilitata in sequenza, il pin di reset viene attivato per il ritardo specificato, quindi il reset viene rilasciato e al sensore viene concesso del tempo per stabilizzarsi internamente. La sequenza di spegnimento esegue le operazioni inverse.

Le tabelle del registro modalità memorizzano le configurazioni complete dei registri del sensore per diverse risoluzioni, frequenze di aggiornamento e velocità MIPI. Quando il livello superiore modifica i parametri di acquisizione, il driver scrive l’intero insieme di registri corrispondente. L’interfaccia pad-format configura il formato immagine del bus multimediale, che deve corrispondere esattamente al formato Bayer generato dal sensore (ad esempio BGGR o RGGB). Una configurazione errata provoca direttamente errori cromatici nell’immagine. L’interfaccia stream-control utilizza stream_on per scrivere i comandi nei registri che abilitano l’uscita dell’immagine MIPI del sensore, mentre stream_off interrompe la trasmissione dell’immagine. Dopo aver implementato il driver, vengono aggiunte opzioni di compilazione nel file Kconfig e nel Makefile del kernel, in modo che il driver possa essere integrato direttamente nel kernel oppure compilato come modulo kernel caricabile dinamicamente.

4. Debug graduale: ottenere il primo frame passo dopo passo

Non è consigliabile tentare immediatamente l’acquisizione dell’immagine. Utilizzare un approccio di risoluzione dei problemi articolato in tre fasi: verificare che il probe del driver venga eseguito correttamente → assicurarsi che la pipeline Media sia completamente connessa → acquisire immagini grezze tramite V4L2.

Fase 1: Verificare che il probe del driver del sensore venga eseguito correttamente

Dopo l’avvio del sistema, esaminare l’output di dmesg e cercare i messaggi di log stampati dal driver del sensore. Usare i2cdetect per eseguire una scansione del bus I2C corrispondente e verificare se l’indirizzo slave del sensore viene rilevato.

• Se nessun dispositivo I2C viene rilevato: controllare l’alimentazione del sensore, la logica di reset, la saldatura hardware I2C e la multiplexing dei pin.
• Se l’indirizzo I2C viene rilevato ma la lettura dell’ID chip risulta anomala: il percorso hardware I2C funziona correttamente; molto probabilmente il problema è dovuto a un indirizzo registro errato o a una mancata corrispondenza tra modello di sensore e driver.

Fase 2: Verificare la pipeline del framework Media

Utilizzare media-ctl per visualizzare l'elenco delle entità del dispositivo multimediale. In condizioni normali, dovrebbero essere visibili entità di sottodispositivo come sensore, mipi_csi, vicap e isp39, con ogni porta pad riconosciuta correttamente.

• Se l'entità del sensore non è visibile: il caricamento del driver del sensore è fallito.
• Se le entità esistono ma il collegamento è disconnesso: l'abbinamento bidirezionale degli endpoint nel DTS è errato.

Durante il debug, media-ctl può essere utilizzato per configurare manualmente l'intera pipeline: stabilire i collegamenti tra le entità e impostare il formato dell'immagine, la risoluzione e la configurazione dei lane per ogni stadio del sottodispositivo. Gli errori generati da media-ctl sono generalmente causati da un numero di lane, da un formato media-bus o da un parametro di risoluzione che supera le capacità hardware del sensore. Una configurazione riuscita di media-ctl indica che il percorso software dal sensore all'ISP è stato stabilito.

Fase 3: Acquisire un'immagine con V4L2 e ottenere il primo frame grezzo

VICAP/ISP genera il nodo /dev/video, che funge da punto di ingresso nello spazio utente per l'acquisizione delle immagini. Utilizzare v4l2-ctl per impostare il formato pixel dell'immagine, acquisire un singolo fotogramma tramite mmap e salvare i dati RAW Bayer. Se la dimensione del file RAW generato corrisponde all'aspettativa teorica, il primo fotogramma è stato acquisito con successo. Il file RAW può quindi essere visualizzato con uno strumento professionale di analisi delle immagini per ispezionare l'immagine originale in formato Bayer.

5. Approcci comuni per la risoluzione dei problemi

• media-ctl segnala un errore durante la configurazione del collegamento: verificare innanzitutto il binding bidirezionale degli endpoint DTS, quindi controllare il formato media-bus, la risoluzione e i parametri relativi al numero di lane.
• Il timeout dell'acquisizione del fotogramma V4L2 avviene senza alcun output di dati immagine: verificare che stream_on sia stato eseguito correttamente all'interno del driver, che il PHY CSI abbia raggiunto il clock lock e che il sensore stia effettivamente generando uno stream di dati MIPI.
• Immagini danneggiate o rumore a strisce: le possibili cause includono una frequenza di clock MIPI errata, un numero di lane errato, una corrispondenza errata del pattern Bayer o un’ondulazione eccessiva sull’alimentazione del sensore.
• Uscita immagine intermittente o perdita occasionale di fotogrammi: i tempi di accensione/ripristino del sensore potrebbero non soddisfare i requisiti oppure l’alimentazione hardware potrebbe non essere sufficientemente stabile.

Disponiamo di una soluzione RK3576 matura e di competenze professionali nello sviluppo personalizzato, nell’adattamento hardware e nell’implementazione per la produzione di massa. Per diversi sensori d’immagine e per diverse esigenze di risoluzione/velocità dei fotogrammi, possiamo fornire revisioni hardware, debug dei driver e ottimizzazione dell’intero sistema, per supportare in modo efficiente progetti personalizzati nel campo della visione industriale, della sicurezza intelligente, dei terminali di visione AI e di altre applicazioni. Contattateci all’indirizzo [email protected].