AiCOS

Aus Lowlevel
Version vom 11. Juli 2009, 01:51 Uhr von ScollPi (Diskussion | Beiträge) (History-Update; Systemkern bestehend aus mehreren Mikrokernels)
Wechseln zu:Navigation,
AiCOS-Logo-small.png
Entwickler: ScollPi
Akt. Version: Research Phase 0 (0.00.38.57)
Lizenz: n/a
OS-Eigenschaften
Plattform: x86 (später auch x64)
Kernelart: Modulares Kernel System (MKS)
Sprache: Assembler, C/C++
API: n/a
Binärformat: BIN, (event. EXE)
IPC-Methode: Channels
Homepage
In Planung


AiCOS ist als ein Betriebssystem geplant, welches Anfangs für Aufgaben im Netzwerkbereich fungieren soll, unter anderem auch als Storage-System. Dabei wird es gezielt auf Multiprozessor bzw. Multicore-System operieren. Ob es auch den Sprung in ein Cluster schafft, wird sich dann zeigen. Aber erst einmal alles Schritt für Schritt, begonnen mit einem Singlecore-System.

AiCOS soll frisches Blut (über eine genauere Definition werde ich noch grübeln) in die Computertechnik bringen, unter anderem ein eigenes FS, eigenes Netzwerkprotokoll und eine eigene Programmiersprache ... wenn es klappt.

AiCOS Wurzel liegen weder in der Linux/Unix-Welt, weder in der Windows-Welt, sondern in Microsofts Singularity.

Dieses Projekt ist zur Zeit wegen eines anderen höher priorisierten Projekt angehalten. Dieses Projekt wird jedoch später fortgesetzt.


Entwicklungsumgebung


Testumgebung:

Es wird immer zuerst in der VM auf dem Entwicklungssystem getestet und erst wenn da alles ohne Probleme läuft, wird auf der realen Maschine getestet. Als Test-PC dient da einmal ein P2 mit müden 400 MHz als Single-Core, um vor allem die Boot-Phasen zu testen. OK, derzeit benutze ich einen Laptop mit P3 mit 1 GHz und satten 256 MiB RAM. Versehentlich auch mal Tests auf meinem Quad-Core, wenn ich vergessen habe die Diskette nach dem Testen rauszunehmen. Aber da zeigt sich schon, dass auf der realen Maschine alles genauso läuft wie bisher in der VM.


Konzept

Bootsektor

  • Der Bootsektor wird so geschrieben, dass es im Prinzip egal ist, an welcher Adresse dieser geladen und ausgeführt wird. Derzeit wird noch ein Fehlercode ausgeben und die Ausführung angehalten, wenn sich der Bootcode nicht an der Adresse 0x00007C00 befindet.
  • Für jedes FS (RAW, FAT, FAT32 und ISO9660) auf dem AiCOS zum Einsatz kommen wird, wird es einen entsprechenden Bootcode geben.
  • Die Aufgabe des Bootsektors sollte wohl ja klar sein, nämlich unabhängig vom Medium den Bootloader zu laden und auszuführen.

Bootloader

  • Protected-Mode
  • Paging mit Physical-Address-Extension (PAE), max. 64 GiByte
  • Soll erste Möglichkeiten des Kernel-Debugging ermöglichen.
  • Einrichten des MKS und laden bedingter Treiber.
    • Mikrokernel für den BSP (Boot Strap Processor).
    • Mikrokernel für jeden APs (Application Processors) ... nur bei MultiCore-Systemen.
    • Management-Kernel.
    • I/O-Kernel.
  • Startup des MKS und Channel-System.
    • Den BSP in den 32-Bit PM schalten und die Kontrolle über den Management-Kernel geben.

Kernel

  • MKS = Modulares Kernel System, unterteilt in:
    • Managemant-Kernel, verwaltet RAM und koordiniert die anderen Kernels für CPU, IO und Subsysteme.
    • CPU-Kernel, jeder Kern hat seinen eigenen Mikrokernel.
    • IO-Kernel.
    • Subsystem-Kernel, für weitere Treiber, Filter und und und ...
  • Soll in sich redundant werden, erfordert aber mind. 2 CPUs bzw. 2 CPU-Kerne.

Notiz: Zum besseren Verständnis meines Konzept ist eine visuelle Darstellung meines OS in Planung. Sie beinhaltet den Bootprozess und den Aufbau des MKS. Diese Visualisierungen werden überwiegend auf der Homepage von AiCOS zu finden sein, die sich derzeit noch im Aufbau befindet.


History

Die letzten 10 Änderungen:

  • 15.01.2009: Version 0.00.??.??
    • ROFS-Bootsektor-Code finalisiert, es kann nun auch eine Datei grö´ßer 64KiB geladen werden. Der Bootloader selbst wurde wegen seiner PM-Funktionalität auf 256 KiB beschränkt.
    • Suchen und Auslesen von MPS (FPS).
  • 14.01.2009: Version 0.00.38.57
    • Grundfunktionen des Memory-Management
    • Suchen und auslesen des PCI-BIOS.
    • Suchen und auslesen des PnP-BIOS.
    • Suchen und auslesen von ACPI.
    • Problematische unerklärbarer Bug im Bootsektor-Code (ROFS) behoben.
  • 11.01.2009 SMAP hinzugefügt.
  • 04.01.2009 Bug im Bootcode behoben; Kernel-Debug implementiert (0.00.35.47)
  • 03.01.2009 Printf implementiert (0.00.34.45)
  • 03.01.2009 C++ Testdummy, um Einsprung zu testen; Test OK (0.00.31.40)
  • 02.01.2009 Paging mit PAE implementiert. (0.00.24.23)
  • 01.01.2009 Bootloader prüft die CPU, da mindestens ein 586er benötigt wird. (0.00.23.20)
  • 01.01.2009 Bug im Bootcode behoben; Bootloader gibt Meldung aus. (0.00.22.16)
  • 01.01.2009 Fehler beim Sprung in den PM behoben, FDD-Motor wird nun auch abgeschaltet. (0.00.21.6)
  • 31.12.2008 Bootsektor: Umadressierung, da Probleme mit dem PM. (0.00.20.5)

Komplette History: http://aicos.amazing-fx.de/history.txt


Statistik

Die folgende Statistik zählte folgende Datei-Typen:

  • Build-System-Dateien (.cmd, .vbs)
  • MSBuild-Projekt-Dateien (.proj, .targets)
  • Assembler-Dateien (.asm, .inc)
  • C/C++ Dateien (.cpp, .h)


  • Gesamtzeilen: 10022

  • Codezeilen: 5504 (55%)
  • Leerzeilen: 1985 (20%)
  • Kommentar: 2533 (25%)


Gezählt wurde mit dem Java-Programm: Lines Of Code Wichtel


Stand der Dinge

Fertig:

  • Bootsector für ROFS, FDD-Version.
  • Bootloader
    • Entry16: 16-Bit-Einsprung in Assembler
    • Entry32: 32-Bit-PM-Einsprung in Assembler
    • Entry: C++ Part
    • Routinen für Textausgabe, darunter auch mit printf()
    • COM-Treiber: für Kernel-Debug benötigt
    • Kernel-Debug
    • SMAP (System Memory Map)


In Arbeit:

  • Bootloader
    • Paging mit PAE (bisher nur 2 MiB gemappt, sollte erstmal für Bootloader-Spielereien reichen).
    • Memory Management.
    • PCI Suuport.
    • PnP Support.
    • ACPI Support.
    • ACPI (Um Anzahl der Cores zu ermitteln).
  • Homepage für AiCOS.


Geplant:

  • Bootloader
    • System-Shell (Kernel-Ersatz, dient zum Anzeigen wichtiger System-Informationen und wird als CLI [Command Line Interface] aufgesetzt.
  • Bootsektor für CD


Roadmap

Ziele für Sprung in Research Phase 1 (Version 0.01)

  • Single-CPU
  • Funtionierender Bootsektor für Floppy (ROFS) und CD (ISO9660) - (Einheitlicher Code, bis auf die unterschiedliche Sektorgröße).
  • Funktionierender Bootloader, der System-Vorab-Checks durchführt, bevor gewissen Funktionen wie Protected Mode oder Paging benutzt werden.
  • Ausführliche Comments in Bootsektoren und Bootloader.
  • AiCOS-Source-Tree, Hardwarebedingter Code wird von System-Code getrennt, damit soll später eine bessere Portierbarkeit erreicht werden, wodurch nur der Hardwarebedingte Code (überwiegend Assembler) ausgetauscht werden muss.
  • AiCOS-Startup-Dummy.


Ziele für Sprung in Research Phase 2 (Version 0.02)

  • Differenzierung des Kernelgrundsystem in Management-Kernel, CPU-Kernel & I/O-Kernel
  • Channel-System als IPC implementieren
  • Hello-World-Prozess


Aktueller Screenshot

Version: 0.00.38.57

bootloader_008.gif

Screenshot mit Windows-Debug


Böse Falle

  • Ständig kackte meine VM ab, als mein Bootloader ins den PM-Segment prang. Man kann sich echt todsuchen, wenn man Hexzahlen und Dezimalzahlen nicht unterscheiden kann. 20d != 20h
  • Und wieder einmal stellte meine VM ihren Dienst beim Sprung ins PM-Segment ein und wieder suchte ich mich blöd. War letztenendes auch logisch, wenn der Bootsektor nur ein Sektor (512 Bytes) des Bootloaders lädt, aber der Sprung in PM-Segment aber an Offset 0x0200 sich befinden. Böse Falle


Meine SourceCode-Ecke


Ziele

Ein vollwertiges OS auf die Beine zu stellen, welches sich auch im Netzwerkbereich behaupten kann. Dabei wird keinster Weise direkt Code von anderen OS verwendet, vorallem keine Bootloader wie z.B. Grub! Vielmehr wird deren Funktionsweise analysiert. Der Kernel, besser gesagt das Kernel-System von AiCOS wird keines im Sinnes der Definition eines Kernels sein, sondern vielmehr ein Systemkern aus einer modularen Ansammlung mehrere Mikrokernels.