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.
DEBUGGING ARM LINUX KERNEL
La crescente popolarità di microcontrollori ad alte prestazioni disponibili ad un costo ridotto, incluso l’ARM a 32-bit, ha permesso a Linux di entrare nel mondo dei dispositivi embedded: ecco perché si ha la necessità di approntare sistemi di debug delle sue applicazioni e del kernel, dal momento che Linux è un vero sistema operativo multi-processo con la possibilità di sfruttare una Memory Management Unit (MMU) per dare ad ogni processo uno spazio di memoria separato. Non solo, la MMU è anche responsabile della protezione dello spazio di memoria di ogni processo rispetto agli altri. Per questa ragione diventa necessario offrire e sfruttare sistemi di verifica, leggi debugger, per lavorare correttamente e senza problemi con il kernel e le applicazioni di Linux senza interferire sui processi in esecuzione. Possiamo, oltre all’open source, sfruttare a questo proposito la Ronetix PM9261 con le toolchain GNU ARMELF e ARM-LINUX: la scheda Ronetix è fornita con Linux installato e la procedura utilizzata, nei suoi tratti fondamentali, è perfettamente integrabile con qualsiasi board di lavoro. Per prima cosa diventa necessario costruire il nostro kernel e installare la nostra toolchain GNU secondo le indicazioni contenute nel riquadro 1: alla fine di questa fase si ottiene il file image/vmeImage. A questo punto è necessario installare i diversi moduli del kernel.
A questo punto occorre caricare su target i file ottenuti; vmImage e rootfs. jffs2 utilizzando il bootloader che il costruttore offre sul suo sito, in accordo con le indicazioni presenti nel file di configurazione.
Figura 1: Le possibilità offerte da PEEDI
Il tutto è fatto con l’interfaccia Ethernet via TFTP o FTP:
telnet 192.168.3.100 ; si assume l’IP del PEEDI pari a 192.168.3.100
peedi> flash set 0 ; select the first flash profile (U-BOOT) peedi> flash erase peedi> flash program peedi> flash set 1 ; select the second flash profile (Kernel) peedi> flash program peedi> flash set 2 ; select the ROOTFS flash profile peedi> flash erase peedi> flash program
E' possibile però ricorrere anche ad uno script file, come:
peedi> run $prog
Il progettista, a questo punto, può iniziare la sua sessione di test con: arm-elf-insight vmlinux Nella console gdb:
(gdb) target remote 192.168.3.100:2000 (gdb) set $pc = 0x10000040 ; si assume che u-boot è posizionato all’indirizzo 0x10000000 (gdb) c
Il nostro target è pronto per iniziare questa avventura e attraverso una console seriale è possibile vedere il comportamento di Linux. L’utilizzatore può intervenire sul processo in esecuzione o impostare punti di interruzione nel codice. In caso si volesse inserire un breakpoint prima dell’esecuzione del kernel non è opportuno utilizzare il comando di halt perché potrebbe sospendere l’esecuzione di un processo. Si consiglia, a questo proposito, di impostare un breakpoint all’interno del kernel come nella funzione start_kernel() o alla funzione main(). Per ottenere gli indirizzi necessari può essere utile utilizzare l’utility nm.
(gdb) target remote 192.168.3.100:2000 (gdb) set $pc = 0x10000040 ; si assume che u-boot è posizionato all’indirizzo 0x10000000 (gdb) hbreak start_kernel ; hardware breakpoint (gdb) c
Leggi anche le Puntate precedenti:
Debugging Linux via JTAG – Puntata 1 | Elettronica Open Source
Debugging Linux via JTAG – Puntata 2 | Elettronica Open Source
