Embedded PC

L’open source, o meglio l’open hardware, è stato pensato anche per le piattaforme PC? ZF Micro Solutions intende rispondere a questa domanda suggerendo il suo ZFx86: un progetto realizzato con l’intento di suggerire una piattaforma low cost e low power per piattaforme Intel.

Di certo non è Arduino, ma ZF Micro Solutions vuole iniziare una nuova fase suggerendo la sua piattaforma di lavoro pensata e realizzata per il segmento embedded PC. Non solo, l’architettura così definita da ZF è anche Linux compatibile; infatti, il suo ZFx86 Easy Embedded PC System (EEPC) è stato realizzato utilizzando la tecnologia SoC e dissipa solo 5W offrendo diverse interfacce, oltre a garantire la compatibilità verso differenti sistemi operativi.

Le figure 1 e 2 mostrano la board EEPC di ZF Micro Solutions. Il prodotto di casa ZF è davvero flessibile perché permette di aggiungere diverse opzioni di boot al fine di eseguire un diverso sistema operativo, o un’applicazione residente in memoria, in luogo di quello di casa Microsoft. A questo proposto può essere opportuno spendere alcune parole sul Master Boot Record (MBR).

Figura 1: zfmicro eepc.

Figura 1: zfmicro eepc.

 

Figura 2: EEPC.

Figura 2: EEPC.

MASTER BOOT RECORD

Il Master Boot Record (MBR) si trova posto all’interno del primo settore di un disco rigido. In particolare, l’MBR si trova a cylinder 0, head 0, sector 1. L’utilizzatore può accedere a questa particolare configurazione con una delle utility presenti in commercio o, in alternativa, può utilizzare benissimo un programma open source. Secondo lo standard di casa Microsoft, ogni Master Boot Record contiene una tabella di quattro 4 entry denominata partition table. Dopo l’accensione, e terminata la fase di POST (power on self test), il BIOS effettua la chiamata all’INT 19. La INT 19 è stata realizzata, ed è disponibile a livello applicativo, per gestire la sequenza di boot; infatti, la INT 19 legge, solitamente, il settore di boot all’interno del floppy disk. Ad ogni modo, è opportuno ricordare che anche con la pressione della combinazione carattere CTRL-ALT-Del si richiama l’esecuzione dell’ INT 19, ma in questo caso viene eseguita a seguito di un POST ridotto. Se durante la lettura del floppy viene rilevato un boot sector, questo viene copiato all’indirizzo 0000:7C00 e l’INT 19 esegue un salto assoluto a questo indirizzo. Nel caso invece che non venga trovato un settore di boot il codice contenuto all’interno dell’ INT 19 cerca di leggere l’MBR del primo hard disk rilevato. Una volta trovato, il master boot record è copiato alla locazione di memoria 0000:7C00. Il programma che viene eseguito all’interno dell’MBR legge la propria partition table alla ricerca di una partizione attiva (bootable).Se la ricerca ha esito positivo, il boot sector di questa partizione viene copiato alla locazione di memoria 0000:7C000 e il codice dell’MBR esegue un salto a all’indirizzo relativo. Al contrario, se non viene trovata nessuna partizione attiva allora viene eseguito una chiamata a INT 18 e il sistema si ferma. È opportuno ricordare che ogni sistema operativo ha il proprio formato di boot sector. Generalmente il piccolo programma all’interno del boot sector localizza la prima parte del loader del kernel del sistema operativo oppure direttamente il kernel stesso o, ancora, un programma gestore di boot, e lo copia in memoria. Ricordiamo che la sequenza di ricerca del boot sector, chiamata anche sequenza di boot, generalmente è configurabile tramite il setup del Bios.

Ricordiamo che il codice del master boot record inizia all’offset 0000, i messaggi del Master Boot Sector iniziano, al contraro, all’offset 008b. Non solo, la partition table inizia all’offset 01be, mentre la segnature si trova all’offset 01fe. La figura 3 mostra il contenuto di un Master Boot Sector tipico. In effetti, dalla figura si nota che i primi 139 bytes (da 00h a 8Ah) dei 512 bytes del settore sono composti da codice eseguibile, i sucessivi 80 bytes (da 8Bh a DAh) contengono messaggi di errore. Gli ultimi 66 byte del settore contengono i 64 byte della tabella di partizione (da 1BEh a 1FDh).

Figura 3: Master Boot Record.

Figura 3: Master Boot Record.

I dati contenuti all’interno dell’area della tabella dipenderanno dalle dimensioni, dal tipo di partizione e dal tipo di file system all’interno della partizione. Il settore termina con l’identificatore AA55h, chiamato anche magic number. Durante il POST il bios fa una ricerca del magic number e,  nel caso non  venga trovato, visualizza un messaggio di errore  del   tipo   “Drive   not   ready” I rimanenti 227 bytes (da DBh a 1BDh) sono messi tutti a zero.

HELLO WORLD

Ecco il solito esempio fatto per comprendere meglio ciò che si dice. Il listato 1 mostra un esempio su come realizzare una utility di boot utilizzando NASM.

; code located at 0000:7C00, adjust segment registers
          cli
          mov ax, 0x07C0
          mov ds, ax
          mov es, ax
          mov fs, ax
          mov gs, ax
; create stack
          mov ax, 0x0000
          mov ss, ax
          mov sp, 0xFFFF
          sti
; post message
          mov si,msgHello
          call DisplayMessage
          mov si, msgEnd
          call DisplayMessage
          hlt
; Display Message
DisplayMessage:
          lodsb                    ; load next character
          or al, al                ; test for NUL character
          jz .DONE
          mov ah, 0x0E             ; BIOS teletype
          mov bh, 0x00             ; display page 0
          mov bl, 0x07             ; text attribute
          int 0x10                 ; invoke BIOS
          jmp DisplayMessage
   .DONE:
          ret
; data section
msgHello db 0x0D, 0x0A, “Ciao Gente”, 0x0D, 0x0A, 0x00
msgEnd db 0x0D, 0x0A, “Questo funzione!!!”, 0x0D, 0x0A, 0x00
;ASM Signature
           TIMES 510-($-$$) DB 0
           DW 0xAA55
Listato 1 – Hello World con boot.asm

Così si crea un file binario:

NASM boot.asm -o boot.bin -f bin

Successivamente, occorre disporre di un floppy disk, cosa difficile oggi giorno, per realizzare un disco di boot attraverso il programma format con il comando:

format a: /q

In seguito con il programma Debug.exe copiamo il nostro programma:

debug boot.bin

-W 100 0 0 1

-Q

Al termine, una volta inserito il floppy nel driver e riavviato il computer, possiamo vedere il seguente messaggio sul monitor:

Ciao Gente

Questo funziona!!

ZFX86 DI ZF

Il progetto è basato sulla piattaforma ZFx86 SoC con una frequenza di lavoro di 100 MHz e rappresenta l’evoluzione del precedente MachZ. Il SoC ZFx86, figura 4, si basa su un’architettura da 32 bit con la compatibilità verso il modulo 486.

Figura 4: zfx86.

Figura 4: zfx86.

La piattaforma permette di gestire interfacce PCI e ISA bus controller, porte USB, seriali e porte parallele. Non solo, stando alle specifiche, il componente permette di utilizzare le cosiddette le I/O general purpose. Il progetto è stato a anche così realizzato per garantire la compatibilità con le piattaforme PC al fine di utilizzare i vari dispositivi esterni quali keyboard, mouse, IrDA, floppy e interfacce hard drive. ZF assicura anche la presenza di interfacce video e di rete senza avere la necessità di utilizzare chipset esterni. A questo proposito la figura mostra la sua architettura e la tabella 1 pone in evidenza le caratteristiche tecniche del prodotto.

TABELLA 1 – SPECIFICHE DELLA EEPC BOARD

TABELLA 1 – SPECIFICHE DELLA EEPC BOARD

ZF utilizza il suo ZF BIOS che sovrintende alla gestione di tutte le periferiche. Il Bios di casa ZF è basato sul prodotto della Phoenix Technologies. ZF, per garantire il boot con differenti sistemi operativi, ha definito un nuovo gestore dell’eccezione Int19 integrato perfettamente con il BIOS al fine di garantire un multiple option-ROM o Extension-Rom di immagini binarie che risiedono nella stessa flash del BIOS. In questo modo tutte le immagini  binarie  che  costituiscono un’applicazione, definita embedded, potrebbero utilizzare la stessa memoria flash. Con il gestore Int19handler è possibile intromettersi nel flusso di esecuzione poco prima che il sistema operativo venga avviato per gestire le diverse modalità di funzionamento. Al termine del processo di boot tutti i componenti presenti risultano già inizializzati e, in base alle differenti Option-Rom identificati in questa fase, il modulo funzionale ZFx86 può mettere in esecuzione i diversi programmi applicativi o i diversi sistemi operativi presenti in flash. Abbiamo già scritto che il vettore INT19 è utilizzato dal BIOS subito dopo la fase di POST al fine di caricare ed eseguire qualsiasi codice di Boot presente in memoria, su hard drive o disco. L’implementazione fatta sul BIOS del ZF si basa sull’opportunità di gestire diverse sequenze di boot: il vettore int19 intercetta qualsiasi richiesta del BIOS e va alla ricerca di sequenze addizionali di boot Rom utilizzando le diverse immagini presenti in memoria attraverso un’opportuna gestione del chip select. Se, in base alle richieste operate, il vettore 19 trova una nuova sequenza di boot, allora si trasferisce il controllo verso l’immagine presente in memoria. Il programma così attivato assume il pieno controllo del PC non cedendo più il controllo al chiamante. Al contrario, se il vettore non trova nessuna immagine allora si restituisce il controllo al processo chiamante per continuare la fase di boot originale. Così, quando il
BIOS è pronto di fare il boot da disco, questo invoca il vettore 19 e il controllo è trasferito al gestore ZF dell’int19. Le
modifiche introdotte da ZF permettono di gestire in modo più flessibile le diverse opzioni di boot. In effetti, il nuovo
ZF int19 inizializza i registri di segmento (DS e ES), oltre a definire il nuovo stack verso la nuova area di memoria.
Il vettore int19 si pone alla ricerca delle zone di memoria secondo il parametro imposto a mem_cs0 definito dal Bios della Phenix attraverso l’utility presente sulla board dal menu: Advanced > Advanced Chipset Control > ISA Memory Chip Select setup Per fare questo è necessario leggere le pagine Flash PAGE, Window BASE, Window SIZE, e Full ISA dai registri ZFLogic. Se il gestore int19 trova solo i valori imposti per default allora non è richesta nessun tipo di controllo e il gestore non si discosta dalla sequenza tradizionale. In caso contrario, il gestore si pone in modalità option-ROM e utilizza il contenuto del registro ES che determina il segmento che deve essere analizzato. Prima di invocare l’estensione del codice, il gestore deve verificare che il valore del checksum sia corretto. Il checksum è calcolato per ogni blocco e la somma di tutti i blocchi si trova nel registro DH. A questo punto esistono due possibili alternative. Quando tutti i blocchi sono stati verificati e il valore del checksum in DH è uguale a zero, il gestore comprende che l’option-ROM è corretto. Al contrario, quando il checksum non è uguale a zero allora, in questo caso, l’esecuzione della parte opzionale è terminata e si continua a ricercare nell’area successiva. Prima però di chiamare il codice del l’estensione, la routine associata del vettore int19 assegna una firma digitale nel registro EDX. L’estensione utilizza questa firma per determinare la sequenza di chiamata. Esiste una variabile di sistema che contiene il limite per la scansione, raggiunto il limite l’estensione passa il controllo alla routine int19 originale. La figura 5 mostra il flusso di esecuzione dell’estensione implementato da ZF su BIOS Phoenix.

Figura 5: flusso di esecuzione.

Figura 5: flusso di esecuzione.

Il nuovo gestore del vettore int19 offre una differente e originale sequenza di boot estremamente flessibile: basta modificare il valore di mem_cs0 per indirizzare regioni diverse. La figura 6, al contrario, mostra le diverse zone di memoria utilizzate dal loader di Linux con la modalità opzionale.

Figura 6: Loader Linux.

Figura 6: Loader Linux.

Scrivi un commento