4. Eigenes OS?

Eigenes OS?

  • ?

    Tobiking2 schrieb:

    4 mb könnten aber knapp werden wenn das OS 8 mb braucht um zu booten

    ein os dass 8MB braucht, kannste gleich bei http://thedailywtf.com/ anmelden.

    Tobiking2 schrieb:

    Wobei es für den Embedded Bereich ja oft auch spezielle Development Kits mit allem drum und dran gibt.

    sogar kostenlos. aber sein OS ständig im simulator laufen zu lassen, ist sehr unbefriedigend (wie alle software, die nur im computer läuft und nicht mit der realen welt interagiert, sondern nur mit einem benutzer, der vor der kiste sitzt).
    🙂

    0
  • E
    Mod

    ein os dass 8MB braucht, kannste gleich bei http://thedailywtf.com/ anmelden.

    Ist einiges an Luft drinnen, die man ablassen kann, wenn notwendig. 8 MB ist doch heute kein Thema mehr in einem echten PC.
    ARM ist eine andere Welt. Die spielt hier aber keine Geige. 😃

    0
  • E
    Mod

    Trennung von Bootloader- und Kernelcode wären etwas was man sich abgucken könnte

    @Tobiking2:
    Ich habe für die Freunde des altehrwürdigen Floppy Disk Formates einen ersten Schuss mit den etwas abgeänderten Startdateien von brokenthorn http://www.brokenthorn.com/Resources/OSDev1.html (schon ziemlich viel Ballast abgeworfen) durchgeführt:

    Hier eine erste Version zum Testen und Mitdenken:
    http://www.henkessoft.de/OS_Dev/Downloads/94.zip

    (Alles mit eingelegter Floppy Disk durchführen, damit der Bootsektor geschrieben wird und boot2.sys sowie ckernel.sys auf die Floppy kopiert werden)

    stage1_bootloader und FAT12:
    - boot.bin (Bootsektor)

    stage2_bootloader:
    - boot2.sys (-->formatierte Floppy)

    kernel:
    - ckernel.sys (-->formatierte Floppy)

    user:
    - initrd & shell (program.elf)

    Als Tools: partcopy, nasm(w), cross-compiler
    Die Startadresse von ckernel.sys habe ich nach 0x40000 verlegt. Klappt gut.

    Läuft im Gegensatz zu brokenthorn in -Werror -Wall Qualität mit den Cross-Tools. Den Kernel habe ich als Binary gelinkt, damit man das Parsen der ELF-Datei einspart.

    Lässt sich mittels Bochs und auf Real PC booten.

    Da kann man nun im nächsten Schritt boot.asm / boot2.asm mit unseren bisherigen Routinen, z.B. für Memory-Bestimmung und Sektoren-Lesen bestücken, noch mehr Ballast abwerfen und einige Adressen noch abändern. Sobald alles robust steht, werde ich das (mit Hinweis auf brokenthorn u.a. als Vorlage) ins PrettyOS-Tutorial einbauen. Gutes Exempel für Second-Stage-Bootloader und Lesen von FAT12-Format.

    0
  • T

    Die Diskette mit Fat12 zu formatieren und nur noch den Bootsektor mit partcopy zu beschreiben find ich auf jeden Fall eine gute Änderung. Was nun natürlich fehlt ist die Möglichkeit Userprogramme von der Diskette zu laden statt aus der initrd. 😉

    Mich hat nur etwas gewundert, dass du den Bootloader Code von Brokenthorn übernommen und deine Sachen hinzugefügt hast, statt deinen eigenen Code umzubauen und zu erweitern. Solange du damit zufrieden ist ist es ok, aber ich schreib normalerweise lieber Funktionen sinngemäß nach, als irgendetwas erstmal 1:1 zu übernehmen und dann anzupassen.

    0
  • E
    Mod

    Mich hat nur etwas gewundert, dass du den Bootloader Code von Brokenthorn übernommen und deine Sachen hinzugefügt hast, statt deinen eigenen Code umzubauen und zu erweitern. Solange du damit zufrieden bist, ist es ok, aber ich schreib normalerweise lieber Funktionen sinngemäß nach, als irgendetwas erstmal 1:1 zu übernehmen und dann anzupassen.

    Das war nur ein schneller Versuch, ob das Zusammenschmieden so klappt, wie ich mir das vorgestellt habe, und das hat es. Ich werde meinen Code um die notwendigen Teile erweitern, weil mir der bisherige Aufbau des Bootloaders besser gefällt als der Code von brokenthorn.

    Die Erweiterung um einen second stage bootloader ist auf jeden Fall vorteilhaft, weil man Platz gewinnt. Das Laden von Diskette und später anderen Datenträgern ist ebenso ein Ziel. 🙂

    0
  • E
    Mod

    @ Tobiking2: Mich würde interessieren, wie Du die Demo15 von Tut20 bei brokenthorn zum Laufen bekommen hast. Ich verwende - wie bereits erwähnt - VC++ 2008 EE.

    0
  • T

    Erhard Henkes schrieb:

    @ Tobiking2: Mich würde interessieren, wie Du die Demo15 von Tut20 bei brokenthorn zum Laufen bekommen hast. Ich verwende - wie bereits erwähnt - VC++ 2008 EE.

    Ich hab gerade nochmal frisch entpackt um zu prüfen das ich nicht irgendwo etwas verstellt habe und da ist mir aufgefallen, dass ich das Projekt nicht bereinigt habe und so die schon kompilierten libs benutzt habe. Nach einer kompletten Bereinigung läuft es bei mir auch nicht mehr.

    Ich habe danach dann gezielt nur einzelnen Projekte bereinigt und es läuft solange ich nicht das Keyboard Projekt bereinige. Nachdem ich bei einem Diff zu Demo14 keinen unterschied gesehen habe, habe ich es dort ausprobiert und auch da tritt der Fehler auf sobald ich Keyboard selber compiliere. Demo12 ist die höchste die ich ohne Keyboard gefunden habe, da diese aber andere Fehler hat, hab ich da nicht weiter probiert.

    0
  • E
    Mod

    Die brokenthorn downloads scheinen ein ziemlicher Software-Müllhaufen zu sein, allerdings mit einigen Edelsteinen darin. 😃

    Ich bin auch etwas verblüfft, da ich die gestern schnell zusammen geschusterte Version 94 zum Laufen bringen wollte, diese aber plötzlich im Kernel nur ein gelbes S auf den Screen brachte (wegen dieses Problems hatte ich extra den Kernel nach 0x40000 geschoben, wegen interner Kernel-Schiebereien im Brokenthorn-Code). Ich habe sogar meinen Upload getestet, ging auch nicht mehr. Gestern abend lief der gleiche Code mit Bochs und Floppy, bin etwas verwirrt. Läuft meine Version 94 bei Dir?
    http://www.henkessoft.de/OS_Dev/Downloads/94.zip
    Das Speichermanagement ist etwas seltsam, muss mal seine Einstiegstuts lesen, in denen er diesen Aufbau beschreibt.

    Die GRUB-Verfechter würden sich wieder schief lachen über diese Krämpfe. 😃

    0
  • T

    Ich hab unter Windows keine ordentliche gcc Toolchain installiert um richtig zu testen. Wenn ich aber unter Linux den Kernel compilier krieg ich folgendes vom Linker:

    ld: section .text1 [0000000000044000 -> 0000000000044009] overlaps section .text [0000000000040000 -> 0000000000044162]

    Der Code ist wohl über die festgelegten Grenzen im Linkerscript gewachsen.

    Edit: Nach ändern der Positionen und starten in QEmu ist mir aufgefallen, dass es gar nicht bis zum C-Kernel durchläuft.

    0
  • E
    Mod

    Da ist offenbar etwas durcheinander geraten.
    boot2.asm, common.inc und kernel.ld müssen sauber aufeinander abgestimmt werden:

    common.inc:

    ; where the kernel is to be loaded to in protected mode
%define IMAGE_PMODE_BASE 0x40000

; where the kernel is to be loaded to in real mode
%define IMAGE_RMODE_BASE 0x3000

; kernel name
ImageName     db "CKERNEL SYS"
ImageSize     dw 0

    boot2.asm:

    jmp dword CODE_DESC:IMAGE_PMODE_BASE

    kernel.ld:

    OUTPUT_FORMAT("binary")
ENTRY(KernelStart)
SECTIONS
{ 
  . = 0x00040000;
  .text   : { __code_start = .;   *(EXCLUDE_FILE(shared_pages.o data.o).text) } 
  . = 0x00045000;
  .text1  : { shared_pages.o(.text)                                    } 
  . = 0x00046000;
  .text2  : { data.o(.text)                                            }
  .data   : { __data_start = .;   *(.data)                             } 	
  .rodata : { __rodata_start = .; *(.rodata) *(.rdata)                 }
  .bss    : { __bss_start = .;    *(.bss) *(COMMON)                    } 
  __end = .;
}

    Dann klappt das auch:

    PrettyOS [Version 0.1.0094] (C) 2009 henkessoft.de

    Memory detection does not work. Estimated usable RAM: 32768 KB

    Ram Disk at: 4008100Ch
    <DIR> dev
    35 file1
    35 file2
    35 file3
    1693 shell

    \> hi <-- I am PrettyOS. Always at your service! >

    (Meine memory detection ist ja noch nicht eingebaut)

    Bitte alles weg werfen und erneut downloaden:
    http://www.henkessoft.de/OS_Dev/Downloads/94.zip (neu upgeloadet)

    Ein kompaktes auf Floppy unsichtbares MyOS.img ist eindeutig einheitlicher und vor allem gegen Verwechslungen gesichert. 😉 👍

    0
  • T

    Macht die Zeile:

    jmp dword 0x08:0x300060 ; offset 0x60 in kernel.elf

    in boot2.asm sinn wenn der Kernel in 0x40000 liegt und kein ELF-Format mehr ist?

    0
  • E
    Mod

    Macht die Zeile: jmp dword 0x08:0x300060 ; offset 0x60 in kernel.elf
    in boot2.asm sinn wenn der Kernel in 0x40000 liegt und kein ELF-Format mehr ist?

    Nein, natürlich nicht. Völliger Blödsinn. 😮

    Da ist beim Hochladen Stage 2 durcheinander geraten.
    Da muss alles genau passen. Auch die Namen stehen mehrfach im Code.
    Kleiner Fehler bei Änderungen: alles kaputt. 😃

    Bitte alles weg werfen und erneut downloaden:
    http://www.henkessoft.de/OS_Dev/Downloads/94.zip (neu upgeloadet)

    (habe jetzt auch etwas mehr Platz geschafft für anderen Compiler, der "dickeren" Code produziert.)

    Selbst downgeloadet, extrahiert und getestet: OK.

    0
  • A

    Erhard Henkes schrieb:

    Kleiner Fehler bei Änderungen: alles kaputt. 😃

    Irgendwo habe ich mal einen Spruch gehört, Assembler Funktionen seien verdammt schnell, man müsse aber beim Programmieren der Assembler Funktionen verdammt langsam denken... 🙂

    0
  • E
    Mod

    Ja, das stimmt wirklich. 😃

    Klappt das bei Dir mit der Version 94? Dank FAT 12 kann man jetzt aus mehreren Versionen alles schön vermischen, spätestens auf der Floppy. 😃
    Wer keine Floppy hat, gibts natürlich auch virtuell (VFD).

    0
  • T

    Erhard Henkes schrieb:

    Klappt das bei Dir mit der Version 94? Dank FAT 12 kann man jetzt aus mehreren Versionen alles schön vermischen, spätestens auf der Floppy. 😃

    Ja es klappt. Man muss aber natürlich drauf achten, dass Stage 1 und 2 zusammen passen. Wenn man ein altes Stage 1 oder 2 mit anderen Adressen benutzt kann das schnell schief gehen.

    Erhard Henkes schrieb:

    Wer keine Floppy hat, gibts natürlich auch virtuell (VFD).

    Unter Linux gibt es losetup 😃

    0
  • E
    Mod

    Na, wenn das soweit klappt (bei Vers. 94 ist sogar initrd-Filesystem dabei, das bisher nicht überall lief), ist es wohl an der Zeit, sich nun den Themen Device-Treiber "Floppy Disk" sowie dem File-Format "FAT 12" zu widmen und First und Second Stage Bootloader auszubauen. 🙂

    0
  • E
    Mod

    Memory Detection klappt nun auch mit dem Second Stage Bootloader, der sich momentan so darstellt:
    ..

    EDIT: includes wurden überarbeitet. Gemeinsames BPB für Stage1 und Stage2 ausgegliedert. Floppy-Motor wurde nun auch ausgeschaltet.

    Das ist m.E. eine brauchbare Basis für die weitere Entwicklung. 🙂

    0
  • ?

    Erhard Henkes schrieb:

    ist es wohl an der Zeit, sich nun den Themen Device-Treiber "Floppy Disk" sowie dem File-Format "FAT 12" zu widmen...

    ah, endlich gehts los mit dem OS *daumen_hoch*
    kannst ja das hier als grundlage für 'nen FAT-treiber nehmen: http://elm-chan.org/fsw/ff/00index_e.html
    🙂

    0
  • E
    Mod

    endlich gehts los mit dem OS *daumen_hoch*

    Ich sagte doch, dass Du etwas Geduld mitbringen musst. Jedes OS wandert im gewissen Sinne durch eine autistische Phase. Bei PrettyOS wurde das durch Verweigern der "Gehhilfe" GRUB noch vertieft. Der Kontakt zur Außenwelt gehört bei vielen Entwürfen im Sinne eines Mikrokernels nicht wirklich zum Systemkern, sondern wird an den User-Space delegiert. Nun wird sich PrettyOS allerdings verstärkt öffnen, sowohl gegenüber dem User als auch dem Computerumfeld. 🙂

    Damit ist allerdings auch die wirklich spannende Phase vorbei.
    Nun verstehe ich Autisten. 😉

    Danke für den interessanten Link! 👍

    0
  • E
    Mod

    Nachdem die Version 97 (incl. initrd) überall stabil läuft, habe ich dies nun auch beschrieben.

    Besonders interessant finde ich die Analyse der Datenstrukturen auf Diskette mit dem Hex-Editor: http://www.henkessoft.de/OS_Dev/Bilder/FAT12_HexEditor.PNG
    Man erkennt sehr schön den Bootsektor, FAT1, FAT2, die Root-Directory und dahinter die Daten. Eine Analyse der Clusterketten in der FAT zeigt die Linked List (folgt noch). Damit wird das Ganze sehr klar und konkret.

    0
Anmelden zum Antworten