4. Eigenes OS?

Eigenes OS?

  • S

    +gjm+ schrieb:

    ich lade GDT dort auf Anraten nochmals, ...

    😕 Das macht hier keinen Sinn weil gelten würde : "alte GDT == neue GDT". Ausserdem müssten dann die Segmentregister erst wieder mit den Deskriptoren der "neuen" GDT initialisiert werden bevor sie "Wirkung" zeigen.

    Der Zweck ist wie gesagt Problemen vorzubeugen, wenn der Bootsektor überschrieben wird, weil die GDT beim LGDT nicht in die CPU geladen wird. Wenn die GDT, die sich außerhalb des Kernels befindet, überschrieben wird, weil die Speicherverwaltung den Bereich, wo der Bootsektor war, als freien Speicher empfinden, knallt es beim Nachladen der Segmentregister.

    Das Laden der Segmentregister ist nicht zwingend notwendig, sofern alte und neue GDT den selben Inhalt haben. (Und wenn die Segmentregister nicht aus Versehen mit alten Selektoren geladen werden, ist es auch kein Problem eine neue GDT anzulegen.)

    Aber wenn Erhard die guten 32 KByte RAM da unten verrotten lassen will, soll mir recht sein. Hat er ja schließlich für bezahlt. ^^

    Erhard Henkes schrieb:

    Ich sehe aber kein kernel.o im Verzeichnis.

    Weil du kein Target abhängig von den $(SOURCES) gemacht hast. Make weiß nicht, dass die Objektdateien vorher gebaut werden müssen, weil du es ihm nicht gesagt hast.

    0
  • E
    Mod

    Ich dachte, dieses

    .c.o:
	$(CC) -c $(CFLAGS) -o $@ $<

    kümmert sich bereits darum. Wenn das nur faul rum hängt, fliegt's raus. 😃
    .c.o sei auch obsolet, habe ich irgendwo gelesen. Dieses $@ $< finde ich auch irgendwie unlesbaren Mist.

    Die sechs Assemblerzeilen schreibe ich nun lieber fix rein, nur mit Variable für Format und Flags.

    TARGET des Link-Vorgangs ist für mich ckernel.bin, oder?

    So wird brav kompiliert, ich kann den Compiler und die Flags zumindest variabel austauschen und verstehe das makefile noch bestens. Das doppelte Aufführen der Dateinamen muss allerdings noch weg, aber unbedingt leserlich und klar nach vollziehbar.

    # Makefile for PrettyOS

ASFLAGS= -O32 -f coff

TARGET= ckernel.bin
OBJ= kernel.o ckernel.o isr.o video.o flush.o gdt.o	\
		idt.o isrs.o irq.o util.o math.o timer.o keyboard.o \
		process.o ordered_array.o paging.o kheap.o descriptor_tables.o \
		task.o fs.o initrd.o syscall.o

LDFLAGS= -T kernel.ld -Map kernel.map
LD= ld

CFLAGS=	-Wall -O          
CC= gcc

all:
	nasmw      -f bin file_data.asm -o file_data.dat
	nasmw -O32 -f bin boot.asm -o boot.bin  
	nasmw $(ASFLAGS) kernel.asm -o kernel.o
	nasmw $(ASFLAGS) isr.asm -o isr.o
	nasmw $(ASFLAGS) process.asm -o process.o
	nasmw $(ASFLAGS) flush.asm -o flush.o
	make compile
	make link
	make image	

compile:	
	$(CC)  $(CFLAGS)  -c ckernel.c -o ckernel.o    
	$(CC)  $(CFLAGS)  -c video.c -o video.o -O1
	$(CC)  $(CFLAGS)  -c math.c -o math.o -O1
	$(CC)        -O   -c util.c -o util.o -O1
	$(CC)  $(CFLAGS)  -c gdt.c -o gdt.o
	$(CC)  $(CFLAGS)  -c idt.c -o idt.o
	$(CC)  $(CFLAGS)  -c isrs.c -o isrs.o	
	$(CC)  $(CFLAGS)  -c irq.c -o irq.o
	$(CC)  $(CFLAGS)  -c timer.c -o timer.o 	
	$(CC)  $(CFLAGS)  -c keyboard.c -o keyboard.o
	$(CC)  $(CFLAGS)  -c ordered_array.c -o ordered_array.o
	$(CC)  $(CFLAGS)  -c paging.c -o paging.o
	$(CC)  $(CFLAGS)  -c kheap.c -o kheap.o
	$(CC)  $(CFLAGS)  -c descriptor_tables.c -o descriptor_tables.o
	$(CC)  $(CFLAGS)  -c task.c -o task.o 
	$(CC)  $(CFLAGS)  -c fs.c -o fs.o
	$(CC)  $(CFLAGS)  -c initrd.c -o initrd.o  
	$(CC)  $(CFLAGS)  -c syscall.c -o syscall.o

link:
	$(LD) $(LDFLAGS) -o $(TARGET) $(OBJ)

image:
	cmd /c copy /b boot.bin + ckernel.bin MyOS    
	del *.coff
	del *.o
	del *.bin
	cmd /c rename MyOS MyOS.bin
	del MyOS

	partcopy MyOS.bin 0 7000 -f0

    Wie kann ich diesen Teil mit "compile:" allgemein ablaufen lassen analog dem Linker-Befehl? Da die o alle aus c kommen, sollte das gehen.

    Sollte man die o (OBJECTS) oder die c (SOURCES, wie unten stehend) auflisten? Ich habe das mit den obj-Dateien bevorzugt, also den Linker-Vorgang in den Mittelpunkt gerückt, weil ja auch obj-Dateien von NASM zu verarbeiten sind.

    Bei makefiles stehe ich immer grundsätzlich auf dem Schlauch, weil jedes Vorbild anders aussieht und die Tutorials absolut nix taugen, weil diese keine klare Linie vorgeben. Vielleicht gibt es auch einfach keine. 😃

    So in etwa findet man es z.B. (Bsp. mit C++, mit diesem obsolet-Stil .cpp.o, den Linker finde ich dort z.B. nicht, Compile- und Link-Vorgang verquickt, irgendwie viel unverständliches Zeugs, die letzte Zeile habe ich ja oben gerade gekillt, weil sie noch nicht gearbeitet hat, lag da nur so rum, ich habe sie aber verstanden trotz wildcards):

    CC=g++
    CFLAGS=-c -Wall
    LDFLAGS=
    SOURCES=main.cpp hello.cpp factorial.cpp
    OBJECTS=$(SOURCES:.cpp=.o)
    EXECUTABLE=hello

    all: $(SOURCES) $(EXECUTABLE)

    $(EXECUTABLE): (OBJECTS)(OBJECTS) (CC) $(LDFLAGS) $(OBJECTS) -o $@

    .cpp.o:
    $(CC) $(CFLAGS) $< -o $@

    Am schlimmsten finde ich so etwas "SOURCES:.cpp=.o" mit diesem Doppelpunkt.
    Vielleicht kann mir da jemand auf die Sprünge helfen. Ich finde es gut, wenn Compile- und Link-Vorgang getrennt dargestellt werden, weil dies bei einem OS wichtig ist.

    So etwas wie
    $(CC) $(CFLAGS) -c $(SOURCES) -o $(OBJECTS)
    wäre gut verständlich. Dann müsste man aber die c-Dateien noch allgemein als Sources angeben. Habe dies probiert, hat aber nicht geklappt. Vielleicht kann jemand meine Idee doch noch zum Laufen bringen:

    # Makefile for PrettyOS

    # Assemble
    ASFLAGS= -O32 -f coff

    # Compile
    SOURCES= ???.c
    CFLAGS= -Wall -O
    CC= gcc

    # Link
    OBJ= kernel.o ckernel.o isr.o video.o flush.o gdt.o \
    idt.o isrs.o irq.o util.o math.o timer.o keyboard.o \
    process.o ordered_array.o paging.o kheap.o descriptor_tables.o \
    task.o fs.o initrd.o syscall.o
    TARGET= ckernel.bin
    LDFLAGS= -T kernel.ld -Map kernel.map
    LD= ld

    all:
    nasmw -f bin file_data.asm -o file_data.dat
    nasmw -O32 -f bin boot.asm -o boot.bin
    nasmw $(ASFLAGS) kernel.asm -o kernel.o
    nasmw $(ASFLAGS) isr.asm -o isr.o
    nasmw $(ASFLAGS) process.asm -o process.o
    nasmw $(ASFLAGS) flush.asm -o flush.o
    make compile
    make link
    make image

    compile:
    ??? #Idee: $(CC) $(CFLAGS) -c $(SOURCES) -o $(OBJECTS)

    link:
    $(LD) $(LDFLAGS) -o $(TARGET) $(OBJ)

    image:
    cmd /c copy /b boot.bin + ckernel.bin MyOS
    del *.o
    del *.bin
    cmd /c rename MyOS MyOS.bin
    partcopy MyOS.bin 0 7000 -f0

    c.o.:
    $(CC) -c $(CFLAGS) -o $@ $<

    0
  • E
    Mod

    Aber wenn Erhard die guten 32 KByte RAM da unten verrotten lassen will, soll mir recht sein. Hat er ja schließlich für bezahlt. ^^

    Ja, aber man muss ja auch andere denken. 🙂 Der Speicher bis 0x00008000 sollte nach dem Boot-Vorgang schon wieder genutzt werden können, aber irgendwo muss das GDT ja dann liegen, z.B. nach dem Kernel-Ende:

    Das gute PrettyOS hat das ja alles schon im C-Kernel eingebaut, wenn ich das richtig sehe, und das wird in main() nach Bildschirmlöschen und Begrüßen umgehend installiert:

    flush.asm (siehe lgdt [...] )
    ..

    Dieses gdt_flush wird mittels gdt_install in main() aufgerufen:
    ..

    int main()
{
    k_clear_screen();
    printformat("Welcome to PrettyOS ... \n");
    // GDT, IDT, ISRS, IRQ, timer, keyboard, paging, interrupts, multitasking
    gdt_install();
//...
}

    Ist das so o.k.? Die GDT sitzt dann bei der Adresse &gdt. Ich habe zur Kontrolle ein printformat eingebaut:

    Welcome to PrettyOS ...
    gdt: 0000D480h

    Den Verschwendungsvorwurf kann ich so nicht auf mir sitzen lassen. 😉 😃

    0
  • E
    Mod

    Bezüglich makefile bin ich nun komplett umgeschwenkt und verwende Folgendes:

    SOURCES = kernel.asm $(filter-out file_data.asm boot.asm kernel.asm make_initrd.c,$(wildcard *.asm *.c))
OBJECTS = $(addsuffix .o,$(basename $(SOURCES)))

ASFLAGSBIN= -O32 -f bin
ASFLAGSCOFF= -O32 -f coff
NASM = nasmw

CFLAGS= -Wall -O          
CC= gcc

LDFLAGS= -T kernel.ld -Map kernel.map
LD= ld

all: boot.bin ckernel.bin
	make -s image
	make -s floppyimage

process.asm: file_data.dat file_data.da1

file_data.dat: file_data.asm
	$(NASM) $(ASFLAGSBIN) $< -o $@

boot.bin: boot.asm
	$(NASM) $(ASFLAGSBIN) $< -o $@

%.o: %.asm
	$(NASM) $(ASFLAGSCOFF) $< -o $@

ckernel.bin: $(OBJECTS)
	$(LD) $(LDFLAGS) $+ -o $@ 

image:
	cmd /c copy /b boot.bin + ckernel.bin MyOS    
	del *.o
	del *.bin
	cmd /c rename MyOS MyOS.bin

floppyimage:	
	partcopy MyOS.bin 0 7000 -f0	

# $<	Erste Abhängigkeit
# $@	Name des Targets
# $+	Liste aller Abhängigkeiten

    Trotz Verwendung von $<, $+ und $@ finde ich diesen ziel- bzw. abhängigkeitsbezogenen Stil ebenfalls gut nachvollziehbar.
    Ich bin immer wieder verblüfft über die vielfältigen Möglichkeiten, die diese Makefile-Syntax bietet. 😃

    0
  • B

    Von den vielfältigen Möglichkeiten abgesehen, die man in 20 Jahren nicht mal genutzt hat - und die noch vielfältigeren, die man noch gar nicht kennt. 😉
    Und bei den ganzen Tools, die in einem Compilerpaket immer dabei sind, fehlt mir immer noch eines, was komplexe zeilenübergreifende Ersetzungen mit Berücksichtigung von Klammerebenen erlaubt. Reguläre Ausdrücke sind viel zu schwach. Aber das wäre ein anderes Projekt 😉

    0
  • E
    Mod

    Da das Verständnis für das Thema (Virtual) Filesystem/Files (Filesystem-Header, File-Header) wichtig ist, habe ich am Beispiel der RAM Disk manuell (mit dem Hex-Editor, damit man mitdenken und abzählen muss, was man macht) ein viertes File (nämlich genau unser winziges 29-Byte-TEST-Programm) in das Filesystem "eingeklinkt". Die Daten werden via Filesystem (Zahl 4 im Filesystem-Header zeigt 4 Files an, File-Header zeigt Name, Offset und Länge an, allerdings nicht Filetyp oder anderes, alos noch sehr primitiv, aber es geht ja noch ums Prinzip) gefunden, in ein lokales Array auf dem Stack gelesen, zur Sicherung an eine neue Stelle in ein globales Array (address_TEST in der Sektion bss; da überlege ich noch, was eigentlich der beste Platz ist) transferiert, im Prozess 'test' als Funktion aufgerufen und ausgeführt.

    Damit wurde nun genau genommen ein (zugegebenermaßen kleines) Programm "von Disk geladen" und in Multitasking "ausgeführt". Das Grundprinzip funktioniert aber auch im User-Bereich mit Datenbereich, Stack, User-Lib etc. gleich.

    http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId216641
    http://www.henkessoft.de/OS_Dev/Downloads/20090621_36x_load_file_TEST.zip

    0
  • E
    Mod

    Das Thema user mode und syscalls habe ich hier beschrieben:
    http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId338709

    Ich verzichte bei Systemaufrufen auf einen Task-Wechsel und verwende den fault_handler (exceptions) und syscall_handler zum Aufruf der gewünschten Kernel-Funktion. Die Assemblerroutine kümmert sich um den korrekten Kontextwechsel von Ring 3 nach Ring 0 und zurück.
    http://www.henkessoft.de/OS_Dev/Bilder/syscall.PNG

    0
  • E
    Mod

    Ein ganz wichtiger Punkt ist nun der Einsatz eines Cross-Compilers/-Linkers, der vor allem auch das ELF-Format erlaubt, das man für andere Hobby-OS und später für User-Programme benötigt. Man benötigt allerdings auch ein brauchbares make-Tool, das alle Anforderungen erfüllt, findet man nun alles hier, natürlich alles einfach und übersichtlich nachzuvollziehen:
    http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId42018

    Wichtig ist, dass man nun aus Assembler-Quellcode leicht elf-object- und mittels des linkers der cross-compiler-tools daraus elf-executable-Dateien herstellen kann. Es ist nun die nächste Aufgabe diese elf-Programme seitens Pretty-OS im "user space" zum Laufen zu bringen. Dann kann man zur Zeit mittels incbin und Einbinden in die RAM Disk Programme im VFS "loadable" zur Verfügung stellen.
    Dort sollte z.B. später die Programme

    init,
    vielleicht noch einge Treiber
    und eine shell

    stehen. Das wäre dann eine interessante Aufgabe für das Assembler-Forum, solche kleinen Programme in Assembler zu erstellen.

    nasm(w) -felf -o file.o file.asm
    i586-elf-ld -T user.ld -nostdinc -o program.elf file.o

    user.ld:

    ENTRY(_start)
OUTPUT_FORMAT(elf32-i386)

SECTIONS
{
    . = 0x400100;

    .text :
    {
      *(.text*)
    }
    .data :
    {
      *(.data*)
      *(.rodata*)
    }
    .bss :
    {
      *(.bss*)
    }
}

    Setzt man kein Linkerscript ein

    i586-elf-ld -nostdinc -o program.elf file.o

    so ergibt sich die default Adresse: 0x08048000 + program_offset
    http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId95189

    Kann jemand erklären, warum gerade diese Adresse verwendet wird?

    Mit Einsatz der Cross-Tools ist das Thema Linux und GRUB damit vorerst vom Tisch, wie gewünscht. 🙂

    Nächstes kapitel wird richtiger user mode, denn bisher wurde der kernel als user mode / read-only eingesetzt (ein Erbe von JM's Tut.)

    0
  • E
    Mod

    User-Land macht Fortschritte. User-Programme werden momentan noch via incbin in die RAM Disk geladen, dort mit VFS gefunden und in den User-Page-Bereich geschoben. Dort greifen sie via syscalls (int 0x7F) auf die in syscall.h/.c freigegebenen Kernel-Funktionen zu.

    Linkerscript user.ld:

    ENTRY(_start)
OUTPUT_FORMAT(elf32-i386)
SECTIONS
{
    . = 0x400100;
	.text : { *(.text*)             }
    .data : { *(.data*) *(.rodata*) }
    .bss :  { *(.bss*)              }
}

    makefile:

    ASFLAGSBIN= -O32 -f bin
ASFLAGSOBJ= -O32 -f elf
NASM = nasmw

CFLAGS=	-O -ffreestanding -fleading-underscore    
CC= i586-elf-gcc

LDFLAGS= -T user.ld -Map kernel.map -nostdinc
LD= i586-elf-ld

all: program.bin program.elf

program.bin: program.asm
	$(NASM) $(ASFLAGSBIN) $< -o $@

program.o: program.asm
	$(NASM) $(ASFLAGSOBJ) $< -o $@

program.elf: program.o
	$(LD) $(LDFLAGS) $+ -o $@ 

#    $<		Erste Abhängigkeit
#    $+		Liste aller Abhängigkeiten	
#    $@		Name des Targets

    Erste kleine User-Beispiel-Programme:

    [BITS 32]
start:
   mov [0x000b8000], byte 'T'
   mov [0x000b8002], byte 'e'
   mov [0x000b8004], byte 's'
   mov [0x000b8006], byte 't'
   mov [0x000b8008], byte ' '
   mov eax, 4
   int 0x7F
   jmp start

    [BITS 32]
start:
   mov ebx, 0x4  ; 1. Argument
   mov ecx, 0x0  ; 2. Argument
   mov eax, 2    ; settextcolor
   int 0x7F

   mov ebx, 0x54 ; 'T' 
   mov eax, 1    ; putch
   int 0x7F

   jmp start

    Output: http://www.henkessoft.de/OS_Dev/Bilder/userprogram001.PNG

    http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId710871 (wird noch ausgebaut)
    http://www.henkessoft.de/OS_Dev/Downloads/20090703_61.zip (Download)

    Nun gäbe es z.B. folgende Aufgaben:
    - elf-exec-Parser
    - syscalls systematisch aufbauen
    - user-Programme schreiben
    - user-lib entwickeln
    - user-Programme init und shell schreiben
    - Treiber

    Hat jemand gute Ideen, was man auf dem jetzigen Stand alles so machen könnte mit kleinen Assembler-Programmen (passt zum Unter-Forum) und dazu passenden Syscalls? 🙂

    Eine Frage ist auch, wie man das Arrangement der Syscalls sinnvoll aufbaut. Vielleicht hat hier jemand eine klare Meinung?

    Auf jeden Fall kann man Teil 2 des Tutorials so langsam beenden, denn wesentliche Elemente eines durch einen eigenen Bootloader hochgefahrenen OS auf dem 80x86 wurden bisher konkret gezeigt.

    Nun stellt sich die Frage, was man in Teil 3 sinnvoll angehen könnte:
    Es kommt bei der Weiterentwicklung von PrettyOS z.B. darauf an, welchen Kernel-Typ man anstrebt. Bei einem monolithischer Kernel umfassen die Syscalls z.B. die POSIX-Funktionen, Win32API bzw. irgendeine eigene API. Dies verlagert die komplette Funktionalität eines Betriebssystems in den Kernel. Beim Mikrokernel-Typ sind die Syscalls vor allem IPC, Speichermanagement und etwas Prozessmanagement. Die IPC stellt die Kommunikation zwischen den Prozessen sicher, um die jeweils benötigtge Funktionalität zu triggern. Der Kernel brennt dann inhaltlich eher auf Sparflamme.
    Darüber hinaus könnte man verschiedene Treiber anbieten. Bisher haben wir die Hardware des PC geschont, so dass Ladevorgänge via Emulator oder in einem Rutsch beim Booten von Floppy Disk abliefen.

    Falls jemand konkret Lust hat, mich bei (Re-)Design des Kernels, Definition der syscalls und Aufbau der User-Applikations-Landschaft (NASM-Assembler oder nach Aufbau einer API-Lib für die syscalls auch in C) zu unterstützen, da wäre ich nicht abgeneigt. Kein Zeitdruck. Ich denke nicht, dass man das konkrete Development im Forum machen kann. Mein persönliches Ziel (gute Co-Autoren werden akzeptiert): Buch "Betriebssystementwicklung - leicht gemacht" 😉

    ICQ: 76194616 🙂
    http://www.henkessoft.de/OS_Dev/OS_Dev3.htm (development ongoing) 🙂

    0
  • E
    Mod

    Wichtiger Meilenstein:
    User-Programme in C mit userlib.h/.c anstelle Assembler-User-Programme. Echt gutes Gefühl, wenn so etwas endlich läuft. 😃 👍
    Hier sollte sogar C++ möglich sein. 😉

    http://www.henkessoft.de/OS_Dev/Downloads/20090705_66.zip

    // userlib.h

#ifndef USERLIB_H
#define USERLIB_H

void settextcolor(unsigned int foreground, unsigned int background);
void putch(unsigned char val);

#endif

// userlib.c

#include "userlib.h"

void settextcolor(unsigned int foreground, unsigned int background)
{
    asm volatile( "int $0x7F" : : "a"(2), "b"(foreground), "c"(background) );
}

void putch(unsigned char val)
{
    asm volatile( "int $0x7F" : : "a"(1), "b"(val) );
}

// program.c

#include "userlib.h"

int main()
{
  settextcolor(14,1);
  putch('T');
  putch('e');
  putch('s');
  putch('t');
  return 0;
}
    0
  • K

    Mit was für einem Dateisystem arbeitest du?
    bzw. hast du schon eins?

    0
  • H

    Wenn du dur mal das Tut zum OS ansehen würdest, oder dir das OS ansiehst, würdest du feststellen, dass dort noch gar kein Festplattenzugriff ist.

    0
  • K

    Ich meine gar keinen Festplatten sondern Diskettenzugriff.
    Außerdem kann es ja sein, dass schon etwas ins Auge gefasst wurde.

    0
  • E
    Mod

    Mit was für einem Dateisystem arbeitest du? bzw. hast du schon eins?

    Bei User-Programmen wird mit dem ELF-executable-Format gearbeitet. In der RAM disk wird ein von James Molloy selbst gestricktes Format eingesetzt (Quellcode für Erzeuger-Programm liegt bei). Bezüglich der "Datenträger" weiß ich noch nicht wie ich vorgehen soll. Diskettenlaufwerke sind sicher nicht mehr der Hit und an vielen PCs nicht mehr vorhanden. Alle Programme werden bisher via "incbin" innerhalb initrd.img in den Kernel transportiert und dort über das VFS und selbst gestrickte Dateisystem gefunden und "geladen".

    0
  • K

    Ah ok.
    Das hilft mir doch schonmal weiter.
    Da ich nicht denke, das Diskettenlaufwerke untergehen sollten und da mein OS die Massen nicht interessieren wird, habe ich ein ext2-System auf der Floppy mit dem OS.
    Ich hab gehofft du benutzt das auch und wüsstest einen Treiber dafür.
    Aber scheint ja nicht der Fall zu sein.

    0
  • E
    Mod

    Da ich nicht denke, das Diskettenlaufwerke untergehen sollten

    Da stehst Du wohl nicht völlig alleine da mit dieser Meinung, aber aufhalten kann den Niedergang niemand mehr. Das Ende der drehenden Scheiben ist nahe.

    ext2-System auf der Floppy mit dem OS

    Da ich MS Windows als Host-System mit Cross-Compiler/-Linker für die OS-Entwicklung verwende, wollte ich mich - wenn überhaupt - eher auf ELF und FAT konzentrieren.

    0
  • E
    Mod

    Die bisherige Begrenzung für den Kernel im Bootloader ist endlich gefallen:
    http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId882541

    Der Bootloader und zugehörige Aufgaben vor dem Start der C-Datei ist bisher noch ein gehöriger Schwachpunkt. Die Ratschläge, endlich GRUB einzusetzen, verstummen nicht.

    Musste allerdings noch die bss section nullen, das hat noch gefehlt.
    Ich könnte echt einen BIOS / Bootloader / ... -Spezialisten brauchen.

    Instabiler Code, der auf mehreren PCs getestet wurde und in einigen Fällen zu "Datenverlusten" in der RAM Disk führte, was dann teilweise #PF oder fehlendes User-Programm zur Folge hatte.
    http://www.henkessoft.de/OS_Dev/Downloads/20090720_83.zip
    (Fehler in fs.h/fs.c muss noch exakt lokalisiert und behoben/abgefangen werden)

    Da das Problem eindeutig in dem verwendeten Code von James Molloy für VFS/RAM Disk liegt, wurde das in nachfoglendem Code einfach umgangen:
    Hier ist ein stabiler Code, der VFS umgeht, solange der Fehler nicht exakt lokalisiert und behoben wurde: http://www.henkessoft.de/OS_Dev/Downloads/85.zip 🙂

    0
  • 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
Anmelden zum Antworten