Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: rizor am 12. December 2008, 17:40
-
Nabend zusammen,
ich bin eben mit meinem Physikalischen Speichermanager fertig geworden.
Leider funktioniert die Multibootstruktur die ich aus dem LOST-Projekt übernommen habe nicht.
Er kann die Speichergröße nicht bestimmen.
Ich habe mir mal die Werte der mb_info->mi_flags ausgegeben.
Da erhalte ich als Dezimalwert "n".
Beim verunden kommt dann auch "n" heraus. Wenn ich es mit der Konstanten HAS_MMAP verunde.
Woran liegt das?
Kann es sein, dass GRUB nicht richtig funktioniert?
Gruß
rizor
-
Seit wann ist "n" eine Dezimalzahl? :|
-
Darüber habe ich mich ja auch gewundert.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
-
Darüber habe ich mich ja auch gewundert.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
Anscheinend hast du nicht recht, sonst würde ja nicht "n" rauskommen.
-
Darüber habe ich mich ja auch gewundert.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
Du meinst: Bei einem bestimmten Beispiel funktioniert sie.
Im allgemeinen ist sie offensichtlich kaputt. Eine Funktion, die einen int ausgeben soll und zum Ergebnis "n" kommt, ist mit recht hoher Wahrscheinlichkeit fehlerhaft...
-
Naja,
ich habe mir einfach eine Methode geschrieben, die einen int Ziffernweise bearbeitet und dann den int + '0' rechnet, damit ich auf ASCII-Int komme.
Das dann auf (char) umgewandelt und ausgegeben.
Wo soll da was nicht stimmen?
Aber das löst ja nicht mein Hauptproblem mit dem Multiboot.
Gruß
rizor
-
Dein Vertrauen in deinen Code muß unerschütterlich sein, wenn du "n" als Dezimalzahl akzeptierst, weil dein Code das so ausgibt... Offensichtlich ist er falsch. Wie du das angestellt hast, kann ich nicht sagen, ohne den Code zu kennen.
Was heißt "kann die Speichergröße nicht bestimmen"?
-
Nein. Aber es ist äusserst unwarscheinlich, dass GRUB kaputt ist (zumindest solange es nicht um den ext2-Treiber geht :-D). Daher ist der Fehler ziemlich sicher in deiner Anzeigeroutine.
Und zum Problem mit der Speichergrösse: Das sieht so aus als ob entweder die Struktur kaputt ist (attribute packed drin?), oder du aber an irgend einer falschen Adresse liest.
-
Oder eben wieder irgendwas falsch ausgegeben und in Wirklichkeit hat es funktioniert.
-
Mein Vertrauen in den Code ist nicht unerschütterlich.
Ich wollte nur erst mal den "schlimmeren" Fehler beheben.
Habe nun auch das Problem entdeckt.
Der interpretiert eine binäre 0 als "n".
Noch weiß ich nicht wieso.
Habe mir mal eine Methode geschrieben, die mir ints als bin ausgibt und dabei habe ich gesehen, dass mi_flags auf 0 steht.
Leider weiß ich nicht wieso.
Er soll erst einmal die Größe für die bitmap ermitteln.
Das klappt nicht, da das Flag nicht gesetzt ist.
-
Setzt du das entsprechende Flag im Multibootheader? (0x02)
-
Bin mir grad nicht sicher.
Das muss doch heißen:
MULTIBOOT_FLAGS equ 0x02
oder?
-
Das sollte das passende Bit sein, ja
-
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.
-
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.
-
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
-
du sagst, du bist mit dem physischen Speichermanager fertig.
hast du die betreffenden bereiche 1:1 gemapped? sonst musst du die ganzen pointer ja noch anpassen.
-
Wie meinst du das?
-
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. ;-)
-
hast du die betreffenden bereiche 1:1 gemapped? sonst musst du die ganzen pointer ja noch anpassen.
Physisch. Da ist noch kein Paging im Spiel.
-
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.
-
hast du die betreffenden bereiche 1:1 gemapped? sonst musst du die ganzen pointer ja noch anpassen.
Physisch. Da ist noch kein Paging im Spiel.
Wow. Für mich war immer Physisch = Paging :oops:
Dann fällt das als mögliche Ursache wohl weg. Außer die basis des Datensegments != 0.( Eine GDT sollte ja auf jeden Fall schon vorhanden sein )
-
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?