4. Eigenes OS?

Eigenes OS?

  • E
    Mod

    Dies ist ja der Hauptthread, der meinen Einstieg in das "OSDEV" begleitet. Daher möchte ich mich hier sehr herzlich bei allen bedanken, die die bisherigen Gehversuche in die Welt des Kernels, der Treiber und des User-Spaces engagiert und tatkräftig unterstützen, sei es durch kleine Hilfestellungen, Hinweise, Diskussionen, Tests, eigene Experimente, kleine Aufsätze sowie Sourcecode. Ein funktionierendes OS ist die Summe vieler kleiner Schritte und Erkenntnisse. Ich wünsche diesem Subforum und unserer kleinen Gruppe um PrettyOS weiterhin viel Spaß, interessante Diskussionen und gutes Gelingen bei allen Vorhaben. 🙂

    0
  • E
    Mod

    Den Helfern, Freunden und Gönnern dieser Gruppierung um das Thema OS-Development am Beispiel PrettyOS möchte ich aufs Herzlichste danken. Euch allen und euren Familien ein frohes und besinnliches Weihnachtsfest und einen erfolgreichen Start in das Jahr 2010!

    0
  • E
    Mod

    Da es heute gelungen ist, das Zusammenspiel von PCI, EHCI und USB 2.0 fehlerfrei zu betreiben, ist es an der Zeit diesen Thread mal wieder "auszupacken". Für mich ist das der Beweis, dass man vieles (nicht alles) bewirken und erreichen kann, wenn man es wirklich will und dran bleibt. 🙂

    0
  • E
    Mod

    Nachtrag: der wirkliche Durchbruch bei USB2 MSD/SCSI fand in der zeit vom 11.05. zum 13.05. statt durch einen Versuch und Hinweis von +gjm+, der diesen Thread und das Projekt von Anfang an wohlwollend verfolgt hat. Ich kann nur hoffen, dass +gjm+ uns auch weiterhin treu verbunden bleibt. 👍

    0
  • E
    Mod

    Weiterer Meilenstein:
    Heute konnten Files von verschiedenen usb-Sticks (512 MB FAT16, 1 GB FAT16, 4 GB FAT32, 16 GB FAT32) per FAT16/32-Filesystem aufgespürt (root dir) und von usb MSD mittels SCSI command "read(10)" in den Speicher geladen (FAT, data area) werden. Damit hat die Floppy Disk (FAT12) als zentrales Speichermedium ausgedient.

    0
  • E
    Mod

    Der "Meilenstein" konnte ausgebaut werden: rev. 476: http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-490-and-sid-is-e7938c7851b1351fd67c91242b76cae3.html

    ttt.elf (unser tic-tac-toe) vom usb-stick (mit FAT16 oder FAT32) wurde geladen und ausgeführt. 🙂

    0
  • E
    Mod

    Aber bis es auch mit Fileeinträgen jenseits des ersten Clusters in der root dir ging, dauerte es dann doch noch etwas. 😉

    0
  • E
    Mod

    Meilenstein:
    Heute haben MrX und ich es in einem tollen team work geschafft, mit

    3:\ttt    elf

    von einem usb-stick ttt zu laden und zu starten. 👍

    0
  • E
    Mod

    Nun kann man von Floppy Disk Device und USB Mass Storage Device laden. Der Device Manager hat an Abstraktionsgrad und Mächtigkeit gewonnen.

    "1:\ttt.elf" (bei vorhandener Floppy sogar mit "ttt.elf") 🙂

    Der device manager ist nun in seinen Grundzügen realisiert und läuft gut.
    Nun kann man von Floppy oder usb MSD mit 1:/ttt.elf (durchgezählte angeschlossene Partitionen) bzw. A:/pqeq.elf eine Datei laden und starten.
    A: ist die sogenannte Port-Ansprechweise
    Ports sind bei uns: FDD, RAM, usb-slots
    Disks sind bei uns: FloppyDisk, RAMDisk, usb-stick
    Partitionen sind z.B. FAT12/16/32-Partitionen darauf. Wir zählen die Ports mit A,B,C, ... und die Partitionen mit 1,2,3,...

    Wir haben also drei Ebenen:

    1. die "Slot"-Ebene, das ist die feste Hardware: RAM, FDD, EHCI-Port
    2. das eingeschobene Wechselmedium: RAMDisk, FloppyDisk, usb-MassStorageDevice
    3. die Partition, die wir mit Namen und Serial kennen: part->serial
    0
  • E
    Mod

    ... und 14 Tage später trauen wir uns, auf usb Mass Storage Devices zu schreiben! Mit einem FAT12-Stick klappt es bereits analog zur Floppy. 🙂
    FAT16 geht ebenfalls korrekt. Bezüglich FAT32 gibt es noch ein Problem bei vielen bereits vorhandenen Einträgen in der root dir (gelöschte zählen mit). Hier muss im FAT-Modul nachgebessert werden. Aber wie diesen Fehler finden? 😉

    0
  • E
    Mod

    Durch Zufall ist mir der Fehler beim Code studieren aufgefallen. Es geht eben nichts über Code Review. Da hatte ich eine Zeile testweise ausgeblendet (zum Glück nicht gestrichen), die hatte nun gerade für einige Fälle gefehlt. 😉

    0
  • E
    Mod

    Meilenstein: Version 0.0.1.0 (Rev. 554) 🙂

    0
  • E
    Mod

    Ein OS (im erweiterten Sinne) besteht nicht nur aus Elementen wie Bootloader, Kernel und Treiber, sondern im Hobby-Bereich auch aus den User-Programmen, die speziell für die API maßgeschneidert wurden. Beispiele sind die Spiele TicTacToe von Mrx und ARROW ATTACK von mir. Der "homo ludens" sucht solche Anwendungen, um sich an den Möglichkeiten der IT zu erfreuen und seine Kreativität zu entfalten. Daher kann ich nur immer wieder ermuntern, unterhaltsame und neuartige Programme für PrettyOS zu schreiben. Die API der Userlib ist noch nicht stabil, aber Programmanpassungen werden sicher kein Problem darstellen, da die API bei ihrem Fortschritt eher verbesserte Möglichkeiten anbieten wird, die das Erstellen erleichtern. Also nix wie ran. 😉

    0
  • E
    Mod

    Ich denke es ist Zeit für einen OSDev Review bei PrettyOS.

    Beginnen wir mit http://wiki.osdev.org/Beginner_Mistakes als Leitfaden.

    Wir haben nun über ein Jahr Entwicklung von PrettyOS (sicher weniger als 1 Mannjahr in Summe, denn es ist ja ein Hobby-Projekt neben Arbeit, Studium, Schule). Die Shell funktioniert bestens bisher. Die Roadmap wurde eingehalten: Eigener Bootloader anstelle GRUB, Laden/Speichern USB-Stick mit FAT. Netzwerk musste da halt zurück stehen mangels Developer Ressourcen. Man kann nicht alles gleichzeitg machen. EHCI, USB2 und FAT sind schwere Brocken. Nun kommen die "Manager" und die Schnittstellen. Manche machen es umgekehrt, ich möchte zuerst die Funktionalität sehen, wissen, dass es wirklich "geht".

    Wir sind zwei aktive Entwickler, vielleicht werden es ab und zu drei sein, die daran werkeln. Die Aufteilung hat bisher gut geklappt aufgrund der unterschiedlichen Interessengebiete. Aber eine Community von 5-10 Leuten, die daran koordiniert arbeiten, ist Illusion. Das muss man rasch einsehen. Im chat gewinnt man neue Leute, und es erhält die Lebendigkeit, leider geht auch Zeit verloren mit für die praktische Arbeit sinnlosen Debatten. Destruktive Stänkerer muss man leider immer wieder in die Schranken weisen. Ertragen muss man auch die "Idler". PrettyOS hat hier momentan einen guten Mix von Leuten, und es gibt ja auch "virtuelle Hinterzimmer" in den chat-Bezirken, wenn wichtige Dinge im kleinen Kreis zu klären sind.

    PrettyOS wurde nie als kommerzielles Projekt geplant, sondern als didaktische Hilfe zum Einstieg in OSDev. Daher auch mein Tutorial von Anfang an, das eher ein Skript/Logbuch für mich selbst war. Ein begleitendes e-book schwebte mir vor. Allerdings braucht das länger als geplant, bis ein Niveau erreicht wird, dass man die Dinge vernünftig ordnen und weiter geben kann. Man muss hier mit sich selbst und anderen geduldig sein. Die Erfahrung, die man selbst macht beim Aufbau eines OS und einer damit zusammen hängenden Community ist umfassend und tiefgehend. Man muss dazu bereit sein. Ansonsten gibt man auf. OSDev ist streckenweise "langweilig" und gleichzeitig fordernd.

    GUI und Maus, übrigens auch Sound sind sicher ein interessantes Feld, aber dies hält durch hohe Komplexität eher von wesentlichen Dingen ab. Ist momentan nicht auf der konkreten Roadmap.

    Wir schreiben unsere eigenen Programme, vielleicht wird die eine oder andere Anwendung portiert werden, aber das ist zweitrangig.

    Die Bezeichnung "PrettyOS" habe ich bereits sehr früh festgelegt, bisher habe ich es nicht bereut. Eine Namensänderung kommt nicht in Frage. 🙂
    Man kann hier aber nur zu Vorsicht raten. Da hilft nur Intuition.

    Zwischen C und C++ wird man wohl immer schwanken. Beides ist möglich, wobei ich bisher nur Erfahrung mit OSDev und C habe. Ich würde es gerne probieren ein OS in C++ zu bauen, aber am Wesentlichen ändert es nichts. Man wird sich mit C++ eher isoliert vorkommen, da die Literatur C oder Assembler einsetzt.

    Inzwischen verwenden wir ein FAT12-Filesystem in dem verwendeten zweistufigen BL, ein ganz angenehmes aber ziemlich unflexibles Verfahren, wenn man z.B. von ubs-stick booten und nachladen will. Niemand hat die Zeit sich intensiv mit dem BL zu befassen. GRUB muss dennoch etwas warten, wobei wir vorbereitet sein müssen. Der Kernel wächst und wächst.

    Linker-Script für den Kernel sein:

    OUTPUT_FORMAT("binary")
OUTPUT_ARCH(i386)
STARTUP(object_files/kernel/kernel.o)
SECTIONS
{
    . = 0x00100000;
    __kernel_beg = .;
    .text   : { __code_start = .;                        }
    . = ALIGN(0x1000);
    .text1  : { object_files/kernel/data.o(.text)        }
    .data   : { __data_start = .;   *(.data)             }    
    .rodata : { __rodata_start = .; *(.rodata) *(.rdata) }
    .bss    : { __bss_start = .;    *(.bss) *(COMMON)    }
    __start_cdi_drivers = .;
    .cdi    : { __cdi_start = .;    *(.cdi)              }
    __stop_cdi_drivers = .;
    __kernel_end = .;
    __end = .;
}

    Fazit: Wir haben den Einstieg ganz brauchbar hingelegt. Nun geht es darum, die Sache rund zu gestalten und sich das Interesse zu erhalten. 👍

    0
  • E
    Mod

    Wir hatten intern diskutiert, was wichtiger sei: Netzwerk oder Grafik (wenn auch nur für verbesserte und höheraufgelöste Textdarstellung). Die Antwort fiel eher zugunsten von Grafik aus. Daher haben wir VM86-Tasks eingeführt. Heute haben wir es zum ersten Mal geschafft, den Video-Mode mittels VM86-task stabil umzuschalten und ein paar bunte Tupfer darzustellen.

    Der "Sündenfall" ist erfolgt. Das Text-"Paradies" ist beendet.
    Nun wird die Pixel-"Hölle" folgen. 😉

    0
  • E
    Mod

    VM86 Tasks laufen stabil. Damit ist das BIOS innerhalb des Protected Mode wieder zugänglich geworden. Wir verwenden die Interrupt Vector Table (IVT) zum Beispiel zur Ausführung von INT 10h. Das BIOS verzweigt in Speicherregionen oberhalb C0000h.

    VM86 erlaubt uns das Umschalten des Video-Modes mittels 16 bit Real Mode Code mitten im Protected Mode.

    Nun steigen wir mittels vbe.h/c in den Bereich der Grafik ein und werden Texte langfristig mit in Pixelmustern definierten Zeichen darstellen.

    Als erstes Projekt steht der Bootscreen als 256-Farben-Bmp-File an. 🙂

    0
  • E
    Mod

    Ein Meilenstein ist sicher die Darstellung eines bmp:
    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_90_bitmap.PNG

    Positionierung und Palette sind zwar noch nicht korrekt, aber das Einlesen des bmp-headers und der bmp-Daten von hinten beginnend und das Auffüllen der Zeilen von rechts nach links gelingt schon.

    Da liegt aber noch einiges an Arbeit zur Stabilisierung und bezüglich Fehlerabfragen vor dem Team.

    EDIT: Mit Revision 0.0.1.112 hats geklappt mit der Geometrie und den Farben der Palette. 🙂

    0
  • E
    Mod

    ... und ein weiterer das Senden eines Netzwerk-Paketes: 🙂
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-763.html

    0
  • E
    Mod

    Nun wurde ein weiterer Meilenstein erreicht:
    http://www.c-plusplus.net/forum/viewtopic-var-p-is-1938461.html#1938461

    Das "Ping" (Ping Request) hat sein "Pong" (Ping Reply) gesehen! 👍
    Auf zwei Systemen - einmal qemu via TAP (Linux), einmal PC über Router (WinXP) - unabhängig bestätigt.

    0
  • E
    Mod

    ... und nun wurde sogar das timeout - zumindest bei "hrping" - überwunden 🙂
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-254893-and-start-is-796.html

    0
Anmelden zum Antworten