Eigenes OS?

Erhard Henkes

das wäre doch doof. die meisten haben windosen. sich extra noch ein OS zu installieren, um dein OS zu bauen, ist nervig.

Interessante Bemerkung. Wenn ich das mit dem Compiler mit ELF (16 u. 32 Bit gemischt) unter Windows schaffe (es gibt ja auch cross-compiler), dann bleibt nur noch GRUB als Thema. Alternativ kann man den bootloader aufmotzen. Mal sehen.

Tobiking2

Erhard Henkes schrieb:

Wenn ich das mit meinem DJGPP (gcc 3.1) ausprobiere erhalte ich vom Linker (ld 2.13) folgende Fehlermeldung:

kernel.o: file not recognized: File format not recognized

Habs grad mal mit dem aktuellen djgpp probiert und das gleiche Problem. DJGPP benutzt nur COFF und unterstützt ELF gar nicht (http://www.delorie.com/djgpp/v2faq/faq22_22.html). Bei coff ist darüber hinaus kein 16 Bit möglich.

Ich bin beim Suchen auf http://exec.h1.ru/docs/os-devel-faq/os-faq-elf.html gestoßen, einer Anleitung um binutils mit elf support zu compilieren.

Erhard Henkes schrieb:

Wenn ich das mit dem Compiler mit ELF (16 u. 32 Bit gemischt) unter Windows schaffe (es gibt ja auch cross-compiler), dann bleibt nur noch GRUB als Thema.

was willste mit 16 bit? dachte dein OS schaltet beim start schon in den (flat memory model) 32bit protected mode und bleibt da auch. oder hab' ich was übersehen?

Erhard Henkes

was willste mit 16 bit?

Schau mal in kernel.asm ... und hier auf das Bild:
http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG

Da liegt der Knackpunkt: 16/32 Bit gemischt in kernel.asm.

Vielleicht kann man das umbauen (ich sehe gerade, dass ich org 0x8000 schon auskommentiert habe, das geht offenbar bereits über das Linker-Skript), damit man coff-Format(?) verwenden kann. Vielleicht kann man auch in zwei Hälften (16 Bit u. 32 Bit Teil trennen, den ersten könnte man als bin resultieren lassen, den zweiten als o(bjekt)-Datei wegen des 'call _main')

Die wating-loop am Ende des 16-Bit-Teils sieht auch nicht sauber aus (war vorher im 32-Bit-Teil, wurde aber aus 16 Bit aufgerufen.

Erhard Henkes schrieb:

Da liegt der Knackpunkt: 16/32 Bit gemischt in kernel.asm.

aber das ist doch ok so, oder? pc-kisten starten nun mal im real-mode, dein asm-code schaltet in den protected mode und ruft die 'main' des kernels auf. von nun an läuft alles im protected mode ab, egal ob C oder assembler. selbst die portabelsten betriebssysteme haben ein paar plattformabhängige assemblermodule. ich weiss garnicht, was dich daran stört, oder ich hab' heute ne besonders lange leitung.

Erhard Henkes

Vielleicht stehe ich heute auf der Leitung. Ich benötige für kernel.asm das aout-Format (verkraftet beim Linken 16/32 bit gemischt) wegen des Linkers! Also ganz sachlich:

So klappt es bestens:

nasmw -O32 -f bin boot.asm -o boot.bin            
	nasmw -O32 -f aout kernel.asm -o kernel.o
	nasmw -O32 -f aout isr.asm -o isr.o
	nasmw -O32 -f aout process.asm -o process.o
	nasmw -O32 -f aout flush.asm -o flush.o

	gcc  -Wall -O  -c ckernel.c -o ckernel.o    
...
	gcc  -Wall -O  -c syscall.c -o syscall.o  

	ld -T kernel.ld kernel.o ... syscall.o  -o ckernel.bin -Map kernel.map

	cmd /c copy /b boot.bin + ckernel.bin MyOS

Nachteil: Modernere Linker kennen kein aout (UNIX assembler out) mehr, wenn ich das richtig verstanden habe.

Versuch 1: nasmw -O32 -f coff kernel.asm -o kernel.o

nasmw -O32 -f coff kernel.asm -o kernel.o
kernel.asm:21: error: COFF format does not support non-32-bit relocations
kernel.asm:26: error: COFF format does not support non-32-bit relocations
kernel.asm:55: error: COFF format does not support non-32-bit relocations
make.exe: *** [all] Error 1

Hier streikt nasm(w) wegen 16 bit relocations.

Versuch 2: nasmw -O32 -f elf kernel.asm -o kernel.o

kernel.o: file not recognized: File format not recognized
make.exe: *** [all] Error 1

Diesmal will der Linker nicht.

Damit hänge ich irgendwie am aout-Format fest.

Vielleicht hilft da ein cross-compiler:

Kennt sich da jemand genau aus? Bin leider (noch) kein Compiler-Experte.

Übrigens ist abc.w hier auch mit mingw gescheitert:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1687893.html

Ich habe das mit mingw (ist in code::blocks enthalten) noch mal probiert:

C:\Programme\CodeBlocks\MinGW\bin\ld: cannot perform PE operations on non PE output file 'ckernel.bin'.

Hmmm, siehe unten!

Kennt sich da jemand genau aus? Offensichtlich lösen die Cross-Compiler dieses Problem.

daher bin ich bei meinem DJGPP (gcc 3.1, ld 2.13) und aout geblieben, habe aber das Gefühl, das man da einen Schritt vorwärts kommen sollte.

Kann mir jemand die Hintergründe, warum man diesen Cross-Compiler bauen muss, mal erklären. Da hat sich doch gegen "früher" etwas verschlechtert, denn ich arbeite doch mit dem DJGPP und dem aout-Format sehr gut! Das Problem ist der Wechsel von aout nach elf.

http://wiki.osdev.org/GCC_Cross-Compiler

Erhard Henkes schrieb:

So klappt es bestens:

nasmw -O32 -f bin boot.asm -o boot.bin            
	nasmw -O32 -f aout kernel.asm -o kernel.o
	nasmw -O32 -f aout isr.asm -o isr.o
	nasmw -O32 -f aout process.asm -o process.o
	nasmw -O32 -f aout flush.asm -o flush.o
		
	gcc  -Wall -O  -c ckernel.c -o ckernel.o    
...
	gcc  -Wall -O  -c syscall.c -o syscall.o  

	ld -T kernel.ld kernel.o ... syscall.o  -o ckernel.bin -Map kernel.map
	
	cmd /c copy /b boot.bin + ckernel.bin MyOS

ok, du kannst nasm- und gcc-output zusammenlinken, also ist doch alles gut. ich sehe jedenfalls keinen grund, die tools zu wechseln (ein solcher wäre für mich z.b. ein ernsthafter bug des gcc oder nasm).
btw, aber wenn du unbedingt wechseln willst, kannste das auch zu einem beliebigen späteren zeitpunkt tun. ist also nix, was die weiterentwicklung deines OS grossartig beeinflussen würde.

chris_g_ivi

Hallo!

Super Topic und Themenwahl!
Ich habe ein kleines Problem! Wenn meine Kernel.bin (ASM + C-Kernel) keine Größe hat, die ohne Rest durch 512 Bytes teilbar ist, dann erhalte Ich einen Triple Fault!
Anfangs habe Ich per "times ??? db 0" die Datei richtig vergrößert, jedoch ist dies bei JEDER Änderung des Kernels notwendig!
Kennt jemand eine Lösung, um dies zu umgehen oder wenigstens das Ergebnis des Linkens auf eine Größe von ?.00 KB zu bringen?

Gruß
Chris

PS: Ich arbeite mit Windoof Vista und habe DJGPP, wie überall angepriesen installiert und in Gebrauch!

Erhard Henkes schrieb:

Ich benötige für kernel.asm das aout-Format (verkraftet beim Linken 16/32 bit gemischt) wegen des Linkers!

Der [BITS 16]-Code in der kernel.asm passt noch in die boot.asm. Dann stünde in der kernel.asm i.e. nur noch folgendes:

[BITS 32]
[extern _main]

 mov    ax, 0x10
 mov    ds, ax      ; data descriptor --> data, stack and extra segment
 mov    ss, ax           
 mov    es, ax
 xor    eax, eax    ; null desriptor --> FS and GS
 mov    fs, ax
 mov    gs, ax
 mov    esp, 0x200000 ; set stack below 2 MB limit

 call _main ; ->-> C-Kernel
(...)

Damit wäre das Linker-Problem vom Tisch. Falls du ernsthaft GRUB in Erwägung ziehst, könntest du konsequenterweise die erste Hälfte von Teil 1 des Tutorials ersatzlos streichen. Das wäre schade.

Erhard Henkes

Der [BITS 16]-Code in der kernel.asm passt noch in die boot.asm.

Ja, die Idee hatte ich gestern auch, nachdem der Code da jetzt relativ kurz ist.

Falls du ernsthaft GRUB in Erwägung ziehst, könntest du konsequenterweise die erste Hälfte von Teil 1 des Tutorials ersatzlos streichen. Das wäre schade.

Ja, das stimmt. Mir gefällt dieser Weg ohne GRUB und Windows auch sehr gut, vor allem, weil alle es anders machen. GRUB ist eben sehr komfortabel. Dafür ist man im Endeffekt an Linux und diesen Bootloader gebunden. Vielleicht schaffen wir es gemeinsam, den Bootloader bzw. kernel.asm (da ist ja Platz, da keine 512 Byte-Grenze mehr vorhanden) den Anforderungen entsprechend zu gestalten und GRUB zu umgehen.

Erhard Henkes

@+gjm+: hast Du die Trennung bereits praktisch durchgeführt?

Ich habe mal versuchsweise getrennt, stürzt aber noch beim Kernel laden ab.

Ansonsten müsste ich nochmal step-by-step versuchsweise den Code in kleineren Häppchen von kernel.asm nach boot.asm schleppen.
Dann könnte man nämlich mal coff testen.

Nachfolgender Code klappt (s.u.).

Erhard Henkes

Einen Fehler habe ich step-by-step gefunden:

cli               ; clear interrupts
    lgdt [gdtr]       ; load GDT via GDTR (defined in file "gtd.inc")	
    jmp 0x8:PM        ; http://www.nasm.us/doc/nasmdo10.html#section-10.1

muss im 16-bit-Teil stehen.

Das macht mir noch ein Problem. So sieht es momentan aus (läuft!):

boot.asm
..

kernel.asm
..

Frage: wie werde ich den 16 bit Teil in kernel.asm noch los? Ich springe ja vom bootloader nach 0x8000 (Kernelstart).

Erhard Henkes schrieb:

Frage: wie werde ich den 16 bit Teil in kernel.asm noch los? Ich springe ja vom bootloader nach 0x8000 (Kernelstart).

Ganz einfach: Im Bootloader in den Protected Mode schalten (lgdt und cr0 laden), und dann mit jmp 0x08:0x8000 in den Kernel springen (d.h. im Bootloader ist auch kein 32 Bit Teil). Im Kernel kannst du dann direkt mit 32 Bit Code anfangen, und musst die Segmentregister erstmal laden. Danach solltest du dann nochmal eine GDT im Kernel laden, falls der Bootloader irgendwann überschrieben wird.

Der boot.asm muß somit nur folgendes hinzugefügt werden:

(...)
.A20_done: 

 cli
 lgdt [gdtr]

 mov eax, cr0
 or  eax, 1
 mov cr0, eax

; jmp 0x8000
 jmp 0x8:0x8000    ; Ist zwar ein 16-bit-FAR-Jmp, allerdings
                   ; wird hier CS mit "index" 8 der GDT geladen (da in PM).
                   ; Deshalb wird der Code ab Sprungziel von der CPU
                   ; als 'BITS 32' interpretiert (s. CODE_Desc in der gdt.inc).
(...)
%include 'gdt.inc' ; <- Achtung : die gdt.inc ist nun hier und nicht mehr in der kernel.asm.

 times 510-($-$$) hlt 
 db 0x55 
 db 0xAA

Nun sollte nur noch in der boot.asm "BITS 16"-Code sein.

Erhard Henkes

Danke! Hat gut funktioniert. Der boot sector ist immer noch halb leer, hat also noch Luft für notwendige Ergänzungen.

kernel.asm stellt sich nun wie folgt dar (ich lade GDT dort auf Anraten nochmals, ist das so im Code richtig umgesetzt?):

[Bits 32]
[global KernelStart]
KernelStart:
    mov    ax, 0x10
    mov    ds, ax        ; data descriptor --> data, stack and extra segment
    mov    ss, ax           
    mov    es, ax
    xor    eax, eax      ; null desriptor --> FS and GS
    mov    fs, ax
    mov    gs, ax
    mov    esp, 0x200000 ; set stack below 2 MB limit

    lgdt [gdtr]          ; load GDT via GDTR (defined in file "gtd.inc")	

[extern _main]           ; entry point in ckernel.c
    call _main           ; ->-> C-Kernel
    jmp $

;;;;;;;;;;;;
; Includes ;
;;;;;;;;;;;;

    %include "gdt.inc"

Die 16/32-Bit-Trennung ist damit gelungen, endlich. Ein kleiner Meilenstein.

Nun geht auch folgendes:

nasmw -O32 -f bin boot.asm -o boot.bin            
nasmw -O32 -f coff kernel.asm -o kernel.o

Aber hier gibt es noch ein kleines Problem, auch noch mit KernelStart:

C:\DJGPP\bin/ld.exe: warning: cannot find entry symbol KernelStart; defaulting to 00008000 <--- Wieso dies?
ckernel.o(.text+0x1f8):ckernel.c: undefined reference to \_file\_data_end' ckernel.o(.text+0x1fd):ckernel.c: undefined reference to_file_data_start'
ckernel.o(.text+0x215):ckernel.c: undefined reference to \_file\_data_end' ckernel.o(.text+0x21a):ckernel.c: undefined reference to_file_data_start'
ckernel.o(.text+0x220):ckernel.c: undefined reference to \_file\_data_start' gdt.o(.text+0xf6):gdt.c: undefined reference to_gdt_flush'
gdt.o(.text+0xfb):gdt.c: undefined reference to \_tss\_flush' idt.o(.text+0x70):idt.c: undefined reference to_idt_flush'
isrs.o(.text+0xe):isrs.c: undefined reference to _isr0' isrs.o(.text+0x21):isrs.c: undefined reference to_isr1'
...
isrs.o(.text+0x29e):isrs.c: undefined reference to _isr127' irq.o(.text+0xc5):irq.c: undefined reference to_irq0'
...
irq.o(.text+0x1f7):irq.c: undefined reference to _irq15' paging.o(.text+0x522):paging.c: undefined reference to_copy_page_physical'
task.o(.text+0x23b):task.c: undefined reference to \_irq\_tail' task.o(.text+0x3c1):task.c: undefined reference to_irq_tail'
task.o(.text+0x7f2):task.c: undefined reference to `_read_eip'
make.exe: *** [all] Error 1

Ich möchte die Syntax mit dem führenden Unterstrich in C behalten. Tipp?

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.

C:\DJGPP\bin/ld.exe: warning: cannot find entry symbol KernelStart; defaulting to 00008000 <--- Wieso dies?

Das Symbol (Label ?) "KernelStart" ist nirgendwo in der kernel.asm definiert.

Erhard Henkes

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.

Also wieder weg.
Der Bereich unter 08:0x8000 wird später nicht beschrieben.

Das Symbol (Label ?) "KernelStart" ist nirgendwo in der kernel.asm definiert.

Mit aout war/ist das kein Problem. Braucht coff das anders? Habe da noch nichts gefunden.

kernel.asm:

[Bits 32]
[global KernelStart]

KernelStart:
    mov    ax, 0x10
    mov    ds, ax      ; data descriptor --> data, stack and extra segment
    mov    ss, ax           
    mov    es, ax
    xor    eax, eax    ; null desriptor --> FS and GS
    mov    fs, ax
    mov    gs, ax
    mov    esp, 0x200000 ; set stack below 2 MB limit

[extern _main]         ; entry point in ckernel.c
	call _main ; ->-> C-Kernel
    jmp $

Das war doch vorher auch nicht anders (da hatte ich nur RealMode).
Warum ist COFF so seltsam?

Ganz schön zickenhaft der ld. Probiere mal folgendes in der kernel.asm:

[BITS 32]

section .text ; <- jawohl lieber ld, "KernelStart" ist nun auch in der section .text :) 

[global KernelStart]

KernelStart:
    mov    ax, 0x10

(...)

Erhard Henkes

Hat wirklich geholfen. Warum schluckt der ld das beim aout-Format und motzt erst beim COFF-Format. Merkwürdiges Verhalten. Man lernt nie aus.

Hilft auch gegen das Ignorieren der C-Funktionen.

Offenbar weiß der Linker beim COFF nicht, wo das Programm anfängt?!

Damit sind wir zumindest den Schritt aout --> coff gegangen.

nasmw -O32 -f coff kernel.asm -o kernel.o
nasmw -O32 -f coff isr.asm -o isr.o
nasmw -O32 -f coff process.asm -o process.o
nasmw -O32 -f coff flush.asm -o flush.o

Vielleicht hilft es bei der Benutzung von Linkern höherer Versionen, die bisher mit aout Probleme hatten.

Erhard Henkes

Wenn wir schon bei so grausamen Themen sind. Ich wollte mal mein opulentes makefile umstellen auf eine variable Darstellung (vor allem, damit man compiler leicht tauschen kann). Hier klappt aber die Umsetzung c --> o und asm --> coff noch nicht, wenn ich das richtig sehe:

# Makefile for PrettyOS

SOURCES=	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

CFLAGS=	-Wall		\
		-O          

LDFLAGS= -T kernel.ld -Map kernel.map
ASFLAGS= -fcoff

CC=gcc
NASM=nasmw
AS=as

all:
	nasmw      -f bin file_data.asm -o file_data.dat
	nasmw -O32 -f bin boot.asm -o boot.bin            
	make -s link
	make -s image	

link:
	ld $(LDFLAGS) -o ckernel.bin $(SOURCES)

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

	partcopy MyOS.bin 0 7000 -f0	

.s.o:
	$(NASM) $(ASFLAGS) $<

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

.a.o:
	$(AS) $(ASFLAGS) -o $<

G:\OSDev\Test\49>make
nasmw -f bin file_data.asm -o file_data.dat
nasmw -O32 -f bin boot.asm -o boot.bin
make -s link
C:\DJGPP\bin/ld.exe: cannot open kernel.o: No such file or directory (ENOENT)
make.exe[1]: *** [link] Error 1
make.exe: *** [all] Error 2

Offensichtlich baut er keine xxx.o aus den xxx.c. und kein coff aus asm.

Wo ist der Hauptfehler? Baue so was sonst nie selbst.