Nachrichten

1

Lowlevel-Coding / Re: grub2 memorymap trouble

« am: 02. December 2013, 20:39 »

Ich hab nun keine Ahnung von D oder D2, aber in C wäre das hier nicht korrekt (sofern das 1:1 übersetzbar ist):

Code: [Auswählen]

ulong entryAddr = cast(ulong)(memMap + memMap.tagType.sizeof + memMap.tagSize.sizeof + memMap.entrySize.sizeof + memMap.entryVersion.sizeof);Im Prinzip wird da ja 16 auf den Zeiger memMap addiert. In C würde dann entryAddr aber nicht wie gewünscht die Adresse von memMap + 16 Bytes enthalten, sondern auf das 16-te TagMemoryMap hinter memMap zeigen, also 256 Bytes hinter memMap.

hi jidder!

du hast natürlich recht mit dem hinweis auf die pointerarithmetik und dein vorschlag behebt das problem.

Code: [Auswählen]

* * Available memory: 0x0; length: 651264
 * * Reserved memory: 0x9f000; length: 4096
 * * Reserved memory: 0xe8000; length: 98304
 * * Available memory: 0x100000; length: 535756800
 * * ACPI reclaimable memory: 0x1fff0000; length: 65536
 * * Reserved memory: 0xfffc0000; length: 262144

so solls aussehn. merci

2

Lowlevel-Coding / grub2 memorymap trouble

« am: 02. December 2013, 14:28 »

hey leute,

zunächst einmal danke für das fantastische lowlevel wiki. die tutorials sind super gemacht! sehr verständlich aufgebaut und mit den notwendigen hintergrund infos angereichert.

mein projekt ist ein kernel in d2. für mich ist das eine neue herausforderung, da es sowohl das erste projekt in d als auch mein erster kernel ist. als compiler kann ich ldc2 oder gdc2 verwenden, das buildenvironment aufzusetzen hat eigentlich bis jetzt den großteil der arbeit gemacht, durch die große abhängigkeit von d auf seine runtime.

aber weiter im text. der kernel ist ein 64bit higher half kernel. die basis steht soweit: textausgabe im framebuffer und bochs/e9 port. gdt, idt und pic sind programmiert und der nächste schritt ist für mich nun die physische speicherverwaltung. diese benötige ich nun als nächstes für die kernel heap verwaltung, denn ich will nicht weiter mit statischen strukturen arbeiten.

die memory infos möchte ich aus den multiboot2 informationen auslesen und habe probleme mit der struktur der einträge.
ich beziehe bereits andere informationen aus der multiboot2 struktur wie die kommandozeile, bootloadername und framebuffer addresse. das auslesen funktioniert.
für die memory map will dass allerdings keinen sinn ergeben, weder die basisaddressen noch die länge der regionen ergeben einen sinn. kann mich hier jemand auf die nächste stufe schubsen? das infomaterial im netz ist leider fast ausschlieslich auf multiboot1 strukturen ausgelegt.

datenstrukturen und codeschnipsel - http://pastebin.com/msiZYpwn
ausgabe des kernels mit der memory map - http://pastebin.com/6Rnyq6zm