The main issue is that some versions of the header have slightly different (additional) fields.
Examples: APM info, ELF info, AOUT info, VBE info etc etc.
The important thing in the early stage is usually just the memory map and modules:
Code: Select all
struct Info_type
{
uint32_t flags, mem_lower, mem_upper, boot_device, cmdline, mods_count, mods_addr;
uint32_t num, size, addr, shndx;
uint32_t mmap_length, mmap_addr;
};
struct Module_type { uint32_t mod_start, mod_end, string, reserved; };
struct MemoryMap_type
{
uint32_t Size;
uint32_t BaseAddr_Low;
uint32_t BaseAddr_High;
uint32_t Length_Low;
uint32_t Length_High;
uint32_t Type;
};
If you lack the ability (not trying to be condescending) to convert an address passed in %ebx to a struct pointer, you need to relook at your skills in C, especially pointer magic.
EDIT:
Firstly, you want to get the E820 memory map: get a pointer to a MemoryMap_type struct from Info->mmap_addr.
You should read some tutorials on parsing the GRUB memory map, it's fairly trivial.
Then you'd have the complete memory map: 0x00 to 0x9FC00 is usually free (as GRUB says, but the real-mode IVT, BDA and EBDA is there). 0xA0000 to 0x100000 is usually reserved for the video memory.
Anything beyond that should be free memory, minus some memory-mapped device address space at the top of the address space.
As for your kernel's size, I'm not sure how to get that -- you might want to look into the ELF or AOUT fields of the multiboot header.
A quick workaround would be to place a symbol at the end of your linker script and
that in C.
As for me, I'd just read my kernel executable off the disk. :p
