Thema: BIOS Memory Map

[kevin]

Nachdem ich heute schon so viel gelernt habe, stelle ich hiermit einen Antrag auf noch mehr. Aber zuerst moechte ich meine neueste Erkenntnis mit euch teilen: Wenn man seine Prozessmanagement-Strukturen in den Videospeicher legt, passieren unter Umstaenden nicht so geplante Dinge.

Weiterhin habe ich festgestellt, dass die Memory Map in qemu Loecher hat. Es gibt belegte Bereiche, nutzbare Bereiche und Bereiche, ueber die keine Aussage getroffen wird (der Videospeicher gehoert zu letzterer Kategorie und kernel2 hat per Default erstmal alles frei). Jetzt muss ich also irgendwie diese Loecher stopfen und frage mich: Kann ich eigentlich davon ausgehen, dass die Liste sortiert ist? In qemu scheint das so zu sein, aber das bricht dann garantiert wieder irgendwo, oder?

Hm, okay, ich merke schon, das geht alles in Richtung kaputter Hack. Am besten baue ich das Ding komplett um, dass es auf belegt defaultet. Aber vielleicht weiss ja trotzdem jemand die Antwort.

[bitmaster]

Hmm... wenn ich dich richtig verstanden habe, dann gibt qemu deiner Meinung nach den Videospeicher als freien nutzbaren Speicher an. Ist das richtig, dass GRUB für dich die freien Speicherbereiche ausliest (ich denke auch mittels 0E820h des int 15h). Wobei das Offset 16 der zurückgegebenen Struktur angibt ob der SPeicherbereich frei ist (1) oder nicht (0, andere Werte sind nicht definiert). Quelle: http://www.uruk.org/orig-grub/mem64mb.html Ich weiß ja nicht ob du auf null prüfst, für nicht freien Speicher? Ich würde auf eins für freien Speicher prüfen, da es ja auch andere Werte geben kann (aber der Speicher dann trotzdem nicht frei sein muss).

Ich bin mir unsicher ob ich dein Problem richtig verstanden habe.

bitmaster

[kevin]

Nicht ganz. Ich kopiere hier mal raus, was displaymem in GRUB ausgibt:

Code: [Auswählen]

EISA Memory BIOS Interface is present
 Address Map BIOS Interface is present
 Lower memory: 639K, Upper memory (to first chipset hole): 129984K
 [Address Range Descriptor entries immediately follow (values are 64-bit)]
   Usable RAM:  Base Address:  0x0 X 4GB + 0x0,
      Length:   0x0 X 4GB + 0x9fc00 bytes
   Reserved:  Base Address:  0x0 X 4GB + 0x9fc00,
      Length:   0x0 X 4GB + 0x400 bytes
   Reserved:  Base Address:  0x0 X 4GB + 0xe8000,
      Length:   0x0 X 4GB + 0x18000 bytes
   Usable RAM:  Base Address:  0x0 X 4GB + 0x100000,
      Length:   0x0 X 4GB + 0x7ef0000 bytes
   Reserved:  Base Address:  0x0 X 4GB + 0x7ff0000,
      Length:   0x0 X 4GB + 0x10000 bytes
   Reserved:  Base Address:  0x0 X 4GB + 0xfffc0000,
      Length:   0x0 X 4GB + 0x40000 bytes
Wie man sieht, gibt es fuer den Code zwischen a0000 und e8000 ueberhaupt keinen Eintrag, bei dem ich eine Chance haette, etwas zu interpretieren.

[bitmaster]

Ja, wie ich sagte gibt es Bereiche die nicht interpretiert werden. Wahrscheinlich listet GRUB die Bereiche nicht auf, die nicht den Typen Null oder Eins besitzen. In deinem Fall sollte dein OS also nur folgenden Speicher verwenden:

Code: [Auswählen]

Usable RAM:  Base Address:  0x0 X 4GB + 0x0,
      Length:   0x0 X 4GB + 0x9fc00 bytes

Usable RAM:  Base Address:  0x0 X 4GB + 0x100000,
      Length:   0x0 X 4GB + 0x7ef0000 bytes
bitmaster

[bluecode]

Grub listet alle Bereiche auf, die auch in der BIOS memory map sind, also auch die != 0 und != 1.

[bitmaster]

bluecode: Sry, ich meinte natürlich die Typen 1 und 2.

Tja, dann listet die Funktion E820h des int 15h halt den Bereich zwischen A0000h und E8000h nicht auf. Aber das ist doch eigentl. egal. Dieser Bereich wird nicht als frei aufgelistet und sollte demnach auch nicht verwendet werden. Ich sage es noch einmal: Das OS sollte nur den Speicher verwenden, der auch als frei markiert ist, also den Typ EINS trägt.

bitmaster

[kevin]

Du erklaerst mir hier die ganze Zeit Dinge, die ich schon weiss. Meine Frage war eine andere und hat mit LOST nur am Rande zu tun, weil ich es eh anders mache. Aber das habe ich schon im ersten Post geschrieben.

[bitmaster]

Scheint ja nicht so zu sein. Deine Frage hier

Jetzt muss ich also irgendwie diese Loecher stopfen und frage mich: Kann ich eigentlich davon ausgehen, dass die Liste sortiert ist? In qemu scheint das so zu sein, aber das bricht dann garantiert wieder irgendwo, oder?

lässt es zumindest anders aussehen. Es ist doch ganz egal ob die Liste sortiert ist oder nicht. Folgenden Tip gebe ich dir mal:

Markiere einfach den ganzen Speicher als reserviert bis auf die Bereiche, die mit dem Typen EINS markiert sind. Dann bist du weder von einer Reihenfolge abhängig noch davon, dass alle Bereiche aufgelistet werden.

bitmaster

[kevin]

Nein, ach... Lies mal meinen ersten Beitrag durch, da sage ich, dass ich genau das machen werde - ganz ohne dich um Rat zu fragen. In diesem Thread geht es nicht mehr um ein konkretes Problem mit einem konkreten OS, sondern einfach nur darum, dass es mich interessiert, ob die Sache grundsaetzlich sortiert ist oder ob das nur Zufall ist.

Aber da das anscheinend keiner weiss, koennte ich den Thread eigentlich auch zumachen.

[bitmaster]

Ist ja gut, ist ja gut.

An alle: Ich habe dem taljeth keine Hilfe gegeben. Er hat alles vorher gewusst. Ich habe ihn nur falsch verstanden.

Jetzt zufrieden?


bitmaster

[kevin]

Spinner.

[bluecode]

Um die Stimmung ein bisschen aufzuheitern.

[ChristianF]

Morgen.
Also folgendes habe ich gefunden:
Multiboot Draft
 
Dort steht, dass es keine Garantie dafür gibt, dass die Auflistung geordnet ist.
Weiterhin steht dort auch, dass der Bootloader eine Sortierung der Bereiche vornehmen sollte, aber nicht muss.
 
Vielleicht hat es ja geholfen 
 
Gruß Christian
 
*EDIT*
Solche Löcher, die einfach nicht angezeigt werden habe ich aber auch.
Das dürfte Video RAM und ROM-Bereiche sein, laut OSDev Wiki

[kevin]

Jepp, danke.