
L’esigenza primaria di µClinux era quella di soddisfare il settore embedded dalla mancanza di una propria distribuzione Linux. La distribuzione µClinux è sottoposta ai vincoli della licenza GPL che permette la modifica del codice sorgente incluso e la sua distribuzione: nessun vincolo può essere imposto dal distributore, come nessun tipo di licenza a pagamento può essere richiesto. Chiunque può, chiedere un pagamento per il supporto tecnico o per la modifica del codice sorgente per particolari applicazioni commerciali. Questo tipo di distribuzione è l’arma vincente perché permette di adattare completamente il sistema operativo in modo che risponda perfettamente alle singole necessità.
Introduzione
µClinux contiene in sé tutte le prerogative di Linux essendo una sua derivazione. In più con µClinux si ha l’opportunità di utilizzare una versione di Linux in un settore particolare come quello dei sistemi dedicati. I suoi vantaggi possono essere così riassunti:
- µClinux è un sistema operativo multitasking;
- è possibile utilizzare una serie di protocolli di rete, con le relative librerie e driver, già presenti nella distribuzione senza dover scrivere una riga di codice per il loro supporto;
- µClinux può utilizzare diversi file system;
- il kernel di µClinux è abbastanza robusto essendo derivato dal kernel di Linux;
- ha la possibilità di disporre del codice sorgente (µClinux è distribuito secondo la GPL);
- utilizzare µClinux non comporta alcuna spesa;
- Il kernel di µClinux è modulare e non monolitico, questo permette di configurare il kernel in base alle reali necessità.
L’uso di un MMU in Linux ha impedito al sistema operativo di diffondersi nel settore embedded a bassa fascia. Questa assenza dal mondo embedded era giustificata dal fatto che Linux è un sistema operativo avanzato che fa uso dei molteplici vantaggi offerti dalla unità di gestione della memoria (MMU), tipicamente questo componente non è presente nella gran maggioranza delle applicazioni basate su microcontrollori. Il primo microcontrollore sul quale è stato eseguito un µClinux è il Motorola MC68328 è oggigiorno esistono porting di questo sistema per un gran numero di microprocessori, tra i quali anche i microcontrollori della famiglia Coldfire.
LE CARATTERISTICHE DI µCLINUX - MMU
Mentre Linux utilizza la segmentazione della memoria per gestire il concetto di memoria virtuale e fisica, µClinux, invece, è stato progettato per essere utilizzato in sistemi embedded con microcontrollori senza MMU. La prerogativa di un MMU è quella di introdurre il concetto di memoria virtuale e di paginazione. I processi sono messi in esecuzione in uno spazio d’indirizzamento logico e il MMU si occupa di tradurre i riferimenti logici, virtuali, in quelli fisici.
In questo modo viene nascosta ai processi, e quindi all’utente, la dimensione fisica dell’applicazione. L’uso di un MMU permette, per esempio, di isolare le fault di un sistema: attraverso l’uso delle partizioni fisiche si impedisce la propagazione delle fault tra le pagine e, in questo modo, si riesce a isolare le partizioni in fault. In questo contesto possiamo partizionare il nostro applicativo e riservare ad una determinata partizione le operazioni critiche: in caso di fault su una partizione si isola la partizione incriminata ma senza pregiudicare l’esecuzione complessiva. Al contrario, senza l’uso di un MMU ogni processo deve essere localizzato in memoria fisica perchè non è ammesso lo swap dei processi. Inoltre, non è nemmeno permesso l’incremento in runtime della sua memoria disponibile.
FILESYSTEM IN µCLINUX
Il sistema operativo µClinux supporta diversi tipi di file system. Un file system per un sistema dedicato deve occupare la minima quantità di memoria possibile e permettere la scrittura di dati nelle memorie di tipo non volatile. Di seguito sono riportati i file system supportati da µClinux:
- RAMFS. Si tratta di un file system che utilizza come dispositivo di salvataggio dati una parte della memoria RAM. Per utilizzare questo file system è necessario abilitare il supporto per il “RAMDISK” in fase di compilazione del kernel. Su questo tipo di file system verranno memorizzati i dati contenuti nella directory “/tmp”. La RAMDISK potrebbe avere una dimensione di 256Kbytes non formattato.
- NFS. Con la sigla “NFS” si indica il (Network File System). Si tratta di un file system remoto che permette di “montare” una cartella di un computer remoto, accessibile tramite la scheda ethernet. La directory cosi montata verrà usata esattamente come se fosse una directory locale.
- ROMFS. Si tratta di un file system di sola lettura, molto semplice, specifico per dispositivi di memoria non volatile, adattissimo all’uso su sistemi embedded per il bassissimo spreco di spazio che comporta.
- JFFS. Si tratta del Journaling Flash File System, pensato per lavorare su dispositivi di memoria non volatile come la memoria Flash. Si tratta di un file system di lettura e scrittura, che permette la scrittura di file in maniera assolutamente trasparente, senza che l’utente sia a conoscenza del particolare algoritmo utilizzato e della tecnologia in uso delle memorie flash.
USO DI µCLINUX
La variante µClinux è basata sul kernel di Linux. Il suo nome deriva dalla sua prima applicazione: con µC si vuole indicare “micro-controller”. Su queste architetture tipicamente non è presente un MMU. Lo spazio di indirizzamento è chiamato “flat”, esiste solo uno spazio d’indirizzo e corrisponde alla memoria reale, mentre se avessimo un MMU potremmo avere una insieme di spazi di indirizzamento in modalità protetta o virtuale. In mancanza di un MMU il kernel e l’applicativo condividono lo stesso spazio d’indirizzi.
Questa soluzione rende il sistema abbastanza unsafe, nel senso che, come già detto, qualsiasi applicazione può, corrompere il kernel. In queste particolari macchine la soluzione µClinux può rappresentare una valida soluzione. La compilazione del kernel µClinux non risulta essere particolarmente difficile e si basa sulla procedura di Linux, utilizzando lo stesso compilatore. Alcuni problemi potrebbero sorgere in fase di compilzione delle applicazioni: in questo caso è necessario intervenire sull’ambiente cross. La cross-factory GNU produce un file di tipo ELF, in un file del genere l’address space inizia da 0x0: questo va senz’altro bene se avessimo un MMU. Un file binario, invece, utilizzato da µClinux ha un formato chiamato flat, bFLT. Per risolvere il problema degli spazi di indirizzamento si procede in questo modo: nel file viene messa una tabella, contenente una lista di offsets rispetto al segmento testo e un indirizzo relativo è aggiunto durante la fase di compilazione. Quello che occorre fare è aggiungere l’indirizzo di base nella lista delle entry in tabella al momento del caricamento in memoria in fase di bootstrap. La tool chain utilizzata può essere così una derivazione di quella GNU. È anche possibile utilizzare un tool esterno che sia in grado di processare tutti gli indirizzi in tabella per crearne una equivalente, ma rilocata durante la fase di linking dell’applicazione. Un tool di questo tipo è elf2flt.
Inoltre, per scrivere applicazioni con µClinux è preferibile non utilizzare la libreria C standard gLibC, perché troppo ingombrante, ma l’equivalente per i sistemi dedicati di piccole dimensioni, la uClibc, che è una derivazione della libc. Come per Linux anche µClinux ha la necessità di utilizzare un root file system. A causa della differente modello di memoria utilizzato, µClinux non può utilizzare lo stesso root file system. Per questo motivo è necessario rifare il build di tutte le applicazioni con un compilatore cross idoneo allo scopo. Il building del root file system è identico a quello di Linux e non presenta particolari difficoltà.
µCLINUX: COME OTTENERLO E COME COSTRUIRLO
La distribuzione µClinux è prelevabile dal sito: www.uclinux.org/pub/uClinux/dist/
Oltre alle varie versioni, sia in forma compilata che in sorgenti, in questo sito è possible anche ottenere, in forma compressa, applicativi su µClinux (per esempio Xcopilot). Il meccanismo utilizzato per creare il binario per il target che si vuole utilizzare è comune alle diverse distribuzioni, la sola cosa che cambia è la selezione del target stesso. Per prima cosa occorre estrarre µClinux dal file compresso:
gunzip < uClinux-dist-XXXXXX.tar.gz |
tar xzf -
cd uClinux-dist
make xconfig
Dall’interfaccia grafica occorre selezionare “Target Platform Selection”, scegliere un target 3com/Xcopilot per Xcopilot o GDB/ARMulator per ARMulator. Si seleziona ora la versione del kernel da utilizzare e la libreria uC-libc. Al termine scegliere Save & Exit. Dopo che questa fase di configurazione è terminata, da shell si dovranno dare i seguenti comandi:
make dep
make
Al termine dell’operazione di make, con l’immagine binaria ottenuta è possibile eseguire il kernel con l’emulatore selezionato: il risultato è µClinux con l’ambiente di emulazione.
µCLINUX CON GDB/ARMULATOR
In questa parte si illustra, a titolo d’esempio, il porting del GDB in una architettura ARM, il cosiddetto GDB/ARMulator: si utilizza il gdb ARM per eseguire µClinux.
A questo punto i passi da fare sono i seguenti:
- Costruzione del debugger/emulator;
- Esecuzione della versione precompilata.
In alternativa da una distribuzione µClinux facendo riferimento al codice sorgente della distribuzione, si può dare il comando:
ln -s images/romfs.img boot.rom
A questo punto possiamo fare il boot di µClinux dalla shell. Possiamo utilizzare il break del debugger, ^C, possiamo mettere dei break points in memoria, esaminare il contenuto della memoria stessa, esaminare e modificare le variabili. Chiaramente, gli eventuali break points devono essere messi prima del comando di run. Per interagire con il kernel al debugger dobbiamo mettere un break point a start_kernel:
...
(gdb) break start_kernel
(gdb) run
In alternativa è possibile usare la distribuzione con GDB/ARMulator. Questa distribuzione è disponibile su: www.uClinux.org/pub/uClinux/utilities/armulator/. Questa pagina web contiene tutte le informazioni necessarie per costruirsi il gdb per utilizzarlo con ARMulator e µClinux. Il sito contiene anche una serie di file pre-compilati di µClinux per le varie versioni di ARMulator.

Complimenti per l’argomento, un po’ di nicchia anche fra gli addetti e che non si trova proprio ovunque. Mi ha sempre interessato come “dialetto di Linux”, anche se non ho mai avuto il tempo di approfondire.
Bello anche il gioco di parole in inglese sul nome, che in inglese si legge “you see Linux”.
µClinux è una derivazione di Linux e questo comporta notevoli vantaggi per un utilizzo più diffuso che a mio parere andrebbe suggerito come ad esempio la possibilità di utilizzare procedure senza dover scrivere codice.
Argomento interessante soprattutto perché, come già detto, si tratta di Linux. Avere un sistema operativo può essere molto utile a seconda delle applicazione.
PS: anni fa ho avuto modo di lavorare con microcontrollori microchip (PIC32MX) che avevano a bordo la MMU.
Io ho fatto delle prove sull’evaluation Kit della Microchip, scegliendo pero’ un PIC32MZ, che
e’ piu’ alta fascia. Sono processori molto belli.
Si è vero e forse erano troppo avanti per il mondo embedded. Peccato che a suo tempo Microchip non scelse ARM come architettura per i 32bit, altrimenti credo che avrebbero veramente dominato il mercato dell’embedded
Sembra cmq ci sia una discreto seguito anche per i PIC32…Ho da poco seguito (per luce riflessa) un porting di FreeRTOS su PIC32 un po’ piu’ spinto di quello che viene distribuito ufficialmente con l’OS. Non male, si comporta molto bene in modo fluido anche con molti task creati.
Ho provato anche a usare la libreria di Microchip, Harmony Central, che dovrebbe semplificare il porting di piastre proprietarie, ma non mi ha convinto piu’ di tanto. Preferisco usare le librerie standard.
La gestione del DMA a tutti i livelli e sicuramente 1 punto di forza del PIC32…si possono fare stack TCP/IP custom molto tirati e ottimizzati usando le API a basso livello che usano il DMA.