Zeal 8 bit OS
v0.5.0
*Wenn die Parameter des Benutzerprogramms auf einen Teil des Speichers in Seite 3 (letzte Seite) hinweisen, gibt es einen Konflikt, da der Kernel während einer Zusammenfassung immer seine RAM -Seite innerhalb derselben Seite zuordnet. Daher wird die Benutzerseite 3 in Seite 2 (dritte Seite) umgerecht, um auf die Parameter des Programms zuzugreifen. Falls die Parameter Zeiger sind, werden sie natürlich geändert, damit sie auf die neue virtuelle Adresse hinweisen (mit anderen Worten, ein Zeiger wird von 16 KB abgezogen, damit sie auf Seite 2 verweist).
Um das 8-Bit-Betriebssystem von Eifer auf Z80-basierte Computer mit einem MMU/Memory-Mapper wie oben gezeigt zu haben, verfügt der Kernel über einen neuen Modus, der über das menuconfig : No-MMU ausgewählt werden kann.
In diesem Modus wird erwartet, dass der OS -Code immer noch in den ersten 16 KB des Speichers von 0x0000 bis 0x3FFF abgebildet wird und der Rest RAM ist.
Im Idealfall sollten 48 KB RAM ab 0x4000 abgebildet werden und würde auf 0xFFFF gehen. In der Praxis ist es jedoch möglich, den Kernel so zu konfigurieren, dass es weniger als das erwartet. Dazu müssen zwei Einträge im menuconfig entsprechend konfiguriert werden:
KERNEL_STACK_ADDR : Dies markiert das Ende des Kernel -Widdergebiets und wird, wie der Name sagt, der Boden des Kernel -Stapels sein.KERNEL_RAM_START : Dies markiert die Startadresse des Kernel -Rams, in dem der Stapel, alle Variablen, die vom Kernel und den Treiber verwendet werden, gespeichert werden. Natürlich muss es groß genug sein, all diese Daten zu speichern. Für Informationen beträgt der aktuelle Kernel BSS -Abschnittsgröße etwa 1 KB. Die Stacktiefe hängt von der Implementierung der Zielfahrer ab. Die Zuordnung von 1 KB für den Stapel sollte mehr als genug sein, solange keine (großen) Puffer darauf aufbewahrt werden. Insgesamt sollte die Zuweisung von mindestens 3 KB für den Kernel-Widder sicher und zukunftssicher sein.Zusammenfassend ist hier ein Diagramm, um die Verwendung der Erinnerung zu zeigen:
In Bezug auf die Benutzerprogramme wird die Stack -Adresse immer vor der Ausführung auf KERNEL_RAM_START - 1 vom Kernel eingestellt. Es entspricht auch der Adresse seines letzten in seinem verwendbaren Adressraum verfügbaren Byte. Dies bedeutet, dass ein Programm die Größe des verfügbaren RAM ermitteln kann, indem sie SP - 0x4000 durchführen, was in der Montage:
ld hl, 0
add hl, sp
ld bc, -0x4000
add hl, bc
; HL contains the size of the available RAM for the program, which includes the program's code and its stack.
Z80 präsentiert mehrere allgemeine Register, nicht alle werden im Kernel verwendet. Hier ist der Umfang von jedem von ihnen:
| Registrieren | Umfang |
|---|---|
| Af, bc, de, hl | System & Anwendung |
| Af ', bc', de ', hl' | Interrupt Handler |
| Ix, iy | Anwendung (im Betriebssystem nicht genutzt) |
Dies bedeutet, dass das Betriebssystem IX und IY -Register nicht verändert, sodass sie in der Anwendung frei verwendet werden können.
Die alternativen Register (Namen, gefolgt von ' ) dürfen nur in den Interrupt -Handlern 1 verwendet werden. Eine Anwendung sollte diese Register nicht verwenden. Wenn Sie sie aus irgendeinem Grund noch verwenden müssen, sollten Sie die Interrupts während der Zeit, in der sie verwendet werden, deaktivieren:
my_routine:
di ; disable interrupt
ex af, af' ; exchange af with alternate af' registers
[...] ; use af'
ex af, af' ; exchange them back
ei ; re-enable interrupts
Denken Sie daran, dass das Deaktivieren der Interrupts zu lange schädlich sein kann, da das System kein Signal von Hardware (Timer, Tastatur, GPIOs ...) erhält.
Der Z80 bietet 8 verschiedene Reset -Vektoren, da das System immer auf der ersten virtuellen Speicherseite gespeichert werden soll. Diese sind alle für das Betriebssystem reserviert:
| Vektor | Verwendung |
|---|---|
| $ 00 | Software Reset |
| $ 08 | Symall |
| $ 10 | Springt zur Adresse in HL (kann zum Aufrufen von HL verwendet werden) |
| $ 18 | Unbenutzt |
| $ 20 | Unbenutzt |
| $ 28 | Unbenutzt |
| $ 30 | Unbenutzt |
| $ 38 | Reserviert für den Interrupt -Modus 1, der von der Zielimplementierung verwendet werden kann |
Wenn ein Benutzerprogramm ausgeführt wird, weist der Kernel 3 Seiten RAM (48 KB) zu, liest die Binärdatei zum Ausführen und lädt sie standardmäßig mit der virtuellen Adresse 0x4000 . Diese virtuelle Einstiegspunktadresse kann über das menuconfig mit Option KERNEL_INIT_EXECUTABLE_ADDR konfiguriert werden. Beachten Sie jedoch, dass vorhandene Programme nicht mehr funktionieren, ohne erneut kompiliert zu werden, da sie zur Laufzeit nicht verlängert werden können.
Wie nachstehend beschrieben, nimmt die exec zwei Parameter an: einen Binärdateinamen zum Ausführen und einen Parameter.
Dieser Parameter muss eine null-terminierte Zeichenfolge sein, die kopiert und an die Binärdatei übertragen wird, um durch Register DE und BC auszuführen:
DE enthält die Adresse der Zeichenfolge. Diese Zeichenfolge wird in den Speicherplatz des neuen Programms kopiert, normalerweise über dem Stapel.BC enthält die Länge dieser Saite (also ohne Null-byte). Wenn BC 0 ist, muss DE vom Benutzerprogramm verworfen werden. Das System stützt sich auf Syscalls, um Anfragen zwischen dem Benutzerprogramm und dem Kernel durchzuführen. Dies ist daher der Weg, um Operationen auf der Hardware auszuführen. Die möglichen Vorgänge sind in der folgenden Tabelle aufgeführt.
| Num | Name | Param. 1 | Param. 2 | Param. 3 |
|---|---|---|---|---|
| 0 | lesen | U8 Dev | U16 buf | U16 Größe |
| 1 | schreiben | U8 Dev | U16 buf | U16 Größe |
| 2 | offen | U16 Name | U8 -Flaggen | |
| 3 | schließen | U8 Dev | ||
| 4 | dstat | U8 Dev | U16 dst | |
| 5 | Stat | U16 Name | U16 dst | |
| 6 | suchen | U8 Dev | U32 Offset | U8 wo |
| 7 | ioctl | U8 Dev | U8 CMD | U16 arg |
| 8 | Mkdir | U16 Pfad | ||
| 9 | Chdir | U16 Pfad | ||
| 10 | Curdir | U16 Pfad | ||
| 11 | Opendir | U16 Pfad | ||
| 12 | Readdir | U8 Dev | U16 dst | |
| 13 | rm | U16 Pfad | ||
| 14 | montieren | U8 Dev | U8 Brief | U8 fs |
| 15 | Ausfahrt | U8 -Code | ||
| 16 | Geschäftsführer | U16 Name | u16 argv | |
| 17 | DUP | U8 Dev | U8 ndev | |
| 18 | msleep | U16 Dauer | ||
| 19 | SetTime | u8 id | U16 Zeit | |
| 20 | GetTime | u8 id | U16 Zeit | |
| 21 | Setdate | U16 Datum | ||
| 22 | Getdate | U16 Datum | ||
| 23 | Karte | U16 dst | U24 SRC | |
| 24 | tauschen | U8 Dev | U8 ndev |
Bitte überprüfen Sie den Abschnitt unten, um weitere Informationen zu jedem dieser Anrufe und deren Parameter zu erhalten.
HINWEIS : Einige Anpassungen können nicht implementiert sein. Zum Beispiel können auf Computern, auf denen Verzeichnisse nicht unterstützt werden, Verzeichnisse im Zusammenhang mit Verzeichnissen weggelassen werden.
Um eine SYSCall durchzuführen, muss die Betriebsnummer in Register L gespeichert werden. Die Parameter müssen nach diesen Regeln gespeichert werden:
| Parametername in der API | Z80 Register |
|---|---|
| U8 Dev | H |
| U8 ndev | E |
| U8 -Flaggen | H |
| U8 CMD | C |
| U8 Brief | D |
| U8 -Code | H |
| U8 fs | E |
| u8 id | H |
| U8 wo | A |
| U16 buf | DE |
| U16 Größe | BC |
| U16 Name | BC |
| U16 dst | DE |
| U16 arg | DE |
| U16 Pfad | DE |
| u16 argv | DE |
| U16 Dauer | DE |
| U16 Zeit | DE |
| U16 Datum | DE |
| U24 SRC | HBC |
| U32 Offset | BCDE |
Und schließlich muss der Code eine RST $08 ausführen (bitte überprüfen Sie die Reset -Vektoren).
Der zurückgegebene Wert ist in A aufgebracht.
Um die Kompatibilität der Benutzerprogramme mit dem Eifer 8-Bit-OS-Kernel zu maximieren, unabhängig davon, ob der Kernel im MMU- oder NO-MMU-Modus kompiliert wurde, sind die SYSCalls-Parameterbeschränkungen dieselben:
Jeder an eine System übergebene Puffer darf keine 16 -KB -virtuellen Seiten überqueren
Mit anderen Worten, wenn sich ein Puffer buf der Größe n in virtueller Seite i befindet, muss sein letzter Byte, der von buf + n - 1 gezeigt wird, ebenfalls genau auf derselben Seite i gefunden werden.
Zum Beispiel, wenn read aufgerufen wird mit:
DE = 0x4000 und BC = 0x1000 sind die Parameter korrekt , da der Puffer, der von DE anpasst, in Seite 1 (von 0x4000 bis 0x7FFF ) gezeigt wird.DE = 0x4000 und BC = 0x4000 sind die Parameter korrekt , da der Puffer, der von DE anpasst, in Seite 1 (von 0x4000 bis 0x7FFF ) gezeigt wird.DE = 0x7FFF und BC = 0x2 sind die Parameter falsch , da der von DE gezeigte Puffer zwischen Seite 1 und Seite 2 ist.exec Obwohl Eifer 8-Bit-Betriebssystem ein Mono-Tasking-Betriebssystem ist, kann es mehrere Programme im Speicher ausführen und aufbewahren. Wenn ein Programm A dank der SYSCall aus der exec ein Programm B ausführt, muss es einen mode bereitstellen, der entweder EXEC_OVERRIDE_PROGRAM oder EXEC_PRESERVE_PROGRAM sein kann:
EXEC_OVERRIDE_PROGRAM : Diese Option gibt dem Kernel mit, dass das Programm A nicht mehr ausgeführt werden muss, sodass das Programm B in denselben Adressraum wie Programm A geladen wird. Mit anderen Worten, das Programm B wird in denselben RAM -Seiten wie Programm A geladen, es überschreibt es.EXEC_PRESERVE_PROGRAM : Diese Option gibt dem Kernel mit, dass das Programm A im RAM aufbewahrt werden muss, bis Programm B seine Ausführung beendet und die SYSCALL exit aufruft. Zu diesem Zweck wird der Kernel 3 neue Speicherseiten ( 16KB * 3 = 48KB ) zuteilt, in denen er ein neu geladenes Programm B speichert. Sobald das Programm B beendet ist, befreit der Kernel die zuvor zugewiesenen Seiten für das Programm B, den Speicherseiten von Remaps Program A und geben den Speicherseiten des Programms zurück. Die Tiefe des Ausführungsbaums ist dank der Option CONFIG_KERNEL_MAX_NESTED_PROGRAMS in der menuconfig definiert. Es repräsentiert die maximale Anzahl von Programmen, die gleichzeitig in RAM gespeichert werden können. Wenn beispielsweise die Tiefe 3 beträgt, kann Programm A CAN -Programm B, Programm B das Programm C anrufen, das Programm C jedoch kein anderes Programm aufrufen kann. Wenn ein Programm jedoch exec mit EXEC_OVERRIDE_PROGRAM aufruft, wird die Tiefe nicht erhöht, da das neue Programm zum Laden die aktuelle überschreibt. Wenn wir das vorherige Beispiel zurücknehmen, kann das Programm C ein Programm nur dann aufrufen, wenn es den exec -Syscall im Modus EXEC_OVERRIDE_PROGRAM aufruft.
Seien Sie vorsichtig, wenn Sie ein Unterprogramm ausführen, werden die gesamte geöffnete Gerätetabelle (einschließlich Dateien, Verzeichnisse und Treiber), das aktuelle Verzeichnis und die CPU-Register gemeinsam genutzt .
Dies bedeutet, dass das Programm B diesen Index erben und somit auch diesen Deskriptor erben und somit auch in der Lage ist, diesen Index zu lesen, zu schreiben oder sogar zu schließen. Wenn B gegen BIL ein Verzeichnis, ein Verzeichnis oder einen Treiber öffnet und ohne Schließung ausgeht, hat Programm A auch Zugriff darauf. Daher lautet die allgemeine Richtlinie, dass ein Programm vor dem Verlassen immer die eröffneten Deskriptoren schließen muss. Der einzige Moment, in dem die Tabelle der geöffneten Geräte und des aktuellen Verzeichnisses zurückgesetzt wird, ist, wenn das erste Programm (Programm A im vorherigen Beispiel) verlässt. In diesem Fall schließt der Kernel alle Deskriptoren in der Tabelle geöffneter Geräte, öffnen Sie die Standardeingabe und -ausgabe und laden das erste Programm neu.
Dies bedeutet auch, dass beim Aufrufen der exec in einem Montageprogramm zum Erfolg alle Register, mit Ausnahme von HL, als verändert angesehen werden müssen, da sie vom Subprogramm verwendet werden. Wenn Sie also AF , BC , DE , IX oder IY bewahren möchten, müssen sie auf den Stapel gedrückt werden, bevor sie exec anrufen.
Die Systeme sind alle in den Header -Dateien dokumentiert, die sowohl für die Montage als auch für C bereitgestellt werden. Sie finden diese Header -Datei im kernel_headers/ Verzeichnis. Weitere Informationen finden Sie in der LEADME -Datei.
Ein Fahrer besteht aus einer Struktur, die enthält:
SER0 , SER1 , I2C0 usw. Nicht-ASCII-Zeichen zulässig, aber nicht empfohlen.init -Routine, die als Kernelstiefel aufgerufen wird.read , wobei Parameter und Rückgabedresse dieselben sind wie in der Syscall -Tabelle.write , wie oben.open Routine, wie oben.close Routine, wie oben.seek , wie oben.ioctl -Routine, wie oben.deinit -Routine, die beim Entladen des Fahrers aufgerufen wird.Hier ist das Beispiel einer einfachen Treiberregistrierung:
my_driver0_init:
; Register itself to the VFS
; Do something
xor a ; Success
ret
my_driver0_read:
; Do something
ret
my_driver0_write :
; Do something
ret
my_driver0_open :
; Do something
ret
my_driver0_close :
; Do something
ret
my_driver0_seek :
; Do something
ret
my_driver0_ioctl :
; Do something
ret
my_driver0_deinit :
; Do something
ret
SECTION DRV_VECTORS
DEFB "DRV0"
DEFW my_driver0_init
DEFW my_driver0_read
DEFW my_driver0_write
DEFW my_driver0_open
DEFW my_driver0_close
DEFW my_driver0_seek
DEFW my_driver0_ioctl
DEFW my_driver0_deinit Die Registrierung eines Treibers besteht darin, diese Informationen (Struktur) in einen Abschnitt namens DRV_VECTORS einzulegen. Die Bestellung ist sehr wichtig, da jede Fahrerabhängigkeit zur Kompilierungszeit gelöst wird. Wenn der Treiber A beispielsweise vom Treiber B abhängt, muss die Struktur von B in den Abschnitt DRV_VECTORS vor A gestellt werden.
Beim Booten stöbert die driver im Abschnitt DRV_VECTORS und initialisiert die Treiber einzeln, indem Sie ihre init -Routine aufrufen. Wenn diese Routine ERR_SUCCESS zurückgibt, wird der Treiber registriert und Benutzerprogramme können sie öffnen, lesen, schreiben, ioctl usw.
Ein Treiber kann den Programmen versteckt werden. Dies ist für Festplattentreiber praktisch, auf die nur die Dateisystemschicht des Kernels zugegriffen werden muss. Dazu sollte die init -Routine ERR_DRIVER_HIDDEN zurückgeben.
Da die Kommunikation zwischen Anwendungen und Hardware durch die oben beschriebenen sympolitischen symfizienrechtlichen Syscalls erfolgt, benötigen wir eine Ebene zwischen der Benutzeranwendung und dem Kernel, mit dem festgelegt wird, ob wir einen Treiber oder ein Dateisystem aufrufen müssen. Bevor wir die Hierarchie einer solchen Architektur zeigen, sprechen wir über Datenträger und Fahrer.
Die verschiedenen Schichten sind so zu sehen:
Flussdiagramm TD;
App (Benutzerprogramm)
VFS (virtuelles Dateisystem)
DSK (Festplattenmodul)
DRV (Treiberimplementierung: Video, Tastatur, Serie usw.)
FS (Dateisystem)
sysdis (SYSCALL -Dispatcher)
HW (Hardware)
Zeit (Zeit- und Datumsmodul)
MEM (Speichermodul)
Loader (Ladermodul)
App -SYSCALL/RST 8 -> SYSDIS;
sysdis --getdate/Zeit-> Zeit;
sysdis-mont-> dsk;
sysdis -> vfs;
sysdis--map-> mem;
sysdis -exec/exit -> lader;
VFS -> DSK & DRV;
dsk <-> fs;
FS -> DRV;
DRV -> HW;
Das 8-Bit-OS von Eifer unterstützt bis zu 26 Festplatten gleichzeitig. Die Festplatten werden durch einen Brief von A bis Z bezeichnet. Es liegt in der Verantwortung des Disk -Fahrers, zu entscheiden, wo die Festplatte im System montiert werden soll.
Das erste Laufwerk A ist etwas Besonderes, da das System nach Einstellungen oder Konfigurationen sucht.
In einer Anwendung kann ein path sein:
my_dir2/file1.txt/my_dir1/my_dir2/file1.txtB:/your_dir1/your_dir2/file2.txt Auch wenn das Betriebssystem völlig romabil ist und kein Dateisystem oder eine Festplatte benötigt, um das erste Programm mit dem Namen init.bin standardmäßig zu laden, wird es auf die Standardscheibe prüft und diese Datei anfordert. Daher benötigt auch der grundlegendste Speicher ein Dateisystem oder ähnliches.
Das erste "Dateisystem", das bereits implementiert ist, heißt "Rawtable". Wie der Name sagt, repräsentiert es die Nachfolge von Dateien, nicht von Verzeichnissen in einem Speichergerät in keiner bestimmten Reihenfolge. Die Dateinamengrößengrenze entspricht dem Kernel: 16 Zeichen, einschließlich des optionalen . und Erweiterung. Wenn wir es mit C -Code vergleichen möchten, wäre es ein Array von Strukturen, die jede Datei definieren, gefolgt vom Inhalt der Datei in derselben Reihenfolge. Ein ROMDISK Packer -Quellcode ist im packer/ am Stamm dieses Repo erhältlich. Weitere Informationen dazu finden Sie in der Readme.
Das ebenfalls implementierte zweite Dateisystem heißt Zealfs. Sein Hauptzweck ist es, in sehr kleine Speicher eingebettet zu werden, von 8 KB bis 64 KB. Es ist lesbar und beschreibbar, es unterstützt Dateien und Verzeichnisse. Weitere Informationen dazu im speziellen Repository.
Das dritte Dateisystem, das schön auf dem Eifer 8-Bit-Betriebssystem zu haben wäre, ist FAT16. Sehr berühmt, bereits von fast allen Desktop-Betriebssystemen unterstützt, die auf CompactFlash- und sogar SD-Karten verwendet werden können, ist dies fast ein Muss. Es wurde noch nicht umgesetzt, aber es ist geplant. FAT16 ist jedoch nicht perfekt, da es nicht für kleine Lagerung angepasst ist. Aus diesem Grund wird Eisealfs benötigt.
Das 8-Bit-Betriebssystem für Eifer basiert auf zwei Hauptkomponenten: einem Kernel und einem Zielcode. Allein der Kernel tut nichts. Das Ziel muss die Treiber, einige MMU -Makros im Kernel und ein Linker -Skript implementieren. Das Linker -Skript ist ziemlich einfach, es listet die Abschnitte in der Reihenfolge auf, die sie im endgültigen Binary vom z80asm -Assembler verknüpft werden müssen.
Der Kernel verwendet derzeit die folgenden Abschnitte, die in jedem Linker -Skript enthalten sein müssen:
RST_VECTORS : Enthält die Reset -VektorenSYSCALL_TABLE : Enthält eine Tabelle, in der die SYSCALL i -Routineadresse unter dem Index i gespeichert ist, muss auf 256 ausgerichtet seinSYSCALL_ROUTINES : Enthält den Syscall -Dispatcher, der aus einem Reset -Vektor bezeichnet wirdKERNEL_TEXT : Enthält den KernelcodeKERNEL_STRLIB : Enthält die im Kernel verwendeten String-RoutinenKERNEL_DRV_VECTORS : Repräsentiert ein Array von Treibern zum Initialisieren und prüfen Sie den Treiberabschnitt für weitere Details.KERNEL_BSS : Enthält die vom Kernel -Code verwendeten Daten, müssen im RAM enthalten seinDRIVER_BSS : Nicht direkt vom Kernel verwendet, sondern in den Treibern definiert und verwendet werden. Der Kernel setzt es auf 0s im Boot, es muss größer sein als 2 Bytes Wie bereits erwähnt, ist der 8-Bit-Computerunterstützung für den Eifer immer noch teilweise, aber genug, um ein Befehlszeilenprogramm auszuführen. Der Romdisk wird erstellt, bevor der Kernel erstellt wird target/zeal8bit/unit.mk Dies erfolgt im script.sh .
Dieses Skript wird das init.bin -Programm kompilieren und es in einen Romdisk einbetten, der mit dem kompilierten Betriebssystem -Binary verkettet wird. Die endgültige Binärdatei kann direkt auf den Nor Flash geblitzt werden.
Was noch implementiert werden muss, in keiner bestimmten Reihenfolge:
Es wurde ein kurzer Port-Port-I-Computer für den TRS-80-Modell-I-Computer erstellt, um zu zeigen, wie das 8-Bit-Betriebssystem für das 8-Bit-Betriebssystem für Ziele, die keine MMU haben, portieren und konfigurieren können.
Dieser Port ist ziemlich einfach, da er einfach das Boot -Banner auf dem Bildschirm anzeigt, nichts weiter. Zu diesem Zweck wird nur ein Videotreiber für den Textmodus implementiert.
Um einen interessanteren Port zu haben, müssten die folgenden Funktionen implementiert werden:
init.bin /romdisk kann schreibgeschützt sein und kann also auf dem ROM gespeichert werdenEin Port zum EZ80 -Antriebslicht, geschrieben und gepflegt von Shawn Sijnstra. Nutzen Sie diese Gabel für agonspezifische Fehler/Anfragen. Dies verwendet den Nicht-MMU-Kernel und implementiert die meisten Funktionen, die die 8-Bit-Computer-Implementierung von Eifer unterstützt.
Dieser Port erfordert einen Lader, damit die Binärdatei vom richtigen Ort gespeichert und ausgeführt werden kann. Das Binärdat ist Osbootz, hier erhältlich.
Beachten Sie, dass der Port den Terminalmodus verwendet, um die Tastatur -E/A zu vereinfachen. Dies bedeutet auch, dass die Datumsfunktion nicht verfügbar ist.
Andere bemerkenswerte Merkmale:
Um eine 8-Bit-OS-MMU-Version für eine andere Maschine zu portieren, stellen Sie sicher, dass Sie zuerst einen Speicher-Mapper haben, der den 64-KB-Adressraum des Z80 in 4 Seiten von 16 KB für die MMU-Version unterteilt.
Stellen Sie sicher, dass RAM aus der virtuellen Adresse 0x4000 und höher verfügbar ist, um den Port No-MMU Eifer 8-Bit-Betriebssystem zu vermitteln. Der idealste Fall ist, dass ROM die ersten 16 KB für das Betriebssystem und RAM in den verbleibenden 48 KB für die Benutzerprogramme und den Kernel -RAM ist.
Wenn Ihr Ziel kompatibel ist, befolgen Sie die Anweisungen:
Kconfig -Datei im Root dieses Repo und fügen Sie den Optionen für das config TARGET und config COMPILATION_TARGET einen Eintrag hinzu. Nehmen Sie die bereits vorhandenen als Beispiele.target/ für Ihr Ziel. Der Name muss mit dem in der neuen config TARGET angegeben sein.unit.mk -Datei. Dies ist die Datei, die alle Quellendateien enthalten muss, die zusammengestellt werden sollen, oder die, die enthalten sind.unit.mk -Datei. Dazu können Sie die folgenden Variablen make :SRCS : Liste der zu montierten Dateien. In der Regel sind dies die Treiber (obligatorisch)INCLUDES : die Verzeichnisse mit Header -Dateien, die enthalten sein könnenPRECMD : Ein Bash -Befehl, der vor dem Bauen des Kernels ausgeführt werden sollPOSTCMD : Ein Bash -Befehl, der nach dem Kernel -Gebäude ausgeführt werden sollmmu_h.asm -Datei, die vom Kernel zum Konfigurieren und Verwenden der MMU enthalten ist. Überprüfen Sie das target/zeal8bit/include/mmu_h.asm um zu sehen, wie es aussehen sollte.zos_disks_mount eine init.bin -Datei enthält, die vom Kernel auf dem Start geladen und ausgeführt wird.zos_vfs_set_stdout registriert.Für den vollständigen ChangeLog überprüfen Sie bitte die Release -Seite.
Beiträge sind willkommen! Fühlen Sie sich frei, jeden Fehler zu beheben, den Sie möglicherweise sehen oder begegnen, oder implementieren Sie jede Funktion, die Sie für wichtig halten.
Dazu beitragen:
(*) Eine gute Commit -Nachricht lautet wie folgt:
Module: add/fix/remove a from b
Explanation on what/how/why
Zum Beispiel:
Disks: implement a get_default_disk routine
It is now possible to retrieve the default disk of the system.
Unter der Apache 2.0 -Lizenz verteilt. Weitere Informationen finden Sie unter LICENSE .
Sie können es frei für den persönlichen und kommerziellen Gebrauch verwenden. Die in jeder Datei vorhandene Kesselplatte darf nicht entfernt werden.
Für einen Vorschlag oder eine Anfrage können Sie mich unter Kontakt [at] Zeal8bit [dot] com kontaktieren
Für Feature -Anfragen können Sie auch ein Problem oder eine Pull -Anfrage eröffnen.
Sie dürfen dennoch nicht als nichtflüchtig angesehen werden. Mit anderen Worten, ein Interrupt -Handler darf nicht davon ausgehen, dass die Daten, die er in einem alternativen Register geschrieben hat, bis zum nächsten Anruf aufbewahrt werden. ↩
