zOS (Z-Betriebssystem)

English

zOS

zOS ist ein Ableger der ZPUTA-Testanwendung, die erstellt wurde, um ZPU Evo und SoC-Operationen zu verifizieren. ZPUTA entwickelte sich weiter, als verschiedene FPGAs in den Umfang der ZPU Evo einbezogen wurden, und es wurde klar, dass sie aufgrund begrenzter Ressourcen fortschrittlicher sein musste. Als ZPUTA einen Grad an Raffinesse erreicht hatte, der einem Betriebssystem aehnelt, wurde es aufgeteilt und zOS wurde geboren.

Urspruenglich zielten die ZPUTA/zOS-Entwicklungen nur auf die ZPU-Architektur ab, und sie hatten zwei primaere Ausfuehrungsmethoden:

• als von IOCP gebootete Anwendung,
• eigenstaendig als ZPU Evo Startup-Firmware gebootet.

Der Startmodus wird in der Konfiguration gewaehlt, und die Funktionalitaet ist identisch. Wenn als Anwendung von IOCP gebootet, wird zOS auf einer SD-Karte gespeichert und beim Booten geladen. Im eigenstaendigen Modus wird zOS im Onboard-Flash (oder vorkonfiguriertem BRAM als ROM) gespeichert.

Kuerzlich wurde zOS auf die ARM Cortex-M4-Architektur portiert, fuer die Verwendung mit dem Freescale K64F im tranZPUterSW-Projekt. Da der K64F eine feste Architektur-CPU/SoC ist, existiert nur eine Ausfuehrungsmethode: 'eigenstaendig' -- gespeichert im Onboard-Flash und gestartet, wenn die CPU eingeschaltet wird.

In zOS wird alle Nicht-OS-Funktionalitaet als Anwendungen auf einer SD-Karte gespeichert. Wenn keine SD-Karte vorhanden ist, ist es besser, ZPUTA zu verwenden, da es die Moeglichkeit bietet, begrenzte FPGA-BRAM-Ressourcen zu beruecksichtigen, indem alle Funktionen von ZPUTA innerhalb des primaer geladenen Images aktiviert/deaktiviert werden koennen.

Zum Betrieb benoetigt zOS eine serielle Verbindung (physisch oder USB-virtuell) mit vorzugsweise einem ANSI/VT100-Terminal-Emulator-Paket. Die Anforderung eines ANSI/VT100-Terminal-Emulationspakets dient dazu, dass Befehle wie der Editor oder Readline korrekt funktionieren. Ein einfaches serielles Terminal funktioniert ebenfalls, jedoch mit eingeschraenkter Anwendungsfunktionalitaet.

Eine neuere Hardware-Entwicklung, der tranZPUter SW-700 v1.3, sieht zOS als Host-Betriebssystem arbeiten, bei dem Tastatur und Display unter seiner direkten Kontrolle stehen. Um die Abwaertskompatibilitaet mit den seriellen Anwendungen zu wahren, wurde ein ANSI-Terminal-Emulator entwickelt und eingebettet.

Verwendung des Betriebssystems

Waehrend meiner gesamten Karriere habe ich Systeme verwendet oder entworfen, bei denen man live mit dem Endprodukt interagieren konnte, um es zu ueberwachen, den Logikfluss entsprechend Marktaenderungen anzupassen oder Probleme in Echtzeit zu beheben. Dies geschah normalerweise ueber einen eingebetteten Befehlsprozessor unter Verwendung der TCP-Client-Server-Verbindung.

Bei der Arbeit an einigen meiner Projekte in diesem Repository hatte ich immer im Sinn, dass ich eine aehnliche Umgebung wollte, auch auf einem eingebetteten System mit begrenzten Ressourcen, in der ich ueberwachen, aendern oder im laufenden Betrieb reparieren konnte.

Die Betriebssystemschnittstelle wurde unter Beruecksichtigung geschrieben, dass nur ein serielles textbasiertes Terminal verfuegbar ist. Einige Komponenten wie der Editor benoetigen erweiterte Faehigkeiten, und zu diesem Zweck wurde die bewerte VT100/ANSI-Emulation als geeigneter Kandidat gewaehlt. Die Interaktion erfolgt tastatur- und textbasiert (keine huebschen GUI-Schnittstellen!).

Kommandozeile

Die erste Begegnung mit dem Betriebssystem ist eine Anmeldemeldung, die CPU, Version usw. anzeigt und eine Eingabeaufforderung fuer Befehlseingaben ausgibt:

Die Interaktion mit dem Betriebssystem unterscheidet sich nicht von MSDOS -- Sie geben einen Befehl ein und erhalten eine Antwort. Die zOS-Befehlszeile ist kein Shell-Interpreter, sondern nur eine einfache Textschnittstelle fuer die Ausgabe von eingebauten Befehlen oder auf der SD-Karte gespeicherten Befehlen. Sie enthaelt eine vereinfachte Readline-Funktionalitaet mit History zur Unterstuetzung bei der Befehlseingabe und -abruf.

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.

Anwendungen

Die derzeit von zOS bereitgestellten Anwendungen befinden sich auf einer SD-Karte und sind nachfolgend zusammengefasst. Fuer detailliertere Informationen verweisen wir auf die Anwendungssektion (in der linken Navigationsleiste).

Die vollstaendigen Befehlstabellen fuer Disk-IO, Disk-Buffer, Dateisystem, Speicher, Hardware, Leistungstests, Programmausfuehrung, diverse Befehle, Anwendungen und tranZPUter-Befehle sind identisch mit der englischen Version und werden dort aufgelistet.

autoexec.bat

Wie bei MSDOS wird, wenn eine Datei mit dem Namen 'AUTOEXEC.BAT' im Stammverzeichnis (oberste Ebene) des SD-Dateisystems erstellt wird, deren Inhalt bei zOS beim Booten/Reset ausgefuehrt. Verwenden Sie diese Datei, um die Einrichtung und den Start Ihrer beabsichtigten Anwendung zu automatisieren.

Technische Details

Dieser Abschnitt zielt darauf ab, einige der inneren Details des Betriebssystems zu liefern.

Speicherorganisation

IOCP Memory Map

zOS wird im Allgemeinen in seiner eigenstaendigen Version verwendet, d.h. das Betriebssystem bootet als primaere Firmware. Fuer Abwaertskompatibilitaet oder zur Unterstuetzung einer schnelleren Entwicklung von zOS auf der ZPU kann IOCP als Bootloader zum Bootstrappen eines zOS-Images von der SD-Karte verwendet werden.

zOS Memory Map

zOS auf der ZPU hat die Speicherbelegung wie im folgenden Diagramm gezeigt. zOS befindet sich im unteren BRAM als Boot-Firmware mit Stack/Heap am oberen Ende des nutzbaren BRAM (oder RAM/SDRAM). Eine Anwendung wird an der im Build-Skript definierten Adresse geladen.

Die Speicherbelegungskarte fuer den K64F-Prozessor ist aehnlich, aber Flash-RAM und RAM sind fest definiert und nicht variabel wie bei der ZPU.

Anwendungsschnittstelle

Wie die meisten Betriebssysteme stellt zOS eine API bereit, die eine entsprechend kompilierte Anwendung nutzen kann, um ihre Groesse und Komplexitaet zu verringern und Funktionen innerhalb des Betriebssystems wie die serielle Verbindung wiederzuverwenden.

Anstatt einen benutzerdefinierten API-Satz zu entwerfen, war es sinnvoller, Methoden innerhalb von zOS fuer die Anwendung freizugeben, z.B. printf. Eine Anwendung, die printf aufruft, um Ausgaben auf dem Terminal anzuzeigen, ruft tatsaechlich printf innerhalb von zOS auf. Dies wird durch Erstellen einer Sprungtabelle an einem festen Vektor innerhalb von zOS ermoeglicht.

Die vollstaendige API-Vektortabelle (93 Vektoren einschliesslich Character-I/O, formatierter I/O, Dateisystem-Operationen, Festplatten-I/O, Speicherverwaltung, Z80-Bus-Operationen und mehr) ist identisch mit der englischen Version und wird dort vollstaendig aufgelistet.

Die Anwendungsvorlage verwendet den Prototypen:

 uint32_t app(uint32_t param1, uint32_t param2)

param1 und param2 koennen beliebige 32-Bit-Werte sein, die beim Aufruf von fileExec in zOS uebergeben werden. Unter normalen Betriebsbedingungen ruft zOS eine Anwendung mit nur einem Parameter auf, param1, der ein (char *)-Zeiger auf die Kommandozeilenparameter ist.

Der Rueckgabecode der Anwendung an zOS ist eine 32-Bit-Ganzzahl ohne Vorzeichen. 0 bedeutet erfolgreiche Ausfuehrung, 0xFFFFFFFF zeigt einen Fehler an.

Automatische Einrichtung und Erstellung (empfohlen)

Der empfohlene Weg, zOS zu erstellen, ist das automatische Einrichtungsskript fuer Ihre Plattform. Es prueft und installiert die Voraussetzungen, installiert die ZPU-Toolchain, klont das Repository (falls Sie sich nicht bereits in einem Checkout befinden) und bietet an, die erste Erstellung durchzufuehren — mit sinnvollen Vorgaben, die Sie durch Druecken der Eingabetaste uebernehmen koennen. Jedes Skript ist eigenstaendig: kopieren Sie einfach die einzelne Datei fuer Ihre Plattform und fuehren Sie sie aus. Die manuellen Schritte weiter unten sind fuer fortgeschrittene Benutzer, partielle Neuerstellungen und CI gedacht.

Die Erstellung wird von build.sh gesteuert, das IOCP, zOS und die Apps fuer eine gewaehlte CPU in einem einzigen Durchgang assembliert/kompiliert. Zwei Toolchains sind beteiligt und die Einrichtungsskripte stellen beide bereit:

Toolchain	Ziel-CPU	Quelle
ZPU zpu-elf-gcc 3.4.2	Small Medium Flex Evo EvoMin (ZPU)	installiert nach /opt/zpu (aus ZPU_TOOLCHAIN_URL)
ARM arm-none-eabi	K64F (Kinetis / Teensy 3.5)	im Repository unter tools/arm mitgeliefert (keine Installation)

Da beide Toolchains Linux- / Cross-Binaerdateien sind, laeuft die Erstellung nativ unter Linux, in Docker unter macOS (Image zos-build:latest) und via WSL1 unter Windows:

Skript	Plattform	Hinweise
setup_zOS.sh	Linux (nativ) / macOS (Docker)	Installiert die Basis-Build-Tools + die ZPU-Toolchain; unter macOS erfolgt die Erstellung im zos-build:latest Docker-Image.
setup_zOS_windows.cmd	Windows 10 / 11	Per Doppelklick startbarer Launcher, der das untenstehende PowerShell-Skript aufruft.
setup_zOS_windows_native.ps1	Windows 10 / 11 (WSL1)	Richtet WSL1 ein und fuehrt die Linux-Einrichtung darin aus.
setup_zOS_wsl1.sh	innerhalb WSL1	Der Linux-Einrichtungsschritt, der automatisch innerhalb der WSL1-Distribution aufgerufen wird.

Linux / macOS — setup_zOS.sh

chmod +x setup_zOS.sh
./setup_zOS.sh

Windows 10 / 11 — setup_zOS_windows_native.ps1 — Doppelklick auf setup_zOS_windows.cmd, oder von einer PowerShell-Eingabeaufforderung:

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

Die Einrichtung klont ZOS_REPO_URL (Standard https://git.eaw.app/eaw/zOS.git) nach ~/zOS. Sobald sie fertig ist, erstellen Sie zOS mit (build.sh waehlt automatisch nativ / Docker / WSL1 fuer den 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 ...)

Die Ausgaben landen unter build/ und build/SD/ — das Boot-ROM (BOOT.ROM / BOOTTINY.ROM), der IOCP_<func>_<addr>.bin-Bootloader und die zOS-.bin, dazu die bin/-App-Binaerdateien, bereit zum Kopieren auf eine FAT-formatierte SD-Karte.

Nuetzliche Umgebungsvariablen-Ueberschreibungen:

Variable	Zweck
ZOS_REPO_URL	Zu klonendes Repository (Standard https://git.eaw.app/eaw/zOS.git).
ZOS_DIR	Erstellung innerhalb eines vorhandenen Checkouts statt Klonen.
ZPU_TOOLCHAIN_URL	Speicherort des zpu-elf-gcc 3.4.2 Toolchain-Tarballs, installiert nach /opt/zpu.
ZOS_BUILD_IMAGE	Docker-Image fuer die macOS-Erstellung (Standard zos-build:latest).
ZOS_ASSUME_YES=1	Alle Abfragen nicht-interaktiv bestaetigen (unbeaufsichtigte / CI-Installationen).

Wenn Sie lieber von Hand erstellen oder eine CI-Pipeline skripten, ist die manuelle Erstellung — die Pfade, die Werkzeugliste, der Build-Tree und die vollstaendige build.sh-Flag-Matrix — im Abschnitt Software Build direkt darunter dokumentiert.

Software-Build

Dieser Abschnitt zeigt, wie ein einfacher zOS-Kernel erstellt wird. Der Ausgangspunkt fuer den Build von zOS ist das ‘build.sh’-Skript, das die gesamte erforderliche Logik enthaelt.

Pfade

Die vollstaendige Pfadtabelle, Werkzeugliste und Build-Tree-Dokumentation sind identisch mit der englischen Version und werden dort detailliert beschrieben.

Werkzeuge

Alle Entwicklung erfolgte unter Linux, insbesondere Debian/Ubuntu. Neben der Standard-Linux-Buildchain wird folgende Software benoetigt:

• ZPU GCC ToolChain - Die GCC-Toolchain fuer die ZPU-Entwicklung. Installation in /opt oder einem aehnlichen gemeinsamen Verzeichnis.
• Arduino - Die Arduino-Entwicklungsumgebung, nicht wirklich erforderlich, ausser wenn Funktionen zur K64F-Version von zOS hinzugefuegt werden.
• Teensyduino - Die Teensy3 Arduino-Erweiterungen fuer die Arbeit mit dem Teensy3.5 Board.

Die vollstaendige Build-Tree-Struktur, build.sh-Parameter und Beispiele finden Sie in der englischen Version.