Eigenes OS?
-
Werde mir wohl den weisshaarigen DJGPP runterladen...
DJGPP (gcc 3.1, ld 2.13):
ld.exe: supported targets: coff-go32 coff-go32-exe a.out-i386 srec symbolsrec tekhex binary ihex
ld.exe: supported emulations: i386go32mingw (ld 2.17.50 20060824 )
ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex
ld: supported emulations: i386peHat da jemand die Lösung für den ASM-Kernel (16 u. 32 Bit) bezüglich Kopplung von NASM output file und Linker (ld 2.17) input file?
-
Erhard Henkes schrieb:
Momentan schmökere ich gerade im Buch von Richard A. Burgess "Developing Your Own 32 Bit Computer Operating System" (MMURTL V1.0). Er hatte sich bei seinem Operating System folgende Ziele gesetzt:
ah, ich glaub' das hatte ich mal in den fingern. ist schon ziemlich alt und er hat sein OS komplett in asm programmiert, ne?
Erhard Henkes schrieb:
The name is an acronym for Message based MUltitasking, Real-Time, kerneL."
'message based' bedeutet, dass kein timer-gesteuerter scheduler drin ist, sondern context-switches werden durch versenden von messages herbeigeführt, oder? finde ich gut. präemptives, gewaltsames multitasking nach zeitscheiben ist manchmal gar nicht so toll.
Erhard Henkes schrieb:
Folgende Punkte sehe ich bisher für mein "PrettyOS" (Deckname):
- Flat 32-Bit Virtual Memory Model (das bedeutet PM bei x86)
- Easy programming
- Simplicity (KISS Prinzip gilt in einer komplexen Welt immer mehr)ja, pretty-OS hört sich auch besser an, als der bisherige name.
flat memory model: was denn sonst? segment/offset-gedöns ist einfach nur übel.
easy programming: muss schon sein. keine übertriebenen schutzmechanismen, vertrau dem programmierer, denn er weiss, was er tut.
KISS: sehr vernünftig.
-
PrettyOS nicht pretty-os oder pretty-OS
Zunächst müssen wir erstmal das NASM/Linker-Problem bei mingw (siehe post von abc.w) lösen, damit wir niemanden verlieren.
Multitasking/Singletasking? Da bin ich mir noch nicht sicher, ob Multitasking am Anfang nicht zuviel des Guten ist. Vorbereitet sind wir ja via PM. Mal sehen.
-
Erhard Henkes schrieb:
Da bin ich mir noch nicht sicher, ob Multitasking am Anfang nicht zuviel des Guten ist. Vorbereitet sind wir ja via PM. Mal sehen.
multitasking oder nicht, hängt nicht davon ab, ob du den protected mode verwendest.
-
Ja, das ist richtig. Als PC-Betriebssystem kenne ich bisher noch kein Multitasking OS im Real Address Mode (=Real Mode), muss irgendwie an mir vorbei gegangen sein. Kannst Du mir da mal auf die Sprünge helfen?
Prinzipiell ist task switching / context switching unabhängig von der Adressierungstechnik (direkt gekoppelt mit der physikalischen Adresse oder indirekt über Zeigertabellen). Auch Protected oder Unprotected hängt damit nicht zwingend zusammen.
Kannst Du mir Beispiele nennen für folgende Kombinationen:
Real Address Mode (0) Unprotected (0) Singletasking (0) Example Virtual Address Mode (1) Protected (1) Multitasking (1) Operating System --------------------------------------------------------------------------------------------- 0 0 0 MS-DOS 0 0 1 ? 0 1 0 ? 0 1 1 ? 1 0 0 ? 1 0 1 ? 1 1 0 ? 1 1 1 Linux, MS Windows NT, ...Ist die Systematik so richtig? Alles wirklich unabhängig voneinander?
-
Habe mir DJGPP heruntergeladen und konnte 20090327_eh_os erfolgreich kompilieren, linken, zusammenkopieren. Ein ähnliches Problem wie mit copy wieder gehabt, diesmal mit rename:
C:\BochsMyOS\20090327_eh_os>make C:\nasm-2.06rc6\nasm -O32 -f bin boot.asm -o boot.bin C:\nasm-2.06rc6\nasm -O32 -f aout kernel.asm -o kernel.o c:\djgpp\bin\gcc -c ckernel.c -o ckernel.o c:\djgpp\bin\ld -T kernel.ld kernel.o ckernel.o rename a.out ckernel.bin process_begin: CreateProcess(NULL, rename a.out ckernel.bin, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. make: *** [all] Error 2Dann habe ich mein Makefile umgebaut:
all: ... cmd /c rename a.out ckernel.bin ...Und so funktioniert es bei mir wieder...
Eine Sache vielleicht noch: Die Funktion outportb() im C-Kernel ist ja als inline gekennzeichnet, "inlinen" tut der GCC anscheinend aber ab Optimierungsstufe -O1:all: ... gcc -c ckernel.c -o ckernel.o -O1 ...Man kann sich die Objektdatei ckernel.o mit objdump anschauen, einmal ohne Optimierungsstufe und einmal mit, z.B. so:
c:\djgpp\bin\objdump.exe -D ckernel.oWofür steht eigentlich -O32 beim Aufruf von nasm? -O steht für Optimierung, aber 32... finde grade nichts über Optimierungsstufe 32 in der nasm Doku...
C:\nasm-2.06rc6\nasm -O32 -f bin boot.asm -o boot.binErhard Henkes schrieb:
Zunächst müssen wir erstmal das NASM/Linker-Problem bei mingw (siehe post von abc.w) lösen, damit wir niemanden verlieren.
Nur aus Neugier, wie viele Leute sind noch dabei ?
Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig 
Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate
-
Habe mir DJGPP heruntergeladen und konnte 20090327_eh_os erfolgreich kompilieren, linken, zusammenkopieren.
Super! Freut mich, dass es bei Dir nun auch klappt. Eigentlich ein Hammer, dass das alte Teil mehr kann als das neue
Allerdings hätte mich auch die wirkliche Lösung für den mingw interessiert, aber Hauptsache es geht. Kann man den alten ld vom DJGPP bei den Dateien vom neueren mingw einsetzen?Ein ähnliches Problem wie mit copy wieder gehabt, diesmal mit rename
Das habe ich inzwischen über Bord geworfen, weil es das ckernel.bin nicht überschrieben hat, hätte man aber vorher mit del löschen können. So sieht es momentan aus (video.c ausgelagert), es wird einfach die Option -o ckernel.bin beim Linker ld angegeben:
http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNGall: nasmw -O32 -f bin boot.asm -o boot.bin nasmw -O32 -f aout kernel.asm -o kernel.o gcc -c ckernel.c -o ckernel.o gcc -c video.c -o video.o ld -T kernel.ld kernel.o ckernel.o video.o -o ckernel.bin --verbose cmd /c copy /b boot.bin + ckernel.bin MyOS.bin del video.o del kernel.o del ckernel.o del ckernel.bin del boot.bin partcopy MyOS.bin 0 800 -f0Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig
Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate 
Falls Du das nicht selbst auf einer Homepage verarbeiten willst, sollten wir ein Kapitel über dein Projekt einbauen (natürlich mit Fotos deines Konstrukts, bitte denke an die VDE und Funkabschirmung ).Gibt man "-O32" nasm (das habe ich von Nobuo T übernommen) bei Google ein, so kommen wir hier mit diesem Thread auf Platz eins heraus.
namsw -help liefert Folgendes:
-O<digit> optimize branch offsets (-O0 disables, default)
Danke für den Hinweis mit der Optimierungsstufe und den Tipp bezüglich objdump (man kann die Leser eines solchen OS-Tutorials bezüglich Tools gar nicht genug fit machen).
Das werde ich ins Tutorial einbauen.Ohne Optimierung:
000000be <_outportb>: be: 55 push %ebp bf: 89 e5 mov %esp,%ebp c1: 83 ec 04 sub $0x4,%esp c4: 8b 45 0c mov 0xc(%ebp),%eax c7: 88 45 ff mov %al,0xffffffff(%ebp) ca: 8b 55 08 mov 0x8(%ebp),%edx cd: 8a 45 ff mov 0xffffffff(%ebp),%al d0: ee out %al,(%dx) d1: c9 leave d2: c3 retMit Optimierung -O1:
000000ac <_outportb>: ac: 55 push %ebp ad: 89 e5 mov %esp,%ebp af: 8b 55 08 mov 0x8(%ebp),%edx b2: 8a 45 0c mov 0xc(%ebp),%al b5: ee out %al,(%dx) b6: 5d pop %ebp b7: c3 ret
-
Zur Zeit schlage ich mich in C mit dem Keyboard Driver herum. Nicht gerade einfach die ganze Thematik, auch didaktisch.
-
Hallo Erhard,
finde ich sehr cool, wie du hier eine mini-OS bastelst, habe ich auch mal versucht und bin irgendwann bis zu einer minigrafischen Oberfäche gekommen.
Ich werde das noch mal rauskramen.Ich finde, dass du, bevor du den Keyboardtreiber schreibst, dir ein geeignetes Konzept zur Interruptbehandlung zulegst und das auch schon mal Schablonenartig implementierst.
Ich finde diese Prolog/Epilog Konzept sehr gut. Mit entsprechenden Tricks und Hirnschmalz kann man es dann auch schaffen, dass die Interrupts _nie_ ausgestellt werden müssen.
http://www-ivs.cs.uni-magdeburg.de/bs/lehre/sose97/bs1/seminare/seminar8.shtml
Viel Erfolg noch.
Jens
-
Erhard Henkes schrieb:
Als PC-Betriebssystem kenne ich bisher noch kein Multitasking OS im Real Address Mode (=Real Mode), muss irgendwie an mir vorbei gegangen sein. Kannst Du mir da mal auf die Sprünge helfen?
z.b. von cmx-rtx, embOS, freeRTOS, proc, usw, gibts auch versionen für x86-boards (das sind systeme für den embedded-bereich, machen alle timer-gesteuertes multitasking). die meisten davon laufen im real mode.
-
Erhard Henkes schrieb:
Zur Zeit schlage ich mich in C mit dem Keyboard Driver herum. Nicht gerade einfach die ganze Thematik, auch didaktisch.
http://www.computer-engineering.org/ps2protocol/
http://maven.smith.edu/~thiebaut/ArtOfAssembly/CH20/CH20-1.html
-
Ein ganz anderer Punkt sind die mathematischen und sonstigen Routinen, die man ständig benötigt, und die aber nicht von einer library abhängig sein dürfen.
Beispiel: Will man eine char-, integer- oder float-Zahl auf dem Bildschirm ausgeben, so muss man zunächst diese in einen "string" umwandeln. Man benötigt also ein "frei schwebendes" k_itoa ohne Routinen aus string.h etc. Selbst im alten K&R wurde ich da nicht fündig, da verweist ständig eine Funktion auf die nächste, wie bei einem russischen Püppchen..
-
Ich finde, dass du, bevor du den Keyboardtreiber schreibst, dir ein geeignetes Konzept zur Interruptbehandlung zulegst und das auch schon mal Schablonenartig implementierst.
Ich möchte es zunächst erstmal ohne Interrupts probieren, bin nicht sicher, ob das vernünftig geht, wird dann aber logischerweise der nächste Schritt.
Ich finde diese Prolog/Epilog Konzept sehr gut. Mit entsprechenden Tricks und Hirnschmalz kann man es dann auch schaffen, dass die Interrupts _nie_ ausgestellt werden müssen.
Danke an alle für die tollen Links. Das hilft mir sehr.
Momentan ist mein Hauptproblem, dass ich zwei Rechner benötige, weil ich nicht ständig Windows booten will, wenn das liebe PrettyOS selbst "aus Bochs heraus" meine Tastatur abgeschossen hat.
EDIT:
Problem gelöst, Keyboard-Treiber funktioniert, zur Zeit noch ohne Interrupts, wie ich es wollte.
OS fragt die Tastatur in einer Schleife ab, löscht den Bildschirm und druckt in Zeile 0 das ASCII-Zeichen und in Zeile 1 den ASCII-Code (dank k_itoa). Zur Zeichendarstellung benötigt man bereits zwei Keymaps (eine mit und eine ohne Shift-Taste, zur Zeit International US-Tastatur).
http://www.henkessoft.de/OS_Dev/Bilder/KeyboardDriver_funktioniert.PNG
Gefällt mir didaktisch gut, vor allem noch alles in C außer den Funktionen outportb(...) und inportb(...).Nun muss ich den Sourcecode noch didaktisch optimieren, sieht teilweise improvisiert ziemlich unordentlich aus, kann man so nicht uploaden.
Module:
ckernel.c:
main()video.c:
k_clear_screen()
k_printf(char* message, unsigned int line, char attribute)
void update_cursor(int row, int col)util.c (wollte es nicht stdlib nennen):
void k_itoa(int value, char* valuestring)
void k_i2hex(unsigned int val, unsigned char* dest, int len)
void float2string(float value, int decimal, char* valuestring)math.c:
int power(int base,int n)keyboard.c:
...
...
k_getch()Wohin gehören outportb, inportb?
Wie würdet ihr überhaupt die Module anordnen?
-
Erhard Henkes schrieb:
Ich bin aus persönlichem Interesse dabei, weil ich u.a. vorhabe, hobbymässig einen echten 80386 auf einer Lochrasterplatine zum Laufen zu bekommen. Ein PC ist mir zu langweilig
Überlege gerade, wie ich die RAM Bausteine 8 Stück je 32 kByte anschliesse. Eins weiss ich inzwischen genau: Auf keinen Fall A20 Gate
Falls Du das nicht selbst auf einer Homepage verarbeiten willst, sollten wir ein Kapitel über dein Projekt einbauen (natürlich mit Fotos deines Konstrukts, bitte denke an die VDE und Funkabschirmung ).Eine Homepage habe ich nicht... und hätte auch nichts gegen ein Kapitel mit ein Paar Fotos von meinem Board
Ein Kapitel, der heissen soll "So nicht" Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste... Meine Idee ist, vom PC aus ein binäres Programm auf die Platine "runterladen" und dieses Programm vom 80386 ausführen lassen. Die Kommunikation mit dem PC soll über eine UART gehen und die Steuerung soll ein ATmega644 übernehmen. Sprich, ein 8-Bit Mikrocontroller soll volle Kontrolle über eine 32-Bit CPU haben. Der ATmega soll den 80386 im Reset halten, wenn ein Programm über UART gesendet wird und, dieses Programm ins RAM schreiben. Danach soll der 80386 "freigelassen" werden Also nicht gerage sinnvoll das Ganze. Nicht, dass jemand denkt, boah, der baut einen PC nach... Ich habe noch nicht mal irgendwelche I/O Bausteine für den 386er. Mein Ziel ist also wirklich "nur" 386er soll ein Programm aus dem RAM ausführen und wenn die Spannung weg ist, dann ist auch das Programm weg. Das Programm könnte natürlich alles Mögliche sein, auch ein kleines OS... nur man müsste dann irgendeine Form von I/O dazubauen und Platz dafür wäre auf der Platine da.
Ich kann Dir gerne ein Paar Fotos von dem Board im jetzigen Stand zuschicken, die RAM Bausteine und der 386er sind aber noch nicht drauf...
-
man müsste dann irgendeine Form von I/O dazubauen
Irgendwie erinnert mich das an diese Robotik-/Elektronik-Boards mit ihren Interfaces nach außen, z.B. I2C-Bus. Vielleicht erhältst Du dort Anregungen.
http://www.roboternetz.de/wissen/index.php/RN-Control
-
Erhard Henkes schrieb:
Irgendwie erinnert mich das an diese Robotik-/Elektronik-Boards mit ihren Interfaces nach außen, z.B. I2C-Bus. Vielleicht erhältst Du dort Anregungen. http://www.roboternetz.de/wissen/index.php/RN-Control
Dazu ist noch ein weiter Weg, zuerst muss RAM mit seinem 32-Bit Datenbus funktionieren. Die Funktion der 19 ICs besteht im Prinzip darinm, dass der 20. IC, der ATmega, wie ein Master mit 20-Bit Adressbus und 32-Bit Datenbus erscheint plus ein Paar Steuersignale... Die Funktion dieser 19 ICs muss ich noch überprüfen
PS: Ups, die UART realisiert mit MAX232 läuft bereits, also sind es nur noch 18 ICs...
-
Erhard Henkes schrieb:
Ein ganz anderer Punkt sind die mathematischen und sonstigen Routinen, die man ständig benötigt, und die aber nicht von einer library abhängig sein dürfen.
such dir was aus: http://penguinppc.org/embedded/howto/library.html
abc.w schrieb:
Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste...
das ist nicht dein ernst?!
abc.w schrieb:
Meine Idee ist, vom PC aus ein binäres Programm auf die Platine "runterladen" und dieses Programm vom 80386 ausführen lassen.
na, dann wäre vielleicht das hier was für dich: http://www.amd.com/epd/processors/4.32bitcont/14.lan5xxfam/24.lansc520/index.html
(x86-kompatibel und so)aber wenn du mehr auf basteln stehst (was ich vermute, siehe oben), dann vielleicht doch eher sowas: http://www.mycpu.eu/
-
+fricky schrieb:
abc.w schrieb:
Es ist nämlich so, dass ich inzwischen 20 ICs auf der Platine habe und wenn ich so überlege, noch ziemlich am Anfang stehe. Diese 20 ICs habe ich nicht draufgemacht, weil ich mir Gedanken gemacht habe, wie die Schaltung optimal oder am Besten wäre, sondern, ich hatte sie zufällig in meiner Bastelkiste...
das ist nicht dein ernst?!
Also, es ist nicht so kompliziert, 12 davon sind 74HC244, Tristate Treiber, ein ATmega, ein Paar Schieberegister, Zähler, 3zu8 Dekoder... Würde sagen, lauter Standard-Bausteine.
+fricky schrieb:
na, dann wäre vielleicht das hier was für dich: http://www.amd.com/epd/processors/4.32bitcont/14.lan5xxfam/24.lansc520/index.html
(x86-kompatibel und so)Package Pin Count and Type 388 PBGA
das ist nicht dein ernst?! Nix für meinen "Schlitz"-Lötkolben. +fricky schrieb:
aber wenn du mehr auf basteln stehst (was ich vermute, siehe oben), dann vielleicht doch eher sowas: http://www.mycpu.eu/
Genau, ich stehe auf Basteln. MyCPU ist interessant, wenn man aber bereits mal mit FPGAs in Berührung gekommen ist und zufällig ein FPGA-Board besitzt, dann, nun ja, 8-Bit CPU, hm, hm...
Und wenn man zufällig ein Paar alte 80386 CPUs besitzt, wo man an die Pins auch noch mit nem "Schlitz"-Lötkolben drankommt, warum nicht irgendwas damit bauen. x86 Assembler-Programmierung kann man zwar am PC schön erlernen und vielleicht sogar irgendwie irgendwo anwenden, aber so richtiges Verständnis für die "Physik" fehlt einem irgendwo. Wie ist es mit dem Datenbus, mit dem Adressbus, wie sieht Adressbus aus, welche Steuersignale sind da, was bedeuten sie, was kann man damit machen usw. Eine selbstgebastelte funktioniernde Platine wäre für mich, dass ich u.a. auch diese "Physik"-Ebene verstanden habe...
-
Ich sehe es schon vor mir: Anleitung von abc.w und mir: "Do-it-yourself-PC&OS": Wir basteln uns unseren PC und anschließend coden wir unser OS.
-
Mit der Bitte um Feedback bezüglich Design:
http://www.henkessoft.de/OS_Dev/Downloads/13 C.zip(enthält eine Testvariante mit funktionierendem keyboard driver in C, noch nicht im Tutorial veröffentlicht)
