[Tutorials] Getting memory info from GRUB

[Dawnkeeper]

I'm still working through the tutorials and hit another wall.
I try to get the memory info from Grub. The Wiki mentions here that the Bare Bone tutorials have prepared this for noobs like me.
So I simply changed the kernel_main of the Meaty Skeleton to fit the mentioned structure.
... no luck ...
After reading up a bit I moved the method structure to kernel_early ... no luck ... and changed the boot.S to push EAX and EBX right before the call.

Now I get the right magic number and a pointer that actually holds reasonable values.
Now my question: is this change correct or am I missing something important?

[AndrewAPrice]

kernel_early and _init probably trash your EAX and EBX registers before you reach kernel_main.

You can:
- push them to the stack before calling kernel_early and _init, and then call kernel_main (and your parameters will already be on the stack!)
- or, save them in memory somewhere, then access those global variables inside of C
- or, temporarily store them in registers that are preserved by the callee (any except EAX, ECX, and EDX - see X86 calling conventions)

The other thing is - your thread is titled "Getting memory info from GRUB" - you need to tell GRUB in the multiboot header what you want it to tell you (assuming you're using GRUB 2 which the tutorial appears to do).

Basically, you need to add a multiboot_header_tag_information_request tag in your multiboot header, then inside of that section put multiboot_tag_type_mmap.

This guide helped me: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf

If an example helps, you can reference my multiboot header (I ask GRUB for the memory map and framebuffer, NASM/Intel syntax.) Make sure you pad your sections to be 8 bytes (add an extra empty 4 bytes if it's not).

[eryjus]

You seem like you are close to the right track. The multiboot header is asking for the information (unless you changed that or any other part).

You will want to do something right off the bat with the EAX/EBX values before your first C function call: Save them -- they will be trashed by the first C functions that is called no matter what, so I feel it is best to make a copy of them in memory (read: data segment) before you do too much in case you want them later.

If bit 6 is checked (tip: use 1<<6 in your code for readability) of the MBI structure->flags field, then you will have a good memory map. Check it to be sure.

Next, the specification implies that the pointers are not to the start of the MMAP_ structure. The thing is that it really does, but the value in the size field does not take in to account the size of size field, so you have to adjust properly (yeah, I know -- read it a couple of times).

Finally, now is the perfect time to invest some of your personal learning time to getting Bochs source, compiling it for debugging, and learn the command set (start with 'help') for debugging. You will be glad you did. Especially when you have a more complicated issue down the road and need some help, most here will point you in that direction anyway. Better to get ahead of the curve. I personally resisted that early on, favoring QEMU and GDB because QEMU emulated the clock better and you could count on a 3 second delay to be much closer to 3 seconds. Now, I use Bochs almost exclusively and the debugger with more than half my tests. My debugging/verification time has gone way down. At any rate, Bochs will be able to allow you to look at the memory where the MBI structure is located and figure out what is really in memory.

Here are a couple of wiki articles to help you along:
Bochs debugging
Kernel Debugging

[eryjus]

assuming you're using GRUB 2 which the tutorial appears to do

The tutorial uses the Multiboot legacy magic number

[Dawnkeeper]

I finally got it to work:

Perhaps someone with Wiki edit rights should head over and correct the tutorials.

[no92]

You can get edit rights by joining the wiki group and do it by yourself.

[Dawnkeeper]

I feel a bit too noobish for that