Università Politecnica delle Marche

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Porting su architettura Cris AXIS ETRAX 100LX del sistema operativo Xenomai Tesi di Laurea di: Lorenzo RUGGERI Relatore: Prof. Aldo Franco DRAGONI Anno Accademico 2010/2011

2 Alla mia famiglia

3 Indice Introduzione vi 1 I sistemi operativi real-time e Linux Caratteristiche generali di un RTOS Task periodici/aperiodici e hard/soft real-time Sistemi Hard e Soft real-time Schedulazione dei sistemi real-time Caratteristiche di un sistema real-time GNU/Linux Interruzioni hardware e software Schedulazione a code multiple Schedulazione CFS Architettura modulare e licenza Open Source Il livello applicativo Portabilità Compilazione, debugging e test I problemi della schedulazione real time sotto Linux Strumenti di supporto Soluzioni real-time per il kernel Linux Linux e le applicazioni real-time Caratteristiche RT del Kernel Linux Approccio RT basato sullo sviluppo del kernel Linux Approccio RT basato sull utilizzo di un kernel RT di basso livello Xenomai Struttura del progetto iii

4 INDICE iv 2.2 Adeos pipeline Adeos e Xenomai I dominii di Xenomai Intercettare le chiamate di sistema Propagazione degli interrupt Installazione di Xenomai su x Testing della skin nativa Sviluppo di script per il testing Cris AXIS ETRAX 100LX La FOX Board Panoramica Accensione Modalità di accesso alla FOX Board Web access FTP access TELNET access Cris ETRAX CPU RISC Registri Flag e Condition Code Organizzazione dei dati in memoria Formato delle istruzioni Gestione degli interrupt su Linux/CRIS Interrupt Paths Casi speciali Software Development Kit (SDK) I sistemi embedded e la cross compilazione Installazione e test del cross compilatore gcc-cris Distribuzione software Configurazione e compilazione del firmware Scrittura del firmware sulla board Porting Approccio al problema del porting Adeos patch per architettura CRIS

5 INDICE v 5 Conclusioni 83 Ringraziamenti 85 Bibliografia 85

6 Introduzione I sistemi operativi in tempo reale (comunemente abbreviati con RTOS) rivestono un ruolo fondamentale nella nostra società coprendo diversi settori applicativi, quali il controllo di impianti industriali, i sistemi di regolazione di volo, il controllo del traffico aereo, navale e ferroviario, i sistemi di difesa militari, le missioni spaziali, i sistemi di telecomunicazione, i sistemi multimediali, l automazione industriale e la robotica. La loro presenza è fondamentale quando si vuole ottenere una risposta dal sistema entro un tempo prefissato. Un sistema operativo real-time non deve essere necessariamente veloce rispetto al tempo medio di risposta: tuttavia il tempo di reazione di tali sistemi è importante e proprio per questo si impongono limiti massimi su di esso (deadlines), in modo tale che le applicazioni possano essere eseguite rispetto a vincoli temporali determinati a priori. Nonostante la vastità degli scenari coinvolti, la maggior parte dei sistemi real-time viene ancora progettata con tecniche empiriche, senza l ausilio di una metodologia scientifica consolidata. La conseguenza di ciò è una scarsa affidabilità del software che, in applicazioni critiche, può causare gravi danni a cose o persone. Negli ultimi anni, è cresciuto un notevole interesse nell utilizzo del sistema operativo Linux per scenari real-time, specialmente nei sistemi di controllo. L architettura semplice e ordinata fornita da Linux garantisce robustezza e ottime prestazioni, mentre la licenza GPLv2 permette di modificare e di cambiare il codice sorgente in relazione alle necessità dell utente. Tuttavia Linux è stato progettato per essere un sistema operativo general purpose; pertanto presenta alcune questioni che (come per esempio le latenze impredicibili a priori, supporto limitato per la schedulazione a tempo reale del task-set, risoluzione temporale dei timer insufficiente) possono vi

7 Introduzione 1 rappresentare un problema per applicazioni real-time. Per questi motivi sono state proposte alcune modifiche con lo scopo di aggiungere le indispensabili caratteristiche «real-time» al kernel Linux sia per piattaforme hardware di utilizzo generico (x86), sia per soluzioni embedded (come per esempio ARM) utilizzate per le applicazioni di controllo. Il lavoro svolto in questa tesi, ha come obiettivo quello di analizzare il funzionamento del sistema Xenomai, in particolare della patch Adeos, al fine di effettuarne il porting sul sistema embedded a nostra disposizione, ovvero una FOX Board ETRAX 100LX, la cui architettura CRIS non è supportata direttamente da Xenomai, a differenza di altre architetture più utilizzate (tipo ARM). Nel Capitolo 1 di questa tesi vengono illustrati i concetti basilari che caratterizzano un sistema operativo real-time, le tecniche più recenti per la schedulazione in tempo reale e la schedulazione utilizzata dal kernel Linux. Nel Capitolo 2 viene descritta, in dettaglio, l architettura di Xenomai e la sua struttura modulare, con una particolare attenzione al funzionamento dello strato introdotto dalla patch Adeos e alla gestione degli interrupt. In questo capitolo viene illustrata anche la procedura di installazione di Xenomai su architettura x86. Inoltre, vengono presentati alcuni test creati appositamente per verificare il funzionamento del sistema e prendere confidenza con le interfacce di programmazione. Nel Capitolo 3 viene descritta dettagliatamente la piattaforma embedded utilizzata per il porting, insieme all ambiente di sviluppo fornito dalla Axis. Per una maggiore dimestichezza con il sistema embedded, viene esposta la procedura per la cross compilazione del kernel Linux e successivamente la procedura per il porting di quest ultimo sulla piattaforma in uso. Nel Capitolo 4 viene affrontato il problema del porting del sistema Xenomai per l architettura a nostra disposizione, basato sulla patch Adeos per ARM. Per finire, nel Capitolo 5 vengono illustrate le conclusione di questo lavoro di tesi.

8 Capitolo 1 I sistemi operativi real-time e Linux 1.1 Caratteristiche generali di un RTOS Un sistema operativo real-time o in tempo reale è un sistema operativo specializzato per il supporto di applicazioni software real-time. Questi sistemi vengono utilizzati tipicamente in ambito industriale (controllo di processo, pilotaggio di robot, trasferimento dati nelle telecomunicazioni) o, comunque, dove sia necessario ottenere una risposta dal sistema entro un tempo prefissato. Un sistema operativo real-time non deve essere necessariamente veloce: non è importante l intervallo di tempo in cui il sistema operativo/applicativo deve reagire; l importante è che risponda entro un tempo massimo predeterminato. In altre parole il sistema deve essere prevedibile. In pratica un sistema real-time deve garantire che una elaborazione (o task) termini entro un dato vincolo temporale o scadenza (detta in gergo deadline). Per garantire questo, è richiesto che la schedulazione delle operazioni sia fattibile. Il concetto di fattibilità di schedulazione è alla base della teoria dei sistemi real-time ed è quello che ci permette di dire se un insieme di task sia eseguibile o meno, in funzione dei vincoli temporali dati Task periodici/aperiodici e hard/soft real-time I task di un sistema real-time possono essere: 2

9 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 3 periodici: quando un task consiste in una sequenza di attività avviate con cadenza regolare; aperiodici: quando un task consiste in una sequenza di attività avviate a intervalli irregolari. I task periodici sono propri di un sistema di controllo a tempo discreto. Quando si ha a che fare con task di tipo periodico, si parla anche di periodo di esecuzione con il quale si intende il lasso di tempo che intercorre tra due attivazioni del task. Solitamente si fa coincidere la deadline con la fine del periodo, poiché questo è il limite massimo di esecuzione di un task. I task di un sistema real-time possono essere ulteriormente distinti in: soft real-time: un task che non rispetta la sua scadenza (in gergo si dice sfondare la deadline) provoca un danno non irreparabile al sistema. Il superamento della deadline produce un degrado delle prestazioni proporzionale al tempo di superamento; hard real-time: un task che superi temporalmente la sua deadline provoca un danno irreparabile al sistema. Sostanzialmente questa distinzione si traduce nella diversa quantificazione dei costi di una possibile inesattezza temporale del sistema. Un esempio di task soft real-time può essere un riproduttore DVD, in cui il mancato rispetto dei vincoli si traduce in un degrado della qualità del filmato, ma non pregiudica il proseguimento della riproduzione; mentre un task hard realtime può essere il controllore della temperatura del nocciolo di una centrale nucleare, dove il mancato rispetto dei vincoli temporali può provocare un evidente disastro. Oltre alla sua criticità (hard o soft), un task real-time J i può essere caratterizzato dai seguenti parametri, (vedi Fig. 1.1): Arrival time a i : (anche detto Release time r i ) è il tempo in cui il task diventa pronto per l esecuzione; Computation time C i : è il tempo massimo necessario al processore per eseguire completamnte il task senza interruzioni; Absolute Deadline d i : è il tempo entro cui il task deve essere completato per evitare danni al sistema (se hard) o un degrado delle prestazioni (se soft); Relative Deadline D i : è l intervallo entro cui il task deve essere completato a partire dal tempo di arrivo (D i = d i r i );

10 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 4 Figura 1.1: Parametri tipici di un processo real-time Start time s i : è il tempo in cui viene eseguita la prima istruzione del task; Finishing time f i : è il tempo in cui il task termina la sua esecuzione. È anche detto Completition time; Response time R i : è la differenza tra il finishing time e il release time:r i = f i r i ; Lateness L i : L i = f i d i rappresenta il ritardo di completamento del task rispetto alla deadline. Si noti che se un task termina prima della sua deadline, la sua lateness è negativa; Tardiness o Exceeding time E i = max(0, L i ): rappresenta il tempo in cui un processo è rimasto attivo oltre la propria deadline; Laxity o Slack time X i : X i = d i a i C i rappresenta il ritardo di attivazione massimo che un task attivo può subire in coda pronti per non eccedere la sua deadline Sistemi Hard e Soft real-time I sistemi real-time si dividono in due categorie: i sistemi «hard» sono quelli che possono garantire la fattibilità di schedulazione di un insieme di task hard e soft real-time; i sistemi «soft» sono quelli che possono garantire la fattibilità di schedulazione di un insieme di soli task soft real-time. Per chiarire meglio il concetto si pensi a un sistema real-time come a un sistema che, dato un insieme di n task, ognuno con i propri vincoli temporali (deadline del task i-esimo), è in grado di minimizzare la funzione di costo definita come: K s = n K i (t) dove K i (t) è la funzione costo del task i-esimo definita come: i

11 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 5 Figura 1.2: Esempi di funzioni di costo per diverse tipologie di task 0 se t d i K i (t) = se t > d i se il task i-esimo è di tipo hard real-time, o come: 0 se t d i K i (t) = f(t) se t > d i se il task i-esimo è di tipo soft real-time, dove si è indicato con f(t) una funzione monotona crescente all aumentare del tempo che scorre. Così come mostrato nella Fig. 1.2 i task di tipo hard real-time dovranno essere schedulati in modo da terminare a un istante t minore della deadline, in modo da far valere la funzione di costo 0 e non ; mentre i task soft real-time dovranno anche loro far valere 0 la funzione di costo relativa ma, in questo caso, uno sfondamento della deadline t > d i non manderà il costo globale del sistema all infinito (equivalente al disastro). In entrambi i casi il comportamento real time è ottenuto dividendo un programma in processi, il cui comportamento è prevedibile e noto in anticipo. Questi processi hanno normalmente una vita breve e possono essere eseguiti nella loro completezza in un tempo inferiore al secondo.

12 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 6 Nel momento in cui viene rilevato un evento esterno, lo scheduler dei processi ha il compito di determinare una opportuna sequenza di esecuzione dei processi, tale da garantire il rispetto di tutte le scadenze. Come descritto nella sezione precedente, gli eventi a cui un sistema real time deve poter reagire sono classificati in task periodici e aperiodici. Nel caso di eventi periodici, se esistono m task e se il task i-esimo arriva con periodo P i e richiede C i secondi di tempo di CPU per essere gestito, il carico può essere gestito solo se: M i=1 C i P i 1 Un sistema real time che rispetta questo vincolo è detto schedulabile. Per esempio, consideriamo un sistema soft real time con tre eventi periodici rispettivamente di 100, 200 e 500 millisecondi. Se questi eventi richiedono 50, 30 e 100ms di tempo di CPU per la loro esecuzione, il sistema è schedulabile in quanto: 50/100+30/ /500 = 0, 5 + 0, , 2 1. Se un quarto evento, con periodo di 1 secondo, si aggiunge al sistema, l insieme dei processi rimarrà schedulabile fino a quando a questo evento non verranno richiesti più di 150ms di tempo di CPU per occorrenza. Notare che, nel calcolo precedente, si suppone implicitamente che l overhead per il cambio di contesto sia così piccolo da poter essere trascurato. I sistemi operativi general purpose non supportano la funzionalità hard real-time, ma possono supportare quelle di tipo soft (per esempio Linux è un sistema soft real-time) Schedulazione dei sistemi real-time Ciò che differenzia un sistema non real-time da un RTOS è principalmente lo schedulatore. Lo schedulatore è un algoritmo che controlla l accesso alla CPU da parte dei vari processi del computer. La schedulazione dei processi è fondamentale per garantire l efficienza computazionale del computer, garantendo un utilizzo ottimizzato della CPU tra processi che evolvono parallelamente, tenendo conto degli interrupt prodotti dai controller delle varie unità I/O, dalle memorie e dagli hard-disk.

13 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 7 Figura 1.3: Task Concetti generali I possibili stati di un task sono: ready : pronto all esecuzione, in attesa della CPU; pended : in attesa di una risorsa richiesta dal task per procedere nell esecuzione; delayed : in attesa della fine di un timeout pressato; suspended : lo stato iniziale di ogni task appena creato. Tutti i task in stato ready sono pronti per essere eseguiti. L accesso alla CPU di un task rispetto a un altro, è funzione dell algoritmo implementato nello schedulatore. Gli aspetti più importanti di uno schedulatore sono: PRIORITÀ: la priorità è un indice che definisce l importanza che un processo ha nei confronti degli altri. Si possono distinguere priorità interna (definita dal sistema in base a diversi requisiti tipo memoria, I/O, tempo di esecuzione) ed esterna (definita dall utente). In aggiunta si definisce una priorità dinamica (aging).

14 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 8 Se un processo ha una priorità bassa verrà sempre scavalcato da processi a priorità più alta. Il rischio è che tale processo non venga eseguito mai (starvation). Perciò quando un processo è pronto per essere eseguito da troppo tempo, la sua priorità viene aumentata dinamicamente dallo scheduler; PREEMPTION: se nella coda esiste un processo pronto a essere eseguito, con priorità maggiore di quello in esecuzione nella CPU, lo scheduler forza il rilascio della CPU e passa a eseguire il processo a più alta priorità. Un esempio può essere l I/O. Se un processo ad alta priorità subisce un interrupt per la gestione di un I/O, lo scheduler passa la CPU al processo successivo. Se lo scheduler non fosse dotato di diritto di prelazione (preemption), il processo ad alta priorità dovrebbe aspettare che il processo a bassa priorità finisca prima di completare il suo ciclo. Con la preemption, invece, la CPU viene liberata dal processo a bassa priorità nell istante in cui il processo ad alta priorità ritorna pronto a essere eseguibile (cioè quando ha finito l I/O). Algoritmi di schedulazione real-time Gli algoritmi di scheduling real time sono distinti in: statici: la decisione di schedulazione è presa prima che il sistema inizi l esecuzione dei processi. Questi metodi richiedono che le informazioni complete circa il lavoro da fare e le scadenze da rispettare, siano disponibili in anticipo rispetto all esecuzione dei processi; dinamici: la decisione di schedulazione è presa durante l esecuzione dei processi. Non hanno restrizioni circa la conoscenza anticipata sui tempi di esecuzione e le scadenze da rispettare. Successivamente verranno analizzate alcune politiche di scheduling realtime, facendo riferimento al particolare contesto delle applicazioni multimediali. Infatti i sistemi operativi che supportano applicazioni multimediali differiscono da quelli tradizionali per tre aspetti principali: la schedulazione dei processi, il file system e la schedulazione del disco. Schedulazione a frequenza monotona Il classico algoritmo statico di schedulazione in tempo reale per processi periodici e prelazionabili è RMS (Rate Monotonic Scheduling, schedulazione a frequenza monotona). È utilizzabile per processi che soddisfino le seguenti condizioni:

15 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 9 1. ogni processo periodico deve essere completato entro il suo periodo di tempo; 2. nessun processo è dipendente dagli altri; 3. ogni processo necessita della stessa quantità di tempo di CPU per ogni periodo di esecuzione; 4. i processi non periodici non hanno scadenze temporali; 5. la prelazione dei processi avviene istantaneamente e senza sovraccarico di lavoro per il sistema. Le prime quattro condizioni sono ragionevoli, mentre l ultima rende più semplice la modellazione del sistema. RMS assegna a ciascun processo una priorità prefissata uguale alla frequenza con cui deve essere eseguito. Un processo che debba essere eseguito ogni 30ms (33 volte/s) acquisisce priorità 33; un processo da eseguire ogni 40ms (25 volte/s) acquisisce priorità 25, mentre un processo da eseguire ogni 50ms (20 volte/s) acquisisce priorità 20. Dato che le priorità variano linearmente con la frequenza (numero di volte al secondo in cui il processo è eseguito), il metodo è detto a frequenza monotona. Durante l esecuzione, lo schedulatore esegue sempre il processo pronto a più alta priorità, prelazionando, se necessario, il processo in esecuzione. È stato dimostrato che RMS è ottimale rispetto alla classe di algoritmi di schedulazione statici. Schedulazione con priorità alla scadenza più vicina L algoritmo EDF (Earliest Deadline First, schedulazione con priorità alla scadenza più vicina), è un algoritmo dinamico e pertanto non richiede nè che i processi siano periodici, nè che abbiano lo stesso tempo di esecuzione per periodo e di CPU. Con questo approccio, è sufficiente che un processo che ha bisogno della CPU annunci la sua presenza e la scadenza temporale. Lo schedulatore mantiene una lista dei processi eseguibili, ordinata rispetto alla scadenza temporale; l algoritmo esegue il primo processo della lista, cioè quello con scadenza temporale più vicina. Quando un nuovo processo è pronto, il sistema controlla se la sua scadenza preceda quella del processo correntemente in esecuzione: in caso affermativo il nuovo processo prelaziona quello corrente.

16 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 10 È interessante notare che, utilizzando priorità statiche, l algoritmo RMS funziona solo se l utilizzo della CPU non è troppo elevato. È possibile dimostrare per ogni sistema di m processi periodici che il funzionamento di RMS è garantito (condizione sufficiente) se: m i=1 C i P i m (2 1/m 1) Per m che tende all infinito, l utilizzo massimo della CPU tende in modo asintotico a ln2 = Questo significa che per m = 3, RMS funziona sempre se l utilizzazione della CPU è uguale e o minore di Al contrario, EDF funziona sempre per qualunque insieme di processi schedulabile e può raggiungere il 100% di utilizzo della CPU. Il prezzo di tutto ciò è pagato in termini di una maggiore complessità dell algoritmo EDF rispetto a RMS Caratteristiche di un sistema real-time Un sistema real-time dovrebbe possedere le seguenti caratteristiche: schedulazione ottima: tutti i task sono noti a priori così come i vincoli temporali. Dovrebbe essere possibile avere uno schedulatore che minimizzi la funzione di costo K s presentata prima; condivisione delle risorse: i task sono entità separate che concorrono a uno stesso scopo: pertanto non è necessario avere spazi di indirizzamento separati; garanzia di esecuzione: tutti i task di tipo hard real-time devono terminare entro le proprie deadline. Nel caso in cui arrivi un nuovo task, o un task non possa completare entro la deadline, una notifica anticipata del sistema può essere utilizzata per impedire l esecuzione del nuovo task o per recuperare l esecuzione del task che sta per sfondare; prevedibilità delle chiamate di sistema: il sistema deve essere in grado di valutare i tempi di calcolo di ogni task per determinare la schedulazione fattibile. Ogni chiamata di sistema deve avere un tempo di esecuzione massimo ben definito in modo da non introdurre ritardi indefiniti. I prodotti delle famiglie Windows e Unix non soddisfano le caratteristiche tipiche di un sistema real-time: per esempio, pur gestendo l esecuzione di più

17 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 11 processi con pre-rilascio, non è possibile prevedere in alcun modo quale sarà il tempo di esecuzione di un singolo processo. Inoltre l utilizzo di hard disk per la conservazione dei dati, dispositivi USB o altri dispositivi che introducono forti latenze di esecuzione da parte della CPU, rende impossibile stabilire con certezza quanto tempo sarà necessario per reperire l informazione utile alla corretta esecuzione del codice. Anche il sistema operativo Windows CE 1 viene erroneamente considerato da alcuni un sistema operativo real-time, quando in effetti non esiste nessuna prerogativa architetturale a livello hardware e software che dia modo di prestabilire il tempo di esecuzione di una serie di operazioni. Esistono diversi fattori che causano la non prevedibilità nella risposta del sistema operativo, i principali sono: il dma: può rubare il bus alla CPU ritardando l esecuzione di un task critico. In un sistema real-time si preferisce disattivarlo o usarlo in modalità timeslice, dove si assegna in maniera costante e fissa il bus al DMA, anche se non ci sono operazioni da fare; la cache: può causare non prevedibilità poiché esistono casi in cui essa fallisce, causando ritardi nell accesso alla memoria da parte della CPU. Ipotizzando il peggiore dei casi si preferisce non usarla affatto; meccanismi di gestione della memoria: queste tecniche non devono introdurre ritardi non prevedibili durante l esecuzione di task critici: la paginazione può causare dei page fault intollerabili per un sistema hard real-time. Tipicamente si usa la segmentazione o la partizione statica della memoria; interrupt: sono generati da dispositivi periferici quando devono scambiare delle informazione con la CPU. Se queste interruzioni si verifcano durante l esecuzione di un task critico, generano ritardi non prevedibili ed è quindi necessario trattarle in maniera opportuna; i sistemi di power management: sono meccanismi hardware che possono rallentare la CPU o far eseguire a essa del codice utile a dissipare minor energia. Essi vengono disattivati in quanto è chiaro che, in un sistema real-time, è importante non sfondare una deadline piuttosto che consumare poca energia. Tra gli RTOS commerciali troviamo il POSIX-conformant (per esempio LynxOS che è Unix compatibile) e non POSIX-conformant come per esempio VxWorks (che supporta in parte gli standard POSIX). 1 sistema operativo sviluppato da Microsoft per dispositivi portatili e sistemi embedded

18 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 12 Per quanto riguarda i sistemi Open Source è possibile l uso di Linux, con necessarie precauzioni, opportunatamente applicate in soluzioni come Xenomai, RTAI, RT-Preempt e altre ancora. 1.2 GNU/Linux In questa sezione si darà una panoramica generale sulle opportunità, i vantaggi e i limiti di utilizzo del sistema operativo GNU/Linux per i sistemi embedded. Verranno considerati sia gli aspetti più strettamente tecnici, sia quelli legati genericamente al modello di sviluppo software. Si noti che parliamo qui di GNU/Linux (e non semplicemente di Linux) per sottolineare il fatto che trattiamo non solo del nucleo del sistema operativo (Linux appunto) ma anche delle applicazioni nonché dei sistemi di sviluppo: editor, sistemi di controllo della configurazione, compilatori, debugger, programmi di test. Buona parte di questi programmi sono il frutto diretto del progetto GNU ( mentre la totalità di essi (compreso ovviamente Linux stesso) è, o meglio può essere, a seconda delle scelte degli utenti, software libero, distribuito secondo la licenza GNU GPL o altre licenze libere. Alcune riflessioni saranno dedicate ai vantaggi dell uso di software libero nello sviluppo di applicazioni embedded. Non ci occuperemo, invece, specificamente di distribuzioni Linux embedded commerciali, ma molti dei concetti qui esposti si applicano ugualmente anche a esse. Il nucleo (kernel) Linux è funzionalmente equivalente a un kernel Unix, e per questo motivo è molto diverso, nonché molto più complesso, della maggior parte dei tradizionali sistemi operativi per applicazioni specifiche (con esigenze di tempo reale o meno), nati per CPU con limitate risorse di calcolo e sistemi con piccole quantità di memoria (sia RAM sia ROM). Qui di seguito si riportano alcune delle caratteristiche più significative, con particolare riferimento agli aspetti che di norma risultano meno familiari per gli utenti provenienti da altre esperienze Interruzioni hardware e software Le interruzioni («interrupt» o IRQ per «interrupt request») sono alla base del funzionamento di un sistema multiprocesso.

19 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 13 Normalmente l esecuzione del codice da parte del processore («CPU», «central processing unit») è sequenziale, poichè viene seguito il flusso logico del programma in esecuzione senza distrazioni. Infatti, le prime macchine adottavano esclusivamente questo modo di funzionamento. Poco dopo, però, si è pensato di permettere l interruzione del normale flusso di istruzioni eseguito dal processore da parte di eventi esterni. Oggi questo meccanismo è ampiamente usato e gli eventi che interrompono il processore sono normalmente associati a una periferica che richiede attenzione: per esempio la pressione di un tasto, l invio di un pacchetto dalla rete o lo scattare del tempo sull orologio di sistema. Il meccanismo usato per riportare le interruzioni al processore può essere dei più vari. Nel caso più semplice si tratta di un unico filo collegato con il mondo esterno, attraverso il quale un circuito dedicato, chiamato PIC («programmable interrupt controller»), comunica la sua richiesta di attenzione. La CPU interromperà il suo lavoro e interrogherà il PIC per sapere quale periferica ha richiesto attenzione. In certi sistemi il processore viene raggiunto da vari segnali, corrispondenti a richieste di interruzioni con priorità diversa e potrebbe non essere necessario un PIC esterno. In altri casi molte periferiche risiedono fisicamente all interno del processore e viene quindi realizzata un architettura con più livelli di priorità con un solo segnale di IRQ proveniente dall esterno. A tale segnale può essere associato o meno un controllore programmabile. Altre variazioni sul tema sono le cosiddette trap (spiegate più avanti), le interruzioni non mascherabili (NMI, «non maskable interrupt») e tutte le complicazioni introdotte nel mondo PC negli ultimi anni (APIC, IO- APIC, MSI, MSI-X). Queste ultime possono essere tranquillamente ignorate, in quanto l interfaccia offerta dal kernel verso i suoi moduli è indipendente dalla gestione di basso livello implementata nel caso specifico. Anche la gestione dei livelli di priorità, quando presente, può essere ignorata dal codice dei driver. Questi possono usare il semplice modello a due livelli in cui il driver può chiedere la disabilitazione temporanea delle interruzioni per poi riabilitarle, oppure non toccare niente del tutto. Le cosiddette trap (trappole), sono interruzioni generate dal processore quando non riesce a eseguire un istruzione macchina, perché si tratta di una divisione per zero, ovvero l indirizzo di memoria cui deve accedere non è valido, oppure l istruzione non è definita nel set di istruzioni della CPU.

20 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 14 In tutti questi casi l esecuzione passa al sistema operativo con un meccanismo simile o identico (a seconda delle scelte dei progettisti hardware) a quello utilizzato nella gestione di interruzioni esterne. Il sistema operativo può analizzare la situazione e correggere il problema (per esempio recuperando una pagina di dati dallo spazio di swap) oppure «punire» il programma che si è comportato male. In un sistema Unix la punizione consiste nell invio al processo di un segnale; nei tre casi elencati si tratta: di SIGFPE (floating point exception), SIGSEGV (segmentation violation) e SIGILL (illegal intruction). Il processo può essere predisposto per intercettare questi segnali e cercare di recuperare la situazione, altrimenti verrà terminato. Anche le interruzioni software si avvalgono del meccanismo hardware delle interruzioni (ancora una volta, un meccanismo simile o identico) al fine di trasferire il controllo al sistema operativo. Nel set di istruzioni del processore è in genere definita una istruzione INT (o SWI software interrupt o equivalente) che trasferisce il controllo al sistema operativo proprio come una trap o una interruzione esterna. Il sistema operativo, analizzando lo stato del processore, estrae gli argomenti passati dal programma e provvede a eseguire la richiesta o a ritornare un codice di errore. Per esempio, su piattaforma x86 le chiamate di sistema per il kernel Linux sono implementate dall interruzione numero 0x80. Il registro EAX contiene il numero della chiamata di sistema e, all uscita, il valore di ritorno; gli altri registri contengono gli argomenti della chiamata di sistema. Per i dettagli implementativi è interessante leggere <asm/unistd.h> per la propria architettura. Rispetto ai requisiti imposti dallo scenario real-time, una prima differenza rilevante riguarda il fatto che il nucleo non è compilato assieme all applicazione, ma vive in maniera indipendente. Il meccanismo di accesso ai servizi del nucleo è costituito dalle chiamate di sistema, implementate attraverso interruzioni software. Inoltre il codice del nucleo funziona sempre in modalità «supervisore»: ha quindi accesso a tutte le risorse hardware della macchina, gestisce direttamente interruzioni ed eccezioni e si occupa di tutte le funzionalità di basso livello (vedi Fig. 1.4). Al contrario, il codice dell applicazione viene eseguito in modalità utente, ed è quindi limitato per quanto riguarda l accesso fisico al sistema, oltre a non poter direttamente gestire interruzioni ed eccezioni. Dal punto di vista

21 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 15 Figura 1.4: Linux e la sua gestione interrupt hardware e software della scalabilità Linux ha lo svantaggio di richiedere sempre un file system per poter funzionare. Si noti tuttavia che ciò non implica necessariamente che il sistema sia dotato di un dispositivo di memorizzazione di massa. È infatti possibile usare svariati supporti fisici per memorizzare un file system: RAM, ROM, memoria FLASH, il file system di un altra macchina con cui si è collegati via rete, e così via Schedulazione a code multiple La parte del nucleo del sistema operativo che decide istante per istante quale sia il processo che debba avere il controllo della CPU prende il nome di schedulatore. A ogni processo vengono assegnati due attributi fondamentali: una priorità e una politica di schedulazione. In Linux esistono due code di processo: i processi soft real-time (scheduler RR o FCFS con priorità statica) e i processi utente (scheduler RR, non realtime con priorità dinamiche). La gestione avviene tramite tick (crediti). A ogni processo sono assegnati un certo numero di crediti che equivalgono a unità di tempo di utilizzo della CPU.

22 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 16 Figura 1.5: Modello dello scheduler Linux Quando un processo diventa pronto o in attesa gli si sottrae il numero di tick utilizzati. Al momento del dispatch (rimozione di un processo dalla CPU e sostituzione con un altro) viene eseguito il processo con maggiori crediti. Quando tutti i processi pronti hanno esaurito i crediti, questi vengono riassegnati. processo i CREDIT I i = CREDIT I i 2 + P RIORIT A Pertanto gli obiettivi che Linux si propone, per quanto riguarda lo scheduling, sono un equa distribuzione della CPU tra i diversi processi e l evitare che un solo processo possa impadronirsi di tutta la banda del processore per evidenti ragioni di sicurezza. Per ulteriori approfondimenti si rimanda alla pagina di manuale [1] relativa alla chiamata di sistema sched_setscheduler(2) Schedulazione CFS Dalla versione in poi del kernel Linux, viene utilizzato l algoritmo di schedulazione CFS (Completely Fair Scheduler). Questo scheduler invece di basarsi sul meccanismo delle code multiple, utilizza un albero RB [2] per la gestione del task-set. L 80% dell implementazione dell algoritmo CFS (Completely Fair Scheduler) può essere riassunta in una singola frase: il CFS fondamentalmente

23 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 17 modella una CPU ideale e accurata multi-tasking sull hardware reale. Una CPU multi-tasking «ideale» è una CPU che ha il 100% dell occupazione di banda e che può eseguire ogni task alla stessa velocità, in parallelo, 1 ognuno alla velocità di nr running (dove nr running è il numero di task attivi). Per esempio se ci sono due processi attivi, li esegue ognuno al 50% delle proprie possibilità, completamente in parallelo. Nell hardware reale possiamo eseguire un solo processo alla volta: mentre un task viene eseguito, gli altri, che rimangono in attesa della CPU, sono in svantaggio, perchè il task corrente si appropria ingiustamente del tempo di CPU. Nel CFS, questo sbilanciamento è espresso e tracciato tramite un valore, associato a ogni task, p->wait_runtime espresso in nanosecondi, dove wait_runtime è il tempo totale di CPU che il processo dovrebbe ancora ottenere affinchè il sistema ritorni perfettamente «giusto» e bilanciato. Su una piattaforma hardware «ideale», il valore p->wait_runtime dovrebbe essere sempre pari a zero; nessun task dovrebbe trovarsi «sbilanciato» rispetto al tempo ideale di suddivisione del tempo di CPU totale 1 nr running. La politica di scelta di attivazione del task sucessivo è basata proprio sul valore p->wait_runtime ed è veramente semplice: il processo che ha il valore più alto di p->wait_runtime sarà quello scelto. In altre parole, il CFS prova ad attivare il task che ha bisogno urgente di altro tempo di CPU. Quindi il CFS cerca di dividere, quanto più possibile, il tempo totale di CPU tra tutti i processi attivi, come accadrebbe idealmente in un hardware multitasking. La parte restante dell implementazione del CFS, che non rientra in questa semplificazione, è relativa a poche cose aggiunte: come i livelli di priorità, la gestione dei sistemi multiprocessore e alcune variazioni per il riconoscimento dei processi non attivi (vedi Sez ). In pratica funziona così: il sistema esegue il processo per un po. Quando questo si sospende (o viene eseguito lo scheduler) l uso della CPU viene accreditato al task: il tempo in cui ha usato la CPU fisica viene sotratto dal tempo totale che gli spettava p->wait_runtime, corretto del tempo ulteriore che comunque gli sarebbe spettato. Appena il valore di p->wait_runtime diventa così basso che un altro processo diventa «il prossimo task» tra quelli conservati nell albero RN ordinato in base al tempo (viene introdotta anche una certa distanza temporale

24 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 18 in modo da non sovra-schedulare i task e non sporcare la cache); al processo corrente viene sotratta la CPU e concessa al nuovo task. Il valore di rq->fair_clock descrive il tempo di CPU in cui il processo è stato in esecuzione rispetto al tempo che avrebbe dovuto ottenere dallo scheduler. Perciò usando questo valore si può misurare il tempo di CPU che un task si aspetta di ottenere. Tutti i processi attivi sono ordinati nell albero RN secondo la chiave rq->fair_clock- p->wait_runtime; il CFS concede la CPU sempre al task collocato nell albero più a sinistra. Con il procedere del sistema, i processi che diventano avviabili vengono inseriti nell albero da «destra» lentamente e, a mano a mano che viene effettuata la schedulazione, a ogni processo viene data la possibilità di spostarsi sempre più a sinistra in modo tale che possa giungere alla CPU in un periodo di tempo deterministico Architettura modulare e licenza Open Source Una caratteristica del kernel Linux è quella di poter essere esteso mentre il sistema funziona (mediante il meccanismo dei moduli). Questo consente il supporto di piattaforme differenti dal punto di vista delle periferiche hardware, senza dover ricompilare il nucleo. I driver di periferica fanno di norma parte del codice del kernel e sono accessibili come voci del file system. Uno dei grossi vantaggi dell uso di software libero nei sistemi embedded è che lo sviluppo dei driver, e in generale di porzioni/moduli del kernel, è ampiamente facilitato rispetto ai sistemi tradizionali, vista la disponibilità totale dei sorgenti del kernel e quindi di un numero notevole di esempi funzionanti sul campo, nonché di un ampia documentazione. Nel caso di utilizzo di macchine con MMU (Memory Management Unit), sempre più frequente in virtù dei costi via via più bassi del silicio, è possibile sfruttare funzioni molto avanzate sia dal punto di vista della protezione della memoria, e quindi dell affidabilità del sistema, sia da quello delle funzionalità. In particolare la disponibilità di chiamate come mmap(), che consente di mappare i contenuti di un file o genericamente di un dispositivo su un intervallo di indirizzi virtuali, rende il kernel Linux particolarmente attraente anche se non è abilitato per la gestione degli interrupt. Il modo Unix/Linux di creare nuovi processi risulta ostico ai programmatori embedded tradizionali.

25 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 19 Quello che Linux fa è «clonare» un processo per poi sostituirne l immagine con quella del programma da eseguire, contrariamente a quanto accade con i sistemi operativi basati su thread, in cui la creazione di un nuovo thread comporta una sola chiamata. Uno dei parametri necessari è l indirizzo del punto di ingresso del thread stesso. Si tenga tuttavia presente che anche sotto Linux è possibile la programmazione a thread. Esistono infatti diverse implementazioni dei cosiddetti «thread POSIX», definiti dalla norma POSIX c. Infine Linux dispone di una grande quantità di meccanismi di comunicazione interprocesso, eredità dei suoi predecessori: si va dai segnali, la forma più arcaica, ad altre più sofisticate (pipe, fifo, semafori, code di messaggi, memoria condivisa, socket). La varietà di possibili soluzioni impone all utente una buona conoscenza di tutte le alternative, al fine di scegliere la più adatta alle esigenze dell applicazione Il livello applicativo Per ciò che concerne la rete, il sistema GNU/Linux fornisce una grande quantità di applicazioni già scritte e collaudate da tempo, ma l aspetto più interessante consiste nel cambio radicale di ottica rispetto all approccio tradizionale. La novità consiste nel fatto che la filosofia Unix (da cui Linux discende da un punto di vista tecnico) privilegia la modularità. Di conseguenza, ciò che verrebbe visto da un programmatore embedded tradizionale come un unica applicazione da scrivere in C, può essere spezzato in una serie di programmi tra loro interagenti, alcuni dei quali già esistenti e altri da scrivere in linguaggi diversi a seconda dell opportunità tecnica. È inutile rimarcare tutti i vantaggi dell approccio modulare. E importante, invece, sottolineare che, con l approccio presentato, la fase di test di modulo risulta semplificata perchè il modulo stesso è già un programma eseguibile, rendendo quindi inutile la costosa scrittura di programmi di test ad hoc. Infine evidenziamo il fatto che l uso di linguaggi di scripting (per esempio script della shell, tcl e le sue varianti, perl) può risolvere un gran numero di problemi i quali risultano ostici in C, come per esempio lavorare con stringhe ed espressioni regolari.

26 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX Portabilità Sebbene in origine sia nato come un sistema operativo esclusivamente per piattaforma x86 (e in particolare PC), il kernel Linux è stato portato su un grande numero di architetture differenti, e anche su macchine non dotate di MMU. A livello di applicazioni, sono disponibili distribuzioni Linux libere che coprono diverse architetture. Per esempio la distribuzione Debian, pur non specifica per l embedded, dispone di pacchetti per differenti piattaforme comunemente impiegate su macchine a impiego specifico (x86, ARM, PowerPC, SH e altre). A livello di librerie C, esistono progetti liberi nati per dare origine a librerie poco esigenti dal punto di vista delle risorse richieste: bisogna tenere presente che Linux non è un sistema operativo utilizzabile per sistemi con risorse limitatissime. L aspetto più delicato è costituito dalla quantità di memoria a disposizione: di norma si prende come limite inferiore quello dei 2MB di memoria RAM + 2MB di memoria ROM (o FLASH), anche se il limite effettivo varia a seconda della piattaforma. La potenza di calcolo richiesta alla CPU dal kernel non rappresenta un fattore particolarmente critico. Nonostante a volte venga considerato «scomodo» e/o «poco usabile», Linux rappresenta una piattaforma ideale anche per ciò che concerne la macchina host, cioè quella in cui si sviluppa il codice che girerà sul campo. Questo è vero anche per quello che riguarda i compilatori, i sistemi di controllo della configurazione, il test e il debugging Compilazione, debugging e test L insieme di binutils (assembler, linker e altri programmi di utilità) e di gcc (GNU compiler collection, il compilatore GNU) costituisce la toolchain standard sotto Linux. Si tratta di strumenti di sviluppo di livello professionale, in grado di produrre codice binario per un numero vastissimo di CPU e sistemi operativi. Il debugger standard sotto Linux fa parte del progetto GNU e si chiama gdb. La versione «base» di gdb prevede l uso da linea di comando, ma esistono anche versioni grafiche (come per esempio Insight e ddd). Inoltre sotto

27 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 21 Linux il debugging delle applicazioni può essere effettuato sia mediante il debugger vero e proprio, sia attraverso strumenti di tracing come per esempio strace(1), che evidenzia la sequenza delle chiamate di sistema effettuate dall applicazione sotto esame. Per ciò che consente il testing, soprattutto se si parla di applicazioni di rete, la disponibilità di linguaggi di scripting e di programmi come netcat(1) o tcpdump(1) rende possibile la scrittura rapida di programmi di test anche relativamente complessi. Il debugging del kernel e dei suoi moduli è invece più problematico. Per scelta progettuale, infatti, il kernel non dispone (in modo nativo) di un modulo per il debugging. Si ricorre quindi di norma ad altri metodi, tutti sostanzialmente riconducibili ad attività di tracciamento. Esistono però anche patch del kernel che consentono il debugging vero e proprio I problemi della schedulazione real time sotto Linux Essendo un kernel multitasking e multiutente, Linux, come altri Unix, non è stato scritto pensando al tempo reale «stretto», ossia ad applicazioni in cui il mancato rispetto dei tempi di esecuzione specificati porti a un malfunzionamento grave. La conseguenza di quanto si è detto in precedenza è il fatto che lo schedulatore Linux non ha il concetto di «deadline», ovvero il tempo entro il quale una certa attività andrà svolta. Non è quindi adatto ad applicazioni in tempo reale perchè non può conoscere i requisiti temporali dei vari processi real-time. Si potrebbe a questo punto pensare che, sostituendo lo schedulatore tradizionale con uno opportunamente riscritto, sia possibile aggirare il problema: questo non è vero a causa di un secondo ordine di motivi. Bisogna, infatti, chiedersi quando possa avvenire un cambio di contesto, ossia quando effettivamente il controllo della CPU possa passare da un processo a un altro. La risposta è che i cambi di contesto, sotto Linux, possono avvenire solo al passaggio dallo spazio del kernel (kernel space) allo spazio delle applicazioni (user space), ossia per esempio al ritorno da una chiamata di sistema oppure al ritorno da un interrupt handler, quando l interruzione avviene mentre la CPU sta eseguendo codice dell utente.

28 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 22 Motivo di ciò è l esigenza di preservare l integrità delle strutture dati interne del nucleo, integrità che verrebbe compromessa se il cambio di contesto potesse avvenire in qualsiasi momento. A causa di questo fatto, non è possibile calcolare un limite superiore per il tempo che intercorre tra un cambio di contesto e il successivo. Prendiamo per esempio il caso in cui avvenga un grande numero di interruzioni annidate mentre la CPU si trova già all interno del codice del kernel. Se si verifica una condizione del genere, non si può prevedere il ritorno al codice utente e quindi procedere a un eventuale cambio di contesto. Se il controller IDE continua a interrompere senza che sia possibile uscire dallo spazio del kernel, il processo utente di elaborazione (anche se a priorità più alta possibile) non può riprendere il controllo perché lo scheduler non può girare. Per maggiori informazioni si può consultare l articolo «Linux e real time (prima parte)» su [4] Strumenti di supporto Linux fornisce strumenti validi anche per ciò che concerne l editing (per esempio emacs), il controllo della configurazione dei moduli (cvs), la stesura della documentazione (texinfdeto, sgmtools), e in generale tutto ciò che riguarda lo sviluppo di software. Il modello di sviluppo da adottare quando si utilizza software libero, deve essere diverso rispetto a quello che si impiega tradizionalmente. Salvo infatti che non ci si affidi a una distribuzione commerciale o si stipuli un contratto di consulenza, il sistema GNU/Linux è distribuito senza garanzia di funzionamento. Questo viene spesso considerato da molti utenti, o meglio dai loro manager, come un difetto. In realtà, non si riesce ad afferrare che il software libero fornisce anche dei diritti e di conseguenza delle opportunità in più rispetto al software proprietario: la disponibilità del codice sorgente per la lettura, lo studio e le modifiche consente di correggere malfunzionamenti, effettuare personalizzazioni, nonché imparare dal codice e dagli errori altrui e in qualche caso contribuire attivamente allo sviluppo. Infine è bene tener presente che sia il kernel sia gli altri pacchetti liberi di un sistema GNU/Linux sono opera di comunità di sviluppatori, con i quali si può stabilire un contatto per ricevere aiuto, scambiare esperienze e consigli.

29 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 23 Pertanto, qualora si volesse realizzare un sistema operativo real-time basato su Linux, occorrerebbe tenere in considerazione queste problematiche. Nel prossimo capitolo viene presentata la soluzione «ibrida» del sistema Xenomai, il quale permette di ottenere un sistema operativo GNU/Linux di tipo real-time. Un recente studio sui sistemi operativi utilizzati nel mercato dei sistemi embedded [3] ha dimostrato come la percentuale di utenti che ha scelto di non utilizzare GNU/Linux Embedded, a causa di lacune nelle caratteristiche di tipo real time, sia scesa dal 25% al 18% negli ultimi tre anni. Da questi dati si può dedurre come il sistema operativo GNU/Linux, sebbene nato non nell ottica di un utilizzo specifico per i sistemi embedded, stia sviluppando quelle capacità tali da renderlo adatto anche al mondo real time, in cui la velocità di risposta, ma soprattutto il determinismo (sia degli eventi, sia delle tempistiche), giocano un ruolo fondamentale. 1.3 Soluzioni real-time per il kernel Linux Linux e le applicazioni real-time Lo sviluppo e la diffusione del sistema operativo Linux e delle applicazioni real-time, soprattutto in contesti embedded, ha portato alla ricerca di soluzioni congiunte in cui sistemi con caratteristiche funzionali di tipo real-time fossero basati sul sistema operativo Linux. L utilizzo di software Open Source offre notevoli vantaggi in termini di costi, flessibilità, sviluppo e supporto. I sistemi embedded ricoprono invece un ruolo sempre più importante in settori come l automazione, l automotive, le telecomunicazioni e il digital entertainment. Come già anticipato Linux rappresenta una grande opportunità: esso è un sistema operativo stabile, libero, in grado di fornire il supporto per moltissime architetture hardware e sviluppato costantemente. Esiste però anche un grande problema: Linux non è stato concepito per essere un sistema operativo real-time. Come noto, Linux è nato ispirandosi a Unix e il suo target principale sono sempre stati i server e recentemente i computer desktop. Linux è stato sempre utilizzato in ambito scientifico anche per sistemi embedded, ma non è mai stato sviluppato con la finalità di essere un sistema operativo veramente real-time. Recentemente si è cercato di trovare soluzioni

30 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 24 finalizzate per avvicinare il sistema operativo Linux al mondo real-time, in modo da rendere questo connubio conveniente. Consideriamo ora le motivazioni tecniche che hanno reso necessario uno sviluppo mirato di Linux in direzione delle applicazioni real-time. La considerazione chiave da fare è la seguente: scelte progettuali che risultano ottime per sistemi operativi general-purpose sono spesso pessime per i sistemi operativi real-time. Un sistema operativo general-purpose non può operare correttamente in ambito real-time, in quanto è stato sviluppato per raggiungere buone prestazioni in contesti con diverse applicazioni in esecuzione contemporanea, ma senza la possibilità di ottimizzare le prestazioni di alcuna di esse in particolare. Inoltre alcune delle principali caratteristiche dei sistemi operativi generalpurpose risultano essere, di fatto, delle limitazioni per le prestazioni in ambito real-time. Per i sistemi multiprocesso è molto importante minimizzare l overhead dovuto al context-switch: se però da una parte uno scheduler che opera con una risoluzione temporale piuttosto bassa (ovvero effettua lo scheduling non troppo frequentemente) riesce a limitare questo overhead, dall altra esso rende molto difficile, se non impossibile, mandare in esecuzione un processo time-critical nei tempi corretti. Consideriamo ora lo sviluppo di un sistema operativo dal punto di vista opposto. Un modo per migliorare le prestazioni real-time è quello di aggiungere dei nuovi punti di preemption, dove il sistema operativo possa fermare l esecuzione di un processo e fornire le risorse a un processo critico. Tuttavia questo approccio, aumentando l overhead dovuto ai contextswitch, riduce le prestazioni generali di un sistema multiprocesso. Normalmente, invece, i sistemi operativi general-purpose vengono sviluppati cercando di ottimizzare le prestazioni medie, lasciando che il comportamento worst-case non sia deterministico Caratteristiche RT del Kernel Linux Il kernel Linux non è stato sviluppato con l intenzione di ottenere un sistema operativo strettamente real-time. Tuttavia, visto il crescente interesse per l utilizzo di Linux in applicazioni embedded con stringenti vincoli temporali, recentemente si è in parte orien-

31 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 25 tato lo sviluppo del kernel Linux nella direzione dei sistemi real-time, tanto che alcuni definiscono il kernel 2.6 (l ultima versione stabile disponibile del kernel Linux) come «Born to be embedded». Il kernel 2.6 presenta infatti alcune caratteristiche fortemente orientate al real-time, come il nuovo scheduler O(1) scritto da Ingo Molnar e alcune patch per la gestione dell interruzione dell esecuzione dei processi. I dettagli delle caratteristiche real-time per le diverse versioni di kernel Linux saranno approfondite in seguito. L interesse per l utilizzo di Linux in sistemi realtime ha portato alla nascita di diversi progetti finalizzati a trovare soluzioni in grado di rendere il sistema operativo Open Source adatto ad applicazioni di tipo real-time. Questi progetti, sviluppati inizialmente sul kernel 2.4, possono essere suddivisi in due categorie in base all approccio adottato nella soluzione del problema: 1. sviluppo del kernel Linux per inserire funzionalità e caratteristiche tipiche degli RTOS; 2. inserimento di un nuovo strato software costituito da un kernel strettamente real-time; tale strato viene posizionato tra l hardware e il kernel Linux. Quest ultimo sarà visto dal kernel real-time come un semplice processo. Il primo approccio (mostrato nella Fig. 1.6), cerca quindi di rendere il kernel Linux maggiormente orientato ad applicazioni real-time, andando a modificare il kernel stesso negli aspetti caratteristici dei sistemi operativi real-time. In particolare si cerca di modificare il comportamento dello scheduler e le caratteristiche di preemption sui processi. Il secondo approccio vuole invece astrarre il kernel Linux dall hardware del sistema frapponendovi un kernel real-time, diverso e indipendente dal kernel Linux, in grado di gestire adeguatamente i processi real-time e di trattare Linux come un processo a bassa priorità. In questo modo si riesce a garantire il corretto trattamento dei processi real-time direttamente con il kernel di basso livello, e a mantenere la compatibilità con le applicazioni Linux che vengono eseguite quando il sistema non è impegnato da applicazioni real-time.

32 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 26 Figura 1.6: Struttura di un sistema operativo basato sul primo approccio (sinistra) e sul secondo approccio (destra) Approccio RT basato sullo sviluppo del kernel Linux Questo tipo di approccio si pone l obiettivo di rendere Linux maggiormente adatto ad applicazioni in tempo reale apportando delle modifiche sostanziali in alcune funzionalità del kernel, strategiche dal punto di vista dell utilizzo in contesti real-time. I due punti fondamentali su cui si agisce sul kernel sono: 1. scheduler; 2. gestione della preemption. Lo scheduler deve essere in grado di svolgere il suo compito considerando le richieste dei processi RT e deve eseguirlo in un tempo predicibile. Lo scheduler del kernel Linux 2.4 non fornisce le garanzie necessarie per un suo utilizzo in un sistema real-time. Il tempo di scheduling dipende infatti linearmente dal numero di task che deve gestire, caratteristica che rende non predicibile il suo tempo di esecuzione. Questo scheduler viene quindi considerato O(N). Per rimediare a tale problema Ingo Molnar ha scritto uno scheduler completamente nuovo che, grazie a una diversa gestione del processo di scheduling, ottempera ai suoi compiti in un tempo indipendente dal numero di task che deve gestire e pertanto viene indicato come O(1). Le principali caratteristiche dei due scheduler sono:

33 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX Scheduler O(N): questo scheduler suddivide il tempo in «epoche», periodi in cui ogni task può utilizzare il proprio timeslice. I timeslice di ogni task vengono calcolati insieme all inizio di ogni epoca (la durata di tale operazione dipende linearmente dal numero di task in esecuzione nel sistema). Al termine di un epoca i task potrebbero non aver utilizzato tutto il loro timeslice: in questo caso il timeslice inutilizzato sarà considerato nel calcolo del timeslice per l epoca successiva; 2. Scheduler O(1): questo scheduler (ideato da Ingo Molnar) permette di definire un tempo massimo di esecuzione indipendente dal numero di task in esecuzione nel sistema. Esso è incentrato su una struttura chiamata runqueue che tiene traccia di tutti i task assegnati a una certa CPU (quindi ci sarà una runqueue per ogni CPU presente nel sistema). Ogni runqueue contiene due array: l active array e l expired array. Tutti i task vengono inizialmente posti nell active array, per poi essere trasferiti uno alla volta nell expired array quando hanno utilizzato tutto il timeslice che gli era stato assegnato. Durante il trasferimento da un array all altro viene calcolato il nuovo timeslice. Quando l active array è vuoto si torna alla situazione iniziale con un semplice swap dei puntatori dei due array. Questo permette di realizzare la transizione tra epoche diverse in un tempo costante. L ordine in cui i task vengono schedulati dipende ovviamente dalla loro priorità. Per individuare il task a massima priorità in un tempo limite predeterminabile, si è adottata una struttura particolare per i due array: essi sono infatti array di linked-list in cui è presente una lista per ogni livello di priorità. Quando un task viene inserito nell array, esso viene in realtà appeso alla linked-list corrispondente al livello di priorità che gli è stato assegnato. Per trovare il task a maggiore priorità è così sufficiente individuare la prima lista di task ed estrarne il processo da mandare in esecuzione. La preemption, ovvero la possibilità di interrompere l esecuzione di un processo per passare il controllo delle risorse a un altro, deve essere gestita in modo da garantire che un processo RT riesca a ottenere la disponibilità delle risorse in un tempo utile a eseguire correttamente (sia dal punto di vista logico sia, soprattutto, temporale) la propria elaborazione. Nel kernel Linux 2.4 i problemi principali che si riscontrano nella gestione della preemption sono dovuti all impossibilità di interrompere l esecuzione dei processi eseguiti in kernel space, al limitato numero di chiamate allo scheduler (che comportano l esecuzione monolitica di grandi parti di codice) e alla mancanza di timer ad alta risoluzione, necessari per gestire uno scheduling molto frequente.

34 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 28 Per ovviare a questi problemi sono state preparate delle patch per il kernel, in parte poi adottate anche nel kernel Linux 2.6 ufficiale. Le principali patch realizzate per agevolare la preemption nel kernel Linux sono: Preemption Patch: consiste nel permettere che lo scheduler venga eseguito e che un task perda il controllo mentre si trova a eseguire del codice appartenente al kernel. Ovviamente un task può essere interrotto solo quando esegue le sezioni del kernel in corrispondenza delle quali la preemption può effettivamente avere luogo senza traumi; Low-Latency Patch: consiste semplicemente nel modificare il kernel, spezzando i loop nel codice e inserendo delle chiamate allo scheduler per aumentare il numero di punti di preemption. Questa patch richiede cambiamenti piuttosto pesanti e diffusi; inoltre raggiunge migliori risultati sui tempi di latenza del kernel rispetto alla Preemption Patch. La funzionalità di questa patch è anche chiamata Voluntary Preemption; High Resolution Timers Patch: introduce la possibilità di utilizzare timer ad alta risoluzione (fino all ordine dei microsecondi) Approccio RT basato sull utilizzo di un kernel RT di basso livello Questo tipo di approccio si pone l obiettivo di rendere Linux adatto ad applicazioni in tempo reale inserendo un nuovo strato software, costituito da un kernel realmente real- time, tra l hardware e il kernel Linux. Il kernel RT di basso livello gestisce direttamente i processi real-time e tratta il kernel Linux come un processo a bassa priorità. Lo scheduler del kernel real-time tratta il kernel Linux come se fosse il task di idle. Linux viene eseguito solo quando non ci sono task RT da lanciare e il kernel RT è inattivo. I task Linux non possono mai bloccare interrupt o proteggere sé stessi dalla preemption del kernel RT. Questo comportamento è reso possibile dall emulazione software del controllo hardware degli interrupt. I due principali progetti che adottano questo genere di approccio sono Xenomai e RTAI, sviluppati rispettivamente dal progetto DENX e dal DIAPM (Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano [9]). Considerando il maggior supporto dei forum, della mailing list e la licenza di utilizzo GPL/LGPL si è deciso di approfondire Xenomai.

35 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 29 Figura 1.7: Struttura di una soluzione real-time Linux con l uso di un kernel RT

36 Capitolo 2 Xenomai In questo capitolo si descriveranno i dettagli della soluzione adottata per il porting. Si porteranno in luce tutti gli aspetti che hanno fatto sì che la nostra attenzione si focalizzasse su questo sistema, a partire dalla struttura del sistema, in particolar modo sulla pipeline Adeos, per finire con la descrizione dei servizi offerti dalle interfacce di programmazione e con la loro modalità di utilizzo. 2.1 Struttura del progetto Il progetto Xenomai iniziato nel 2001, finì col fondersi, due anni più tardi, nel progetto RTAI allo scopo di creare una piattaforma software gratuita, con caratteristiche real-time, chiamata RTAI/fusion che si appoggiava al kernel real-time di Xenomai. Nel 2005 il progetto tornò indipendente da RTAI per continuare lo sviluppo autonomamente. La caratteristica principale di Xenomai è la presenza di API (Application Programming Interface) indipendenti tra loro. Accanto alle interfacce (chiamate anche skin) che emulano i principali sistemi operativi real-time proprietari, Xenomai permette di sviluppare delle applicazioni, sfruttando le potenzialità del kernel real-time e della sua perfetta integrazione con l ambiente Linux. A questo proposito, Xenomai mette a disposizione due alternative per lo sviluppo del software: una estensione real-time dello standard POSIX e una 30

37 CAPITOLO 2. XENOMAI 31 Figura 2.1: Schema dell architettura di Xenomai skin nativa, semanticamente vicina alle interfacce degli altri sistemi operativi in tempo reale (VxWorks, psos+, uitron, VRTX). Al contrario di RTAI, Xenomai predilige principalmente la portabilità, l estensibilità e la mantenibilità. I comportamenti richiesti dai tradizionali RTOS, relativi alla gestione dei thread e alla loro sincronizzazione, agli interrupt e alla risoluzione dei tempi, sono stati implementati nel nucleo esportando alcune classi di servizio. Tali servizi rappresentano lo strato fondamentale su cui sviluppare ogni API secondo le proprie esigenze. Per rendere tale strato indipendente dall architettura utilizzata, viene fornito il supporto necessario per il controllo dell hardware, attraverso un sottostante layer software (Hardware Abstraction Layer) a cui si accede tramite una interfaccia standardizzata. In questo modo, il porting del kernel real-time su un altra architettura, consta solamente dell implementazione di questa interfaccia a basso livello per la piattaforma che si vuole utilizzare. Questo strato software deve fornire le funzionalità di un RTOS ovvero deve: inviare su richiesta gli interrupt esterni all handler specifico;

38 CAPITOLO 2. XENOMAI 32 fornire un modo per nascondere o meno gli interrupt; garantire la possibilità di creare nuovi thread di controllo nella forma più semplice; fornire un supporto per interrupt periodici e aperiodici utilizzati nella gestione dei timer; supportare l allocazione di memoria non pageable. In figura 2.1 risultano evidenti le posizioni dei vari componenti a partire dalla pipeline Adeos, di cui si parlerà dettagliatamente nella sezione seguente, per continuare col livello di astrazione dell hardware e con il kernel real-time fino ad arrivare alle varie interfacce di programmazione. 2.2 Adeos pipeline Xenomai basa il suo funzionamento sul layer di virtualizzazione Adeos, che è disponibile come patch del kernel. Adeos abilita entità multiple, chiamate anche dominii, che permettono di poter avere sullo stesso hardware un ambiente GNU/Linux e un RTOS perfettamente funzionanti. Tutti i dominii esistenti non sono necessariamente consapevoli dell esistenza degli altri, ma ognuno di essi può e deve interagire con Adeos. Ogni entità compete con l altra per il processamento di eventi esterni, come gli interrupt, e di eventi interni, come trap ed exception, a seconda della priorità che è stata loro fissata. Oltre alla virtualizzazione, Adeos consente di esportare ai dominii un API generica indipendente dall architettura della CPU. La struttura di Adeos può essere vista come una catena di dominii che hanno il compito di gestire il controllo di eventi. Un dominio è una componente software kernel-based che può chiedere al layer Adeos di essere notificato quando si verificano determinati eventi: l arrivo di un interrupt esterno o di un interrupt virtuale autogenerato; ogni chiamata di sistema richiesta dalle applicazioni Linux; tutte le altre chiamate di sistema generate dal codice del kernel, come per esempio lo switch o l uscita dei task di Linux e la notifica di segnali.

39 CAPITOLO 2. XENOMAI 33 Figura 2.2: Schema dell astrazione introdotta dalla pipeline Adeos Adeos assicura che gli eventi siano inviati in maniera ordinata ai vari dominii secondo il rispettivo ordine di priorità nel sistema, in modo da assicurare consegne tempestive e predicibili di tali eventi. Quanto detto si ottiene, appunto, tramite l assegnazione di una priorità statica a ogni dominio per mezzo della quale viene determinato l ordine di consegna degli eventi a tutti i dominii. I dominii attivi si trovano accodati secondo la loro priorità, realizzando così l astrazione della pipeline utilizzata da Adeos per ottenere un flusso di eventi, ordinato dal dominio a priorità maggiore sino a quello a priorità minore. Tutti gli eventi in arrivo sono inviati all inizio della pipeline, ovvero al dominio a più alta priorità, e inoltrati progressivamente fino all ultimo dominio esistente, quello a priorità più bassa. Nella figura 2.2 viene illustrata una rappresentazione generica di un sistema basato su Adeos, in cui si possono osservare più dominii che condividono trap e interrupt attraverso l astrazione della pipeline. Il kernel Linux può ricoprire qualunque posizione nella pipeline ed è marcato come dominio root, in quanto tutti gli altri dominii hanno bisogno di Linux per poter essere installati, spesso come moduli del kernel dello stesso. Uno stadio della pipeline occupato da un dominio può trovarsi in stallo, il che significa che il successivo interrupt in arrivo non sarà consegnato all handler del dominio e, allo stesso tempo, gli sarà impedito di scorrere verso i dominii di priorità inferiore. Quando uno stadio si trova in stallo, gli interrupt pendenti sono accu-

40 CAPITOLO 2. XENOMAI 34 Figura 2.3: Gestione di Adeos su dominii multipli con n CPU mulati nel log degli interrupt del dominio ed eventualmente elaborati, una volta rimosso lo stato di stallo dall operazione interna di sincronizzazione. I dominii utilizzano questa funzione, per proteggere le proprie sezioni critiche da prelazioni indesiderate da parte dei propri interrupt handler. In ogni caso, grazie alla virtualizzazione del controllo degli interrupt introdotto da Adeos, un dominio di priorità più alta può comunque ricevere interrupt ed eventualmente prelazionare un dominio a priorità più bassa. Questo significa che se si utilizza Adeos, si può avere il kernel Linux che svolge le proprie operazioni critiche e, allo stesso tempo, un sistema real-time in cima alla pipeline, che sarà in grado di ricevere gli interrupt ogni volta senza alcun ritardo. Quando un dominio finisce di processare gli interrupt pendenti che ha ricevuto, richiama un servizio di Adeos che porta la CPU al dominio successivo della pipeline, cosicché quest ultimo possa processare i propri interrupt e così via sino al dominio che si trova nell ultima posizione della pipeline. Nella figura 2.3 viene illustrato il modo in cui diversi dominii, eseguiti su CPU multiple, condividono gli interrupt in arrivo attraverso l astrazione della pipeline introdotta da Adeos. Risulta evidente che si deve mantenere una corretta memorizzazione de-

41 CAPITOLO 2. XENOMAI 35 gli interrupt pendenti quando uno stadio si trova in stallo. Questo viene realizzato tramite un log che tiene conto del dominio i-esimo e della n-esima CPU. Gli interrupt non sono l unico genere di eventi che può fluire attraverso l astrazione della pipeline. Gli eventi interni, innescati dal kernel Linux stesso o dalle sue applicazioni, possono generare quelli che sono chiamati eventi di sistema. Gli eventi di sistema sono notifiche sincrone di trap, exception o di alcune azioni del kernel Linux che sono notificate attraverso la pipeline. Dal momento in cui questi eventi sono sincroni per definizione, non c è alcun modo di ritardare la loro notifica tramite l operazione di stallo, non essendo possibile posticipare la loro gestione. Un codice che fa partire un evento di sistema, potrebbe non essere in grado di continuare senza l intervento immediato dell handler corrispondente. Per chiarire meglio quanto detto, consideriamo un errore di paginazione: l handler relativo deve attivarsi immediatamente al momento dell exception relativa all indirizzamento di memoria. L operazione di stallo su un dato dominio ha significato solo per quanto riguarda gli interrupt reali o virtuali Adeos e Xenomai Tutte le caratteristiche di Adeos elencate sino a ora permettono l implementazione di Xenomai accanto al kernel Linux. Come sistema in tempo reale, è facile intuire che l esigenza di Xenomai è quella di riuscire a gestire tutti gli interrupt in arrivo, prima che il kernel Linux sia in grado di notarli. Inoltre, Xenomai deve assicurarsi di poterli elaborare immediatamente anche in presenza dei tentativi di blocco del kernel Linux. Xenomai deve assicurarsi di rafforzare la priorità di gestione dei propri thread, anche quando questi si trovano in esecuzione in altri dominii. Mettendo a disposizione queste caratteristiche, Adeos consente a Xenomai di avere latenze di interrupt predicibili nell ordine dei micro-secondi, con qualunque attività di Linux contemporaneamente in esecuzione. Tutto ciò, abbinato alla tecnica di co-scheduling dei task di Linux, fornisce latenze di scheduling dei thread real-time deterministiche. In figura 2.1 si può notare la posizione di Adeos che risulta direttamente a contatto con l Hardware Abstraction Layer (HAL), posto al di sotto del

42 CAPITOLO 2. XENOMAI 36 nucleo di Xenomai. Molte delle richieste per i servizi Adeos sono diramate proprio da quest ultimo I dominii di Xenomai Xenomai permette l esecuzione di thread real-time sia in kernel-space, sia entro lo spazio di indirizzi di un processo Linux. Di seguito ci si riferirà a quest ultimi come thread di Xenomai che non devono essere confusi con i regolari task di Linux. Tutti i thread gestiti da Xenomai sono conosciuti dal suo nucleo. Xenomai introduce quindi un vero supporto user-space per il real-time, che determina la vera novità rispetto ai tradizionali sistemi a doppio kernel, in cui le applicazioni RT potevano essere eseguite solo se incorpate in moduli del kernel. L approccio di Xenomai nei confronti di Linux, a differenza di quello realizzato dal sistema RTAI/LXRT, si può definire simbiotico. Infatti, i thread di Xenomai possono andare in esecuzione non solo nel dominio a maggior priorità della pipeline (dominio primario), ma anche nel dominio di Linux (dominio secondario) che viene considerato ancora real-time anche se soggetto a latenze di scheduling più elevate. Affinché sia garantito un pieno supporto real-time ai thread che si trovano in esecuzione nel dominio secondario, è necessario che siano rispettati i seguenti punti: schema di priorità comune: si deve fare in modo che il kernel real-time e il kernel Linux condividano lo stesso schema di priorità. In altre parole, un thread di Xenomai dovrebbe veder rispettata la sua priorità qualunque sia il dominio di esecuzione. Il kernel Linux eredita automaticamente la priorità del thread di Xenomai che è passato in modalità secondaria: ciò significa che i thread di Xenomai, in esecuzione in modalità primaria, non prelazioneranno necessariamente quelli che si trovano in modalità secondaria, a meno che la loro effettiva priorità sia più alta.

43 CAPITOLO 2. XENOMAI 37 Figura 2.4: Migrazione tra dominii Quanto descritto è esattamente l opposto di quello che accade su RTAI, dove i thread che migrano nel kernel Linux perdono allo stesso tempo la loro priorità real-time. I task di Linux saranno sempre prelazionati dai thread di Xenomai, in esecuzione in modalità primaria, mentre i thread di Xenomai, passati in modalità secondaria, continueranno a competere con questi ultimi tramite il sistema di priorità; predicibilità dei tempi di esecuzione del programma: i tempi di esecuzione di un thread di Xenomai, in modalità secondaria, non dovrebbero essere condizionati dalle attività di gestione degli interrupt di Linux o, in termini più generici, da qualunque attività asincrona che si verifica a livello del kernel. Il modo più semplice per evitare che questo accada, è mandare il kernel Linux in starvation quando un thread di Xenomai è in esecuzione nel dominio di Linux, cosicché non vengano introdotti ritardi dovuti agli interrupt handler. Per mandare in starvation il kernel Linux, si introduce un dominio intermedio di Adeos in cui bloccare gli interrupt quando necessario. Tale dominio è chiamato interrupt shield e va a occupare nella pipeline la posizione tra il kernel real-time e il kernel Linux (Figura 2.5). L interrupt shield viene attivato ogni volta che un thread di Xenomai viene schedulato dal kernel Linux e disattivato in tutti gli altri casi. L abilitazione di tale schermo può essere effettuata per una determinata applicazione o in fase di compilazione di Xenomai marcando l opportuna flag di configurazione;

44 CAPITOLO 2. XENOMAI 38 Figura 2.5: Interrupt shield granularità del kernel Linux: per ottenere delle buone prestazioni in modalità secondaria, è necessario che il kernel Linux esponga la sua sezione non prelazionabile per il più breve tempo possibile, cosicché si possa schedulare in tempi rapidi un thread di Xenomai che ha effettuato lo switch di modalità. Inoltre, questo assicura che i thread di Xenomai possono realizzare la migrazione dal dominio primario al secondario entro un ridotto periodo di tempo, poichè questa operazione deve attendere un punto di rescheduling. Xenomai beneficia dei continui miglioramenti riguardo alla prelazione del kernel, come per esempio l estensione PREEMPT_RT di Ingo Molnar [Rif]. Ovviamente i thread di Xenomai che vanno in esecuzione in modalità primaria non sono affetti dal livello di granularità del kernel e beneficiano sempre delle basse latenze garantite dal nano-kernel real-time, poichè non devono sincronizzarsi in alcun modo con le operazioni di Linux, le quali vengono prelazionate incondizionatamente; gestione dell inversione di priorità: sia il kernel real-time, sia il kernel Linux devono gestire il caso in cui l esecuzione di un thread ad alta priorità viene impedita da un thread a priorità inferiore, che tiene occupata una risorsa condivisa per un certo tempo. Xenomai fornisce questo supporto, mentre il kernel Linux vi riesce solo nella sua variante PREEMPT_RT. Per questa ragione lo sviluppo di Xenomai segue con attenzione lo sviluppo della patch PREEMPT_RT, nonostante la release principale del kernel rimanga il sistema di riferimento. In conclusione, quando il kernel di Xenomai viene caricato, la pipeline Adeos contiene tre stadi attraverso i quali fluiscono tutti gli interrupt secondo l ordine di priorità: il dominio primario di Xenomai, il dominio dell interrupt shield e il dominio di Linux Intercettare le chiamate di sistema Dal momento in cui le skin, le quali sono allocate nello stack del nano-kernel real-time, possono esportare i propri set di servizi ai thread user-space di

45 CAPITOLO 2. XENOMAI 39 Xenomai, si deve gestire un modo in cui le corrispondenti chiamate di sistema e le chiamate regolari del kernel Linux vengono spedite ai rispettivi handler. Xenomai intercetta ogni chiamata di sistema relativa a exception o trap inviata a tutti i dominii da parte dei thread real-time tramite il servizio di Adeos adeos_catch_event(). In questo modo Xenomai riesce a: inviare le richieste per i servizi real-time dalle applicazioni ai rispettivi handler, i quali sono implementati dalle varie interfacce di programmazione che sono in esecuzione sul kernel real-time; assicurarsi che ogni chiamata di sistema sia effettuata sotto il controllo del dominio appropriato, effettuando se necessario una migrazione del chiamante al dominio richiesto senza nessuna interruzione. Per esempio una chiamata di sistema avanzata da un thread di Xenomai, che si trova in esecuzione nel dominio real-time, provocherà una migrazione automatica nel dominio di Linux prima che la richiesta venga trasmessa all handler. Al contrario, supponendo di avere un thread di Xenomai che invoca una chiamata di sistema per Xenomai potenzialmente bloccante, questo viene spostato nel dominio real-time, prima che il servizio sia assolto, cosicché il thread possa andare in sleep sotto il controllo del kernel real-time. In questo modo si riesce a ottenere una ottima integrazione dei thread Xenomai in Linux Propagazione degli interrupt Data la sua posizione in cima alla pipeline, il kernel real-time di Xenomai è il primo a essere avvisato di un interrupt in arrivo, lo processa e lo segnala in modo che possa essere inoltrato agli altri dominii della pipeline. Ricevuta la notifica dell arrivo di un interrupt, il kernel real-time effettua un rescheduling e fa partire il thread a più alta priorità che lo gestisce. Adeos ha due modalità di propagazione per gli interrupt attraverso la pipeline: modalità implicita: ogni interrupt in arrivo è marcato automaticamente come pendente in ogni log di dominio che accetta tale interrupt; modalità esplicita: un interrupt, se necessario, viene propagato manualmente al dominio confinante nella pipeline.

46 CAPITOLO 2. XENOMAI 40 La scelta della modalità di propagazione è settata all interno di ciascun dominio. Per quel che riguarda Xenomai, viene sempre utilizzata la modalità esplicita per tutti gli interrupt che vengono intercettati. Ogni handler deve richiamare il servizio di propagazione esplicito per inoltrare un interrupt in arrivo lungo la pipeline. Nel caso in cui non sia definito l handler per un dato interrupt, questo viene propagato incondizionatamente al kernel Linux mantenendo quindi il sistema funzionante. 2.3 Installazione di Xenomai su x86 Il primo passo da intraprendere per l installazione di Xenomai sul kernel vanilla è il recupero dei sorgenti dal sito ufficiale del progetto. Una volta recuperata l ultima release stabile, disponibile al momento, si è passati all estrazione dell archivio nella cartella /usr/src tramite il comando tar: tar -xjvf xenomai-2.5.x.tar.bz2 La versione utilizzata in questa tesi è la Terminata l estrazione dell archivio, il passo successivo è controllare le versioni del kernel Linux, supportate dalla patch Adeos, disponibili nella sottocartella ksrc/arch/x86/patches e scaricare il relativo kernel vanilla [10]. Per l installazione su x86 è stato utilizzato il kernel Sempre con il comando tar si effettua l estrazione dei sorgenti del kernel nella directory /usr/src. A quel punto resta solo da avviare lo script opportuno dell archivio di Xenomai per applicare le patch e compilare quindi il sottosistema real-time integrato nel kernel Linux. Preparazione del kernel Nella cartella scripts è presente lo script prepare-kernel.sh, che va utilizzato con la seguente sintassi: prepare-kernel.sh --linux=<linux-srctree> [--adeos=<adeos-patch>] [--arch=<target-arch>] linux specifica il percorso della cartella dove sono stati estratti i sorgenti del kernel vanilla, nel nostro caso la cartella /usr/src/linux

47 CAPITOLO 2. XENOMAI 41 adeos indica il percorso in cui si trova la patch Adeos da applicare sulla cartella del kernel. arch specifica l architettura del target. Configurazione e preparazione del kernel Terminata la fase di preparazione dei sorgenti del kernel, è necessario creare il file di configurazione. Questo può essere realizzato attraverso una configurazione grafica tramite il comando make menuconfig o in alternativa make xconfig/gconfig. Utilizzando il primo dei comandi appena elencati, ci si trova di fronte alla seguente schermata: Figura 2.6: Menu di configurazione del kernel Per chi abbia già compilato un kernel Linux, è facile notare immediatamente una nuova voce nel menu di configurazione ovvero la sezione Real-time sub-system, che comprende tutte le funzionalità relative al nano-kernel di Xenomai. Esplorando il contenuto del sottomenu, si trovano varie opzioni di configurazione come l inclusione delle nuove classi di scheduling (es. Sporadic Ser-

48 CAPITOLO 2. XENOMAI 42 ver), supporto per il debug, abilitazione delle varie interfacce di programmazione (POSIX, VxWorks, psos), settaggio dei watchdog e altre impostazioni da valutare secondo le proprie necessità. Da questa schermata di configurazione, si possono disattivare le parti relative all hardware che non verranno utilizzate, come per esempio i moduli realtivi a Joystick, Touchscreen, etc. Inoltre, è necessario controllare che determinate voci siano attive, mentre altre funzionalità devono essere disabilitate poiché possono compromettere le prestazioni, in termini di latenza, del kernel real-time. Esaminando nel dettaglio, si deve fare attenzione alle seguenti voci del menu di configurazione: in Processor type and features: Controllare che la voce relativa alla Interrupt pipeline sia abilitata. Questo garantisce che l implementazione della I-pipe aggiunta con la patch Adeos sia attiva; Verificare che le voci Local APIC support on uniprocessors e IO- APIC support on uniprocessors siano abilitate. in Power management and ACPI options: Disabilitare tutto il sotto menu ACPI ; Disattivare il controllo di potenza avanzato APM ; Nella menu CPU frequency scaling disabilitare la voce riferita alla CPU. Oltre alle opzioni appena elencate, si è disattivata la voce SMP perchè si è compilato il kernel con il supporto per un solo processore. Terminata la fase di configurazione si deve uscire dall interfaccia grafica e salvare le modifiche. A questo punto nella source tree del kernel sarà disponibile il file.config, con tutte le informazioni relative alla configurazione appena effettuata. Il passo successivo è la compilazione del kernel. Compilazione e avvio del nuovo kernel Tramite il comando make si può procedere alla compilazione del kernel. Tuttavia si è scelto di adottare un accorgimento molto pratico, cioè quello di

49 CAPITOLO 2. XENOMAI 43 creare dei pacchetti.deb, così da avere disponibile l installazione del kernel patchato per qualunque altra macchina con architettura x86. Per lanciare la compilazione e creare i pacchetti.deb, i repository di Debian mettono a disposizione il pacchetto kernel-package che contiene lo script per la compilazione e fornisce il modo di creare un immagine del kernel Linux. Il comando per eseguire quanto detto è il seguente: make-kpkg --initrd --append-to-version -xenomai --revision 1.0 kernel_image kernel_headers Le opzioni append-to-version e revision sono facoltative, ma utili per distinguere diverse versioni di kernel customizzati. La fase di compilazione è piuttosto lunga in quanto i sorgenti da compilare sono molto corposi e numerosi. In un sistema multi-core si può velocizzare questa operazione utilizzando l opzione CONCURRENCY_LEVEL=p, dove p indica il numero di processori che si vogliono dedicare alla compilazione del kernel. Terminata la compilazione, si ha a disposizione il file relativo all immagine della source tree del kernel e il file contenente i vari header. Nel nostro caso particolare avremo a che fare con i seguenti file: linux-image xenomai.deb; linux-headers xenomai.deb. Per installare i pacchetti, si utilizza il comando dpkg specificando l opzione -i. Attraverso questa procedura l immagine del kernel con i relativi headers viene installata, inoltre viene anche aggiornato il bootloader (nel nostro caso il grub). Riavviando il sistema, troveremo visualizzata anche la voce del kernel xenomai. Selezionandola si potrà avviare il kernel modificato con l inclusione del dominio real-time.

50 CAPITOLO 2. XENOMAI 44 Figura 2.7: Xenomai Controllo sul buffer del kernel della corretta attivazione di Per controllare che l installazione sia andata a buon fine, si può filtrare la voce Xenomai dal contenuto dei messaggi del buffer del kernel: dmesg grep -i xenomai Il risultato prodotto in output sulla shell è visualizzato in figura 2.7 Dalla prima riga è possibile vedere che Adeos è stata attivata e si trova regolarmente in esecuzione e che il dominio relativo al kernel real-time di Xenomai è stato attivato. Di seguito vengono elencati tutti i servizi di Xenomai attivati in fase di configurazione. L ultimo step da eseguire è l installazione del supporto user-space di Xenomai. Questo si realizza tramite l esecuzione dello script configure presente nella cartella /usr/src/xenomai. Una verifica veloce della buona riuscita dell installazione, si può riscontrare mandando in esecuzione alcuni programmi forniti con Xenomai. Infatti, nella cartella /usr/xenomai/bin si possono trovare una serie di binari da avviare che realizzano una serie di test sul sistema appena installato.

51 CAPITOLO 2. XENOMAI Testing della skin nativa L interfaccia di programmazione nativa segue determinate linee guida. In primo luogo si tratta di un API compatta, che fornisce un numero contenuto di servizi, senza rinunciare ad avere un sistema stabile e di facile programmazione nell ambiente GNU/Linux. Tali servizi vengono resi disponibili in maniera non ambigua, in modo da non poter essere semanticamente confusi e lasciare allo sviluppatore il compito di combinarli tra loro per ottenere il risultato desiderato. Sebbene sia preferibile eseguire le applicazioni di Xenomai in user-space, possono presentarsi dei casi in cui bisogna eseguire del codice in moduli del kernel come per esempio nel caso di hardware poco performanti. Per questo motivo la skin nativa fornisce lo stesso set di servizi real-time alle applicazioni indipendentemente dal loro spazio di esecuzione. Inoltre, è possibile che attività real-time che si trovano in spazi di esecuzione differenti, debbano cooperare e questo è possibile tramite la condivisione degli stessi oggetti messi a disposizione dalla skin. Utilizzando la skin nativa si può inoltrare la stessa chiamata di sistema per eseguire un azione senza preoccuparsi dello spazio di esecuzione. Ciò significa che un task sarà sempre rappresentato da un descrittore RT_TASK, una coda da un RT_QUEUE e un semaforo da un RT_SEM qualunque sia lo spazio in cui vengono utilizzati. Tali descrittori possono essere condivisi tra gli spazi di esecuzione cosicché un servizio invochi un oggetto che è stato creato nello spazio opposto. Per creare una facile corrispondenza per la ricerca di questi descrittori sul sistema Xenomai, esiste un registro unificato: esso permette a tutte le categorie di servizi real-time di indicizzare ogni oggetto che creano in una unica chiave simbolica definita dall applicazione. Come tutte le altre, la skin nativa è una parte opzionale del sistema Xenomai ed è basata sullo stesso kernel real-time che fornisce una serie di servizi. I servizi dell API nativa sono implementati dal modulo del kernel chiamato xeno_native e, come già detto, possono essere invocati sia in kernelspace, utilizzando le funzioni di chiamata inter-moduli, sia dal contesto userspace attraverso la libreria libnative.so invocando le opportune chiamate di sistema.

52 CAPITOLO 2. XENOMAI 46 La skin nativa fornisce sei categorie di servizio e ognuna di esse definisce un set di chiamate di sistema disponibili per entrambi gli space. Tali categorie sono: gestione dei task: definisce il set di servizi relativi allo scheduling e al controllo in senso lato dei task. Un applicazione necessita di questa chiamate di sistema per creare task e controllarne il comportamento. Tutti questi servizi sono inclusi di base nel modulo dell API nativa indipendentemente dalle opzioni di configurazione adottate. Essa utilizza una scala di priorità per i task, compatibile con la scala POSIX per la classe di schedulazione SCHED_FIFO, supportata da Linux (dove 99 rappresenta il livello di priorità più alto); servizi di timing: raggruppa tutte le chiamate di sistema relative alle interrogazioni e alla gestione del timer di sistema. Questa categoria comprende anche la creazione di timer chiamati Alarms; supporto di sincronizzazione: fornisce supporto ai task che necessitano di sincronizzare le proprie operazioni. Gli oggetti di sincronizzazione utilizzabili per questo scopo sono semafori, mutex, variabili condizionali e event flag; messaggi e comunicazione: questa categoria implementa diversi modi per lo scambio di dati tra i task real-time o tra attività real-time in kernel-space e processi di Linux in user-space; gestione di dispositivi i/o: la skin nativa fornisce un supporto per l interazione con interrupt e per accedere alla memoria di dispositivi di input/output dal contesto user-space. Per quel che riguarda la completa creazione di driver per dispositivi è disponibile l interfaccia RTDM; supporto di registri: consente l accesso alle chiamate di sistema da contesti di esecuzione differenti. 2.5 Sviluppo di script per il testing Una volta installato il sistema Xenomai, si è scelto di sviluppare alcuni semplici, ma pragmatici script sulla skin nativa, per verificare il funzionamento dello scheduler RT. Uno script interessante prevede la creazione di due task real-time aventi lo stesso periodo ognuno dei quali va a occupare la CPU rispettivamente per

53 CAPITOLO 2. XENOMAI e per 2 3 del periodo, in modo da avere in totale una occupazione della CPU pari al 100%. Una possibile implementazione di questo test consiste nel seguente set di istruzioni: #i n c l u d e <s t d i o. h> #i n c l u d e <s i g n a l. h> #i n c l u d e <unistd. h> #i n c l u d e <sys /mman. h> #i n c l u d e <time. h> #i n c l u d e <n a t i v e / task. h> #i n c l u d e <n a t i v e / timer. h> // uso d e l l a r t _ p r i n t f ( ) #i n c l u d e <rtdk. h> RT_TASK task_desc_1 ; RT_TASK task_desc_2 ; void task_body_1 ( void arg ) { // task1 p e r i o d i c o, con periodo t1=3s rt_task_set_periodic (NULL, TM_NOW, ); i n t i ; f o r ( i =0; i <10; i++) { // c1=1s r t _ p r i n t f (" Busy wait 1 s... \ n " ) ; rt_timer_spin ( ); rt_task_wait_period (NULL) ; } } void task_body_2 ( void arg ) { // task2 p e r i o d i c o, con periodo t2=3s rt_task_set_periodic (NULL, TM_NOW, );

54 CAPITOLO 2. XENOMAI 48 i n t i ; f o r ( i =0; i <10; i++) { // c2=2s r t _ p r i n t f (" Busy wait 2 s... \ n " ) ; rt_timer_spin ( ); } } rt_task_wait_period (NULL) ; i n t main ( i n t argc, char argv [ ] ) { s i g n a l (SIGTERM, catch_signal ) ; s i g n a l (SIGINT, catch_signal ) ; / Avoids memory swapping f o r t h i s program / m l o c k a l l (MCL_CURRENT MCL_FUTURE) ; / Perform auto i n i t o f rt_print b u f f e r s / / i f the task doesn t do so / rt_print_auto_init ( 1 ) ; / c r e a z i o n e task RT / r t _ p r i n t f (" c r e a z i o n e task1 c1 / t1 =1/3\n " ) ; rt_task_create(&task_desc_1, "Task1 ", 0, 99, 0 ) ; r t _ p r i n t f (" c r e a z i o n e task2 c2 / t2 =2/3\n " ) ; rt_task_create(&task_desc_2, "Task2 ", 0, 99, 0 ) ; / avvio task RT / r t _ p r i n t f (" task1 pronto \n " ) ; rt_task_start (&task_desc_1, &task_body_1, NULL) ; r t _ p r i n t f (" task2 pronto \n " ) ; rt_task_start (&task_desc_2, &task_body_2, NULL) ; pause ( ) ; r t _ p r i n t f (" c a n c e l l a z i o n e task \n " ) ; rt_task_delete(&task_desc_1 ) ;

55 CAPITOLO 2. XENOMAI 49 } rt_task_delete(&task_desc_2 ) ; Come prima cosa si creano i due task RT con la funzione: int rt_task_create (RT_TASK * task, const char * name, int stksize, int prio, int mode) dove: task è l indirizzo del descrittore di task Xenomai usato per memorizzare i dati del rispettivo task; name è una stringa ASCII e rappresenta il nome simbolico del task; stksize rappresenta la dimensione (in byte) dello stack del nuovo task, passandogli zero come valore verrà utilizzata una dimensione predefinita; prio è un intero che va da 0 a 99 e costituisce la priorità che si vuole assegnare al task (0 indica la priorità minima, 99 la priorità massima); mode indica la modalità di creazione del task. Nel caso in cui la creazione del task vada a buon fine, la routine restituirà il valore intero zero. E importante sottolineare che la funzione esplicitata può essere chiamata sia in un contesto user-space, per esempio all interno della funzione principale di uno script, sia in un contesto kernel-space, per esempio all interno della funzione di inizializzazione del modulo (init_module). Un altra osservazione da tener presente è che dopo aver chiamato questa procedura, è possibile il rescheduling dei task da parte del sistema Xenomai. Inoltre, creato un processo, questo rimane inattivo fin tanto che non si chiama la funzione: int rt_task_start (RT_TASK * task, void(*)(void *cookie) entry, void * cookie) dove: task, come già detto, è l indirizzo del descrittore del task Xenomai e entry è l indirizzo del corpo della routine del task contenente le istruzione. Anche in questo caso, se la routine ha avuto successo viene restituito il valore intero zero. Dopo aver chiamato la procedura in questione, il task può essere schedulato per la prima volta.

56 CAPITOLO 2. XENOMAI 50 Essendo queste due funzioni strettamente correlate è possibile ottenere lo stesso risultato in un solo step, utilizzando la funzione rt_task_spawn() la quale richiede, ovviamente, un numero maggiore di parametri. Come accennato le procedure rt_task_start() e rt_task_spawn() vogliono come parametro anche l indirizzo della routine contenente le istruzioni che il processo deve svolgere. Quindi, in base alle ipotesi fatte per il nostro test, dovremo far sì che i due task creati abbiano lo stesso periodo e, inoltre, che un task occupi la CPU per il 33, 3% e l altro per il 66, 6%. E possibile rendere periodico un task richiamando la funzione: int rt_task_set_periodic (RT_TASK * task, RTIME idate, RTIME period) dove: task è l indirizzo del descrittore del task di cui si vuole settare il periodo; idate è la data (assoluta) di esecuzione della prima istruzione, in altre parole costrituisce il ritardo affinchè la prima istruzione del processo venga eseguita. Nel nostro caso abbiamo impostato tale valore a TM_NOW in modo da non avere alcun ritardo iniziale; period rappresenta il periodo del task, espressa in nanosecondi o in clock ticks. E possibile eseguire le azioni in più periodi utilizzando, per esempio, il ciclo iterativo for(;;), all interno del quale deve essere richiamata, come ultima istruzione la funzione: int rt_task_wait_period(null) la quale mette il task nello stato di attesa del prossimo periodo, a discrezione dello scheduler di Xenomai. All interno del ciclo iterativo for(;;), per simulare l uso della CPU da parte del task, abbiamo utilizzato la semplice funzione: void rt_timer_spin (RTIME ns) che tiene occupata la CPU per un certo numero di cicli non compiendo alcuna azione, ossia «brucia» cicli di CPU. Infatti, l unico parametro richiesto dalla routine è proprio il tempo di impiego della CPU espresso in nanosecondi o in numero di cicli della cpu (clock ticks).

57 CAPITOLO 2. XENOMAI 51 E possibile cancellare un task, in modo tale che tutte le risorse del kernel assegnategli al momento della creazione vengano rilasciate chiamando la funzione: int rt_task_delete (RT_TASK * task) E importante sottolineare l uso della funzione rt_printf() al posto della printf() [16], Infatti, tutti i thread Xenomai vengono avviati in modalità primaria (nucleo RT) ma, invocando una primitiva non RT, in questo caso la printf(), il thread viene spostato nella coda dei processi di Linux, mantenendo la stessa priorità, cioè si ha un passaggio in modalità secondaria. Così facendo però, il thread entra in competizione con i task di Linux, di conseguenza l ordine di esecuzione dei processi potrebbe essere diverso da quello che ci aspettiamo. Come test successivo abbiamo pensato di rendere meno uniforme e più dinamica la creazione dei vari task, generando casualmente il numero di processi creati (al massimo 10), il tempo computazionale (c i ) e il periodo (t i ) di ogni task. Per far questo abbiamo utilizzato la coppia di funzioni note srand() e rand(). Lo sviluppo di questi test è stato fatto sia in user-space sia in kernel-space, evidenziando le seguenti differenze: nel contesto di esecuzione user-space non è possibile settare una C/T globale pari a 1, poiché bisogna considerare delle latenze dovute al cambio di contesto dei due task. L occupazione massima della CPU che si è raggiunta empiricamente è del 95%; in kernel-space ci si può spingere a un limite del 99%, oltre il quale si provoca un crash del nano-kernel di Xenomai. Risulta interessante notare che utilizzando lo script in user-space, l utente resta in grado di controllare i dispositivi di input come touchpad e tastiera, sebbene con notevoli rallentamenti. Nel caso del modulo kernel-space, questo è impossibile poichè, come già visto, ci si può spingere verso limiti di computazione più elevati, eliminando la possibilità di entrare in esecuzione alle routine di controllo di tali dispositivi.

58 Capitolo 3 Cris AXIS ETRAX 100LX 3.1 La FOX Board Panoramica La FOX Board [12] utilizzata per il porting del sistema RT Xenomai, (Fig. 3.1) è una scheda madre prodotta dalla Acme Systems di ridotte dimensioni e bassi consumi con un microprocessore ETRAX 100LX, a 100MIPS RISC CPU progettato dalla Axis Communications. La scheda possiede le seguenti caratteristiche tecniche: Caratteristiche Hardware 1 microprocessore RISC con architettura Axis ETRAX 100LX MCM 4+16 (32 bit, 100 MHz di frequenza di clock) prodotto da Axis Communications; 4 MB di memoria flash e 16 MB di memoria RAM (per questo è anche denominata "LX416"); 1 porta Ethernet a 10/100 Mb/s; 2 porte USB 1.1; 1 porta seriale TTL a 3,3 Volt per consolle; 2 connettori di espansione con segnali per interfacce IDE, SCSI, porte seriali, linee di I/O e bus I2C; alimentazione singola a 5 Volt, 280 ma (equivalente a circa 1 W di potenza); 52

59 CAPITOLO 3. CRIS AXIS ETRAX 100LX 53 Figura 3.1: FOX Board dimensioni: 66x72x19 mm; peso: 37g; range temperature: 0 70 C. Caratteristiche Software Linux kernel 2.4 (upgrade al 2.6 disponibile); WEB server, FTP server, SSH, TELNET e PPP preinstallati; supporto ai convertitori usb/seriali basati su chip FTDI; supporto alle chiavi di memoria USB; ambiente di sviluppo (SDK) Open Source per sistemi Linux; compilatore GNU C 1 con interfaccia web disponibile gratuitamente su Internet per la compilazione di piccole applicazioni senza dover installare l SDK. 1 il gcc (GNU Compiler Collection, in origine GNU C Compiler) è un compilatore multitarget creato inizialmente dal fondatore della Free Software Foundation, Richard Matthew Stallman, come parte del Progetto GNU. Le versioni recenti sono incluse nelle principali distribuzioni del sistema operativo GNU/Linux, e di molti altri sistemi.

60 CAPITOLO 3. CRIS AXIS ETRAX 100LX 54 Questa scheda è adattabile a moltissimi utilizzi, che spaziano dal semplice lettore MP3 a veri e propri web server, ed è espandibile grazie ai componenti hardware aggiuntivi (quali per esempio display, espansioni di memoria, antenne GSM/GPRS) messi in commercio da Acme Systems e da altre ditte. La scheda è progettata espressamente per ospitare un sistema operativo Linux. Infatti, viene fornita con una immagine del kernel Linux pronta per essere eseguita. Come è noto, il kernel di questo sistema operativo offre un elevato grado di adattabilità Accensione Per funzionare la scheda necessita di una tensione continua pari a 5 Volt, che gli può essere fornita collegando un alimentatore commerciale di tipo PS5V1A al connettore J14 o collegando un alimentatore tipo quello dei floppy disk al connettore J2 (Fig. 3.2). Figura 3.2: Alimentazione attraverso il connettore J14 o J2 Una volta alimentata, i tre led presenti, DL1, DL2 e DL3 si illuminano per un breve periodo di tempo, dopo di che rimane acceso solo il led verde. Il significato dei tre led è il seguente: Led rosso DL1, può essere usato dall utente per controllare le applicazioni software. Normalmente è spento. All avvio viene utilizzato dal kernel per indicare un errore sulla board. Tipicamente lampeggia quando l indirizzo MAC della scheda Ethernet non è configurato (que-

61 CAPITOLO 3. CRIS AXIS ETRAX 100LX 55 sta condizione si verifica solo dopo la riprogrammazione della memoria flash con il comando boot_linux -F, cioè quando il kernel è stato riprogrammato cancellando tutte le informazioni del «boot block»); Led giallo DL2, mostra il traffico LAN sul connettore ethernet; Led verde DL3, è collegato direttamente alla rete di alimentazione e di conseguenza mostra lo stato acceso/spento della board Modalità di accesso alla FOX Board La FOX Board ha un connettore femmina LAN RJ45 per la connessione alla rete Ethernet 10/100 Mbit (J11). E possibile collegare direttamente un PC attraverso un cavo Ethernet incrociato. La configurazione di default della rete sulla FOX Board è: indirizzo IP: netmask: default gateway: Quindi per vedere la scheda tramite TCP/IP dal nostro PC, bisogna che questo sia configurato sullo stesso pool di indirizzi LAN, cioè l indirizzo IP del PC deve appartenere o al range da a o al range da a Vi sono principalmente tre modalità per utilizzare il sistema Linux presente sul sistema embedded Web access La FOX Board ha preinstallato di default il web server BOA 2. Se il PC si trova sulla stessa LAN della piattaforma embedded, come descritto sopra, digitando il seguente URL: all interno di un browser, comparirà la schermata in figura (Fig. 3.3). La home page predefinita si trova su /usr/html/index.html. Questo file viene salvato in una cartella di sola lettura, quindi non è possibile modificarne il contenuto. Per cambiare la home page predefinita o per aggiungerne altre, è necessario utilizzare la cartella di lettura/scrittura /usr/html/local. 2 è un webserv http elementare ma efficace, in grado di offrire le funzionalità tipiche di questo servizio. Si compone fondamentalmente di un demone, boa, e di un file di configurazione, /etc/boa/boa.config.

62 CAPITOLO 3. CRIS AXIS ETRAX 100LX 56 Figura 3.3: Home page FOX Board FTP access Il sistema embedded ha un server FTP sempre attivo che opera sulla porta 21. Se la board è correttamente visibile sulla LAN, digitando il seguente comando all interno della shell: ftp verrà chiesto di inserire l username e la password, che sono rispettivamente root e pass (vedi Fig. 3.4). Figura 3.4: ftp access Una volta effettuato il login è possibile per esempio navigare all interno

63 CAPITOLO 3. CRIS AXIS ETRAX 100LX 57 del file system della board o impostare la modalità binaria per il traferimento dei file TELNET access La FOX board ha un server Telnet sempre attivo e in ascolto sulla porta 23, che consente l accesso remoto da PC. Per l accesso Telnet è possibile utilizzare il software gratuito PuTTY, il quale supporta anche sessioni SSH, che a differenza del Telnet sono protette. Al fine di utilizzare Putty è necessario deselezionare l opzione «Return key sends Telnet New Line instead of M» nel pannello di configurazione di PuTTY, come mostrato in Fig Figura 3.5: Pannello di configurazione Telnet di PuTTY 3.2 Cris ETRAX Il cuore della FOX Board è una CPU Axis ETRAX 100LX. Questo chip è stato progettato e realizzato dalla Axis Communications per l impiego in sistemi embedded del sistema operativo Linux (LX sta per Linux).

64 CAPITOLO 3. CRIS AXIS ETRAX 100LX 58 La sua architettura è nota negli ambienti Linux come un architettura CRIS che è l acronimo di Code Reduced Instruction Set. Mentre ETRAX è un acronimo delle caratteristiche del chip: Ethernet, Token Ring, AXis. Le informazioni seguenti (sottosezione 3.2.1) rappresentano una piccolissima parte del manuale «AXIS ETRAX 100LX Designer s Reference», per maggiori dettagli e chiarimenti si consiglia di consultare direttamente il documento [14] CPU RISC La CPU della ETRAX 100LX è una CPU RISC a 32-bit con istruzioni a 16-bit, compatibile con l architettura CRIS. Funziona con una frequenza di clock di 100 MHz e può raggiungere una velocità di picco pari a 100 MIPS Registri Il processore contiene 14 General Registers a 32-bit (R0-R13), uno Stack Pointer a 32-bit (R14 o SP) e un Program Counter a 32-bit (R15 o PC) (Fig. 3.6). L architettura del processore comprende anche 16 Special Registers (P0- P15), 10 dei quali sono definiti (Fig. 3.7). Figura 3.6: General Registers

65 CAPITOLO 3. CRIS AXIS ETRAX 100LX 59 Figura 3.7: Special Registers Flag e Condition Code Il Condition Code Register (CCR) e la sua estensione a 32 bit, il Dword Condition Code Register (DCCR), contengono 11 diversi flag, mentre i bit rimanenti sono sempre a zero (vedi Fig. 3.8) Organizzazione dei dati in memoria I tipi di dati supportati dalla CRIS sono: byte, intero 8 bit; word, intero 16 bit; dword, intero o indirizzo 32 bit. Ogni locazione indirizzabile contiene dati di un byte. Questi sono archiviati in memoria con il byte meno significativo all indirizzo più basso (little indian). La CPU CRIS nella ETRAX 100LX ha una bus dati a 32-bit. La conversione da 32 bit a 16 bit, se necessaria, viene eseguita mediante l interfaccia del bus. Se i dati superano i 32-bit, la CPU dividerà l accesso ai dati in due accessi separati. Perciò, l uso di parole non allineate e dword possono degradare le prestazioni.

66 CAPITOLO 3. CRIS AXIS ETRAX 100LX 60 Figura 3.8: CCR e DCCR Le figure seguenti mostrano un esempio di organizzazione dei dati con un bus a 16 bit Fig. 3.9 e con un bus a 32 bit Fig Figura 3.9: Esempio di organizzazione dei dai con un bus a 16 bit Formato delle istruzioni L istruzione base ha la lunghezza di una dato word, cioè 16-bit. Le istruzioni devono essere 16 bit allineati. Quando la CPU recupera 32 bit, contenenti due istruzioni allineate a 16 bit, salva i due byte superiori in un registro interno di prefetch. Dopodiché, la

67 CAPITOLO 3. CRIS AXIS ETRAX 100LX 61 Figura 3.10: Esempio di organizzazione dei dati con un bus a 32 bit CPU effettuerà una lettura per ogni seconda istruzione durante l esecuzione del codice consecutivo. La maggior parte delle istruzioni hanno la fisionomia generale in Figura Figura 3.11: Fisionomia generale di un istruzione Gestione degli interrupt su Linux/CRIS E molto importante ai fini del porting della patch Adeos, capire come il kernel Linux sull architettura CRIS gestisca le interruzioni [17]. Si ricordi che la funzione principale del livello di astrazione hardware (HAL) è quella di prendere gli interrupt dall hardware e se necessario inoltrarli a Linux o al gestore real-time Interrupt Paths Nella Fig. 3.12, vengono mostrati i percorsi di gestione dei vari interrupt del kernel Linux su architettura CRIS. Nella maggior parte dei casi un interrupt causa l esecuzione della routine IRQxx_interrupt (queste routine vengono inserite nel vettore degli interrupt ogni volta che un gestore dell interrupt «xx» viene installato, per esempio, da un driver hardware). La prima istruzione della routine consiste nel salvare i registri e disabilitare gli interrupt (poichè non vengono disabilitati automaticamente). Do-

68 CAPITOLO 3. CRIS AXIS ETRAX 100LX 62 Figura 3.12: Interrupt handling paths in the Linux kernel on CRIS

69 CAPITOLO 3. CRIS AXIS ETRAX 100LX 63 podiché l interrupt xx viene mascherato. Se questo non fosse mascherato e il sistema potesse ricevere nuovi interrupt. prima che quello gestito venga riconosciuto, si entrerebbe in un loop infinito. Viene chiamata poi la routine-c, do_irq, passandogli come parametro il numero dell interrupt. Questa funzione esegue il gestore dell interruzione, inoltre dovrebbe anche riconoscere l interrupt. Normalmente le interruzioni vengono disattivate durante l esecuzione dell handler, ma questo dipende da come il gestore è stato installato. La ricezione degli interrupt potrebbe rimanere attiva mentre si esegue l handler. Questa soluzione è possibile se l interrupt è stato precedentemente mascherato. Quando il gestore ha terminato, la routine IRQxx_interrupt continua e infine smaschera l interrupt. Il percorso appena descritto è il più importante da capire, ma è anche necessario vedere cosa accade dopo. Alcune routine meritano una spiegazione: ret_from_intr, controlla se il processore era in user o in kernel (supervisor) mode quando si è verificato l interrupt. User-mode significa che era in esecuzione un applicazione in user-space e kernel-mode che era in esecuzione qualche codice del kernel, come un driver. In user-mode si ha un percorso più lungo; _ret_with_reschedule, controlla se il processo corrente ha qualche signal pendente o è necessaria una schedulazione. In modo tale che venga inoltrata la routine appropriata; _Rexit, è responsabile del ripristino dei registri precedentemente salvati e del ritorno al codice interrotto (dal processore quando si è verificato l interrupt). Attraverso questa routine, tutti i gestori delle interruzioni si concludono «con il ritorno» Casi speciali IRQ 0: Interruzioni hardware (hwbreakpoint) usate solo per il debug; IRQ 1: Interruzioni dal watchdog. Se il watchdog è abilitato nella configurazione del kernel, la routine IRQ1_interrupt visualizza le informazioni di debug e in seguito il chip viene resettato. La routine può essere chiamata anche per il reset del chip da software, dato che il watchdog è usato per questo;

70 CAPITOLO 3. CRIS AXIS ETRAX 100LX 64 IRQ 2: Per gli interrupt del timer viene usata la routine speciale IRQ2_interrupt. Questa funziona è simile alla routine IRQxx_interrupt, solamente che gli interrupt non vengono mascherati. Questo perchè do_irq gestisce anche le interruzioni software pendenti (chiamando do_softirq) dopo l attuale gestore di interrupt. do_softirq consente gli interrupt durante l esecuzione dei gestori: un nuovo interrupt del timer può essere processato solo se non è mascherato. L interrupt del timer è cruciale e dovrebbe essere sempre processato il più presto possibile, in quanto il watchdog deve essere resettato e l orologio di sistema aggiornato; IRQ 14: il bus-fault della MMU (Memory Management Unit) si verifica per esempio quando un istruzione cerca di accedere a un indirizzo di memoria per il quale la traduzione da indirizzo virtuale a fisico non è memorizzata nella TLB. Quando si verifica un bus-fault viene chiamata la ruotine mmu_bus_fault. Questa salva i registri e disabilità gli interrupt come la procedura generale. Viene poi chiamata la routine-c handle_mmu_bus_fault, che si suppone risolva il bus-fault, qualunque esso sia. Al ritorno viene inoltrata ret_from_intr, ma invece di _Rexit è usata la funzione speciale _RBFexit. Essa riprista i registri e riavvia l istruzione che ha causato il fault; IRQ 15: Le interruzioni multiple si verificano quando ci sono diversi interrupt attivi allo stesso tempo. La routine multiple_interrupt, inizialmente, salva i registri e disabilita gli interrupt; in seguito processa il primo interrupt in attesa, chiamando la routine IRQxx_interrupt con una scorciatoia. La scorciatoia può essere percorsa dato che i registri sono stati salvati. L interrupt viene poi trattato in modo normale. Se vi sono altri interrupt attivi, verrà chiamata di nuovo la routine multiple_interrupt. 3.3 Software Development Kit (SDK) I sistemi embedded e la cross compilazione I sistemi embedded, a causa delle limitate risorse di cui dispongono, non possono ospitare ambienti di sviluppo. Non è possibile eseguire su di essi nessun IDE, editor di testo, compilatori e debugger. Tuttavia è necessario scrivere applicativi per questi sistemi. Il problema viene risolto utilizzando una macchina host opportunamente configurata per generare il codice oggetto, che sarà poi trasferito ed eseguito sulla macchina target, il sistema embedded.

71 CAPITOLO 3. CRIS AXIS ETRAX 100LX 65 Il processo relativo alla costruzione di un programma su di un sistema host, per poter poi essere eseguito su di un sistema target, è chiamato cross compilazione, il cui elemento fondamentale è il cross compilatore. Il gcc è stato portato praticamente su tutti i principali sistemi: per ognuno di essi è stato configurato per produrre dei binari ottimizzati per quella particolare architettura. Il gcc è il cross compilatore ottimale da utilizzare per costruire una cross toolchain. La costruzione di un cross compilatore e di una cross toolchain non sono operazioni semplici. Per effettuare una cross compilazione non è sufficiente disporre di un cross compilatore, configurato e ottimizzato per una particolare architettura hardware. Sono necessarie anche una serie di utility, che a loro volta devono essere costruite, ottimizzate e configurate per poter contribuire alla cross compilazione per quella particolare architettura. Il cross compilatore richiede il supporto delle librerie C e di altri eseguibili, come il linker, l assembler e il debugger. L insieme dei tool, delle librerie e dei programmi usati per la cross compilazione si chiama cross platform toolchain, o toolchain in breve. Tutte le macchine atte alla compilazione di codice dispongono di una toolchain. Se gli eseguibili prodotti sulla macchina host dovessero girare su una macchina target, dotata di una architettura simile all host, allora la toolchain è detta nativa. Se macchina host e macchina target hanno differenti architetture, allora la toolchain è detta cross platform. La cross toolchain può essere costruita a mano o si possono utilizzare dei tool (crosstoll, buildroot, crossdev) che cercano di automatizzare tutto il processo di costruzione della toolchain. Il principale problema che si può incontrare impiegando questi tool è che potrebbero non funzionare e fallire la costruzione della cross toolchain. Questa eventualità può accadere soprattutto se si cerca di utilizzare una versione del compilatore gcc, dei binutils, delle librerie C o del kernel che ancora non è supportata dal tool. In questi casi l unica alternativa è quella di costruire a mano la toolchain. La costruzione della toolchain può rivelarsi un compito più o meno complicato a seconda dei pacchetti software che si utilizzeranno.

72 CAPITOLO 3. CRIS AXIS ETRAX 100LX 66 Per quanto riguarda la CPU a nostra disposizione sulla FOX Board, è disponibile gratuitamente, sul sito della Axis, un Software Development Kit (SDK) ufficiale. Inoltre, sono fruibili una serie di ambienti di sviluppo alternativi completamente open source e scaricabili dal sito della Acme Systems realizzati da utenti appassionati. Per esempio: phrozen sdk fatto da John Crispin. Questo SDK storico è stato usato dalla Acme Systems per costruire immagini di default del kernel. Quando Acme Systems ha sviluppato la prima versione della sua FOX Board LX, Axis Communications ha rilasciato il suo Axis SDK versione 2.01 basato sulle versioni del kernel e A partire da questa versione, John Crispin, un utente appassionato di FOX Board, ha rilasciato la sua Phrozen SDK basata su quella dell Axis SDK, ma con un sacco di nuovi driver, utility, altri miglioramenti è un menuconfig più facile da usare. Successivamente Crispin non ha proseguito lo sviluppo di questo ambiente. Linux kernel o Librerie glibc o uclibc. cris OS fatto da Claudio Mignani. Questo ambiente si basa sul porting di OpenWRT, originariamente realizzato da John Crispin e ora fortemente migliorato da Claudio Mignanti. I principali vantaggi di questo ambiente sono che l intero file system è sia leggibile sia scrivibile, e l installazione del pacchetto è molto facile grazie al repository software on-line in formato binario fatto da Mignani. Linux kernel Librerie uclibc. foxserve SDK realizzato da Davide Cantaluppi. Questo ambiente si basa sul phrozen sdk migliorato con web server Apache, PHP, WebDAV e SQLite. Linux kernel Libreria glibc. FoXServe funziona solo sulla FOX Board LX832. Per quanto riguarda il nostro lavoro di tesi abbiamo scelto il Software Development Kit ufficiale della Axis [13]. Questo, è costituito da tre parti principali: il compilatore, il debugger e la distribuzione software (vedi Fig. 3.13) Installazione e test del cross compilatore gcc-cris Il primo passo per poter utilizzare l ambiente di sviluppo per applicazioni è quello di installare il cross compilatore. L architettura CRIS, utilizzata dall Axis ETRAX 100LX, è supportata dal GNU Compiler Collection (GCC)

73 CAPITOLO 3. CRIS AXIS ETRAX 100LX 67 Figura 3.13: Schema a blocchi SDK distribuito dalla Free Software Foundation (FSF). L assembler, il linker e altri strumenti CRIS sono inclusi come parte del sorgente GNU Binutils. Analogamente per la libreria Newlib. Vi sono due modi per installare il compilatore. Il primo, da noi adottato, è quello di scaricarare direttamente, dal sito della Axis, il pacchetto binario pre-compilato cris-dist i386.deb e installarlo. Mentre la seconda soluzione, più complicata, consiste nel compilare prima il codice sorgente e poi installare i file binari ottenuti. Il compilatore viene installato di default nella directory: /usr/local/cris. E importante sottolineare il fatto che l installazione presenta due compilatori, uno per crisv10 (relativo alla ETRAX 100LX) e uno per crisv32 (relativo alla ETRAX FX). Di conseguenza è necessario selezionare il compilatore giusto in fase di cross-compilazione. Per essere certi di utilizzare quello appropriato, lanciando il comando: /<path to compiler>/bin/gcc-cris --version dove <path to compiler> di default corrisponde a: /usr/local/cris. Si dovrebbe ottenere la schermata in figura 3.14, per quanto riguarda il compilatore crisv10. Figura 3.14: Versione gcc-cris Al fine di verificare il funzionamento del compilatore gcc-cris, abbiamo scritto una semplicissima applicazione in C, prima compilata ed eseguita sul

74 CAPITOLO 3. CRIS AXIS ETRAX 100LX 68 sistema host e poi cross-compilata sul sistema host ed eseguita sul sistema target. In pratica, abbiamo scritto il codice sorgente (Algoritmo 3.1) in un file denominato hello.c salvato all interno della directory /hello. Algoritmo 3.1 Codice sorgente applicazione hello.c #i n c l u d e <s t d i o. h> i n t main ( i n t argc, char argv [ ] ) { p r i n t f (" H ello World! \ n " ) ; r eturn 0 ; } Poi abbiamo compilato l algoritmo per il sistema host con il seguente comando: gcc -o hello_host hello.c Il quale ha prodotto, all interno della stessa directory del file oggetto, il file binario, hello_host, chiaramente eseguibile sul sistema host. Mandando in esecuzione il file ottenuto, sarà possibile visualizzare sullo schermo la semplice stringa «Hello World!». Quanto detto finora non è niente più che la classica compilazione di un applicazione in C. Successivamente abbiamo poi cross-compilato lo stesso file sorgente, hello.c per il sistema target. Il comando che ci permette di ottenere il file eseguibile sul sistema embedded è il seguente: gcc-cris -mlinux -o hello_target /hello/hello.c Ciò è fattibile nel caso in cui si abbia precedentemente aggiunto il percorso del compilatore gcc-cris alla variabile d ambiente PATH con il comando: export PATH=$PATH:/usr/local/cris/bin Dal momento che il file binario, hello_target, non può essere eseguito sul sistema host, come ci aspettavamo, lo abbiamo caricato sul sistema embedded per verificare che l esecuzione produca gli stessi risultati. Ciò può essere ottenuto tramite FTP o SCP. Naturalmente, il sistema embedded deve supportare il metodo di trasferimento scelto. Inoltre, il file eseguibile può essere scritto solo su un file system scrivibile. Utilizzando il caricamento sul sistema embedded tramite FTP bisogna eseguire i seguenti comandi. Per prima cosa occorre connettersi alla board

75 CAPITOLO 3. CRIS AXIS ETRAX 100LX 69 digitando il comando: ftp <ip address> che come abbiamo visto richiedererà l username e la password. Successivamente bisogna assicurarsi di trasferire il file in modalità binaria e non in modalità ASCII. Per far questo basta lanciare il comando: ftp> binary L eseguibile può essere posizionato sia nella partizione flash riscrivibile (/mnt/flash) sia nella partizione tmpfs (/tmp) nella RAM. Ovviamente, se si inserisce l eseguibile nella RAM, esso non sarà disponibile al riavvio del sistema. Quindi, portiamoci nella directory /mnt/flash con il comando: ftp> cd /mnt/flash e carichiamo il file con: put <file name> Dal momento che il trasferimento di un file utilizzando FTP non rende eseguibile il file, è necessario impostare manualmente il bit execute. E possibile utilizzare il comando chmod dal client FTP: ftp> chmod 755 <file name> Infine ci disconnettiamo: ftp> quit Poichè la FOX Board possiede due porte USB 1.1, per il trasferimento del file eseguibile, hello_target, possiamo utilizzare anche una semplice chiavetta usb. Una volta caricato il file sulla piattaforma di destinazione, per verificare se funziona come previsto, ci connettiamo alla board tramite Telnet o ssh con PuTTY e, dopo aver effettuato il login, ci spostiamo dentro la directory /mnt/flash con il comando: cd /mnt/flash e lanciamo l applicazione come visto per il sistema host:./hello_target Ciò che otterremo sarà di nuovo la stringa «Hello World!» Distribuzione software La distribuzione software è il sottoinsieme dell ambiente di sviluppo utilizzato dalla Axis, che comprende tutto il codice sorgente e i file del sistema di compilazione, necessari a produrre un immagine del firmware di Linux per l Axis ETRAX.

76 CAPITOLO 3. CRIS AXIS ETRAX 100LX 70 Il sistema di compilazione permette una configurazione semplice e flessibile delle opzioni hardware e delle applicazioni software. Inoltre, è disponibile un certo numero di configurazioni, predefinite per i sistemi più comunemente usati. Le caratteristiche del firmware di destinazione (Linux 2.6) sono: pieno supporto al MMU, libreria standard glibc o uclibc, librerie condivise, thread Linux e POSIX e varie applicazioni. Il kernel Linux include, inoltre, driver per le interfacce della ETRAX come Ethernet, porte seriali e parallele, general purpose I/O, USB e IDE. Un elenco completo delle librerie e delle applicazioni incluse nel Software Development Kit è reperibile all indirizzo Internet com/wiki/doku.php?id=axis:sw-list. Il passo successivo, dopo aver installato il cross compilatore, per avere un SDK «completo» (senza Debugger) è quello di installare la distribuzione software (la versione più recente è la 2.20). Prima di far questo però bisogna verificare che tutti i requisiti richiesti dalla distribuzione siano soddisfatti. Elenco requisiti: OS: qualsiasi distribuzione Linux abbastanza nuova dovrebbe funzionare; interfaccia di rete Ethernet; accesso root; compilatore C gcc; GNU make versione 3.80 o 3.81; GNU wget; CRISS cross-compilatore; awk (o gawk); bc; byacc (o yacc se byacc è un link a esso); lex o flex; perl; sed; tar;

77 CAPITOLO 3. CRIS AXIS ETRAX 100LX 71 zlib (per esempio zlib1g e zlib1g-dev); md5sum; curses o ncurses (per esempio libncurses5 e libncurses5-dev); bison; which. La distribuzione software è composta da un pacchetto di installazione e da un insieme di pacchetti distribuiti. Può essere installata in due modi: installazione normale e installazione tarball. L unica differenza tra le due procedure riguarda la modalità di accesso ai pacchetti distribuiti, in quanto entrambe richiedono il pacchetto di installazione. L installazione normale necessita di una connessione Internet sul computer dove si installa la distribuzione software. Mentre, con l installazione tarball si scaricano tutti i tarball supplementari (pacchetti.tar) che riguardano i pacchetti distribuiti per essere poi utilizzati su un sistema target. Noi abbiamo optato per l installazione normale. In pratica, durante il processo di installazione vengono scaricati tutti i pacchetti software richiesti. Questo riduce la quntità di spazio occupato dalla distribuzione software installata, nonché la quantità di contenuto scaricato. Ovviamente, sul computer è necessaria una connessiona a Internet. Come prima cosa, bisogna scaricare il pacchetto di installazione devboard- R2_20.tar.gz dal sito della Axis. Il pacchetto contiene, tra le altre cose, lo script di configurazione per l installazione della distribuzione. Dopo aver scaricato il file è necessario estrarlo con il comando: tar xvfz devboard-r2_20.tar.gz L estrazione crea una directory devboard-r2_20. A questo punto bisogna entrare nella directory appena creata ed eseguire lo script di configurazione. Questo scaricherà e istallerà gli strumenti e il codice sorgente necessario per configurare la distribuzione software. cd devboard-r2_20./configure Lo script di configurazione chiederà la tipologia del prodotto per il quale si vuole costruire il firmware. La selezione che si effettua determina i file di configurazione che verranno utilizzati. Nel nostro caso abbiamo selezionato la tipologia di prodotto «fox_416». In alternativa, è possibile impostare il

78 CAPITOLO 3. CRIS AXIS ETRAX 100LX 72 tipo di prodotto settando la variabile DEV_BOARD_PRODUCT=<product name> prima di eseguire lo script di configurazione. Successivamente viene chiesto se si desidera personalizzare il firmware o mantenere la configurazione predefinita per la tipologia di prodotto selezionata. E consigliabile configurare la distribuzione del software, dal momento che la configurazione predefinita include solo un sottoinsieme di tutti i pacchetti disponibili. Immettendo y, la selezione dei pacchetti può essere configurata prima che questi vengano scaricati, risparmiando tempo e spazio sul disco. Questa domanda viene fatta solo la prima volta che si installa la distribuzione software, anche se questa può essere configurata successivamente Configurazione e compilazione del firmware Per selezionare quali pacchetti vogliamo includere o togliere nel firmware, una volta recati all interno della directory devboard-r2_20, bisogna eseguire il comando: make menuconfig Ciò che otteniamo nella shell è un menù grafico suddiviso per categorie, in modo da rendere la selezione dei pacchetti abbastanza semplice e logica. Nel nostro caso, oltre alla configurazione di default, abbiamo abilitato il supporto dropbear ssh 3 e il supporto a utelnetd 4. In alternativa a questo comando possono essere eseguiti make xconfig o make config. E importante salvare la configurazione prima di uscire dall utility. Fatto ciò, bisogna eseguire lo script./configure per installare i pacchetti richiesti dalla configurazione. Questi genererà il Makefile di primo livello che viene utilizzato per compilare l immagine del firmware. Ora basta lanciare il comando make dopodiché occorre attendere (richiede abbastanza tempo) che il processo di creazione dell immagine del firmware termini. 3 Secure SHell, è un protocollo di rete che permette di stabilire una sessione remota cifrata tramite interfaccie a riga di comando con un altro host di una rete informatica. E il protocollo che ha sostituito l analogo ma insicuro Telnet. 4 è un protocollo di rete utilizzato su Internet. L obiettivo del procollo Telnet è fornire un supporto per le comunicazioni sufficientemente generalizzato, bidirezionale e orientato ai byte (8 bit). E solitamente utilizzato per fornire all utente sessioni di login remoto di tipo riga di comando tra host su Internet.

79 CAPITOLO 3. CRIS AXIS ETRAX 100LX 73 Per quanto riguarda la versione 2.20 della distribuzione software, questa produrrà una immagine basata sulla versione del kernel Linux Scrittura del firmware sulla board Poichè sulla piattaforma embedded a nostra disposizione vi era un kernel Linux 2.4, mentre con la distribuzione software 2.20 si ottiene un immagine del kernel Linux , abbiamo aggiornato la board con questo firmware compilato precedentemente. Come si può notare dalle caratteristiche tecniche del sistema embedded, sulla board vi è una memoria FLASH in cui è possibile archiviare tutti i file di programma necessari per il corretto funzionamento del sistema stesso. In questa memoria permanente viene salvato il sistema operativo Linux e tutte le applicazioni e i dati di cui necessita la board. In pratica corrisponde al disco rigido di un PC. E importante ricordare che non c è bisogno di ricompilare una nuova immagine del firmware per avere la FOX Board con le nostre applicazioni. E sufficiente, invece, nella maggior parte dei casi, trasferire semplicemente le nostre applicazioni tramite FTP o SSH direttamente nel file system della scheda in una zona riscrivibile della memoria flash (/mnt/flash). Uno dei metodi di reflashing della scheda, chiamato «local network flashing», si basa su un piccolo codice ROM all interno del processore AXIS che viene eseguito all accensione quando il jumper J8 è chiuso. Questo codice carica nella memoria cache interna i pacchetti che gli vengono inviati dal PC attraverso la LAN. L Axis eseguirà progressivamente i frammenti di codice contenuti in questi pacchetti e di conseguenza inizierà a interagire con il PC per scaricare la procedura di programmazione scelta per la memoria flash. Tale metodo funziona solo su una rete locale e non supporta alcun routing IP. Inoltre richiede che il PC e la FOX Board siano sulla stessa rete locale (vedi 3.1.3). All interno della directory principale SDK ( /devboard-r2_01/ ) occorre digitare:. init_env uno script che viene creato quando si lancia il comando make. Lo scopo di questo file è quello di settare tutte le variabili d ambiente necessarie alla di-

80 CAPITOLO 3. CRIS AXIS ETRAX 100LX 74 stribuzione software. Come regola si dovrebbe sempre richiamare il seguente script prima di iniziare a lavorare con l SDK in una nuova shell. Dopo init_env, bisogna lanciare il comando: boot_linux -F -i <image_filename>... In seguito otterremo un messaggio come quello in Figura Figura 3.15: Network flashing In questo momento si deve spegnere la FOX Board, chiudere il jumper J8 (Ethernet flashing) sulla scheda (vedi Fig. 3.16) Figura 3.16: Ethernet flashing e riaccenderla di nuovo (così facendo la FOX Board dovrebbe essere sulla stessa LAN del PC avendo lanciato il comando boot_linux). Se la procedura risulta corretta, vedremo il processo di trasferimento del file immagine nella memoria FLASH della scheda con messaggi come quelli in Figura Durante la programmazione il LED rosso (DL1) della scheda rimane sempre acceso. Al termine della fase di programmazione della FOX Board essa si riavvia automaticamente. Bisogna tuttavia ricordarsi di rimuovere il jumper J8 altrimenti la scheda carica ancora i pacchetti dalla rete e non si avvia.

81 CAPITOLO 3. CRIS AXIS ETRAX 100LX 75 Figura 3.17: Ethernet flashing Alcune opzioni utilizzabili con il comando boot_linux: -d «dispositivo», interfaccia di reta da utilizzare, eth0 di default; -f, salva l intera immagine del firmware sulla memoria flash tranne che la partizione di recupero; -F, salva l intera immagine del firmware sulla flash. Inoltre questa operazione sovrascrive i parametri memorizzati nella partizione di recupero, come il numero di serie e l indirizzo MAC; -h, visualizza informazioni e opzioni aggiuntive non mostrate in questo elenco; -i «image», il percorso e il nome dell immagine da usare; -i, visualizza i risultati del comando «etraxboot» invece di eseguirlo.