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 - rizor

Seiten: 1 ... 23 24 [25] 26 27
481
Lowlevel-Coding / Re: Paging
« am: 17. December 2008, 19:27 »
Das bedeutet, dass meine Page-Directory an einer anderen stelle liegen muss, oder wie?
Also bei 0x2000, etc.
Aber wie mache ich das am besten mit meiner physikalischen Speicherverwaltung?
Die gibt mir ja vor, wo das alles zu liegen hat.
482
Lowlevel-Coding / Re: Paging
« am: 17. December 2008, 19:11 »
Ok stimmt.
War vorher auch nicht da...
Wieso soll es auf 0x1000 zeigen?
Das muss doch dahin zeigen, wo meine Directory liegt, oder?
Aber ich alloziere mir ja Speicher dieser Größe und wer sagt mir, dass das Teil bei 0x1000 liegt?
483
Lowlevel-Coding / Re: Paging
« am: 17. December 2008, 18:48 »
Das ist der initialisierende Code:

paging_directory = (paging_directory_t)phys_alloc(PAGING_DIRECTORY_SIZE);
    memset(paging_directory , 0 , BLOCK_SIZE);
    paging_directory[PAGING_VIRTADDR >> PAGING_DIR_SHIFT] = (dword)paging_directory | PAGING_PRESENT | PAGING_WRITEABLE;
    size_t kernel_size = ((dword)kernel_end - (dword)kernel_start) / BLOCK_SIZE;
    map_paging_range(kernel_start , kernel_mem_start , PAGING_PRESENT | PAGING_WRITEABLE | PAGING_NOTTLB , kernel_size);
    size_t video_size = 80 * 25 * 2 / BLOCK_SIZE + 1;
    map_paging_range((physaddr_t)0xB8000 , (virtaddr_t)0xB8000 , PAGING_PRESENT | PAGING_WRITEABLE , video_size);
    map_paging(paging_directory , paging_directory , PAGING_PRESENT | PAGING_WRITEABLE);
    map_paging_range(bitmap_start , bitmap_start , PAGING_PRESENT | PAGING_WRITEABLE , bitmap_length / BLOCK_SIZE);
    //enable paging
    _write_cr3((dword)&paging_directory);
    _write_cr0(_read_cr0() | 0x80000000);

Wieso soll cr3 aof 0x1000 zeigen?
Meintest du nicht er 0x1090?
484
Lowlevel-Coding / Re: Paging
« am: 17. December 2008, 17:18 »
Danke.
Nun habe ich leider ein anderes Problem.
Wenn ich alles gemappt habe und dann das Paging aktivieren möchte, bekomme ich beim qemu ein triple fault.
Das liegt daran, dass ih cr0 das 31-Bit setze.
Leider kann ich mir nicht erklären.
Was mir aufgefallen ist, ist dass wenn ich zwei debug-ausgaben mache, dass meine page-directory auf 0x0001090 oder so zeigt und der Eintrag in dem cr3 Register auf 0x0001027 oder so.
Woran kann das liegen?
Ist das der Grund für meinen triple fault?

Leider funktioniert bei mir bochs nicht (findet die VGA-Bibliothek nicht), deshalb kann ich damit leider nicht debuggen und das Debugging beim qemu will bei mir nicht so richtig laufen...

Danke für eure Hilfe.

Gruß
rizor
485
Lowlevel-Coding / Re: Makefile "spinnt"
« am: 17. December 2008, 09:56 »
Danke.
Ein klarer Fall von Betriebsblindheit
486
Lowlevel-Coding / Re: Paging
« am: 17. December 2008, 00:06 »
Habe mal versucht mein Paging zu implementieren.
Leider funktioniert das Mappen des GraKa-Speichers nicht.
Der Code soeht wie folgt aus:
size_t video_size = 80 * 25 * 2 / BLOCK_SIZE + 1;
map_paging_range((physaddr_t)0xB8000 , (virtaddr_t)0xB8000 , PAGING_PRESENT | PAGING_WRITEABLE , video_size);

Dazu dann noch die Methode, die mappen soll:
    paging_table_t paging_table;
    dword virt_page = (dword)vaddr;

    if(vaddr == NULL)
        panic("Illegal call to the NULL-Table-Entry");

    if(flags & ~0x01F)
        return;

    if(((dword)vaddr | (dword)paddr) && 0xFFF)
        panic("The requested address is not 4k-aligned");

    //page does not exist
    if((paging_directory[virt_page / PAGING_TABLE_SIZE] & PAGING_NOTTLB) == 0 ){
        paging_table = (paging_table_t)phys_alloc(sizeof(paging_table_t));

        paging_directory[virt_page / PAGING_TABLE_SIZE] = ((dword)paging_table) | flags;

        memset(paging_table , 0 , BLOCK_SIZE);
    }

Es wird folgender Panic ausgelöst:
The requested address is not 4k-aligned

Woran kann das liegen?
487
Lowlevel-Coding / Makefile "spinnt"
« am: 17. December 2008, 00:02 »
nabend,

wollte eben meinen neuen virtuellen Speichermanager compilieren.
Leider funktioniert mein Makefile nicht.
Der Aufruf sieht wie folgt aus:

CC = /usr/bin/gcc
ASM = /usr/bin/nasm
CFLAGS = -O3 -fstrength-reduce -fomit-frame-pointer -finline-functions -fno-stack-protector -nostdinc -fno-builtin -march=i386 -I../include
ASMFLAGS = -felf

all:
$(CC) $(CLFAGS) -c -o ../../obj/virtmem.c.o virtmem.c
$(CC) $(CFLAGS) -c -o ../../obj/physmem.c.o physmem.c
$(ASM) $(ASMFLAGS) -o ../../obj/virtmem.asm.o virtmem.asm

Die physmem und die asm Datei werden kompiliert.
Das Problem ist, dass er die Header-Dateien nicht findet.
Die befinden sich aber genau da, wo sie sein sollten.
Wenn ich die virtmem-Datei von Hand kompiliere, geht es.
Woran liegt es, dass er es mit dem Makefile nicht macht?
488
Lowlevel-Coding / Re: Paging
« am: 16. December 2008, 21:16 »
Ok, danke.
Habe ich übersehen....
Nun habe ich trotzdem noch eine Frage.
Wenn ich eine Seite mappen möchte, erstelle ich als erstes eine Directory die dann mit einer Table_Page zusammenarbeitet, oder wie?
Dann habe ich mir mal den Code von LOST angeschaut und bei map_page oder so nur Bahnhof verstanden.
Wieso mappt ihr eine neue Adresse erst in den Kernel-Bereich?
reicht es nicht aus, wenn man eine Directory und eine Table hat?
Man kann doch den Unterschied zwischen Kernel und User mit dem Flag realisieren.
Dann könnte man noch unter Umständen abfragen, ob ein Bereich schon beschrieben ist, wenn ja dann einen Panic auslösen oder beim Multitasking denjenigen der Requested abschießen.
Und wenn der noch nicht besteht einfach einen neuen erzeugen.
Wenn es sich dann dabei um einen Kernelaufruf einfach den Usermode nicht mit einschalten.

Ich finde eure Variante ein wenig zu kompliziert, es sei denn ich habe das mit dem Paging noch nicht richtig verstanden.
489
Lowlevel-Coding / Paging
« am: 16. December 2008, 17:53 »
Nabend zusammen,

ich bin eben dabei jetzt paging einzubauen.
Dabei sind mir ein paar Fragen gekommen.
Wie arbeiten denn die physikalische und die virtuelle Speicherverwaltungen zusammen?
Wenn ich das richtig verstanden habe, ist Paging komplett unabhängig von der physischen Verwaltung.
Wenn ja, wozu brauche ich dann eine physikalsche Verwaltung?
Gut ok, damit kann ich die Module etc nachladen, aber das könnte ich ja auch anders realisieren.
Allerdings ist eines ein ganz großes Fragezeichen:
Wenn ich mir eine virtuelle Verwaltung aufbaue, liegt die doch im RAM, oder liegt die im Prozessorcache?
Müsste ich nicht bei der Erstellung der Virtuellen Verwaltung die Pages in der physischen Verwaltung anmelden?
Ich habe auch gelesen, dass ich bestimmte physische Speicherbereiche in den virtuellen Bereich mappen kann.
Das wäre doch dann zum Beispiel für den VGA-Block nützlich, oder?
Wie würde das denn dann aussehen?
Ich kann ja nur noch über virtuelle Adressen daran kommen.
Oder mappe ich den vor dem aktivieren des Paging-Mechanismusses?

Das waren jetzt so die Fragen, die mir auf anhieb gekommen sind.
Da folgen bestimmt noch einige.

Danke.

Gruß
rizor
490
Lowlevel-Coding / Re: Bitmaps
« am: 14. December 2008, 22:43 »
Danke.
Jetzt verstehe ich es komplett.
491
Lowlevel-Coding / Re: Bitmaps
« am: 14. December 2008, 20:20 »
Nein, ich glaub ihr versteht mich falsch oder ich euch.
Der Bootloader lädt ja die Module in den RAM und markiert diese in seiner Memorymap.
Mein Problem ist folgendes:
Wenn der Bootloader ein modul an das Ende des RAMs legt, dann ist das ja der letzte Block.
Wenn ich nun den Speicher mit einer bitmap darstellen möchte und nur den Speicher anschaue, bis ich den letzten freien Block gefunden habe, dann kann es doch passieren, dass mir das Modul, dass an das Ende gelegt wurde abstürzt.

Wenn das geschehen ist, möchte ich es nachladen um somit mein System am Leben erhalten. Das lade ich aber an eine andere Stelle, denn mein Speichermanager kennt diesen "nicht existierenden" Block ja nicht. Also verliere ich doch das Ende + den Speicher für das reinitialisierte Modul, oder?

Hoffe ich konnte mich jetzt deutlicher ausdrücken.
492
Lowlevel-Coding / Re: Bitmaps
« am: 14. December 2008, 18:52 »
Was ist denn, wenn am Ende ein Modul liegt, dass abstürzen kann und neu gestartet werden muss.
Wenn ich das Teil neu starte, kann ich das ja nicht genau an die selbe Stelle legen sondern mein alloc gibt mir einen Bereich vor.
Dann verschwände ich doch den letzten Speicherblock.
Oder liegt am Ende immer was vom BIOS oder dem Multiboot?
493
Lowlevel-Coding / Re: Bitmaps
« am: 14. December 2008, 17:45 »
Aber was ist, wenn der letzte Teil des RAMs belegt ist?
Dann fehlt dieser Teil doch, denn die Länge, des Blocks, der in der Bitmap steht, gibt doch nur an, dass bis zu diesem Punkt die Bedingung gilt, dass der Speicher frei ist, oder?
494
Lowlevel-Coding / Re: Bitmaps
« am: 14. December 2008, 16:09 »
Eine Sache verstehe ich immer noch nicht.
Ich habe es jetzt mal einfach übernommen, weil ich dachte, dass mir das dann später klra wird.
Ist es aber leider nicht.
Beim Berechnen der Bitmap-Größe hat der LOST folgende Abfrage:
((dword) (mmap[i].mm_base_addr + mmap[i].mm_length)
                > (dword) (uintptr_t) upper_end) && (mmap[i].mm_type == 1)

Warum?
Wenn ich die Abfrage richtig verstehe, schauen wir nach ob das untere Ende eine Map unter unserem eigenen upper_end liegt.
Wenn dann auch noch der Speicher frei ist, wird das auch noch erfüllt, haben wir eine neue obere Grenze wieso?
Damit verlieren wir doch speicher für unsere Bitmap, oder?

Wenn ich mir überlege, dass der Speicher von 0 - FF1 belegt ist und dann eine Map ab FF2-FF3 frei ist, wird unsere neue obere Grenze fpr die Bitmap FF3, oder?
Dann ist 0-FF1 nicht in unserer Bitmap.
Oder halt ein anderer Teil dieser Größe.
Das wirkt für mich ein wenig unlogisch.

Hoffe ihr könnt Licht ins dunkel bringen.

Gruß
rizor
495
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 13. December 2008, 14:50 »
Ich habe das Problem "gelöst".
Das Problem lag an der Array-Schreibweise.
Weiß nicht wieso. aber wenn ich dann den Pointer immer inkrementiere funktioniert es (glaub ich)
Was sollte rauskommen, wenn ich beim Qemu einen RAM von 128 wähle?.
Meine Debug-Ausgaben liefern folgende Werte:
Größe der Bitmap: 0x00000FFE
Größe des Speichers: 8184
Startstelle der Bitmap: 0x00000000
Die Größe des Rams habe ich wie folgt berechnet:
Größe der Bitmap * Anzahl an Bits pro Block * 8

Kann das sein?
Zumindest werden die Werte immer größer, wenn ich beim Qemu den RAM erweitere.

Wie kann ich am einfachsten testen, ob der Speichermanager jetzt richtig funktioniert?
496
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 13. December 2008, 11:40 »
Nur um das klarzustellen:
Du machst in deinem Assembler-Teil:
push ebx
push eax
call kernel_entry

Die Funktion kernel_entry hat in C die folgende Deklaration:
void kernel_entry(unsigned int magic, struct multiboot_info* mbi)
Mit argv machst du da eigentlich nichts, ausser du weisst was du tust. ;-)

Genau so sieht es aus.
Leider behebt das immer noch nicht meinen Fehler.
497
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 13. December 2008, 01:42 »
Wie meinst du das?
498
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 13. December 2008, 01:11 »
So, nachdem ich nun endgültig am verzweifeln bin, stell ich mal den Code rein.

Die Methode, die die Bitmapgröße feststellt:
size_t count_bitmap_size(struct multiboot_info *mb_info){
physaddr_t highestAddr = 0;

if (mb_info->mi_flags & MULTIBOOT_INFO_HAS_MMAP){
struct multiboot_mmap *memmap = (struct multiboot_mmap*)mb_info->mi_mmap_addr;
size_t i;
for(i = 0; i < mb_info->mi_mmap_length / sizeof(memmap); i++){
if(((dword)(memmap[i].mm_base_addr + memmap[i].mm_length) >
(dword)highestAddr) && (memmap[i].mm_type == 1)){
highestAddr = (physaddr_t)(dword)(memmap[i].mm_base_addr + memmap[i].mm_length);
}
}
}
else
panic("Unable to count the memorysize.");

return (size_t)highestAddr / BLOCK_SIZE / 8;
}


Und noch wie ich auf den Stack pushe:
push ebx
push eax

Nun noch der Aufruf in der Main:
init_kernel((struct multiboot_info*)argv[1]);

Ich hoffe ihr findet den Fehler.
Mitlerweile kann ich den Code nicht mehr sehen.

Danke.

Gruß
rizor
499
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 22:09 »
Habe jetzt leider noch ein Problem beim bestimmen der Größe der Bitmap.
Ich gehe ja den ganzen Speicher durch und suche nach einer Adresse, die über meiner momentanen Grenze liegt.
Das Problem ist, dass er mir sagt, dass folgender Vergleich immer falsch ist.
Das kann ich mir beim besten Willen nicht vorstellen.
((dword)memmap[i].mm_base_addr + memmap[i].mm_length >(dword)highestAddr)
Das kann doch fast nicht sein, oder?
Mein highestAddr wird mit 0 initialisiert.

[Edit]
Angeblich ist der Speicherblock auch immer belegt.
Kann es sein, dass der ein Problem mit dem Zugriff auf die einzelnen Teile der memmap hat?

[Edit]
Habe mir eben mal die basisaddresse und die länge der speicherbereiche der mmap der Multiboot angeschaut.
Die sind alle 0.
Woran kann das liegen?
Habe die Ausgabe mitlerweile kontrolliert.
Die stimmt.
500
Lowlevel-Coding / Re: Multibootstruktur funktioniert nicht
« am: 12. December 2008, 21:26 »
Ich habe mir mal die multiboot_info als hex ausgeben lassen.
Da habe ich gesehen, dass das 6 Bit für die MMAP_addr gesetzt ist.
Jetzt verstehe ich nichts mehr.
Das mit 0x02 funktioniert nicht. Das habe ich ja gemacht.

[Edit ]
Mir ist der Fehler eben aufgefallen.
Ich hatte den Header als Struct interpretiert und übergeben.
Seiten: 1 ... 23 24 [25] 26 27

Einloggen