[SOLVED]Grub2 memory map entries ba...

[0xd3ba]

Hello again,
I would like help with the following issue.
I'm following Multiboot2 specification (https://www.gnu.org/software/grub/manua ... iboot.html)
What I'm doing is checking the addresses of the memory map entries inside GDB's register dump:

Code: Select all

uint64_t main(uint32_t magic, uint32_t mbi) {

. . . . 

if(tag->type == MBOOT_TAG_MMAP){
            struct mboot_mmap *mmap = (struct mboot_mmap *)tag;
            struct mboot_mmap_entry *entry = mmap->entries;
            
            i=0;
            while((uint32_t)entry < (uint32_t)mmap + mmap->size){
                i++;
                if(i==2) return entry->base_addr;
                entry = (struct mboot_mmap_entry *)((uint32_t)entry + mmap->entry_size);
            }
. . . . 

(Basically i is the entry number I'm interested in, returning i'th entry's base_address (ending up in EAX) and halting the CPU) - inefficient but have no other choice (no printk..etc)
The issue is that all the entry's base addresses are being returned as 0. (Tried for all possible values of i)
I'm supplying 32MB of RAM from qemu and basic memory information (mem_lower and mem_upper values are being returned correctly - around 639KB for mem_lower and around 31.5 MB for mem_upper)

And entry->type is also returning 0 !! (even for 1st entry). This is driving me crazy

Structures for mmap and mmap_entry are as follows:

Code: Select all

struct mboot_mmap_entry {
    mboot64_t   base_addr;
    mboot64_t   length;

    #define MBOOT_MEMORY_AVAILABLE    1
    #define MBOOT_MEMORY_RESERVED    2
    #define MBOOT_MEMORY_ACPI_RECLAIMABLE    3
    #define MBOOT_MEMORY_NVS    4
    #define MBOOT_MEMORY_BADRAM    5

    mboot32_t   type;
    mboot32_t   zero;
};

struct mboot_mmap {
    mboot32_t   type;
    mboot32_t   size;
    mboot32_t   entry_size;
    mboot32_t   entry_type;
    mboot32_t   entry_version;
    struct mboot_mmap_entry entries[0];
};

Any idea about this issue ?

Thanks

[Octocontrabass]

(Basically i is the entry number I'm interested in, returning i'th entry's base_address (ending up in EAX) and halting the CPU) - inefficient but have no other choice (no printk..etc)

Not just EAX. You're returning a 64-bit integer, which means the upper half is in EDX. What values are you seeing in EDX? Does it look suspiciously similar to each entry's length instead of the base_address? As if your code is reading four bytes past where it should be?

Structures for mmap and mmap_entry are as follows:

One of these structures doesn't match the specification. The difference is an extra four bytes...

[0xd3ba]

One of these structures doesn't match the specification. The difference is an extra four bytes...

So THIS was the thing that was causing the issue *facepalm*

Not just EAX. You're returning a 64-bit integer, which means the upper half is in EDX. What values are you seeing in EDX? Does it look suspiciously similar to each entry's length instead of the base_address? As if your code is reading four bytes past where it should be?

I can't believe I overlooked the part that EAX is only 32bits

Anyways, everything is now working as it should be !
THANKS A LOT !!