Debugging Linux via JTAG – Puntata 1

Utilizzando il JTAG è possibile condurre sessioni di debug sul kernel di Linux, vediamo come in questo articolo della Rubrica Firmware Reload, all’interno della quale potrete leggere articoli tecnici della passata rivista cartacea Firmware, inerenti argomenti che riscuotono ancora molto interesse tra professionisti e appassionati di elettronica. 

Esistono, come molti sviluppatori software e hardware hanno posto in evidenza, differenti sistemi di test che rispondono a precise esigenze di tipo commerciale con prerogative legate all’aspetto tecnico. Non solo, l’offerta open source è notevolmente variegata e offre tutto il necessario per condurre un lavoro d’integrazione e di test, anche se poi le aziende, nella maggior parte dei casi, preferiscono utilizzare sistemi di tipo commerciale per via del possibile supporto e di una certificazione finale del loro prodotto. Una delle ragioni fondamentali che spingono le aziende a preferire soluzioni di tipo commerciale è la possibilità di utilizzare degli strumenti cosiddetti affidabili che permettono di verificare il codice sviluppato anche a livello kernel.

Storicamente, Linux nasce su un’architettura Intel x86 dove l’ambiente host e target di norma coincidono, ma solo in seguito, grazie alla sua diffusione in ogni ambiente e applicazione, sorse anche l’esigenza di disporre di strumenti più flessibili tanto che il principale ispiratore di Linux, Torvalds, decise di inserire una patch KGDB (debugger del kernel di Linux) nella struttura principale di Linux fino a quando, dalla versione 2.6.26 venne presentata una variante più snella del KGDB. Per inciso, possiamo ricordare che con la versione 2.6.35 del kernel, il KGDB poteva essere usato come front-end del GDB sullo stesso computer in luogo dei due originariamente previsti. In effetti, la versione originaria del KGDB prevedeva la presenza di due macchine tra loro connesse attraverso una linea seriale con due istanze di GDB su ogni macchina. La connessione seriale si basava su una banale RS232 utilizzando una configurazione null modem o ricorrendo a un’interfaccia di rete con UDP/IP (a volte chiamata anche come KGDB over Ethernet o KGDBoE). Di certo, una decisione del genere deriva dal fatto che, per un sistema embedded, diventa pressoché necessario disporre di uno strumento flessibile che consente di fare il debugging del kernel, anche se poi, con l’introduzione del JTAG l’approccio si è sostanzialmente mutato per via della maggiore flessibilità offerta e di una minore invasività delle patch del kernel come ci si era abituati con KGDB.

Figura 1: PEEDI

JTAG – LO STANDARD

Il JTAG (Joint Test Action Group) è stato inizialmente sviluppato come un modo per testare la connessione elettrica dei circuiti, anche se poi oggi è più comunemente utilizzato per le attività di debug dei sistemi embedded. Un adattatore JTAG, a volte indicato come in-circuit emulator (ICE), è utilizzato per accedere ai moduli di debug on-chip all’interno della CPU di destinazione. Il proposito di realizzare uno standard per il test dei circuiti è un’idea che viene da lontano; in effetti, il boundaryscan JTAG fu pubblicato per la prima volta nel 1990 con il riferimento di IEEE 1149.1 noto anche come TAP (Test Access Port) o anche BSA (Boundary Scan Architecture). Questo particolare standard definisce la logica di test da includere nei circuiti integrati, che può essere utilizzata a livello di scheda per effettuare collaudi strutturali precisi e la programmazione dei componenti direttamente su target. Nel tempo, seppur siano stati inseriti nuovi aggiornamenti, le sue funzioni messe a punto nella versione iniziale non sono state modificate ma, al contrario, sono state introdotte nuove funzioni di tipo opzionale. L’idea dello standard, in sostanza, è molto semplice: si intende finalmente standardizzare il controllo dell’interfaccia utilizzando, a questo scopo, un sottoinsieme di pin fisici (quattro fondamentali e uno opzionale) e, aspetto molto interessante, è anche possibile verificare le connessioni sul circuito stampato prima della programmazione per accertarsi che non vi siano dei corti indesiderati che potrebbero danneggiare il dispositivo in modo irreparabile.

Un sistema di questo tipo utilizza i pin TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), TMS (Test Mode Select), TRST (Test Reset). I primi due sono utilizzati per il transito dei dati, mentre gli altri tre sono segnali di controllo con il segnale TRST definito opzionale nello standard IEEE 1149.1. Non solo, nel caso in cui in uno schema elettrico siano presenti più dispositivi, l’utilizzo del sistema JTAG consente di collegarli in modo seriale: l‘ingresso per l’intero schema elettrico rimane uno e coincide con il segnale TDI del primo dispositivo della catena, mentre l’uscita diventa il segnale TDO dell’ultimo. Il collegamento tra un dispositivo e il successivo è effettuato cortocircuitando il segnale TDO di un dispositivo con il segnale TDI di quello successivo. I segnali di controllo (TCK, TMS, TRST) sono connessi in parallelo su tutti i dispositivi della catena, e in questo modo il numero di pin rimane costante indipendentemente dal numero di dispositivi presenti nella catena JTAG. Utilizzare la tecnologia JTAG per verificare il codice è un’attività interessante e consente anche di ottenere enormi flessibilità: in passato si utilizzavano anche altri sistemi quali il BDM di Motorola, ora Freescale utilizzato in ambiente ColdFire e68k like.

In questo modo, si poteva disporre di un debug particolarmente economico e perfettamente comparabile con i costosi emulatori. In effetti, il BDM offre il vantaggio che non vengono richiesti ulteriori circuiti da integrare con il microcontrollore di cui si vuole realizzare il debug: in sostanza, si utilizza uno speciale hardware all’interno del microcontrollore stesso. Attraverso il JTAG possiamo interrompere la CPU, ispezionare i suoi registri e la memoria, e definire punti di interruzione. In effetti, però, per apprezzare un sistema di questo tipo è anche necessario utilizzare anche un debugger software. Alcuni fornitori di adattatori JTAG offrono anche strumenti software, mentre altri si basano su pacchetti open source. Anche se la maggior parte dei debugger JTAG al giorno d’oggi supportano Linux, è necessario al momento dell’acquisto un dispositivo a basso costo, e chiedere l’eventuale compatibilità con Linux, la MMU, il formato binario dei file di Linux e il supporto dei moduli caricabili. Se lo supporta a distanza GDB (GNU debugger) e protocollo, si può essere sicuri che si tratta di andare a lavorare. Il PEEDI, ad esempio, è un tipico debugger hardware su JTAG con la piena disponibilità di lavorare con GDB e Linux. In effetti, per le sue caratteristiche, PEEDI è la soluzione ottimale per il debugging hardware di schede con interfaccia JTAG. È molto veloce, economico e con buone possibilità prestazionali tanto che può rappresentare l’abbinamento ideale per un sistema Linux embedded. Non solo, PEEDI fornisce anche funzionalità di Flash programmer (anche su memorie NAND), Figura 1.

Il prodotto di casa Ronetix offre interessanti caratteristiche che permettono un suo utilizzo per una ampia possibilità di processori con un buon supporto di prodotti open-source. Ronetix, il costruttore del sistema di test, garantisce anche la possibilità di poter fare il download di immagini firmware da TFTP, FTP, HTTP server o MMC/SDcard, supporta l’interfaccia Telnet a linea di comando e l’interfaccia pannello frontale dei due tasti e del display a 7-segmenti. Non solo, si garantisce anche il funzionamento stand-alone del FLASH programmer senza PC: i file da programmare sono memorizzati su una schedina MMC/SD e il controllo si stabilisce attraverso il pannello frontale. PEEDI è però un sistema commerciale e, in quanto tale, deve essere acquistato. In realtà, è anche possibile utilizzare sistemi più di basso profilo o, addirittura, costruirci qualcosa di analogo ma non è questo lo scopo dell’articolo.