zOS (Z-Sistema Operativo)

English

zOS

zOS e' un derivato dell'applicazione di test ZPUTA, creata per verificare le operazioni della ZPU Evo e del SoC. ZPUTA si e' evoluta man mano che vari FPGA sono stati inclusi nell'ambito della ZPU Evo, e divenne chiaro che doveva essere piu' avanzata a causa delle risorse limitate. Quando ZPUTA raggiunse un grado di sofisticazione simile a un sistema operativo, fu divisa e nacque zOS.

Originariamente, gli sviluppi di ZPUTA/zOS miravano solo all'architettura ZPU, e avevano due metodi di esecuzione primari:
  • come applicazione avviata da IOCP,
  • in modalita’ autonoma come firmware di avvio della ZPU Evo.
La modalita' di avvio viene scelta nella configurazione e la funzionalita' e' identica. Quando avviato come applicazione da IOCP, zOS e' memorizzato su una scheda SD e caricato all'avvio. In modalita' autonoma, zOS e' memorizzato nella flash onboard (o BRAM preconfigurata come ROM).

Recentemente, zOS e' stato portato sull'architettura ARM Cortex-M4, per l'uso con il Freescale K64F nel progetto tranZPUterSW. Poiche' il K64F e' un CPU/SoC ad architettura fissa, esiste un solo metodo di esecuzione: 'autonomo' -- memorizzato nella flash onboard e avviato quando la CPU si accende.

In zOS, tutta la funzionalita' non-OS e' memorizzata come applicazioni su una scheda SD. Se non e' disponibile una scheda SD, e' meglio utilizzare ZPUTA, in quanto offre la possibilita' di tenere conto delle limitate risorse BRAM dell'FPGA consentendo di abilitare/disabilitare tutte le funzioni di ZPUTA all'interno dell'immagine caricata primariamente.

Per il funzionamento, zOS richiede una connessione seriale (fisica o USB virtuale) con preferibilmente un pacchetto di emulazione terminale ANSI/VT100. Il requisito di un pacchetto di emulazione terminale ANSI/VT100 serve affinche' comandi come l'editor o readline funzionino correttamente. Un semplice terminale seriale funzionera' comunque, ma con funzionalita' applicativa limitata.

Un piu' recente sviluppo hardware, il tranZPUter SW-700 v1.3, vede zOS funzionare come sistema operativo host dove tastiera e display sono sotto il suo controllo diretto. Per mantenere la compatibilita' con le applicazioni seriali, e' stato sviluppato e integrato un emulatore di terminale ANSI.

Utilizzo del sistema operativo

Durante tutta la mia carriera ho utilizzato o progettato sistemi in cui era possibile interagire in tempo reale con il prodotto finale per monitorarlo, adattare il flusso logico in base ai cambiamenti del mercato o risolvere problemi in tempo reale. Questo avveniva normalmente tramite un processore di comandi integrato utilizzando la connessione client-server TCP.

Lavorando su alcuni dei miei progetti in questo repository, ho sempre avuto in mente di volere un ambiente simile, anche su un sistema embedded con risorse limitate, in cui potessi monitorare, modificare o riparare al volo.

L'interfaccia del sistema operativo e' stata scritta considerando che e' disponibile solo un terminale testuale seriale. Alcuni componenti come l'editor richiedono capacita' avanzate, e a questo scopo e' stata scelta la collaudata emulazione VT100/ANSI come candidato adatto. L'interazione e' basata su tastiera e testo (nessuna bella interfaccia GUI!).

Riga di comando

Il primo incontro con il sistema operativo e’ un messaggio di accesso che mostra CPU, versione, ecc. e presenta un prompt per l’inserimento dei comandi:

zOS Startup Screen

L'interazione con il sistema operativo non differisce da MSDOS -- si digita un comando e si riceve una risposta. La riga di comando di zOS non e' un interprete di shell, ma solo una semplice interfaccia testuale per l'emissione di comandi incorporati o comandi memorizzati sulla scheda SD. Include una funzionalita' readline semplificata con cronologia per assistere nell'inserimento e nel recupero dei comandi.


Key Action
CTRL-A Go to start of line.
CTRL-B Move cursor one position to the left.
CTRL-C Abort current line and return CTRL-C to calling application.
CTRL-D Not defined in shell, passed to running application.
CTRL-E Go to end of line.
CTRL-F Move cursor one position to the right.
CTRL-K Clear the line.
CTRL-N Recall next historized command.
CTRL-P Recall previous historized command.
HOME Go to start of line.
END Go to end of line.
DEL Delete character under cursor.
BACKSPACE Delete character to left of cursor.
ARROW UP Recall previous historized command.
ARROW DOWN Recall next historized command.
ARROW RIGHT Move cursor one position to the right.
ARROW LEFT Move cursor one position to the left.
Command Action
!<number> Recall and execute given historised command identified by <number>.
hist[ory] List the history buffer.

Applicazioni

Le applicazioni attualmente fornite da zOS si trovano su una scheda SD e sono riassunte di seguito. Per informazioni piu' dettagliate, consultare la sezione applicazioni (nella barra di navigazione a sinistra).

Le tabelle complete dei comandi per IO su disco, buffer disco, file system, memoria, hardware, test di prestazione, esecuzione programmi, comandi vari, applicazioni e comandi tranZPUter sono identiche alla versione inglese e sono elencate li’.

autoexec.bat

Come in MSDOS, se un file chiamato 'AUTOEXEC.BAT' viene creato nella directory radice (livello superiore) del file system SD, il suo contenuto verra' eseguito da zOS all'avvio/reset. Utilizzare questo file per automatizzare la configurazione e l'avvio dell'applicazione prevista.

Dettagli tecnici

Questa sezione mira a fornire alcuni dei dettagli interni del sistema operativo.

Organizzazione della memoria

IOCP Memory Map
zOS viene generalmente utilizzato nella sua versione autonoma, cioe' il sistema operativo si avvia come firmware primario. Per la compatibilita' con le versioni precedenti o per supportare uno sviluppo piu' rapido di zOS sulla ZPU, IOCP puo' essere utilizzato come bootloader per avviare un'immagine zOS dalla scheda SD.

IOCP Memory Map

zOS Memory Map
zOS sulla ZPU ha la disposizione di memoria come mostrato nel diagramma seguente. zOS risiede nella BRAM inferiore come firmware di avvio con stack/heap nella parte superiore della BRAM utilizzabile (o RAM/SDRAM). Un'applicazione viene caricata all'indirizzo definito nello script di build.

zOS Memory Map for ZPU

La mappa di memoria per il processore K64F e’ simile, ma la Flash RAM e la RAM sono definite in modo fisso e non variabile come nella ZPU.

zOS Memory Map for K64F


Interfaccia dell'applicazione

Come la maggior parte dei sistemi operativi, zOS fornisce un’API che un’applicazione opportunamente compilata puo’ utilizzare per ridurre le proprie dimensioni e complessita’ e riutilizzare le funzioni all’interno del sistema operativo come la connessione seriale.

Piuttosto che progettare un set API personalizzato, era piu’ sensato esporre i metodi all’interno di zOS per l’uso dell’applicazione, ad esempio printf. Un’applicazione che chiama printf per visualizzare l’output sul terminale chiama effettivamente printf all’interno di zOS. Questo viene ottenuto creando una tabella di salto a un vettore fisso all’interno di zOS.

La tabella completa dei vettori API (93 vettori inclusi Character I/O, I/O formattato, operazioni sul file system, I/O su disco, gestione della memoria, operazioni sul bus Z80 e altro) e’ identica alla versione inglese e viene elencata completamente li’.

Il prototipo del template dell’applicazione e’:

 uint32_t app(uint32_t param1, uint32_t param2)
param1 e param2 possono essere qualsiasi valore a 32 bit passato nella chiamata fileExec in zOS. In condizioni operative normali, zOS chiama un'applicazione con un solo parametro, param1, che e' un puntatore (char *) ai parametri della riga di comando.

Il codice di ritorno dell'applicazione a zOS e' un intero a 32 bit senza segno. 0 indica esecuzione riuscita, 0xFFFFFFFF indica un errore.

Configurazione e compilazione automatizzate (consigliato)

Il modo consigliato per compilare zOS e' lo script di configurazione automatizzata per la propria piattaforma. Verifica e installa i prerequisiti, installa la toolchain ZPU, clona il repository (se non ci si trova gia' all'interno di un checkout) e propone di eseguire la prima compilazione — con valori predefiniti sensati che si possono accettare premendo Enter. Ogni script e' autonomo: e' sufficiente copiare il singolo file per la propria piattaforma ed eseguirlo. I passaggi manuali piu' in basso sono destinati agli utenti avanzati, alle ricompilazioni parziali e alla CI.
La compilazione e' gestita da build.sh, che assembla/compila IOCP, zOS e le app per una determinata CPU in un unico passaggio. Sono coinvolte due toolchain e gli script di configurazione le forniscono entrambe:
Toolchain CPU di destinazione Origine
ZPU zpu-elf-gcc 3.4.2 Small Medium Flex Evo EvoMin (ZPU) installata in /opt/zpu (da ZPU_TOOLCHAIN_URL)
ARM arm-none-eabi K64F (Kinetis / Teensy 3.5) inclusa nel repository in tools/arm (nessuna installazione)

Poiche’ entrambe le toolchain sono binari Linux / cross, la compilazione viene eseguita nativamente su Linux, in Docker su macOS (immagine zos-build:latest) e tramite WSL1 su Windows:

Script Piattaforma Note
setup_zOS.sh Linux (nativo) / macOS (Docker) Installa gli strumenti di build di base + la toolchain ZPU; su macOS compila all’interno dell’immagine Docker zos-build:latest.
setup_zOS_windows.cmd Windows 10 / 11 Launcher da doppio clic che richiama lo script PowerShell sottostante.
setup_zOS_windows_native.ps1 Windows 10 / 11 (WSL1) Configura WSL1 ed esegue al suo interno la configurazione Linux.
setup_zOS_wsl1.sh all’interno di WSL1 Il passo di configurazione Linux richiamato automaticamente nella distribuzione WSL1.

Linux / macOS — setup_zOS.sh

chmod +x setup_zOS.sh
./setup_zOS.sh

Windows 10 / 11 — setup_zOS_windows_native.ps1 — doppio clic su setup_zOS_windows.cmd, oppure da un prompt PowerShell:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_zOS_windows_native.ps1

La configurazione clona ZOS_REPO_URL (predefinito https://git.eaw.app/eaw/zOS.git) in ~/zOS. Una volta terminata, si compila zOS con (build.sh seleziona automaticamente native / Docker / WSL1 per l’host):

./build.sh -C Evo  -O zos        # zOS for the Evo ZPU
./build.sh -C K64F -O zos        # zOS for the K64F (ARM Cortex-M4)
./build.sh -h                    # all options (-C CPU, -I IOCP, -O os, -o os ver, addresses, sizes ...)
Gli output vengono creati in build/ e build/SD/ — la ROM di avvio (BOOT.ROM / BOOTTINY.ROM), il boot loader IOCP_<func>_<addr>.bin e il file .bin di zOS, oltre ai binari delle app in bin/ pronti per essere copiati su una scheda SD formattata FAT.

Override utili delle variabili d’ambiente:

Variabile Scopo
ZOS_REPO_URL Repository da clonare (predefinito https://git.eaw.app/eaw/zOS.git).
ZOS_DIR Compila all’interno di un checkout esistente invece di clonare.
ZPU_TOOLCHAIN_URL Posizione del tarball della toolchain zpu-elf-gcc 3.4.2 installata in /opt/zpu.
ZOS_BUILD_IMAGE Immagine Docker usata per la compilazione su macOS (predefinita zos-build:latest).
ZOS_ASSUME_YES=1 Accetta tutti i prompt in modo non interattivo (installazioni automatiche / CI).
Se si preferisce compilare manualmente o si sta creando una pipeline CI, la compilazione manuale — i percorsi, l'elenco degli strumenti, l'albero di build e la matrice completa dei flag di build.sh — e' documentata nella sezione Build del software immediatamente sotto.


Build del software

Questa sezione mostra come costruire un kernel zOS di base. Il punto di partenza per il build di zOS e’ lo script ‘build.sh’, che contiene tutta la logica necessaria.

Percorsi

La tabella completa dei percorsi, l’elenco degli strumenti e la documentazione del build tree sono identici alla versione inglese e sono descritti in dettaglio li’.

Strumenti

Tutto lo sviluppo e’ stato effettuato su Linux, in particolare Debian/Ubuntu. Oltre alla catena di build standard Linux, e’ necessario il seguente software:

  • ZPU GCC ToolChain - La toolchain GCC per lo sviluppo sulla ZPU. Installare in /opt o una directory comune simile.
  • Arduino - L’ambiente di sviluppo Arduino, non realmente necessario tranne quando si aggiungono funzioni alla versione K64F di zOS.
  • Teensyduino - Le estensioni Arduino per Teensy3 per lavorare con la scheda Teensy3.5.

La struttura completa del build tree, i parametri di build.sh e gli esempi si trovano nella versione inglese.