Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Scan

Seiten: [1]
1
Lowlevel-Coding / Re: Longmode Fragen
« am: 01. February 2008, 22:46 »
Code: [Auswählen]
start.o: In function `start':
src/start.asm:(.text+0x37): relocation truncated to fit: R_X86_64_32 against `.text'
start.o: In function `start_long':
src/start.asm:(.text+0x4b): relocation truncated to fit: R_X86_64_32 against `.data'
src/start.asm:(.text+0x53): relocation truncated to fit: R_X86_64_32 against `.data'

Wäre die Fehlermeldung...

Aber irgnedwie ist mir das alles zu umständlich, vielleicht bleibe ich erstmal bei 32 bit ^^ Danke für eure Mühen  :-)
2
Lowlevel-Coding / Re: Longmode Fragen
« am: 01. February 2008, 13:00 »
Okay, mal abgesehen davon, dass sich der LD beschwert, wenn ich über 4 GB versuche zu mappen, scheint es zu funktionieren. Danke
3
Lowlevel-Coding / Re: Longmode Fragen
« am: 31. January 2008, 22:29 »
soll also heißen, gcc macht es nicht mit, wenn ich versuche, über 4 GB oder unter 2 GB den kernel zu mappen?

edit: Außerdem: Wieso ist mein Kernel, ohne eigentlichen Inhalt, schon 2 MB groß? Wie soll ich denn testen ohne Floppy?
4
Lowlevel-Coding / Re: Longmode Fragen
« am: 31. January 2008, 21:13 »
Nur ne kleine Frage, dann les ich nochmal AMD und Intel genau durch: Was wäre denn ein guter Wert für den Kernel, um gemappt zu werden

Code: [Auswählen]
OUTPUT_FORMAT("elf64-x86-64")
ENTRY(start)
phys = 0x0000000000100000; /* 1 megabytes */
virt = 0x0000800000000000; /* 128 gigabytes */
diff = virt - phys;
SECTIONS
{
. = virt;

__kernel_phys_start__ = . - diff;

.text : AT(ADDR(.text) - diff)
{
*(.text)
*(.rodata*)
. = ALIGN(0x1000);
}
.data ALIGN(0x1000) : AT(ADDR(.data) - diff)
{
*(.data)
}
        .bss ALIGN(0x4) :  AT(ADDR(.bss) - diff)
        {
*(.bss)
*(COMMON)
}

. = ALIGN(0x1000);

__kernel_phys_end__ = . - diff;
}
das ist jetzt meine linkerdatei, und irgendwie beschwert sich ld, dass text, data und bss am falschen platz sind
5
Lowlevel-Coding / Re: Longmode Fragen
« am: 31. January 2008, 17:17 »
4) Und ein eintrag in die 64 bit GDT/IDT, wie sehen die aus?
6
Lowlevel-Coding / Re: Longmode Fragen
« am: 31. January 2008, 17:15 »
2) Also alles mit software-threading... hmm

3) Aber einen JIT-Compiler in ASM? Na ja...
7
Lowlevel-Coding / Re: Longmode Fragen
« am: 31. January 2008, 16:35 »
1) Ah danke für den Hinweis =D

2) Also gibt es kein TSS register mehr?

3) Na ja so was will ich nicht versuchen

Danke für die schnelle Antwort =D
8
Lowlevel-Coding / Longmode Fragen
« am: 31. January 2008, 14:05 »
Da ich ja jetzt endlich 'ne 64 Bit Maschine habe, wollte ich (natürlich) auch ein wenig beim Programmieren aufrüsten. Im Moment lese ich das AMD Manual zum AMD64 format, aber da die Community mir immer mehr sagen konnte als die entwickler, wollte ich hier mal ein paar fragen stellen:

1. Wie komme ich in den 64 bit Modus? (Konnte ich nirgens finden)
2. Was verändert sich beim programmieren im 64 bit Modus (GDT, IDT, Tasks)
3. Was ändert sich beim Kompilieren (Linkerdatei, spezielle gcc-flags usw)

Danke im Voraus für die antworten  :-D
9
Lowlevel-Coding / Re: 4Mb-Pages
« am: 22. December 2007, 23:38 »
Is zwar echt verdammt witzig, diesen Thread zu beobachten... aber was, frag ich mich, hat er noch mit den Pages zu tun?
10
OS-Design / Re: Streaming und Messaging
« am: 21. December 2007, 15:58 »
Ach verdammt...
11
OS-Design / Streaming und Messaging
« am: 21. December 2007, 14:38 »
Ich hab heute wohl ein wenig zu viel nachgedacht und ich wollte mal eine professionellere Meinung hören als meine eigene:

Ich dachte folgendes: Bei Unix-Systemen gibt es ja die device Dateien in /dev, unter anderem aich /dev/tty* für die Terminals, in die man ja einfach reinschreiben kann und es erscheint auf der Konsole. Inwiefern das nun funktioniert, weiß ich nicht und ist auch erstmal irrelevant.

Nun dachte ich mir: Warum kann der Kernel nicht einfach eine Art Speicherbereich anlegen, der so ähnlich ist wie diese devices, um Beispiel ein array von 80*25 words für eine Konsole. Wie in einen C++-Stream könnte man nun in diesen Speicher schreiben lassen, anstatt zum Beispiel den Video-Treiber direkt anzusprechen. Der Video-Treiber seinerseits macht nichts weiter, als diesen Speicherbereich komplett auszulesen und anzuzeigen, abhängig von der aktuellen Konsole.

So könnte man doch eigentlich auch das Messaging allgemein aufziehen, oder? Die Treiber und Programme haben bestimmte, vom Kernel verwaltete Streams, in die sie lesen und schreiben und den Inhalt ensprechend verarbeiten.

Ich weiß jetzt nicht, ob die Idee neu ist oder so was  :| Ist mir nur halt einfach gekommen. Bestimmt gibt es das schon  :roll:
12
Lowlevel-Coding / Re: 4Mb-Pages
« am: 21. December 2007, 14:20 »
Ich brauche die 4MB-pages nur an einer einzigen Stelle, nämlich für das mirror-mapping im Kernel. Sonst müsste ich, nur damit ich global auf den Speicher zugreifen kann, 1024 page tables bauen, jede mit 4 KB Speicherverbrauch, also schon alleine 4 MB nur für die mirror map verschwendet. So brauche ich nur 8 KB.
13
Lowlevel-Coding / Re: 4Mb-Pages
« am: 20. December 2007, 15:40 »
Achso die 4MB pages werden anstelle der Page tables in das Directory geschrieben! Wieder schlauer geworden...  :roll:
Jetzt funktioniert es, danke sehr  :-D
14
Lowlevel-Coding / 4Mb-Pages
« am: 20. December 2007, 10:48 »
Joa ich bin mal wieder dabei... hab wegen einer Lapalie irgendwie alles verloren, was ich mal vorgearbeitet habe.
Beim vorherigen Entwurf von Eyrin hat das Mirror-Mapping funktioniert, aber ich weiß nicht mehr wie. Ich wollte alles als eine liste von 4MB maps darstellen, damit ich 1024 page tables benutzen muss usw. sondern nur 2. Ich glaube, dazu sind die Dinger auch da.
Hab mir also das Intel Manual zu Herzen genommen und nachgesehen, und diesen Code gebaut:
Code: [Auswählen]
start:
mov eax, ebx
sub eax, (0xf0000000-0x00100000)
mov [multiboot], eax

push 2
popf

; First thing to do is setting up the memory to virtual memory

; At first: Mirror map all the memory from 0x00000000 to 0xf0000000

mov eax, 0x00301000
mov ebx, 0x00000083
mov ecx, 0xf00 / 4
.loop1:
mov [eax], ebx
add eax, 0x04
add ebx, 0x00400000
loop .loop1

or dword [0x00301000], 0x10 ; Disable cache for the first 4 MB in memory (too much movement)

; Second: map physical memory from kernel start to kernel end to 0xf0000000
extern __kernel_phys_end__

mov eax, 0x00302000
mov ebx, 0x00100103
mov ecx, 0x1000 / 0x04
.loop2:
mov [eax], ebx
add eax, 0x04
add ebx, 0x1000
loop .loop2

; Then set the directory up

mov dword [0x00300000], 0x00301103
mov dword [0x00300f00], 0x00302103

mov eax, 0x00300000
mov cr3, eax

; Set PSE flag
mov eax, cr4
or eax, 0x10
mov cr4, eax

; Set Paging
mov eax, cr0
or eax, 0x80000000
mov cr0, eax
Okay ich bin mit kommentaren sparsam, aber es sollte soweit ersichtlich sein. Der Kernel liegt physikalisch an 0x00100000 und virtuell bei 0xf0000000 und wird offensichtlich ordentlich gemappt. Aber mein Problem ist jetzt folgendes: Beim nächsten Schritt versucht der auf Speicher zuzugreifen, auf 0x00100090 oder so, dass allerdings aus irgendeinem Grund nach 0x40000000 gemappt worden ist. Und weiß nicht wieso, ich hab doch alles ordentlich gesetzt oder?

TFYA
Seiten: [1]

Einloggen