4. Eigenes OS?

Eigenes OS?

  • E
    Mod

    Ich möchte auf eine hervorragende, bisher 20-teilige Serie (BrokenThorn Entertainment, "Mike") aufmerksam machen: http://www.brokenthorn.com/Resources/OSDev1.html
    (didaktisch wirklich gut, da von Grund auf mit eigenem Bootloader und FAT12 System gearbeitet wird; leider noch einige kleine Fehler enthalten, Author wurde von mir über diese informiert)

    Ich hab gehofft du benutzt das auch und wüsstest einen Treiber dafür.

    Vielleicht sind die ersten Teile des obigen Tutorials für Dich das richtige, verwendet allerdings FAT12 anstelle ext2.

    0
  • E
    Mod

    Das Thema Analyse des physikalischen Speichers wurde nun auch erfolgreich umgesetzt: http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId584885
    Allerdings haben wir mit int 15h eax = 820h die 80er verlassen und sind auf neuere Zeiten (spätestens ab 2002, funktioniert aber vielfach bereits bei früheren PCs) umgestiegen. 😉

    Der Bootloader ist nun allerdings voll gestopft. Platz für FAT12 ist dort nun nicht. Wir verwenden ja noch "raw format". Die Frage ist, ob man sich überhaupt noch Gedanken über Floppy Disk machen soll.

    0
  • S

    Erhard Henkes schrieb:

    Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

    Für meine Studienarbeit habe ich einen Echtzeit-fähigen Mikrokernel entwickelt mit einem EDF Scheduler. Während der Diplomarbeit erweitere ich den um energieeffiziente Schedulingalgorithmen. Das ganze läuft auf einem gumstix connex400 mit einem Intel PXA255 (ARMvt5). Code darf ich noch nicht veröffentlichen 😞

    0
  • E
    Mod

    @supertux: Klingt echt toll! Davon musst Du hier berichten, sobald Du dies darfst. Aber vielleicht kannst Du mit Deinen Erkenntnissen hier einige wichtige Weichenstellungen kommentieren und beeinflussen. PrettyOS soll ja vor allem ein Experimentier-OS werden und Einsteiger in diese Materie ansprechen und ermuntern.

    Das Bild von einem OS, das man vor Augen hat, wird entscheidend geprägt durch das Interface. Daher habe ich nun auch begonnen die "Shell" (in Ring 3) zu entwickeln:
    http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId29082

    Ich stelle mir momentan vor allem die Frage: Was gehört in die syscall-API (teuer) und was in die user-API (bläht User-Programm auf)? 😕

    0
  • S

    Erhard Henkes schrieb:

    @supertux: Klingt echt toll! Davon musst Du hier berichten, sobald Du dies darfst. Aber vielleicht kannst Du mit Deinen Erkenntnissen hier einige wichtige Weichenstellungen kommentieren und beeinflussen. PrettyOS soll ja vor allem ein Experimentier-OS werden und Einsteiger in diese Materie ansprechen und ermuntern.

    das hörst sich sehr interessant an, hab ein bisschem im Code nachgeschaut. Leider kenne ich mich mit x86 überhaupt nicht aus, also verstehe ich den Code und viele (für x86) Notwendige Sache gar nicht.

    Ich muss meine Ausarbeitung in ca. 2 1/2 Wochen abgeben, dann Vortrag halten und so. Also erst danach werde ich wahrscheinlich meine Sachen (plus Sources) veröffentlichen können.

    0
  • E
    Mod

    ARM ist für einige interessant. Vielleicht kannst Du auch einen passenden Emulator verlinken. 🙂

    0
  • E
    Mod

    Ich habe PrettyOS nun auch unabhängiger und stabiler gemacht. Da hatten sich nach dem Umstieg von DJGPP nach Cross-Tools doch einige unbehobene Schwachpunkte angesammelt. Nun kann man Kernel und User-Programme mit CFLAGS= -Werror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builtin kompilieren.
    Physikalischer Speicher wird nun auch automatisch bestimmt und für das Paging (Anzahl der Frames = Phys. Memory / Pagesize) übernommen.

    Das ist die bisher stabilste und beste Version: http://www.henkessoft.de/OS_Dev/Downloads/88.zip (läuft inzwischen mit -Werror und -Wall und benötigt keine Header der Cross-Tools)

    Hier habe ich wieder initrd und VFS verwendet, um die shell zu finden/laden:
    http://www.henkessoft.de/OS_Dev/Downloads/90.zip
    (dabei gibt es aber auf bestimmten PC noch Probleme, die ich bisher nicht lokalisieren und beheben kann):
    Die Shell wurde als ELF-Programm via incbin (data.asm) über die Paarung RAM Disk / VFS lokalisiert und gestartet. Der visuelle Eindruck beginnt sich zu entwickeln.

    Ich stelle mir für die Zukunft die Fragen:
    - wie sollen die syscalls aussehen?
    - was gehört in die user-lib?
    - Sollte man Standards einsetzen? (POSIX, standardisierte C-userlib)
    - Sollte man letztendlich doch GRUB einsetzen oder stur den eigenen Bootloader ausbauen? (niemand hetzt mich)

    0
  • ?

    Wenn du mich fragst, ich würde auf jeden Fall einmal das Thema GRUB anschneiden.
    Es soll immerhin ein OS- und kein Bootloader-Tutorial bleiben / werden.

    0
  • H

    Ich würde Standards einsetzen, weil es dann einfacher ist Programme zu entwickeln bzw. zu portieren.

    0
  • ?

    Als erstes vorweg: ich beobachte die Entwicklung des Tutorials jetzt schon einige Zeit und bin echt begeistert! Mach auf jeden Fall weiter.

    Zum Thema GRUB: Ich fände es schade um die viele Arbeit, die jetzt schon in den eigenen Bootloader investiert wurde. Außerdem find ich es gut, dass man so von Anfang an gut erklärt bekommt, wie so ein Betriebssystem von Grund auf aufgebaut ist. Wenn man den Anfang jetzt GRUB machen lässt, werden wieder Fragen wie "Wie läuft das denn eigentlich mit GRUB ab?" aufgeworfen. Es ist zwar viel Arbeit, doch ist der Lerneffekt zumindest für mich größer, wenn mit dem jetzigen Bootloader weitergearbeitet wird. 🙂

    Übrigens habe ich festgestellt, dass der Bootloader sich im Bochs-Emulator bei folgenden IPS folgendermaßen verhält (Näherungswerte):

    400.000 -> Bootloader wird garnicht erst geladen
    400.050 -> Bootloader startet verzögert (ca. 7 Sekunden)
    400.100 -> Bootloader startet verzögert (ca. 5 Sekunden)
    400.500 -> Bootloader startet verzögert (ca. 1 Sekunde)
    402.000 -> Bootloader startet vollkommen normal

    Getestet wurde übrigens mit jeweils 8 MB RAM (das Niedrigste, ohne eine Fehlermeldung von alloc_frame() zu bekommen, dass es keine freien Frames mehr gebe, um anschließend (außer bei 7MB RAM) im "Page Fault >>> Exception. System Halted! <<<" zu enden ;))

    Woran liegt das genau, warum sind so kleine Werte hierbei so entscheidend?

    0
  • E
    Mod

    ich beobachte die Entwicklung des Tutorials jetzt schon einige Zeit und bin echt begeistert! Mach auf jeden Fall weiter.

    Ich plane im Hintergrund bereits ein neues völlig eigenes OS, muss aber erst noch mehr Erfahrung sammeln. Bei OSDEV zählt Erfahrung mehr als jede noch so tolle Theorie. Jeder baut hier auf den anderen auf. MSDOS auf CP/M, Linux auf Minix, ...

    Zum Thema GRUB: Ich fände es schade um die viele Arbeit, die jetzt schon in den eigenen Bootloader investiert wurde. Außerdem find ich es gut, dass man so von Anfang an gut erklärt bekommt, wie so ein Betriebssystem von Grund auf aufgebaut ist.

    Sehe ich genau so! Ich war nur deutlich verunsichert, weil ich bei seltsamen Fehlern jedes Mal mühsam belegen muss, das es nicht am Bootloader hängt. Seit ich diesen Schwachpunkt in initrd (buffer overflow durch strcpy; behoben durch Einbau von strncpy in Version 0.1.0090, die läuft schon sehr stabil, aber ich weiß noch nicht, warum manche PC da Blödsinn machen) behoben habe, geht es mir besser. Der Bootloader ist schon echt klasse. Jetzt ist ja auch die Speichererkennung mit dabei. Man könnte noch ein FAT12 einbauen, dann könnte man den kernel als kernel.sys von Floppy laden. Aber das macht die Sache auch nicht besser.

    0
  • E
    Mod

    400.000 -> Bootloader wird garnicht erst geladen
    400.050 -> Bootloader startet verzögert (ca. 7 Sekunden)
    400.100 -> Bootloader startet verzögert (ca. 5 Sekunden)
    400.500 -> Bootloader startet verzögert (ca. 1 Sekunde)
    402.000 -> Bootloader startet vollkommen normal

    Getestet wurde übrigens mit jeweils 8 MB RAM (das Niedrigste, ohne eine Fehlermeldung von alloc_frame() zu bekommen, dass es keine freien Frames mehr gebe, um anschließend (außer bei 7MB RAM) im "Page Fault >>> Exception. System Halted! <<<" zu enden ;))

    Interessante Untersuchung, mach weiter so! 🙂
    Der minimalistische Denkansatz gefällt mir!

    Bei mir sieht das wie folgt aus:

    romimage: file=$BXSHARE/BIOS-bochs-latest

    cpu: count=1, ips=10000000, reset_on_triple_fault=1

    megs: 1024

    vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest

    vga: extension=vbe

    floppya: 1_44=G:\OSDev\User\MyOS.img, status=inserted

    ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
    ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15
    ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11
    ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9

    boot: floppy

    floppy_bootsig_check: disabled=0

    log: bochsout.txt

    panic: action=ask
    error: action=report
    info: action=report
    debug: action=ignore

    debugger_log: -

    parport1: enabled=1, file="parport.out"

    vga_update_interval: 300000

    keyboard_serial_delay: 250

    keyboard_paste_delay: 100000

    mouse: enabled=0

    private_colormap: enabled=0

    keyboard_mapping: enabled=0, map=

    i440fxsupport: enabled=0

    Momentan bin ich guter Dinge, weil sich das OS die letzten Tage gewaltig stabilisiert hat, sogar die Version mit initrd/VFS läuft jetzt stabil:
    ..

    Ich sehe aus praktischer Sicht vier Komponenten eines OS:

    1. PC/BIOS
    2. Bootloader
    3. Kernel
    4. Userspace
    0
  • E
    Mod

    Ich habe das jetzt auch mal getestet:

    8MB:

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

    Usable RAM: 7740 KB

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

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

    7MB:

    loc_frame: no free frames!!!message from alloc_frame: no free frames!!!message f
    rom alloc_frame: no free frames!!!message from alloc_frame: no free frames!!!mes
    sage from alloc_frame: no free frames!!!message from alloc_frame: no free frames
    !!!message from alloc_frame: no free frames!!!message from alloc_frame: no free
    frames!!!message from alloc_frame: no free frames!!!message from alloc_frame: no
    free frames!!!message from alloc_frame: no free frames!!!message from alloc_fra
    me: no free frames!!!message from alloc_frame: no free frames!!!message from all
    oc_frame: no free frames!!!message from alloc_frame: no free frames!!!message fr
    om alloc_frame: no free frames!!!message from alloc_frame: no free frames!!!mess
    age from alloc_frame: no free frames!!!message from alloc_frame: no free frames!
    !!message from alloc_frame: no free frames!!!message from alloc_frame: no free f
    rames!!!message from alloc_frame: no free frames!!!message from alloc_frame: no
    free frames!!!message from alloc_frame: no free frames!!!message from alloc_fram
    e: no free frames!!!message from alloc_frame: no free frames!!!Ram Disk at: 4008
    100Ch
    <DIR> dev
    35 file1
    35 file2
    35 file3
    7719 dummy
    1693 shell

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

    Stimmt! Allerdings ohne #PF, zumindest bei Version 0.1.0090 🙂

    8 MB Minimum finde ich gar nicht übel. 👍

    PS: Ich sehe gerade: da gehört noch ein Space hinter "no free frames!!!"

    0
  • T

    Erhard Henkes schrieb:

    Dieses Tutorial macht mir Mut: http://www.brokenthorn.com/Resources/OSDev1.html (zwar einige Fehler enthalten, aber bezüglich des didaktischen Ansatzes richtig gut). Allerdings überfrachtet es den Leser im Sinne eines Nachschlagwerkes mit Theorie-Details. Die Praxis geht dort fast unter.

    Der Code davon gefällt mir aber persönlich ganz gut. Flags als Veroderung von Defines, Code aufgeteilt in Teilbereiche (wie Hal, Lib etc.) und die Trennung von Bootloader- und Kernelcode wären etwas was man sich abgucken könnte.

    0
  • E
    Mod

    zu http://www.brokenthorn.com/Resources/OSDev20.html :
    Der Aufbau gegliedert in boot.bin, kernel.sys und kernel.exe unter Verwendung von FAT12 und VC2008 Express ist vorbildhaft, da hast Du Recht. Echt klasse gemacht.

    Ob VC++ 2005 od. 2008 unbedingt sein muss, da kann man sich streiten, aber professionell ist es auf jeden Fall. Man lernt halt wenig über makefile und linker script, was ich für einen OSDever für wichtig halte.

    Konntest Du sein OS schon booten/starten? 😕

    Mir ist das noch nicht gelungen.
    Ich habe bisher aber nur Demo15 aus tut20 getestet:
    http://www.brokenthorn.com/Resources/Demos/Demo15.zip

    In boot.asm fehlen drei Doppelpunkte bei den Labels, aber auch nach Ergänzung (nasm motzt herum, warum der Autor dies nicht liest?) verschwindet der "Reset" beim Booten nicht. Liegt der Fehler bereits hier?

    kernel.sys klappt gut, oder liegt hier im Code das Problem? In zip-Datei mitgeliefertes kernel.sys funktioniert auch nicht.

    Kernel.exe: VC++ 2008 Express (bei der Demo sind noch die 2005er Projektdateien dabei, kann man aber updaten) gibt einige Warnungen aus, kompiliert/linkt aber alles und schreibt kernel.exe auf floppy disk.

    Hast Du da praktische Tipps, wie man es zum Laufen bekommt, oder muss ich den Autor ansprechen? Auch mit Bochs 2.4.1 gibt es einen Reset (wie bei real PC).

    Bei solchen Zeilen:

    mov ax, 0x0000 ; set the stack

    gibt es normalerweise Kritik (siehe Anmerkungen von NobuoT weiter vorne). Das müsste wirklich nicht sein.

    Mein Fazit:
    Tutorial: sehr umfassend, viele Rechtschreibfehler, didaktischer Stil gut
    Grundlegender Code-Aufbau: Klasse! Davon kann man lernen.
    Tools: Mit freien Windows-Tools (nasm, partcopy, VC++ 2005/08 Express) umsetzbar, kein GRUB, sondern eigener Bootloader mit FAT12-Erkennung!
    Praktische Umsetzung/Fehlerfreiheit: negativ (bootet, resettet aber, Warnungen von nasm und VC++ 2008, offenbar schaut sich der Autor die Meldungen seiner Tools nicht an, ist mir aber auch schon passiert, typische Verdrängung, Hauptsache vorwärts)

    Das ist wirklich schade, denn ansonsten ist das Tutorial hervorragend. Vielleicht liegt das Problem auch in Kernel.exe? Kannst Du Dich näher auslassen über deine Erfahrungen? Welche Demo-Version geht bei Dir?

    Flags als Veroderung von Defines

    Was gefällt Dir da besonders gut?

    0
  • T

    Ich habe noch nicht versucht den Code zu kompilieren und zu starten. Werd ich nacher mal ausprobieren. Habe den Code nur durchgesehen um ein paar Anregungen zu bekommen, da C nicht gerade meine Hauptsprache ist, und da sind mir die Sachen aufgefallen. Visual Studio ist auch nicht unbedingt meine Wahl für Betriebsystementwicklung, zumal da auch C++ im Spiel ist. Allerdings sieht das mit dem inline Assembler etwas eleganter aus als beim gcc.

    Das mit den Defines ist mir hauptsächlich beim IDT und GDT aufgefallen:

    gdt_set_descriptor (1,0,0xffffffff,
    I86_GDT_DESC_READWRITE|I86_GDT_DESC_EXEC_CODE|I86_GDT_DESC_CODEDATA|I86_GDT_DESC_MEMORY,
    I86_GDT_GRAND_4K | I86_GDT_GRAND_32BIT | I86_GDT_GRAND_LIMITHI_MASK);

    Ist besser zu erkennen was gesetzt ist, als wenn da einfach als Flag 0x9A steht. Es ist natürlich im Tutorial erklärt, aber wenn man später auf den Code zurück kommt muss man es wieder nachlesen.

    Edit: Habs jetzt ausprobiert (Demo15.zip aus Tutorial 20) und es läuft in Virtualbox und QEmu ohne Probleme. Wichtig war vor allem als Debug zu kompilieren, da Release anscheinend nicht richtig konfiguriert ist. Als beim Release Build 740 Fehler kamen wollte ich schon aufgeben. Ansonsten habe ich nichts umgestellt. Allerdings nutze ich Visual Studio Professional und kein Express, was noch einen Unterschied machen könnte.

    0
  • E
    Mod

    Habs jetzt ausprobiert (Demo15.zip aus Tutorial 20) und es läuft in Virtualbox und QEmu ohne Probleme. Wichtig war vor allem als Debug zu kompilieren, da Release anscheinend nicht richtig konfiguriert ist.

    Mit VC++ 2008 Express im Debug-Modus kompiliert, Release geht überhaupt nicht wegen massenweise Fehler. Auf der Diskette befindet sich hinterher kernel.sys und kernel.exe. habe auch mal die hal.dll dazu, bringt aber nichts, besteht ja auch keine Abhängigkeit der kernel.exe.

    Keine Ahnung, wie Du das schaffst. Läuft nicht mit Virtual PC 2007 (bootet zwar, hinterher aber nur blauer Bildschirm mit blinkendem Cursor), überhaupt nicht mit Sun xVM VirtualBox und nicht mit Bochs 2.4.1. Dieser Zustand ist gelinde gesagt nicht gerade berauschend. 🙄

    gdt_set_descriptor (1,0,0xffffffff, I86_GDT_DESC_READWRITE|I86_GDT_DESC_EXEC_CODE|I86_GDT_DESC_CODEDATA|I86_GDT_DESC_MEMORY,
    I86_GDT_GRAND_4K | I86_GDT_GRAND_32BIT | I86_GDT_GRAND_LIMITHI_MASK);

    Ja stimmt, das könnte man machen, ist ja bei Windows-Programmierung Standard.

    0
  • ?

    huh? hab lange nicht mehr hier reingeschaut, aber wie's ausseiht, seid ihr immer noch dabei, den x86 in betrieb zu nehmen? *heul*
    🙂

    0
  • ?

    Erhard Henkes schrieb:

    ARM ist für einige interessant. Vielleicht kannst Du auch einen passenden Emulator verlinken.

    wieso emulator? nehmt doch 'nen richtigen ARM, z.b. sowas: http://www.mikrocontroller.net/articles/MP2103-Stick:_Ein_Mini-Mikrocontroller-Board_mit_USB_und_bis_zu_4MB_Datenspeicher
    🙂

    0
  • T

    ,fricky schrieb:

    wieso emulator? nehmt doch 'nen richtigen ARM, z.b. sowas: http://www.mikrocontroller.net/articles/MP2103-Stick:_Ein_Mini-Mikrocontroller-Board_mit_USB_und_bis_zu_4MB_Datenspeicher
    🙂

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

    Erhard Henkes schrieb:

    ARM ist für einige interessant. Vielleicht kannst Du auch einen passenden Emulator verlinken.

    QEmu kann so einiges emulieren (http://www.qemu.org/status.html), darunter auch ARM und MIPS. Wobei es für den Embedded Bereich ja oft auch spezielle Development Kits mit allem drum und dran gibt.

    0
Anmelden zum Antworten