Università Politecnica delle Marche

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea di Ingegneria Elettronica Porting su architettura ARM Marvell 88F6281 ed analisi comparativa delle patch real-time RTAI e Xenomai per il kernel Linux Tesi di Laurea di: Francesco LUCCONI Relatore: Prof. Aldo Franco DRAGONI Correlatori: Prof. Massimo CONTI Ing. Massimiliano PIRANI Anno Accademico 2009/2010

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 Scenario di utilizzo dei RTOS Sviluppo di SW real-time per applicazioni di controllo Ulteriori scenari applicativi 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. 40 iii

4 INDICE iv Approccio RT basato sull'utilizzo di un Kernel RT di basso livello Xenomai Adeos pipeline Adeos e Xenomai I domini di Xenomai Intercettare le chiamate di sistema Propagazione degli interrupt Installazione di Xenomai su x RTAI (Real Time Application Interface) Struttura e funzionamento di RTAI LXRT Scheduling in RTAI Inter-Process Communication (IPC) in RTAI Struttura di un modulo del kernel RTAI Struttura di un processo RTAI LXRT Installazione di RTAI su x RT_PREEMPT Preemption Patch Low Latency patch Scheduler O(1) Porting di Xenomai ed RTAI su ARM Board Marvell SheevaPlug Architettura ARM Il microcontrollore come sistema embedded CPU Marvell 88F Contatori e timers La cross-compilazione Lavoro di porting Xenomai su piattaforma ARM MV88F RTAI su piattaforma ARM MV88F Valutazione delle soluzioni rispetto agli aspetti implementativi 88 4 Test Linux Test Project Test real time di Xenomai ed RT_PREEMPT

5 INDICE v Setup della suite LTP Risultati dei test Conclusioni 99 Ringraziamenti 103 Bibliograa 105

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 traco 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 pressato. 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 scientica consolidata. La conseguenza di ciò è una scarsa adabilità del software che, in applicazioni critiche, può causare gravi danni a cose o persone. Negli ultimi anni, è maturato un notevole interesse nell'utilizzo del sistema operativo Linux per scenari real-time, specialmente nei sistemi di controlvi

7 Introduzione vii lo. L'architettura semplice ed ordinata fornita da Linux garantisce robustezza ed ottime prestazioni, mentre la licenza GPLv2 permette di modicare e di cambiare il codice sorgente in relazione alle necessità dell'utente. Tuttavia Linux è stato progettato per essere un sistema operativo generalpurpose e pertanto presenta alcune questioni che (come per esempio le latenze inpredicibili a priori, supporto limitato per la schedulazione a tempo reale del task-set, risoluzione temporale dei timer insuciente) possono rappresentare un problema per applicazioni real-time. Per questi motivi sono state proposte alcune modiche per aggiungere le indispensabili caratteristiche real-time al kernel Linux sia per piattaforme hardware di utilizzo generico (x86) che per soluzioni embedded (come per esempio ARM) utilizzate per le applicazioni di controllo. In questo lavoro di tesi svolto in collaborazione con la società Spes di Fabriano è stata svolta una indagine sulle varie alternative real-time disponibili sul kernel Linux per la board Marvell SheevaPlug con processore MV88F6281 (con set di istruzioni ARMv5te) sia in termini di costo temporale nell'implementazione del porting sulla board che per quanto riguarda le prestazioni real-time. La tesi è stata organizzata illustrando nel Capitolo 1 i concetti basilari che caratterizzano un sistema operativo real-time, le tecniche più recenti per la schedulazione a tempo reale e la schedulazione presente nel kernel Linux nativo. Nel Capitolo 2 vengono mostrate alcune tra le più importanti soluzioni attuabili per il kernel Linux (sia per piattaforme x86 che embedded) mentre nel Capitolo 3 viene presentato il lavoro svolto per il porting delle soluzioni real-time RTAI e Xenomai sulla board precedentemente citata. Nel Capitolo 4 vengono confrontate le prestazioni computazionali delle

8 Introduzione viii soluzioni real-time mediante test software anch'essi opportunatamente descritti ed inne nel Capitolo 5 vengono presentate le conclusioni di questo lavoro di tesi e gli sviluppi futuri sia per quanto riguarda un'estensione del confronto nel panorama dei sistemi RTOS.

9 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 pressato. 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 1

10 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 2 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: ˆ periodici: quando un task consiste in una sequenza di attività attivate con cadenza regolare ˆ aperiodici: quando un task consiste in una sequenza di attività attivate ad intervalli irregolari I task di tipo periodico sono propri di un sistema di controllo 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 di un task periodico. È uso comune far coincidere la priorità con l'inverso del periodo poiché questo è il limite massimo di esecuzione di un task. I task di un sistema real-time possono però essere: ˆ 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 della deadline. ˆ hard real-time: un task che nel caso superi temporalmente la sua deadline provoca un danno irreparabile al sistema. Sostanzialmente questa distinzione si traduce nella diversa quanticazione 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 lmato, ma non pregiudica il proseguimento della riproduzione; mentre un task hard realtime può essere il controllore della temperatura del nocciolo di una centrale

11 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 3 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 ): ˆ 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 completamente 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 ) ˆ 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 completion time ˆ Response time R i : è la dierenza tra il nishing time ed 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 Figura 1.1.1: Parametri tipici di un processo real-time

12 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX Sistemi Hard e Soft real-time I sistemi real-time si possono dividere 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 può pensare ad un sistema real-time come ad 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 denita come: K s = n K i (t) i dove K i (t) è la funzione costo del task i-esimo denita come: 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 i task di tipo hard real-time dovranno quindi essere schedulati in modo da terminare ad 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

13 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 5 ma, in questo caso, uno sfondamento della deadline t > d i non manderà il costo globale del sistema all'innito (equivalente al disastro). Figura 1.1.2: Esempi di funzioni di costo per diverse tipologie di task 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. Nel momento in cui viene rilevato un evento esterno, lo scheduler dei processi ha il compito di determinare un'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 possono essere classicati 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. Ad esempio, consideriamo un sistema soft real time con tre eventi periodici

14 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 6 di periodo 100, 200 e 500 millisecondi, rispettivamente. Se questi eventi richiedono rispettivamente 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 no a quando a questo evento non richiederà 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 (ad esempio Linux è un sistema soft real-time) Schedulazione dei sistemi real-time Ciò che dierenzia 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'ecienza computazionale del computer, garantendo un utilizzo ottimizzato della CPU tra processi che evolvono parallelamente, tendendo conto degli interrupt prodotti dai controller delle varie unità I/O, dalle memorie, dagli hard-disk. 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,

15 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 7 ˆ delayed : in attesa della ne di un timeout pressato, ˆ suspended : lo stato iniziale di ogni task appena creato. Figura 1.1.3: Tasks Tutti i task in stato ready sono pronti per essere eseguiti. L'accesso alla CPU di un task rispetto ad un altro è funzione dell'algoritmo implementato nello schedulatore. Gli aspetti più importanti di uno schedulatore sono: PRIORITÀ: la priorità è un indice che denisce l'importanza che un processo ha nei confronti degli altri. Si possono distinguere priorità interna (denita dal sistema in base a diversi requisiti tipo memoria, I/O, tempo di esecuzione) ed esterna (denita dall'utente). In aggiunta si denisce una priorità dinamica (aging). 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). Per questo motivo quando un processo è pronto ad essere eseguito da troppo tempo, la sua priorità viene aumentata dinamicamente dallo scheduler. PREEMPTION: se nella coda esiste un processo pronto ad essere eseguito con priorità maggiore di quello in esecuzione nella CPU, lo scheduler forza il rilascio della CPU e passa ad 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à nisca prima di completare il suo ciclo. Con la preemption,

16 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 8 invece, la CPU viene liberata dal processo a bassa priorità nell'istante in cui il processo ad alta priorità ritorna pronto ad essere eseguito (cioè quando ha nito l'i/o). Algoritmi di schedulazione real-time Gli algoritmi di scheduling real time possono essere distinti in: ˆ statici: la decisione di schedulazione è eettuata prima dell'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. Nel seguito verranno analizzate alcune politiche di scheduling real time, facendo riferimento al particolare contesto delle applicazioni multimediali. Infatti, i sistemi operativi che supportano applicazioni multimediali, dieriscono da quelli tradizionali per tre aspetti principali: la schedulazione dei processi, il le 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 soddisfano le seguenti condizioni: 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 a 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.

17 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 9 Le prime quattro condizioni sono ragionevoli, mentre l'ultima rende più semplice la modellazione del sistema. RMS assegna a ciascun processo una priorità pressata uguale alla frequenza con cui deve essere eseguito. Ad esempio, 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 a eseguire ogni 50ms (20 volte/s) acquisisce priorità 20. Dato che le priorità a 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, è suciente che un processo che abbia bisogno e 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 aermativo il nuovo processo prelaziona quello corrente. È interessante notare come nell'esempio riportato in Fig.2.3 l'algoritmo

18 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 10 RMS fallisca. Questo è dovuto al fatto che, utilizzando priorità statiche, l'algoritmo 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 suciente) se: m i=1 C i P i m (2 1/m 1) Per m che tende all'innito, l'utilizzo massimo della CPU tende in modo asintotico a ln2 = Questo signica 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 questo è 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 dunque avere uno schedulatore che implementi una schedulazione che minimizzi al massimo la funzione di costo K s presentata prima. ˆ Condivisione delle risorse: i task sono entità separate ma che concorrono ad 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 quindi, nel caso in cui arrivi un nuovo task o un task non possa completare entro la deadline, una notica anticipata del sistema può essere utilizzata per impedire l'esecuzione del nuovo task o di 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, quindi ogni chiamata di sistema deve avere un tempo

19 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 11 di esecuzione massimo ben denito in modo da non introdurre ritardi indeniti. I prodotti delle famiglie Windows 1 e Unix non soddisfano le caratteristiche tipiche di un sistema real-time: ad esempio, pur gestendo l'esecuzione di più 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. Ci sono diversi fattori che causano la non prevedibilità nella risposta del sistema operativo. Tra di essi, i principali sono i seguenti: ˆ Il DMA: può rubare il bus alla CPU ritardando l'esecuzione di un task critico. In un sistema real-time si preferisce quindi disattivarlo o usarlo in modalità timeslice dove si assegna in maniera costante e ssa 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 e può causare ritardi nell'accesso alla memoria da parte della CPU. Dovendo considerare quindi il caso peggiore si preferisce non usarla aatto. ˆ Meccanismi di gestione della memoria: queste tecniche non devono introdurre ritardi non prevedibili durante l'esecuzione di task critici, ad esempio 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. ˆ Le interruzioni: sono generate da dispositivi periferici quando hanno qualche informazione da scambiare con la CPU. Queste interruzioni durante l'esecuzione di un task critico generano ritardi non prevedibili e quindi debbono essere trattate in maniera opportuna. 1 Anche il sistema operativo Windows CE erroneamente viene da alcuni considerato un sistema operativo real-time, quando in eetti non esiste alcuna prerogativa architetturale a livello hardware e software che dia modo di prestabilire il tempo di esecuzione di una serie di operazioni da parte di questo sistema operativo.

20 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 12 ˆ I sistemi di power management: sono meccanismi hardware che possono rallentare la CPU o far eseguire ad essa del codice utile a dissipare minor energia. È chiaro che in un sistema real-time è importante non sfondare una deadline piuttosto che consumare poca energia, quindi questi meccanismi vengono disattivati. Tra gli RTOS commerciali troviamo il POSIX-conformant (ad esempio LynxOS che è Unix compatibile) e non POSIX-conformant come ad esempio VxWorks (che supporta in parte gli standard POSIX). Per quanto riguarda i sistemi Open Source è possibile l'uso di Linux, con necessarie precauzioni, opportunatamente applicate in soluzioni come Xenomai, RTAI, RT_PREEMPT ed altre ancora che verranno mostrate in dettaglio nel prossimo capitolo. 1.2 GNU/Linux In questa sezione si darà una panoramica generale sulle opportunità, i vantaggi ed 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 congurazione, 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) sono, o meglio possono essere, a seconda delle scelte degli utenti, software libero, distribuito secondo la licenza GNU GPL o altre licenze libere. Alcune

21 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 13 riessioni saranno infatti dedicate ai vantaggi dell'uso di software libero nello sviluppo di applicazioni embedded. Non ci occuperemo invece specicamente di distribuzioni Linux embedded commerciali, ma molti dei concetti qui esposti si applicano ugualmente anche ad esse. Il nucleo (kernel) Linux è funzionalmente equivalente ad un kernel Unix, e per questo motivo è molto diverso, nonché molto più complesso, della maggior parte dei tradizionali sistemi operativi per applicazioni speciche (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 che appaiono tra le più signicative, con particolare riferimento agli aspetti che di norma risultano meno familiari per gli utenti che provengano da altre esperienze Interruzioni hardware e software Le interruzioni ("interrupt" o IRQ per "interrupt request") sono alla base del funzionamento di un sistema multiprocesso. Normalmente l'esecuzione del codice da parte del processore ("CPU", "central processing unit") è sequenziale, seguendo il usso logico del programma in esecuzione e senza distrazioni da questo compito. Inizialmente, con le prime macchine, non c'erano alternative a questo modo di funzionamento. Poco dopo, però, si è pensato di permettere l'interruzione del normale usso di istruzioni seguito dal processore da parte di eventi esterni. Oggi questo meccanismo è ampiamente usato e gli eventi che interrompono il processore sono normalmente associati ad una qualche periferica che richiede

22 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 14 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 lo 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à quindi 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 esserci bisogno di un PIC esterno. In altri casi ancora molte periferiche risiedono sicamente all'interno del processore stesso e viene realizzata un'architettura con più livelli di priorità con un solo segnale di IRQ proveniente dall'esterno, al quale può essere associato o meno un controllore programmabile. Altre variazioni sul tema sono le cosiddette trap (che verranno spiegate più tardi), le interruzioni non mascherabili (NMI, "non maskable interrupt") e tutte le complicazioni introdotte nel mondo PC in questi ultimi anni (APIC, IO-APIC, MSI, MSI-X) che per fortuna possono essere ignorate tranquillamente in quanto l'interfaccia oerta dal kernel verso i suoi moduli è indipendente dalla gestione di basso livello implementata nel caso specico. Anche la gestione dei livelli di priorità, quando presente, può essere ignorata dal codice dei driver che 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 ad eseguire un'istruzione macchina, per esempio perché si tratta di una divisione per zero, o l'indirizzo di memoria cui deve accedere

23 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 15 non è valido, oppure l'istruzione non è denita nel set di istruzioni della CPU. 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 (oating point exception), SIGSEGV (segmentation violation) e SIGILL (illegal intruction). Il processo può essere predisposto per intercettare questi segnali e per cercare di recuperare la situazione, se non lo è verrà terminato. Anche le interruzioni software si avvalgono anche loro del meccanismo hardware delle interruzioni (ancora una volta, un meccanismo simile o identico) al ne di trasferire il controllo al sistema operativo. Nel set di istruzioni del processore è in genere denita una istruzione INT (o SWI software interrupt o equivalente) che trasferisce il controllo al sistema operativo proprio come una trap o un'interruzione esterna. Il sistema operativo analizzando lo stato del processore estrae gli argomenti passati dal programma e provvede ad 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.

24 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 16 Rispetto ai requisiti imposti dallo scenario real-time, una prima dierenza 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 ). Figura 1.2.1: Linux e la sua gestione interrupt hardware e software Al contrario, il codice dell'applicazione viene eseguito in modalità utente, ed è quindi limitato per quanto riguarda l'accesso sico al sistema, oltre a non poter direttamente gestire interruzioni ed eccezioni. Dal punto di vista della scalabilità Linux ha lo svantaggio di richiedere sempre un le system per poter funzionare. Si noti tuttavia che ciò non implica necessariamente il fatto che il sistema sia dotato di un dispositivo di memorizzazione di massa. È infatti possibile

25 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 17 usare svariati supporti sici per memorizzare un le system: RAM, ROM, memoria FLASH, il le system di un'altra macchina con cui si è collegati via rete, e così via Schedulazione a code multiple Il componente del nucleo del sistema operativo che decide istante per istante quale sia il processo che debba avere il controllo della CPU si chiama schedulatore. Ad ogni processo vengono assegnati due attributi fondamentali: una priorità ed 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). Ad ogni processo sono assegnati un certo numero di crediti che equivalgono ad unità di tempo di utilizzo della CPU. 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).

26 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 18 Figura 1.2.2: Modello dello scheduler Linux 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 del'algoritmo CFS (Completely Fair Scheduler) può essere riassunta in una singola frase: il CFS fondamentalmente 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, ognuno alla velocità di 1 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, quindi mentre un task viene eseguito, gli altri, che rimangono in attesa della CPU, sono in svantaggio, perchè il task corrente si appropria ingiustamente del

27 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 19 tempo di CPU. Nel CFS, questo sbilanciamento è espresso e tracciato tramite un valore, associato ad ogni task, p->wait_runtime espresso in nanosecondi, dove wait_runtime è il tempo totale di CPU che il processo dovrebbe ancora ottenere anchè 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 attivare il task che ha un bisogno urgente di altro tempo di CPU. Quindi il CFS cerca di dividere il tempo totale di CPU tra tutti i processi attivi, quanto più possibile, fedelmente a quello che accadrebbe idealmente in un hardware multitasking. La restante parte dell'implementazione del CFS, che non rientra in questa semplicazione, è relativa a poche 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: quel po' di tempo in cui ha usato la CPU sica 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 RB ordinato in base al tempo, al processo corrente viene sottratta la CPU e concessa al

28 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 20 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 dal 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 RB 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 vengo inseriti nell'albero via via da 'destra' - lentamente e, mano a mano che viene eettuata la schedulazione, ad 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 permettere di essere esteso mentre il sistema funziona (mediante il meccanismo dei moduli). Questo consente il supporto di piattaforme dierenti 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 le 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.

29 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 21 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'adabilità del sistema, sia da quello delle funzionalità. In particolare la disponibilità di chiamate come mmap(), che consente di mappare i contenuti di un le 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. Per ciò che concerne i processi, il modo Unix/Linux di crearne di nuovi riesce di solito un po' ostico ai programmatori embedded tradizionali. 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 cui parametri è già 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", deniti dalla norma POSIX c. Inne 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ù sosticate: pipe, fo, semafori, code di messaggi, memoria condivisa, socket, eccetera. La varietà di possibili soluzioni impone all'utente una buona conoscenza di tutte le alternative al ne di scegliere la più adatta alle esigenze dell'applicazione.

30 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX Il livello applicativo Soprattutto 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 di tutti sta nel cambio radicale di ottica rispetto all'approccio tradizionale. La "novità" sta soprattutto nel fatto che la losoa 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 tutta in C, può essere spezzato in una serie di programmi tra loro interagenti, alcuni dei quali già esistenti ed altri da scrivere in linguaggi diversi a seconda dell'opportunità tecnica. È inutile rimarcare tutti i vantaggi dell'approccio modulare. Quello che invece è importante sottolineare è che, con l'approccio presentato, la fase di test di modulo risulta semplicata perchè il modulo stesso è già esso stesso un programma eseguibile, rendendo quindi inutile la costosa scrittura di programmi di test ad hoc. Inne evidenziamo il fatto che l'uso di linguaggi di scripting (ad esempio script della shell, tcl e le sue varianti, perl, eccetera) può risolvere un gran numero di problemi che risultano ostici in C, come ad esempio lavorare con stringhe ed espressioni regolari 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 dierenti, ed anche su macchine non dotate di MMU.

31 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 23 Anche a livello di applicazioni, sono disponibili distribuzioni Linux libere che coprono diverse architetture. Ad esempio la distribuzione Debian, pur non specica per l'embedded, dispone di pacchetti per svariate piattaforme comunemente impiegate su macchine ad impiego specico (x86, ARM, PowerPC, SH ed altre). Anche a livello di librerie C, esistono progetti liberi nati per dare origine a librerie particolarmente poco esigenti dal punto di vista delle risorse richieste. Limiti di applicabilità Dal punto di vista tecnico bisogna tenere presente che Linux non è un sistema operativo che possa essere utilizzato 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 eettivo varia a seconda della piattaforma. La potenza di calcolo richiesta alla CPU dal kernel in se stessi non rappresenta invece un fattore particolarmente critico. Nonostante venga qualche volta considerato "scomodo" e/o "poco usabile", Linux rappresenta una piattaforma ideale anche per ciò che concerne la macchina host, ossia quella sulla quale si sviluppa il codice che girerà sul campo. Questo è vero anche per quello che riguarda i compilatori, i sistemi di controllo della congurazione, il test ed il debugging Compilazione, debugging e test L'insieme di binutils (assembler, linker ed 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 professio-

32 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 24 nale, 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 grache (come ad esempio Insight e ddd). Inoltre sotto Linux il debugging delle applicazioni può essere eettuato sia mediante il debugger vero e proprio sia attraverso strumenti di tracing come ad esempio strace(1), che evidenzia la sequenza delle chiamate di sistema eettuate 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 specicati porti ad un malfunzionamento grave. La conseguenza di quanto si è detto in precedenza è il fatto che lo schedulatore Linux non ha il concetto di "deadline", ossia tempo entro il quale una certa attività andrà svolta, e non è quindi adatto ad applicazioni in

33 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 25 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, ma questo non è vero a causa di un secondo ordine di motivi. Bisogna infatti chiedersi quando possa avvenire un cambio di contesto, ossia quando eettivamente il controllo della CPU possa passare da un processo ad 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 ad 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. 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 ed 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 verica una condizione di questo genere, non si può prevedere quando si ritornerà al codice utente e quindi procedere ad un eventuale cambio di contesto. Ad esempio se il controller IDE continua ad 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

34 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 26 l'articolo Linux e real time (prima parte) su [4] Strumenti di supporto Per chiudere, Linux fornisce strumenti validi anche per ciò che concerne l'editing (ad esempio emacs), il controllo della congurazione dei moduli (cvs), la stesura della documentazione (texinfo, sgmtools), ed in generale tutto ciò che concerne in generale lo sviluppo di software. L'approccio allo sviluppo 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 adi ad 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 aerrare 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 modiche consente di correggere malfunzionamenti, eettuare personalizzazioni, nonché imparare dal codice e dagli errori altrui e in qualche caso contribuire attivamente allo sviluppo. Inne è 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. Pertanto anchè si voglia realizzare un sistema operativo real-time basato su Linux occorre tenere in considerazione queste problematiche. Le soluzioni che vengono mostrate nel prossimo capitolo attuano strategie dierenti per ottenere un sistema operativo GNU/Linux di tipo real time.

35 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 27 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 specico per i sistemi embedded, stia sviluppando quelle capacità tali da renderlo adatto anche al mondo real time, in cui il determinismo (sia degli eventi, sia delle tempistiche), giocano un ruolo fondamentale. 1.3 Scenario di utilizzo dei RTOS Per contestualizzare tutto il lavoro svolto nell'attività di tesi, in questa sezione viene presentato anche il progetto per la quale Spes è stata coinvolta con pieno interesse, ovvero la denizione di una piattaforma software per la simulazione realtime di sistemi dinamici. La società è infatti interessata ad una investigazione completa delle alternative real-time per Linux presenti sul mercato, in vista dell'adozione di una di queste per lo sviluppo di una piattaforma embedded Sviluppo di SW real-time per applicazioni di controllo Il progetto è mirato alla progettazione di una architettura software, orientata su Linux, per la simulazione real-time di sistemi dinamici e per la prototipazione rapida di controllori digitali. La scelta della piattaforma opensource Linux come base per questo sistema permette di sfruttare l'enorme quantità di applicazioni già disponibili a costo zero e di utilizzare hardware standard e a basso costo, ampiamente disponibile sul mercato, per l'implementazione di sistemi di controllo digitale.

36 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 28 Questa attività di ricerca trae le sue origini dalla necessità di disporre di un ambiente a a realtime e di strumenti di programmazione per applicazioni di controllo, caratterizzato da un'elevata essibilità d'impiego, un'interfaccia semplice e da elevate prestazioni. L'obiettivo principale alla quale mira questo lavoro è la semplicazione della fase di testing dei controllori digitali mediante la fornitura della simulazione in tempo reale dell'impianto con la stessa interfaccia utilizzata per la comunicazione tra le applicazioni di controllo ed il sistema eettivo. Questa interfaccia comune, basata sulla libreria COMEDI, permette di poter far lavorare il controllore dal sistema simulato a quello reale, senza nessuna modica del software di controllo. Inoltre è stato sviluppato un set di applicazioni di ausilio per l'utente nello sviluppo dei task real-time relativi alla simulazione dell'impianto sotto test. Una particolare attenzione è stata posta nella generazione automatica della cinematica simbolica e per i modelli dimamici dei meccanismi relativi alla robotica rispetto ad una descrizzione del robot in termini dei suoi parametri cinematici e del centro di massa interziale di ciascun link. Attualmente sono disponibili numerosi software commerciali specializzati per la progettazione di sistemi di controllo e per la simulazione di sistemi dinamici come per esempio Scilab/Scicos, Matlab/Simulink, Mathematica, e cosi via [6, 7, 8, 9]. Tutte queste caratteristiche sono molto utili ai ni di una rapida prototipazione dei sistemi di controllo perchè semplicano drasticamente lo sviluppo e riducono il tempo richiesto per la sintesi del controllore. Queste applicazioni consentono all'utente di studiare il comportamento di un sistema dinamico ed, in fase di progettazione del controllore, di vericare la sua ecacia la sua azione di controllo.

37 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 29 Questa tecnica è considerata come una pratica standardizzata per assumere una procedura iterativa basata sulla simulazione di un sistema ad anello chiuso per la sistemazione dei parametri del controller. Solitamente il programmatore utilizza questi software per poter ottenere il migliore controllore che poi deve essere adattato all'interno di un sistema di controllo hardware/software reale. Questa fase successiva implica la riscrittura della legge di controllo in un linguaggio di programmazione standard (per esempio in C) che si interessi dell'intefaccia hardware tra il controllore e lo scenario sico. Questo step progettuale può introdurre qualche comportamento indesiderato nel controllore indesiderato in quanto sia i ritardi temporali che la quantizzazione introdotti dai dispositivi digitali possono modicare il comportamento o, nella peggiore delle ipotesi, destabilizzare il sistema controreazionato. Tra le recenti applicazioni di CACSD 2 è presente la caratteristica standard di conversione automatica dal schema di controllo sviluppato all'applicazione che può essere eseguita per varie piattaforme real-time ed anche di interfaccia diretta tra i pacchetti software per la simulazione con eventuali dispositivi input/output a tempo reale. Negli ultimi anni la questione relativa alla rapidità di prototipazione di sistemi di controllo digitali è stata rivolta da numerosi ricercatori per ridurre il tempo e lo sforzo necessario per ottenere il sistema di conrollo per l'impianto fornito in [10]. Inoltre possono essere implementati algoritmi realtime per l'integrazione di sistemi di equazioni dierenziali ordinarie, tramite il quale è stato possibile collegare la simulazione dell'impianto da controllare direttamente all'appli- 2 Computer Aided Control System Design

38 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 30 cazione di controllo al ne di valutarne la correttezza e le prestazioni, per poi passare al controllo del sistema sico reale senza alcune modica alla applicazione di controllo stessa. Comunque questo approccio richiede che il controllore nale sia testato nell'impianto reale per vercarne l'ecacia nel contesto operativo. Questa fase è molto critica perchè durante questo test vi è la possibilità causare ingenti danni all'hardware in quanto il sistema può lavorare in condizioni pericolose. Come dato di fatto, l'interfaccia tra l'algoritmo di controllo e l'impianto è basato su dispositivi come DAC, ADC e linee I/O, decoder, e così via; spesso molti di questi dispositivi sono raggruppati in una singola board, chiamata appunto Data Acqusition Board (o DAQ). In commercio sono presenti molte board DAQ general-purpose, ciascuna di esse con interfacce software speciche, compatibilità hardware limitata rispetto alle board dello stesso produttore ed incompatibilità assoluta rispetto all'hardware di altri produttori. Di conseguenza, una applicazione di controllo progettata specicatamente per una board DAQ non può essere utilizzata per hardware diverso da quello considerato precedentemente, almeno senza la ridenizione intera dell'interfaccia I/O. Per evitare questo problema, la libreria Comedi 3 [11] fornisce un set di API per le applicazioni di controllo in automazione. Questa libreria consente di ottenere applicazioni indipendenti dalla board DAQ che si vuole utilizzare per interfacciare il sistema di controllo dell'impianto monitorato. La maggior parte delle board DAQ è supportato da Comedi ed è possibile estendere il supporto verso ulteriori schede scrivendo il driver spe- 3 COntrol and MEasurement Device Interface

39 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 31 cico. Inoltre Comedi può supportare alcune tra le estensioni real-time più conosciute come RTAI ed RTLinux. Questo approccio permette di rendere l'implementazione del controllore indipendente dal sottosistema di input/output. Con questa architettura è possibile monitorare il comportamento sia del controllore che dell'impianto (o più precisamente, il modello dinamico dell'impianto) senza connessioni siche del sistema di controllo sul processo. La Fig ore uno schema semplice dell'approccio precedentemente descritto. Figura 1.3.1: Struttura software tipica per il controllo industiale (a sinistra) e schema software applicato con le librerie Comedi (a destra) Siccome questa trattazione può essere utile nella fase progettuale, tutto ciò migliora l'adabilità del sistema di controllo perchè è possibile testare condizioni critiche senza nessun rischio, riducendo sensibilmente la possibilità di disfunzioni e guasti del controllore quando viene poi denitivamente applicato nel contesto reale. Questo ambiente di programmazione può essere utilizzata con successo come strumento didattico nei corsi di controlli automatici, in modo tale da permettere agli studenti di testare i loro controllori digitali.

40 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 32 In [12] è stata presentata un'architettura simile mentre un'applicazione basata su RTAI per la simulazione di sistemi dinamici è stata derivata dal modello di Modelica [8] dell'impianto. Sia la piattaforma CACSD Scilab/Scicos che quella Matlab/Simulink possono essere utilizzate per la progettazione dei controller digitali perchè permettono di ottenere applicazioni di controllo real-time pronte per l'utilizzo con il supporto delle librerie RTAI-Linux e di Comedi. In ogni caso, è estemamente importante accertarsi che l'esecuzione dell'algoritmo usato per risolvere le equazioni dierenziali del sistema sotto test sia a tempo reale. Per questo motivo, si può usare la libreria scientica GNU [13] e siccome è opensource può fornire tutte le funzioni necessarie per l'implementazione degli algoritmi di simulazione Ulteriori scenari applicativi La domotica rappresenta per tutti una comodità (ma per altri può costituire anche una necessità) al ne di migliorare la qualità della propria vita, permettendo di avere maggiore sicurezza, gestendo a distanza apparecchi domestici e funzionalità, demandando funzioni e comandi, ecc. In questa parte si intende proporre alcuni scenari applicativi dei RTOS totalmente nuovi riguardo la gestione integrata di tutte le funzionalità (comandi, controlli, visualizzazioni, sensori, allarmi, ecc) richieste da un moderno Sistema-casa, al ne, come già citato, di migliorare la qualità della vita di chi vi abita. Il tutto rappresenta infatti un'applicazione reale e concreta sull'utilizzo dell'informatica e dei sistemi di comunicazione wireless relativa ad edici di varia destinazione.

41 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 33 Lo studio, lo sviluppo e la realizzazione del progetto non sono solo - nalizzati all'ottenimento di una gestione eciente ed innovativa dell'edicio rappresentato per esempio, da unità abitative, condomini, uci, ospedali, scuole, istituzioni, ma anche a rispondere alle varie esigenze che possono presentare determinate categorie di persone (per esempio anziani, malati, persone diversamente abili, ecc). L'innovazione della soluzione proposta è basata sulla comunicazione totalmente wireless (senza li) che le varie funzioni ed applicazioni del sistema complessivo utilizzano, per un continuo scambio di informazioni (dati) in tempo reale. Nasce quindi la possibilità di nodi (punti) mobili (considerando il nodo come interfaccia fra il sistema wireless e l'applicazione reale), che possono permettere all'utente (persona sica), non solo di essere costantemente informato sulla attuale situazione del proprio Sistema-casa (per esempio attraverso display, touch-screen, palmari, cellulari, ecc), ma anche di gestire attraverso semplici comandi, tutte le funzioni domestiche (e non) del sistema-casa complessivo, dovunque ci si trovi. Una casa sicura implica fondamentalmente un maggiore grado di autonomia anche solo tramite tradizionali controlli, quali per esempio, antiintrusione, controllo perdite di gas ed il suo relativo utilizzo corretto (per es. fornelli e forni che si spengono automaticamente dopo un tempo massimo), allarme antincendio, controllo temperatura e umidità (riscaldamento e condizionamento), elettrodomestici che si spengono se non usati o se accesi per troppo tempo (per es. ferri da stiro, caettiere, ecc), controllo perdite d'acqua, ecc.

42 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 34 Figura 1.3.2: Applicazioni pratiche inerenti alla domotica Come già accennato in precedenza, oltre che una comodità l'automatizzazione di alcune funzioni nella casa può diventare una necessità, in caso di malattia e disabilità e può consentire al tempo stesso anche un notevole risparmio energetico: per esempio luci che si accendono e si spengono da sole seguendo la presenza dell'utente, porte e nestre automatizzate che si possono gestire con comandi facilmente azionabili dall'utente (da palmari, da cellulari, attraverso comandi vocali, rilevatori di presenza, ecc), pensili della cucina motorizzati che si adattano all'esigenza di chi li utilizza, elettrodomestici intelligenti che si attivano con maggiore frequenza quando la taria, relativa al consumo energetico, è ridotta, controlli di caldaie/condizionatori automatizzati che regolano la temperatura secondo le preferenze dell'utente ottimizzando i consumi, collegamenti con centri di assistenza centralizzati per aumentare l'autonomia degli utenti implementando, quando è possibile, l'assistenza remota. La g illustra schematicamente alcune di queste

43 CAPITOLO 1. I SISTEMI OPERATIVI REAL-TIME E LINUX 35 funzioni di base citate (Sistema-casa).

44 Capitolo 2 Soluzioni real-time per il kernel Linux 2.1 Linux e le applicazioni real-time Lo sviluppo e la diusione 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 ore notevoli vantaggi in termini di costi, essibilità, 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 quindi 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 36

45 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 37 a Unix e il suo target principale sono sempre stati i server e recentemente i computer desktop. Linux è stato sempre utilizzato in ambito scientico anche per sistemi embedded, ma non è mai stato sviluppato con la nalità di essere un sistema operativo veramente real-time. Recentemente si è quindi cercato di trovare soluzioni nalizzate ad avvicinare il sistema operativo Linux al mondo realtime, 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 eettua lo scheduling non troppo frequentemente) riesce a limitare questo overhead, dall'altra esso rende molto dicile, 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

46 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 38 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 ad 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 [14, 15]. 2.2 Caratteristiche RT del Kernel Linux Come detto, 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 è parzialmente orientato lo sviluppo del Kernel Linux nella direzione dei sistemi real-time, tanto che alcuni deniscono 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 approfonditi nel seguito. L'interesse per l'utilizzo di Linux in sistemi real-time ha portato alla nascita di diversi progetti nalizzati 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

47 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 39 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 tipo di approccio (mostrato nella Fig ) cerca quindi di rendere il Kernel Linux maggiormente orientato ad applicazioni real-time andando a modicare il Kernel stesso negli aspetti caratteristici dei sistemi operativi real-time. In particolare si cerca di modicare il comportamento dello scheduler e le caratteristiche di preemption sui processi. Figura 2.2.1: Struttura di un sistema operativo basato sul primo approccio (sinistra) e sul secondo approccio (destra) 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à.

48 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 40 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 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 modiche 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 compiere il suo compito considerando le richieste dei processi RT e deve svolgere il suo compito 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 ad 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: 1. Scheduler O(N): questo scheduler suddivide il tempo in epoche che sono periodi in cui ogni task può utilizzare il proprio timeslice. I

49 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 41 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 denire 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 ad 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 massimo 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ì suciente individuare la prima lista contenente 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 ad un altro, deve essere gestita in modo da garantire che un processo RT riesca ad ottenere la disponibilità delle risorse in un tempo utile ad eseguire correttamente (sia dal punto di vista logico che, soprattutto, temporale) la propria elaborazione.

50 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 42 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 che vengono 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. Per ovviare a questi problemi sono state preparate delle patch per il Kernel, in parte poi adottate anche nel Kernel Linux 2.6 uciale. Le principali patch realizzate per agevolare la preemption nel Kernel Linux sono: ˆ Preemption Patch: questa patch consiste nel permettere che lo scheduler venga eseguito e che un task perda il controllo anche mentre si trova ad eseguire del codice appartenente al kernel. Ovviamente un task può essere interrotto solo quando esegue quelle sezioni del kernel in corrispondenza delle quali la preemption può eettivamente avere luogo senza traumi. ˆ Low-Latency Patch: questa patch consiste semplicemente nel modi- care il kernel spezzando i loop nel codice ed inserendo delle chiamate allo scheduler per aumentare il numero di punti di preemption. Questa patch pertanto richiede cambiamenti piuttosto pesanti e diusi. Questa patch 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 (no 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.

51 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 43 Il Kernel RT di basso livello gestisce direttamente i processi real-time e tratta il Kernel Linux come un processo a bassa priorità. Figura 2.2.2: Struttura di una soluzione real-time Linux con l'uso di un Kernel RT 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 se 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 tipo di approccio sono Xenomai e RTAI, sviluppati rispettivamente dal progetto DENX ( org) e dal DIAPM (Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano,

52 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX Xenomai Adeos pipeline Xenomai basa il suo funzionamento sul layer di virtualizzazione Adeos che è disponibile come patch del kernel. Adeos abilità entità multiple, chiamate anche domini, che permettono di poter avere sullo stesso hardware un ambiente GNU/Linux e un RTOS perfettamente funzionanti. Tutti i domini 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 e exception, a seconda della priorità che è stata loro ssata. Oltre alla virtualizzazione, Adeos consente di esportare ai domini un'api generica indipendente dall'architettura della CPU. La struttura di Adeos può essere vista come una catena di domini 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 noticato quando si vericano 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 ad esempio lo switch o l'uscita dei task di Linux e la notica di segnali Adeos assicura che gli eventi siano inviati in maniera ordinata ai vari domini secondo il rispettivo ordine di priorità nel sistema in modo da assicurare consegne tempestive e predicibili di tali eventi. Quanto detto si ottiene

53 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 45 Figura 2.3.1: Schema dell'astrazione introdotta dalla pipeline Adeos appunto tramite l'assegnazione di una priorità statica a ogni dominio tramite la quale viene determinato l'ordine di consegna degli eventi a tutti i domini. I domini attivi si trovano accodati secondo la loro priorità realizzando così l'astrazione della pipeline utilizzata da Adeos per ottenere un usso di eventi ordinato dal dominio a priorità maggiore 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 no all'ultimo dominio esistente, quello a priorità più bassa. Nella gura viene illustrata una rappresentazione generica di un sistema basato su Adeos in cui si possono osservare più domini 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 domini 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 signica che il successivo interrupt in arrivo non sarà consegnato all'handler del dominio e allo stesso tempo gli sarà impedito di scorrere verso i domini di priorità inferiore. Quando uno stadio si trova in stallo gli interrupt pendenti sono accumu-

54 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 46 Figura 2.3.2: Gestione di Adeos su domini multipli con n CPU lati nel log degli interrupt del dominio e eventualmente elaborati una volta rimosso lo stato di stallo dall'operazione interna di sincronizzazione. I domini 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 signica 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 nisce di processare gli interrupt pendenti che ha ricevuto richiama un servizio di Adeos che porta la CPU al dominio successivo della pipeline così che quest'ultimo possa processare i propri interrupt e così via no al dominio che si trova nell'ultima posizione della pipeline. Nella Fig viene illustrato il modo in cui diversi domini eseguiti

55 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 47 su CPU multiple condividono gli interrupt in arrivo attraverso l'astrazione della pipeline introdotta da Adeos. Risulta evidente che si deve mantere una corretta memorizzazione degli 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ò uire 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 notiche sincrone di trap, exception o di alcune azioni del kernel Linux che sono noticate attraverso la pipeline. Dal momento in cui questi eventi sono sincroni per denizione, non c'è alcun modo di ritardare la loro notica tramite l'operazione di stallo non essendo possibile ritardare 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 signicato solo per quanto riguarda gli interrupt reali o virtuali Adeos e Xenomai Tutte le caratteristiche di Adeos elencate no ad 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

56 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 48 Figura 2.3.3: Architettura di Xenomai 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. Inoltre Xenomai deve anche assicurarsi di raorzare la priorità di gestione dei propri thread anche quando questi si trovano in esecuzione in altri domini. 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 gura si può notare la posizione di Adeos che risulta direttamente a contatto con l'hardware Abstraction Layer (HAL) che si trova al di sotto del nucleo di Xenomai. Molte delle richieste per i servizi Adeos sono diramate proprio da quest'ultimo I domini 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

57 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 49 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 dierenza di quello realizzato dal sistema RTAI/LXRT, si può denire simbiotico. Infatti i thread di Xenomai possono andare in esecuzione non solo nel dominio di più alta 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. Anchè 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 n 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ò signica 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 eettiva priorità sia più alta. 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 quest'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 verica 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 così che 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 ad occupare nella pipeline la posizione tra il kernel real-time e il

58 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 50 Figura 2.3.4: Interrupt shield kernel Linux (Figura 2.3.4). 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 eettuata per una determinata applicazione o in fase di compilazione di Xenomai marcando l'opportuna ag di congurazione. ˆ 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 così che si possa schedulare in tempi rapidi un thread di Xenomai che ha eettuato 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 benecia dei continui miglioramenti riguardo la prelazione del kernel come ad esempio l'estensione PREEMPT_RT di Ingo Molnar [19]. Ovviamente i thread di Xenomai che vanno in esecuzione in modalità primaria non sono aetti dal livello di granularità del kernel e beneciano 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 incodizionatamente. ˆ Gestione dell'inversione di priorità: Sia il kernel real-time che 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 di quanto detto, quando il kernel di Xenomai viene caricato, la pipeline Adeos contiene tre stadi attraverso i quali uiscono tutti

59 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 51 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 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 domini 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 eettuata sotto il controllo del dominio appropriato eettuando se necessario una migrazione del chiamante al dominio richiesto senza nessuna interruzione. Ad 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 sia 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 così che il thread possa andare in sleep sotto il controllo del kernel real-time. Linux. In questo modo si riesce un'ottima integrazione dei thread Xenomai in

60 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL 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 domini della pipeline. Ricevuta la notica dell'arrivo di un interrupt, il kernel real-time eettua 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 connante nella pipeline La scelta della modalità di propagazione è settata all'interno di ciascuno dominio. Per qual 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 denito l'handler per un dato interrupt, questo viene propagato incondizionatamente al kernel Linux mantenendo quindi il sistema funzionante Installazione di Xenomai su x86 Il primo passo da intraprendere per l'installazione di Xenomai sul kernel vanilla è il recupero dei sorgenti dal sito uciale 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

61 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 53 La versione utilizzata in questa tesi è la anche se al momento esistono aggiornamenti di Xenomai no alla versione 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 dal sito http: // Per l'installazione su x86 è stato utilizzato il kernel Sempre con il comando tar si eettua 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 specica il percorso della cartella dove sono stati i estratti i sorgenti del kernel vanilla, nel nostro caso la cartella /usr/src/linux adeos indica il percorso in si trova la patch adeos da applicare sulla cartella del kernel. arch specica l'architettura del target. Congurazione e preparazione del kernel Terminata la fase di preparazione dei sorgenti del kernel, bisogna creare il le di congurazione. Questo può essere fatto tramite una congurazione

62 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 54 graca tramite il comando make menucong o in alternativa make xcon- g/gcong. Utilizzando il primo dei comandi appena elencati ci si trova di fronte alla seguente schermata: Figura 2.3.5: Schermata del menucong Per chi abbia già compilato un kernel Linux è facile notare immediatamente una nuova voce nel menu di congurazione ovvero la sezione Realtime sub-system che comprende tutte le funzionalità relative al nano-kernel di Xenomai. Esplorando il contenuto del sottomenu si trovano varie opzioni di congurazione come l'inclusione delle nuove classi di scheduling (es. Sporadic Server), supporto per il debug, abilitazione delle varie interfacce di programmazione (POSIX, VxWorks, psos), settaggio dei watchdog ed altre impostazioni da valutare secondo le proprie necessità. Per quel che riguarda le altre impostazioni del kernel, si può procedere col disattivare le parti relative all'hardware che non verrà utilizzato come ad esempio i moduli realtivi alle interfacce per Joystick, Touchscreen, etc.

63 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 55 Per quel che riguarda le altre impostazioni del kernel bisogna controllare che alcune voci siano attive e si devono disabilitare alcune funzionalità che possono compromettere le prestazioni in termini di latenza del real-time kernel. Esaminando nel dettaglio si deve fare attenzione alle seguenti voci del menu di congurazione: ˆ 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. Vericare 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 congurazione si deve uscire dall'interfaccia graca e salvare le modiche. A questo punto nella source tree del kernel sarà disponibile il le.cong con tutte le informazioni relative alla congurazione appena eettuata. 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 ovvero quello di creare dei pacchetti.deb così da avere disponibile l'installazione del kernel patchato per qualunque altra macchina con architettura x86.

64 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 56 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 è molto 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=x dove x indica il numero di processori che si vogliono dedicare alla compilazione del kernel. Terminata la compilazione si hanno a disposizione di le, uno relativo all'immagine della source tree del kernel e uno contenente i vari header. Nel nostro caso particolare avremo a che fare con i seguenti le: ˆ linux-image xenomai deb ˆ linux-headers xenomai deb Per installare i pacchetti si utilizza il comando dpkg specicando l'opzione -i. Con questa procedura viene installata l'immagine del kernel con i relativi headers e si aggiorna il bootloader (nel nostro caso il grub). Riavviando il sistema, in fase di avvio sarà ora visibile la voce del kernel xenomai Per controllare che l'installazione sia andata a buon ne si può ltrare la voce Xenomai dal contenuto dei messaggi del buer del kernel:

65 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 57 dmesg grep -i xenomai Il risultato prodotto è il seguente: Figure 2.3.6: Messaggi in fase di avvio di Linux relativi al nanokernel Xenomai L'ultimo step da eseguire è l'installazione del supporto user-space di Xenomai. Questo si realizza tramite l'esecuzione dello script congure presente nella cartella /usr/src/xenomai. Una veloce verica della buona riuscita dell'installazione si può avere mandando in esecuzione alcuni dei test forniti con Xenomai. Nella cartella /usr/xenomai/bin si possono trovare una serie di binari da avviare che realizzano una serie di test sul sistema appena installato. 2.4 RTAI (Real Time Application Interface) Struttura e funzionamento di RTAI La losoa implementativa adottata da RTAI è già stata presentata nei paragra precedenti. Nel caso di RTAI lo strato software aggiunto a basso livello è chiamato RTHAL (Real-Time Hardware Abstraction Layer) o RTAI_HAL. RTHAL racchiude in un'unica struttura tutti i dati e le funzioni del kernel temporalmente critiche: permette di catturare facilmente le funzionalità del kernel (interrupt, system call, timer) per poterle gestire in accordo a po-

66 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 58 Figura 2.4.1: Schema della struttura di RTAI litiche real-time. Per sfruttare l'astrazione software creata da RTHAL, si sostituiscono le operazioni sulle strutture originali con operazioni su puntatori RTHAL. Questi puntatori sono aggiornabili dinamicamente in modo da farli puntare alle strutture Linux se RTAI è disattivato oppure alle strutture del Kernel RT quando RTAI è attivo. In questo modo inoltre Linux non ha più il controllo sull'abilitazione e sulla disabilitazione delle interruzioni. In termini stretti RTHAL non è il kernel RT, ma è solo l'oggetto che si occupa di intercettare le chiamate al kernel Linux. I possibili scenari sono quindi due: ˆ RTAI non attivo: normale funzionamento di Linux. ˆ RTAI attivo: solo le funzionalità RT possono accedere direttamente all'hardware. Linux è gestito dallo scheduler RT di RTAI come un processo a bassa priorità. Grazie a questo semplice meccanismo di swap di puntatori è possibile attivare e disattivare RTAI con il sistema in funzione senza alcun problema.

67 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 59 Figura 2.4.2: Schema della struttura di ADEOS RTAI è fornito sotto forma di moduli del kernel, potendo così estendere le funzionalità del kernel Linux in maniera assolutamente dinamica senza dover essere necessariamente caricato al boot del sistema. Le funzionalità di RTAI sono suddivise in diversi moduli, che saranno da caricare in base agli strumenti utilizzati dall'utente. Successivamente è stata proposta un'evoluzione del progetto chiamata ADEOS (Adaptive Domain Environment for Operating Systems), sempre basata sull'idea di avere uno strato software che intercetta le chiamate al sistema operativo, che estende le funzionalità viste di RTAI (vedi Fig ): lo scopo di questa evoluzione è quello di fornire un ambiente essibile per condividere risorse hardware tra più sistemi operativi o tra più istanze di uno stesso sistema operativo. Tale sistema è realizzando adottando un microkernel che gestisce la comunicazione tra i diversi domini (sistemi operativi) presenti. La gestione delle interruzioni è implementata con uno schema a pipeline in cui ogni stadio rappresenta un dominio: ogni interruzione viene propagata nella pipeline ed ogni stadio può accettare l'interrupt e gestirlo, ignorarlo, propagarlo, scartarlo, etc.

68 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 60 Figura 2.4.3: Schema della gestione a pipeline delle interruzioni Il meccanismo di ADEOS racchiude tutto quello che RTAI realizzava con RTHAL. Installando RTAI come dominio a massima priorità per ADEOS e Linux in uno stadio a priorità minore si ottiene che RTAI gestisce gli interrupt prima del Kernel Linux ed opera in accordo con le esigenze dei processi real-time [16]. Come è già stato accennato precedentemente, RTAI non rispetta pienamente lo standard POSIX, ma supporta parzialmente solo gli standard 1003.c (pthread, mutex) e 1003.b (pqueue) LXRT I processi RTAI nativi sono eseguiti in kernel mode e pertanto le API originali di RTAI sono utilizzabili solo dai moduli del kernel. LXRT è uno strumento che permette di sviluppare processi real-time usando le API RTAI da user space: con LXRT si è quindi cercato di mantenere simmetria tra le API in kernel space e quelle in user space. L'utilizzo di LXRT permette un passaggio più graduale dai processi Linux ai processi real- time e una maggiore protezione dell'hardware in quanto in kernel space si può accedere liberamente alla memoria di sistema. L'utilizzo di LXRT risulta molto utile in fase di test e prototipazione, ma è meno eciente rispetto alla programmazione in kernel space. Un processo real-time può essere quindi realizzato con due dierenti modalità: esso può essere scritto sotto forma di modulo del kernel (eventualmente eettuando in kernel space solo i compiti prettamente RT e lasciando

69 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 61 eseguire ad un processo non RT le operazioni secondarie come il trattamento e la stampa dei dati) oppure come processo user space utilizzando le funzionalità fornite da LXRT Scheduling in RTAI RTAI permette una gestione full-preemptable dei processi, in funzione delle loro priorità [16]. La congurazione dello scheduler in RTAI dipende da tre fattori: 1. Numero di processori 2. Modalità di funzionamento dello scheduler 3. Politica di scheduling Il numero di processori presenti nel sistema determina la scelta di quale modulo del Kernel caricare: ˆ Uniprocessor Scheduler (UP): utilizzabile nei sistemi monoprocessore. ˆ Symmetric Multiprocessor Scheduler (SMP): in un sistema multiprocessore permette di ottenere una distribuzione di carico simmetrica. Per ottimizzare l'esecuzione permette di associare un certo processo ad una singola CPU o ad un insieme ristretto di esse. ˆ Multi Uniprocessor Scheduler (MUP): in un sistema multiprocessore impone ad ogni processo l'esecuzione su una singola CPU stabilita al momento della creazione del processo. Meno essibile, ma più eciente di SMP. La modalità di funzionamento dello scheduler riguarda la temporizzazione con cui lo scheduler viene eseguito: ˆ Periodic mode: esegue lo scheduler periodicamente al termine di un periodo pressato: il timer viene settato una sola volta all'inizio dell'esecuzione. Il periodo dei processi deve essere multiplo esatto del periodo dello scheduler, in caso contrario il periodo dei processi è approssimato al multiplo del periodo dello scheduler più vicino (introduce un jitter di attivazione).

70 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 62 ˆ One-shot mode: Lo scheduler viene eseguito in maniera non periodica. Il timer deve essere settato ogni volta in base al processo più prioritario che andrà in esecuzione. Permette una gestione più essibile delle temporizzazioni di tutti i processi a costo di un maggiore overhead dovuto alla necessità di riprogrammare il timer al termine di ogni periodo. La politica di scheduling riguarda come viene eettuata la scelta del processo da mandare in esecuzione: ˆ FIFO: il processo attivo a priorità più alta ottiene il controllo della CPU no a quando la rilascia volontariamente oppure diventa attivo un processo a priorità maggiore ˆ Round-Robin (RR): il processo attivo a priorità più alta ottiene il controllo della CPU per un determinato intervallo di tempo, al termine del quale il controllo passa ad un altro processo allo stesso livello di priorità (se presente). Un processo può subire preemption da parte di un processo a priorità maggiore Inter-Process Communication (IPC) in RTAI RTAI fornisce diversi strumenti per la comunicazione inter-processo, anche per la comunicazione tra processi RT e processi Linux [16]. Gli strumenti di IPC disponibili in RTAI sono: ˆ FIFO real-time: Meccanismo di base per scambiare dati in modo asincrono tra processi real-time e processi Linux non real-time ˆ Shared memory: Condivide aree di memoria tra processi RT e processi Linux ˆ Messaggi: Possibilità di inviare messaggi sia in maniera asincrona che sincrona (RPC) tra processi RT ˆ Mailboxes: Permettono di inviare/ricevere messaggi di qualsiasi dimensione, ordinati per priorità o per istante di arrivo, tra processi RT e processi Linux ˆ Semafori: Permettono di sincronizzare i processi nell'accesso a risorse condivise evitando inversioni di priorità incontrollate Struttura di un modulo del kernel RTAI La struttura di un modulo RTAI base è molto semplice e non si discosta molto da un qualsiasi modulo del kernel [16]. Nella Fig si riporta l'esempio di un modulo RTAI base:

71 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 63 # include <rtai.h> # include < rtai_sched.h>... RT_TASK * task ;... void task_routine () { while (1) { /* Codice real - time */ rt_task_wait_period (); } }... int init_module ( void ) { rt_task_init (& task, task_routine, 0, stack_size, priority, 0, 0); timer_period = start_rt_timer ( nano2count ( le9 )); task_period = 2* timer_period ; rt_task_make_periodic (& task, now, task_period ); } void cleanup_module ( void ) { rt_task_delete (& task ); stop_rt_timer (); } Figura 2.4.4: Esempio di un modulo RTAI Il modulo è costituito da una funzione init_module() e una cleanup_module() (presenti in tutti i moduli del kernel) oltre che dalla funzione task_routine() che denisce la routine real-time Struttura di un processo RTAI LXRT La scrittura di un processo real-time RTAI in user space comporta l'utilizzo degli strumenti forniti da LXRT [16]. Di seguito si riporta l'esempio di un processo RTAI LXRT:

72 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 64 # include < rtai_lxrt.h>... int main ( void ){ // Inizializzazione del processo RT_TASK * task ;... sched_setscheduler (0, SCHED_FIFO, & priorità ); mlockall ( MCL_CURRENT MCL_FUTURE ); task = rt_task_init ( nam2num (" Name ")), priority, stack_size, 0); timer_period = start_rt_timer ( nano2count ( le9 )); task_period = 2* timer_period ;... // Parte real - time rt_make_hard_real_time (); rt_task_make_periodic ( task, now, task_period ); while (1) { /* Codice real - time */ rt_task_wait_period (); } // Terminazione del processo rt_make_soft_real_time (); rt_task_delete ( task ); return 0; } Figura 2.4.5: Struttura di un processo RTAI LXRT Il codice può essere suddiviso, da un punto di vista logico, in tre parti: 1. Inizializzazione del processo 2. Parte real-time 3. Terminazione del processo Installazione di RTAI su x86 L'installazione di RTAI non è particolarmente complessa anche se, ovviamente, comporta l'applicazione di una patch al kernel Linux e la conseguente ricompilazione dello stesso. Il processo di installazione di RTAI su un sistema Linux è costituito dai seguenti passi: ˆ scaricare i sorgenti di un kernel uciale vanilla ( ˆ scaricare una versione di RTAI contenente la patch per la versione di kernel posseduta (

73 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 65 ˆ applicare la patch di RTAI ai sorgenti del kernel scaricato lanciando, dalla cartella radice dei sorgenti, il comando: patch p1../<percorso_patch>/<nome_patch>.patch ˆ congurare il kernel (i particolari sulla congurazione sono riportati di seguito) ˆ compilare ed installare il kernel ˆ congurare RTAI (i particolari sulla congurazione sono riportati di seguito) ˆ compilare ed installare RTAI (l'installazione si eettua semplicemente con make install) Per congurare il kernel basta lanciare make menucong dalla cartella radice dei sorgenti e settare le seguenti opzioni: ˆ Processor type and features Use register arguments OFF ˆ Processor type and features Interrupt pipeline ON ˆ Loadable module support Module versioning support OFF Per congurare RTAI basta lanciare make menucong dalla cartella radice dei sorgenti e settare il percorso della cartella radice dei sorgenti del kernel a cui è stata applicata la patch [16].

74 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX RT_PREEMPT Preemption Patch La preemption patch nasce dall'osservazione che era possibile eettuare, in modo sicuro, la prelazione di processi in esecuzione in kernel mode, se questi non stavano eseguendo nessuna sezione critica protetta da spinlock 1 [17]. La patch, introdotta durante lo sviluppo di quello che sarebbe diventato il ramo stabile del kernel 2.6 è attualmente mantenuta da Robert Love. La preemption patch rende il kernel prelazionabile, permettendo la sospensione del task che in un determinato momento è in kernel mode se un altro task con priorità superiore è pronto per essere eseguito. É stato osservato che grazie alla patch i tempi medi di latenza subiscono un netto miglioramento, riducendosi a circa 1 ms e migliorando la responsitività complessiva del sistema [18]. Per poter eettuare la prelazione del kernel, è stata modicata la struttura che descrive il processo, introducendo il membro preempt_count. Se preempt_count è zero allora il kernel può essere prelazionato senza rischi, se la variabile ha un valore diverso da zero allora la prelazione non è possibile. Per operare su preempt_count sono state introdotte due macro: preempt_disable e preempt_enable, la prima disabilita la prelazione incrementando preempt_count, la seconda decrementa il valore di preempt_count e quando questa raggiunge lo zero allora la prelazione è abilitata. Le routine di spinlock sono state modicate in modo tale da chiamare la macro preempt_disable in entrata e chiamare preempt_enable in uscita. 1 Gli spinlock sono utilizzati per realizzare la mutua esclusione attraverso un lock busywait. Quando il lock è libero, un thread può occuparlo, operare in modo esclusivo, e quindi rilasciato. Se il lock non è libero, il thread deve attendere nché non diventa disponibile.

75 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 67 Analogamente è stato modicato il codice assembly relativo al ritorno da una interrupt o da una chiamata di sistema per esaminare il contenuto di preempt_count prima di decidere se eettuare o meno una nuova schedulazione Low Latency patch La Low-Latency patch [17], scritta da Ingo Molnar e attualmente mantenuta da Andrew Morton, aronta il problema della riduzione della latenza dello scheduler inserendo dei punti di schedulazione all'interno dei blocchi di codice del kernel eseguiti per lungo tempo. Periodicamente, in corrispondenza dei punti di schedulazione, il kernel verica se un qualche processo a priorità superiore di quello che è attualmente running ha richiesto di essere schedulato. I blocchi di codice identicati per l'inserimento dei punti di schedulazione sono i cicli su grosse strutture dati. Il task che ha bisogno di essere schedulato setta la variabile need_resched. Per poter identicare in quali blocchi di codice poter inserire i punti di schedulazione, Morton ha scritto una apposita patch, la rtc-debug patch, per il driver del clock real time. Quando la latenza dello scheduler supera una determinata soglia, viene scritto sul le del log di sistema il contenuto dello stack, in modo tale da poter identicare la routine che ha causato la latenza. Questa patch fornisce i risultati migliori se utilizzata congiuntamente alla preemption patch [17, 20, 21] Scheduler O(1) Il numero di cicli impiegati dallo scheduler per stabilire quali task mandare in esecuzione, per quanto a lungo e su quale CPU, in caso di macchine

76 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 68 multiprocessore, insieme al tempo impiegato a compiere il contex switch sono direttamente proporzionali al numero di processi presenti nel sistema. Figura 2.5.1: Struttura delle code dello scheduler O(1) Maggiore è il numero dei processi, maggiori saranno le latenze introdotte dallo scheduler. Il classico scheduler O(n) è stato sostituito dallo scheduler O(1) sviluppato da Ingo Molnar. Lo scheduler O(1) impiega sempre un lasso di tempo costante sia per schedulare il prossimo processo sia per eettuare il contex switch, rendendosi di fatto indipendente dal carico del sistema. L'algoritmo implementa due code, una per i processi attivi e l'altra per i processi expired (vedi Fig ). I processi real time condividono tutti la stessa coda. Entrambe le code sono ordinate in base alla priorità, per ognuna delle quali è mantenuta una lista dei processi pronti ad essere eseguiti. Gli indici delle code sono mantenuti in una bitmap, in questo modo la ricerca del processo a priorità più alta si riduce ad una ricerca O(1). Quando un processo ha esaurito il proprio quanto di tempo è spostato nel vettore dei processi expired e contemporaneamente il suo quanto è ripristinato. Nel momento in cui la coda dei processi attivi è vuota, lo scheduler inverte le due code, facendo diventare attiva la coda expired e viceversa,

77 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 69 quindi procede alla schedulazione del processo a priorità più alta. Tutte queste operazioni sono molto veloci essendo compiute su puntatori. Lo scheduler O(1) ha il pregio di operare sempre su code ordinate in base alla priorità dei processi, in questo modo non sarà necessario scorrere liste composte da n processi alla ricerca di quello a priorità maggiore da mandare in esecuzione. Lo scheduler O(1) elimina di fatto il goodness loop e il recalculation loop. Il goodness loop indica il ciclo che lo scheduler deve eettuare per scorrere la lista dei processi pronti alla ricerca del task a priorità più alta da mandare in esecuzione. Con recalculation loop si indica invece il ciclo da eettuare sui processi che hanno esaurito il loro quanto di tempo ed hanno bisogno che venga ricalcolato. Entrambi questi cicli dipendono dal numero di processi (real time o meno) presenti nel sistema. Lo schedulatore, inne, riconosce 140 livelli di priorità, di questi i primi 100 sono occupati dai processi real time i rimanenti 40 sono dedicati ai processi time sharing (Fig ). Per poter denire un task real time in linux bisogna considerare tre parametri: ˆ Scheduling Class ˆ Priorità del processo ˆ Timeslice Scheduling Class: Linux ore tre classi di schedulatore, due relativi a processi real time, uno per processi non real time. Le tre classi sono: ˆ SCHED_FIFO: Implementa la politica First In First Out per i processi real time. Un processo gestito con questa politica rimarrà running ntanto che non si bloccherà su di una operazione di I/O, non sarà prelazionato da un processo a priorità più alta o non rilascera volutamente la CPU. Se il processo è prelazionato da un altro processo di priorità più alta, sarà inserito in testa alla lista dei processi aventi la

78 CAPITOLO 2. SOLUZIONI REAL-TIME PER IL KERNEL LINUX 70 sua stessa priorità, in modo tale da essere schedulato per primo quando il processo che lo ha prelazionato terminerà la sua esecuzione. Alla ne dell'esecuzione il processo è inserito in coda alla lista dei processi aventi priorità identica alla sua. ˆ SCHED_RR: La politica implementata dallo schedulatore real time Round Robin è simile a quella implementata dallo scheduler SCHED_FIFO, con la dierenza che i processi possono essere running solo per un quanto di tempo. Terminato il quanto il processo è prelazionato ed è inserito in coda alla lista dei processi con la sua priorità. Se il processo è prelazionato da un processo con priorità più alta, sarà schedulato di nuovo per poter terminare il quanto di tempo, non appena il processo che lo ha prelazionato termina. ˆ SCHED_OTHER: In questa classe si colloca il classico schedulatore time-sharing di linux, utilizzato per i processi non real time. Priorità: I processi non real time, gestiti con la politica time-sharing, hanno una priorità pari a zero. I processi real time, sia che siano schedulati con SCHED_FIFO che con SCHED_RR, hanno una priorità che varia in un range tra 1 e 99. Maggiore è il numero assegnato, maggiore è la priorità. I processi real time hanno quindi sempre una priorità maggiore di quella dei processi time sharing. La priorità dei processi real time può essere manipolata tramite le funzioni sched_getparam e sched_setparam, la prima setta la priorità, la seconda la legge. Queste funzioni sono ininuenti se chiamate su processi time sharing. TimeSlice: É l'intervallo di tempo assegnato al processo running prima che venga prelazionato. Questo valore ha eetto solo se si usa la politica SCHED_RR. Un processo gestito con politica SCHED_FIFO, teoricamente, potrebbe rimanere running all'innito, nché non decide di rilasciare la CPU [17].

79 Capitolo 3 Porting di Xenomai ed RTAI su ARM Il porting di un sistema embedded Linux si risolve spesso con una semplice ricompilazione per l'architettura target che in questo caso è un ARM9 Marvell 88F628; tale scelta è stata fatta per puri scopi didattici e dimostrativi, in modo tale da confrontare sia l'ecenza computazionale che la dicoltà implementativa di entrambe le soluzioni. Raramente è necessario applicare delle patch al software per poter gestire delle condizioni particolari. Il grande vantaggio di GNU/Linux è che il software che gira sui sistemi embedded è lo stesso che si trova sui desktop o sui server. Ciò permette di utilizzare una macchina host, generalmente un normale pc, più performante e dotato di risorse hardware superiori rispetto alla macchina target, il sistema embedded, per sviluppare (mediante un opportuno cross-compilatore), testare e debuggare il sistema e le applicazioni che dovranno girare su di esso e quindi trasferire il sistema nito sul target. In questo capitolo vengono inizialmente analizzati lo scenario embed- 71

80 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 72 ded ARM e le caratteristiche tecniche della board SheevaPlug utilizzata; successivamente vengono mostrate le procedure di porting per Xenomai ed RTAI. 3.1 Board Marvell SheevaPlug Architettura ARM L'architettura ARM (precedentemente Advanced RISC Machine, prima ancora Acorn RISC Machine) indica una famiglia di microprocessori RISC a 32-bit utilizzata in una moltitudine di sistemi embedded. Grazie alle sue caratteristiche di basso consumo (rapportato alle prestazioni) l'architettura ARM domina il settore dei dispositivi mobili dove il risparmio energetico delle batterie è fondamentale. Attualmente la famiglia ARM copre il 75% del mercato mondiale dei processori a 32 bit per applicazioni embedded ed è una delle più diuse architetture a 32 bit del mondo. I processori ARM vengono utilizzati in PDA, cellulari, lettori multimediali, videogiochi portatili e periferiche per computer. Importanti rami della famiglia ARM sono i processori XScale e i processori OMAP prodotti da Texas Instruments. I dispositivi ARM presentano un'architettura RISC `load and store' per parole di 16 e 32 bit, un set di istruzioni ortogonali, 37 registri di interi a 32-bit (6 registri di stato e 31 di uso generale) e 7 modi di operare (USR, FIQ, IRQ, SVC, ABT, SYS, UND). Per compensare il progetto semplice rispetto a processori della stessa epoca come l'intel e il Motorola 68020, il processore comprendeva alcune caratteristiche uniche come:

81 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM esecuzione condizionata di molte istruzioni per ridurre i salti e compensare gli stalli della pipeline; 2. le operazioni aritmetiche sono le uniche che possono alterare i registri delle esecuzioni condizionate; 3. shifter a 32 bit che può essere utilizzato in contemporanea con la maggior parte delle istruzioni senza penalizzazioni di tempo; 4. metodo di indirizzamento a indice molto potente; 5. Interrupt a 2 livelli molto veloce e semplice con un sottosistema di registi collegati che commutano. Una delle caratteristiche più interessante dei processori ARM sono 4 bit addizionali utilizzati per realizzare dei codici condizionali per ogni istruzione. Questi codici riducono i bit disponibili per l'indirizzamento, ma forniscono la possibilità di evitare salti nel caso di semplici istruzioni if. Gli ultimi 4 bit dell'operando sono quindi comparati con i con le ag del CPSR. Se questi non sono uguali l'istruzione non è eseguita e passa attraverso la pipeline come un NOP (No Operation). Un'altra caratteristica unica del set di istruzioni è la capacità di shiftare i dati durante le normali operazioni sui dati (operazioni aritmetiche, logiche e di copia di registri). Per esempio il codice C seguente a += (j 2); viene tradotto in questa unica istruzione assembly eseguita in un solo ciclo macchina ADD Ra, Ra, Rj, LSL #2 Queste caratteristiche rendono i programmi ARM normalmente più densi degli equivalenti programmi per altri processori RISC.

82 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 74 Inoltre, il processore ricorre a meno accessi alla memoria e riesce a riempire meglio le pipeline. Quindi le CPU ARM possono utilizzare frequenze inferiori a quelle di altri processori consumando meno potenza per svolgere gli stessi compiti. Un processore ARM possiede anche caratteristiche viste raramente nei proces- sore RISC come ad esempio l'indirizzamento relativo al PC (il PC negli ARM è un registro a 16 bit), indirizzamento con il pre e post incremento. Una caratteristica curiosa dei processori ARM è che, con il tempo, il set di istruzioni incrementa. I primi processori ARM (prima dell'arm7tdmi) per esempio non avevano istruzioni per caricare quantità a due bit quindi non erano in grado di gestire direttamente tipi di dati corti. I primi processori ARM di largo consumo come gli ARM7 erano basati su un disegno con pipeline a 3 stadi: fetch, decode e execute. I processori più moderni, come l'arm11, per incrementare le prestazioni, sono passati a pipeline a 5 stadi. Altri cambiamenti per incrementare le prestazioni includono un sommatore veloce e un sistema di predizione dei salti. Altra interessantissima caratteristica dei processori ARM riguarda le instrunction set presenti. Oltre al nativo ARM a 32 bit ne esistono altri due molto interessanti: il Thumb e il Jazelle. Il codice Thumb, avente istruzioni di 16 bit, è più leggero del classico ARM ma è dotato di meno funzionalità. Per esempio solo i salti possono essere condizionati e alcuni opcode non possono essere utilizzati da tutte le istruzioni. Nonostante queste limitazioni, nel caso di sistemi dotati di limitata larghezza di banda verso la memoria, il Thumb fornisce prestazioni migliori del set di istruzioni completo. Molti sistemi embedded sono dotati di un bus verso la memoria limitato e sebbene il processore possa indirizzare con 32 bit spesso si utilizzano

83 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 75 indirizzamenti a 16 bit o simili. In queste situazioni conviene creare codice Thumb per la maggior parte del programma e ottimizzare le parti di codice che richiedono molta potenza di calcolo utilizzando il set di istruzioni completo. Esistono anche due varianti del codice Thumb: il Thumb-2 il quale contiene particolari istruzioni a 32 bit, e il Thumb-2EE specicamente progettato per gestire codice per applicazioni real time. Il primo processore dotato di Thumb è stato l'arm7tdmi. Tutti gli ARM9 e le famiglie successive (incluso gli XScale) sono dotati di Thumb. Il codice Jazelle permette al processore di eseguire nativamente il Java byte code. Questa tecnologia è totalmente compatibile con il codice ARM standard e il Thumb. Il primo processore dotato di Jazelle è stato l'arm926j-s, utilizzato sui telefoni cellulari per velocizzare l'esecuzione del software e dei giochi Java. Il Jazelle aumenta per oltre il 95% le prestazioni del codice java supportando 140 istruzioni java ed emulando le restanti 94 con routine ARM Il microcontrollore come sistema embedded L'approccio odierno è quello di accostare alle solite logiche programmabili un microcontrollore o un DSP e di realizzare quindi un sistema compatto avente tutto il necessario per progettare una vasta gamma di sistemi. Tali dispositivi sono denominati SoPC (System on a Programmable Chip). I loro vantaggi sono evidenti. Primo fra tutti, il fatto di avere un microprocessore e una memoria integrati consente di velocizzare notevolmente i passi progettuali. Questi sistemi rappresentano un passo decisivo nell'elettronica moderna, eliminando di fatto la necessità di avere componenti discreti ed integrando tutto in un unico package.

84 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 76 Oramai si ha la possibilità di realizzare sistemi veramente integrati ad un costo contenuto. Le CPU embedded in Logica Programmabile al momento sono classicabili in sei categorie: ARM (ARM922T per Altera, ARM7TDMI per Triscend), PowerPC 405D (Xilinx), MIPS (Quick- Logic), 8051 (Triscend, Sidsa, Cygnal), AVR RISC (Atmel), M8C (Cypress MicroSystems). L'integrazione dei microcontrollori nelle FPGA consente di realizzare sistemi real-time ecenti. Infatti, gestire sistemi in grado di rispondere in maniera immediata a eventi imprevisti non è cosa facile, soprattutto se si utilizzano semplici FPGA che hanno forti problemi di temporizzazione (clock skew) se il progetto non è realizzato in maniera perfetta. Introdurre un microprocessore in grado di funzionare a frequenze che possono raggiungere anche i 100 MHz, consente di realizzare facilmente sistemi adabili. La necessità di avere sistemi real-time e la possibilità di avere on-chip processori veloci e memorie integrate, suggerisce l'utilizzo di veri e propri sistemi operativi in grado di gestire tutto quanto il dispositivo. Si è soliti quindi parlare di µkernel. Varie aziende del settore si sono già attivate in questo senso promuovendo i propri prodotti e realizzando kernel proprietari per i loro dispositivi. Il divario prestazionale che un tempo divideva i microcontrollori dai microprocessori si sta via via assottigliando sempre più ed è lecito supporre che tra non molti anni questo divario sarà solamente un ricordo CPU Marvell 88F6281 La CPU Marvell SoC 1 88F6281 si appoggia sulla tecnologia embedded Sheeva ed è un controller integrato ad elevate performance. Supporta 1 System on Chip

85 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 77 una core Marvell Sheeva interamente compatibile con il set di istruzioni ARMv5te con 256 KB di cache L2. Il processore 88F6281 fa parte della famiglia CPU Feroceon, ottimizzata per l'occupazione sica (dimensioni ridotte), per il basso assorbimento di potenza e per elevate prestazioni. Inoltre aggiunge ulteriori caratteristiche per ridurre i costi relativi alle parti utilizzate per la progettazione e la costruzione della CPU. Tale CPU può essere utilizzato per una vasta gamma di applicazioni come router, gateway, media server, memorizzazione dati, reti e servizi di stampa. Figura 3.1.1: Schema a blocchi della CPU Marvell 88F6281 Il SoC presenta: ˆ frequenza di clock GHz ˆ 512 MB di memoria ram DDR2/800 ˆ cache L1 16 KB+16 KB

86 CAPITOLO 3. PORTING DI XENOMAI ED RTAI SU ARM 78 Figura 3.1.2: Tipico scenario applicativo della CPU Marvell 88F6281 ˆ interfaccia per memoria DDR2 a 16 bit (con data rate no a 800 MHz) ˆ porta Ethernet Gigabit ˆ porta USB 2.0 con PHY integrato ˆ supporto per la sicurezza di rete con vari algoritmi di cifratura disponibili ˆ 2 canali TDM, interfaccie SDIO, NAND ash, SPI, TWSI e UART L'architettura innovativa presente sul chip che fornisce una connettività verso qualsiasi tipo di periferica abilita la comunicazione della board verso unità multiple; quindi in fase di progettazione è possibile creare sistemi digitali con elevata scalabilità. Inoltre tale board realizza un'elevata integrazione tra CPU e memoria che comporta elevati beneci nelle prestazioni applicative di tale prodotto.