Autor Thema: Multibootstruktur funktioniert nicht  (Gelesen 7898 mal)

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« 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
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 12. December 2008, 17:47 »
Seit wann ist "n" eine Dezimalzahl? :|
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 12. December 2008, 17:50 »
Darüber habe ich mich ja auch gewundert.
Meine Methode zur Bestimmung der Zahlen stimmt aber.
Das habe ich getestet.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

jgraef

  • Beiträge: 67
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 12. December 2008, 18:53 »
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.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 12. December 2008, 19:14 »
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...
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 12. December 2008, 19:27 »
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
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 12. December 2008, 19:39 »
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"?
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #7 am: 12. December 2008, 19:39 »
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.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 12. December 2008, 19:41 »
Oder eben wieder irgendwas falsch ausgegeben und in Wirklichkeit hat es funktioniert.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 12. December 2008, 20:01 »
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.
« Letzte Änderung: 12. December 2008, 20:06 von rizor »
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 12. December 2008, 20:12 »
Setzt du das entsprechende Flag im Multibootheader? (0x02)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 12. December 2008, 20:38 »
Bin mir grad nicht sicher.
Das muss doch heißen:
MULTIBOOT_FLAGS     equ 0x02

oder?
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 12. December 2008, 21:18 »
Das sollte das passende Bit sein, ja
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #13 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.
« Letzte Änderung: 12. December 2008, 21:35 von rizor »
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #14 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.
« Letzte Änderung: 12. December 2008, 22:40 von rizor »
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #15 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
« Letzte Änderung: 13. December 2008, 01:13 von rizor »
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 13. December 2008, 01:21 »
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.
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 13. December 2008, 01:42 »
Wie meinst du das?
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #18 am: 13. December 2008, 09:41 »
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. ;-)

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 13. December 2008, 10:45 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

 

Einloggen