Question on The Grub Memory Map !!

[smainoo]

Hi everybody , I read some Questions about Grub Memory Map on Qemu in the Forum, I think that i have some Other Problems .
I followed the famous code in "kernel.c" : http://www.gnu.org/software/grub/manual ... iboot.html
to get a memory Map , But i'm sure the map is wrong ,Lol.

I emulated the code on Qemu 1.4.
the result is in this snapshot :
http://hpics.li/51f5775

When emulate the Code in The : http://www.brokenthorn.com/Resources/OSDev17.html (Nice Series by the way .Thankx Mike.)
I get a nice Map :
http://hpics.li/3579bf9
Any Help You Welcome.

[palk]

In situations like this, it's usually good to print out the full map in binary, so you can see what it is that your program sees. Also, we can't provide advice to you about fixing your code when you haven't actually posted your code for us to look at.

[smainoo]

In situations like this, it's usually good to print out the full map in binary, so you can see what it is that your program sees.

Thanks Palk for the Help .
I think it's nice Idea to print all the structure in binary, I'll try it .

Also, we can't provide advice to you about fixing your code when you haven't actually posted your code for us to look at.

The Code is the same as "kernel.c" in the "Multiboot Specification Manual" Site at:
http://www.gnu.org/software/grub/manual ... rnel_002ec

I assumed that the code is correct .

[Combuster]

The source lacks compilation instructions. Which means you're probably using "gcc", right? WRONG.

[smainoo]

The source lacks compilation instructions. Which means you're probably using "gcc", right? http://wiki.osdev.org/Posting_Checklist

Yes, I used the Default "Gcc" with :CFLAGS= -fno-stack-protector -ffreestanding -fno-builtin
the "gcc -dumpmachine" command give me:
i486-linux-gn

So, should have a cross-compiler ?

[FallenAvatar]

Why do I need a Cross Compiler?

[jstoddard]

Are the structures you use (that is, the contents of multiboot.h) also the same found in the tutorial? I simply downloaded the multiboot.h file from the grub sources, which turned out to be a bad idea for various reasons, one of which is a problem that appears to be somewhat similar to yours. I'm not sure it's the exact same issue, but it's similar enough that I thought it might be worth sharing. I wrote my memory mapping code based on the example from the multiboot specification as well (though in my case it isn't copy-and-paste, which would have been problematic due to some details of my setup, including the fact that I have no printf yet). Notice that I got similar nonsense while trying to read grub's memory map:

http://www.flickr.com/photos/113162334@N04/11698219393/

But I also noticed that the upper half of "length" looked like what I expected to find in "type", that "size" was what I expected in every case, and so perhaps there was some sense to the other numbers. Perhaps they may just be out of order. (As an aside, that's what prompted the "Sanity check" seen in the screenshot -- I wanted to double check that my function to print out numbers was actually working and that something like endianness wasn't biting me in the butt...)

This is where I come back to multiboot.h: The copy provided by grub ends the multiboot_mmap_entry struct with "GRUB_PACKED" (which isn't defined anywhere in the file; I assume it references some other part of grub source). Replacing it with (or defining it as) "__attribute__((packed))" provided a quick and effective solution:

http://www.flickr.com/photos/113162334@N04/11698350164/

The packed attribute is correctly set in the multiboot.h code in the specification document, so that's the best route to go in order to avoid any problems...

[smainoo]

Update: I made a Cross-toolchain. However, the same problem persists.
Thank you jstoddard for the help
I think that there's no "GRUB_PACKED" in the actually multiboot.h source code -->
https://www.gnu.org/software/grub/manua ... 002eh.html

and the "multiboot_mmap_entry" is nicely packed with "__attribute__((packed))" --->

Code: Select all

struct multiboot_mmap_entry
     {
       multiboot_uint32_t size;
       multiboot_uint64_t addr;
       multiboot_uint64_t len;
     #define MULTIBOOT_MEMORY_AVAILABLE              1
     #define MULTIBOOT_MEMORY_RESERVED               2
       multiboot_uint32_t type;
     } __attribute__((packed));
     typedef struct multiboot_mmap_entry multiboot_memory_map_t;

So, it's pretty good subject to me ,to start learn debugging . (No solution for Now )
I get rid of a Grub problem by replace My bootloader with the one in "Broken's OSdev tuto" with some modification to load Binary format, it works fine.

[rod]

I was also trying to use the example code for kernel.c and multiboot.h from:
http://www.gnu.org/software/grub/manual ... iboot.html
and the reported memory didn't seem to be correct.

I found some code to compile the examples:
http://lists.gnu.org/archive/html/bug-g ... 00041.html
but didn't use the objcopy part.

Finally I used some slightly modified versions of kernel.c and multiboot.h at:
http://neuraldk.org/document.php?grubKernel
that finally reported likely good memory regions.