Eigenes OS?

Erhard Henkes

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!!!"

Tobiking2

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.

Erhard Henkes

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?

Tobiking2

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.

Erhard Henkes

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.

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

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

Tobiking2

,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.

Erhard Henkes

wie's aussieht, seid ihr immer noch dabei, den x86 in betrieb zu nehmen?

yep, wir haben uns bereits bis zum User-Space durch gekämpft, und immer noch eigener Bootloader.

wieso emulator? nehmt doch 'nen richtigen ARM, z.b. sowas

Interessantes I/O Board für den PC.

Erhard Henkes

zu brokenthorn: Ich habe es nun mit Tut 19, Demo14 probiert, das klappt mit Bochs, also liegt es in Demo15 offenbar am Code für kernel.exe.

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).

Erhard Henkes

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.

Erhard Henkes

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.

Tobiking2

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.

Erhard Henkes

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.

Erhard Henkes

@ 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.

Tobiking2

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.

Erhard Henkes

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.

Tobiking2

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.

Erhard Henkes

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.