QEMU Emulatore per Sistemi Embedded

Sul blog di Elettronica Open Source puoi leggere non solo tutti gli articoli Premium riservati agli abbonati Platinum 2.0 e inseriti nella rivista Firmware 2.0 (insieme ad articoli tecnici, progetti, approfondimenti sulle tecnologie emergenti, news, tutorial a puntate e molto altro) ma anche gli articoli della Rubrica Firmware Reload. In questa Rubrica del blog abbiamo raccolto gli articoli tecnici della vecchia rivista cartacea Firmware, che contengono argomenti e temi evergreen per Professionisti, Makers, Hobbisti e Appassionati di elettronica. Utilizzare immediatamente un sistema target per provare il nostro lavoro non è una cosa scontata. Per questa ragione, al fine di migliorare l’efficienza, può essere necessario utilizzare dei sistemi alternativi che ci permettano di provare il nostro software prima di disporre di una reale piattaforma hardware.

Introduzione

Oggi il ciclo di vita di un prodotto orientato per il mondo embedded si è notevolmente ridotto rispetto al passato; in effetti, rispetto a decenni or sono, ci possiamo ritenere fortunati che un prodotto per il mondo consumer abbia una vita utile di un decennio. Infatti, oggi diventa sempre più difficile realizzare un prodotto per il segmento consumer per via delle mutate condizioni tecnologiche, sempre più complesse ed estreme, insieme ad un accoppiamento sempre più spinto con i diversi sub-sistemi presenti. La portata e la complessità di componenti software in questo segmento industriale è salita significativamente nel corso degli anni. Non solo, con il continuo rimodellamento e sviluppo del software, allo scopo di garantire una sempre più corretta gestione dei processi di sistemi di automazione industriale, è necessario ottenere un prodotto che sia in grado di assicurare il rispetto dei vincoli di efficienza: ecco perché diventa sempre più stringente disaccoppiare il software dall’hardware sottostante.

VIRTUALIZZARE O EMULARE: LA CHIAVE DI VOLTA

Una sfida di questo tipo si affronta, e si vince, solo se si modifica il punto di vista. Infatti, occorre pensare a nuovi modelli di sviluppo che possono dare un vantaggio al nostro lavoro perché l’abilità di sviluppare applicazioni per un hardware senza il dispositivo fisico, in sé è sicuramente un grande vantaggio: occorre trasformare il problema della mancanza di una piattaforma hardware in una nuova opportunità di lavoro. Non solo, oltre a sopperire ad una piattaforma hardware immediatamente disponibile, è anche possibile offrire un ambiente sicuro e protetto per la sperimentazione di applicazioni nuove e non sperimentate. Infatti, dal momento che gli emulatori moderni supportano vari tipi di hardware e sistemi operativi, l’applicazione può anche essere testata allo scopo di garantire la scalabilità e l’affidabilità, e non solo per la sua funzionalità. Questo approccio rende le nuove piattaforme di test molto potenti e flessibili, oltre a rivelarsi preziosi in caso di sviluppo del kernel e driver di periferica dove un piccolo errore può mandare in crash l’intero sistema operativo. Non è mai esistita una definizione universalmente riconosciuta del termine “virtualizzazione”, anche se il concetto di virtualizzazione è presente da almeno quattro decenni.

Tutto sommato, possiamo senza dubbio dire che la virtualizzazione è un’astrazione di una o più risorse hardware allo scopo di ottenere un certo comportamento, o piattaforma hardware configurata. In questo contesto, quando ci riferiamo ad una piattaforma hardware configurata, ci vogliamo riferire o ad un computer di fascia alta o ad un sistema di test per una certa architettura hardware. In passato, con il concetto di emulazione ci si voleva riferire alla virtualizzazione di un hardware dedicato. Oggi, ci si vuole riferire alla replicazione di funzioni di un sistema da un altro, in modo che l’emulatore agisca in modo simile al sistema emulato. Esistono differenti tipi di virtualizzazioni a seconda del sistema da virtualizzare e livelli di astrazione utilizzati per realizzarla. Quando si parla di emulazioni hardware, al contrario, ci vogliamo riferire alla virtualizzazione dell’hardware richiesto sulla macchina host. Chiaramente, una virtualizzazione di questo tipo è estremamente lenta, anche se abbiamo il vantaggio di sviluppare, in modo simultaneo, il nostro software insieme all’hardware. A questo riguardo, QEMU e Bochs sono esempi di emulatori hardware. Occorre anche chiarire il concetto di virtualizzazione nativa. In questo caso dobbiamo utilizzare un hypervisor che si usa come mediatore tra il sistema operativo e l’hardware sottostante: questo hardware, per inciso, deve essere supportato dal sistema operativo che stiamo utilizzando. KVM e VMware possono rappresentare dei classici esempi di soluzioni complete di virtualizzazione. Esiste anche il concetto, e termine, di para-virtualizzazione. In questo caso, utilizziamo un hypervisor per l’accesso condiviso all’hardware sottostante: questo metodo offre migliori prestazioni, anche se, dato che il codice di virtualizzazione è integrato nel sistema operativo stesso, il sistema operativo ospite deve essere modificato per utilizzare l’hypervisor.

Figura 1: Prompt di login di QEMU per ARM

QEMU: UNA POSSIBILE SOLUZIONE

QEMU può rappresentare una valida soluzione ad un problema di questo tipo per diversi motivi. Per prima cosa è software open source libero da costi ed è supportato da una comunità composta da un numero non indifferente di sviluppatori. QEMU può anche vantare due modi operativi. Nella modalità User-Mode, ad esempio, può eseguire binari compilati per diverse architetture su un host x86-Linux. In questa modalità può raggiungere prestazioni quasi native. Non solo, QEMU offre anche la disponibilità di diversi target, da PowerPc 603e fino ad arrivare agli ultimi ARM passando anche dai dispositivi di casa Microchip, o la possibilità di utilizzare diverse macchine host: x86-Windows e x86-Linux.

QEMU PER ARM

Una volta che disponiamo di una versione QEMU per la nostra architettura hardware di riferimento, per la precisione per il mondo ARM dell’eseguibile qemu-system-arm, possiamo prendere confidenza con questo ambiente utilizzando un’immagine di test, ovvero reperire il file compresso arm-test-0.2.tar.gz. Questo file, costruito grazie al lavoro di Paul Brook, può essere prelevato dalla home page di QEMU: il file contiene due immagini quali zImage.integrator e arm_root.img utilizzate per provare il nostro ambiente virtuale.

 

# cp DownloadDirectory/arm-test-0.2.tar.gz
$PRJROOT/images
# cd $PRJROOT/images
# tar -xvf arm-test-0.2.tar.gz
# cd arm-test
# cat README

Così, con o senza l’interfaccia grafica possiamo testare la versione per ARM con i seguenti comandi:

# qemu-system-arm -kernel zImage.integrator
-initrd arm_root.img

Oppure:

# qemu-system-arm -kernel zImage.integrator
-initrd arm_root.img \
-nographic -append “console=ttyAMA0”

Il Riquadro 1 pone in evidenza lo script, in ambito Windows, da utilizzare per lanciare QEMU in versione ARM.

 

QEMU PER POWERPC

L’immagine del kernel Linux per QEMU-PowerPC è costruita in modo usuale senza particolari accorgimenti, anche se arrivare ad una configurazione di questo tipo richiede un certo lavoro non privo di sforzi. Per costruire una immagine di questo tipo possiamo utilizzare una configurazione standard Debian (Lenny) con minimi impatti su un sistema Linux host. In questa particolarità il progetto DietPC può rappresentare, di certo, una preziosa risorsa per produrre una versione di QEMU per l’ambiente PowerPC su Windows. Per lanciare l’emulatore è necessario utilizzare il comando seguente:

# qemu-system-ppc -L . -M g3beige -m
128 \
-localtime -no-reboot -name P-Robo \
-hdc “PRobo.img” -boot c\
-net nic -net user \
-redir tcp:22::22 tcp:2345::2345

Dando uno sguardo a ciascun argomento utilizzato, possiamo dire che l’eseguibile qemu-system-ppc è la versione QEMU per PowerPC, mentre con lo switch -L si punta a un folder che contiene il firmware OpenBios. Non solo, con -M g3beige si configura l’emulazione per beige G3 PowerMac, il quale risulta compatibile con il core PowerPc 603e, mentre con –m 128 si costringe a utilizzare, per l’ambiente da emulare, 128 mega byte di RAM virtuale. Proseguendo nell’esame dei diversi switch utilizzati si scopre che:

  • localtime, si imposta l’RTC al valore del nostro tempo locale (local time)
  • no-reboot, si impone di uscire senza un reboot
  • nome P-Robo, impone il nome al guest, in questo caso P-Robo
  • hdc “PRobo.img”, si impone a QEMU di utilizzare l’immagine PRobo. img come ide hard disk
  • boot c, imposta QEMU per l’avvio da disco fisso
  • net, crea un NIC con una connessione verso una VLAN
  • net user, si connette in modalità utente verso una rete VLAN
  • redir tcp:22::22, reindirizza le connessioni SSH da host a guest
  • redir tcp:2345::2345 reindirizza una porta gdbserver predefinita per le connessioni da host a guest

QEMU SU MICROCHIP

Esiste anche la possibilità di utilizzare QEMU su architetture Microchip e, per dimostrare la sua fattibilità, la Tabella 1 pone in evidenza le differenti scelte utilizzabili.

Tabella 1: Selettori per configurare la variante Microchip

Infatti, per selezionare una particolare architettura, con relativa board, è necessario specificare l’opzione -machine: pare anche far presente che ogni scheda utilizza un differente assegnamento per UART, SPI e card SD. Ad esempio, per utilizzare un piccolo esempio, come il classico Hello World, su una board Max32 è necessario utilizzare il seguente comando:

/usr/local/qemu-mips/bin/qemu-system-
mipsel -machine pic32mx7-max32
-nographic \
-monitor none \
-serial stdio \
-bios boot-max32.hex \
-kernel hello-max32.hex

Un comando di questo tipo permette di sfruttare l’emulatore QEMU producendo il seguente risultato:

Board: chipKIT Max32
Processor: M4K
RAM size: 128 kbytes
Load file: ‘/local/BSD/pic32sim/demo/
retrobsd/boot-max32.hex’, 6720 bytes
Load file: ‘hello-max32.hex’, 4576 bytes
Hello, World!
..........
Hello, World!
......

 

Articolo della rivista cartacea Firmware Anno 2015 - Numero 113

Scarica subito una copia gratis

Scrivi un commento

Send this to a friend