Hello fellow developers.
I've recently started programming my own OS in C/assembler. The Bare Bones article pretty much set me up.
In my current phase I'm trying to get the memory management up and running. So I access the provided multiboot_memory_map structure (from multiboot.h) for those whose 'type' is 1, and thereby not reserved.
My actual problem arises when I try to set up my virtual memory (just using a simple linked list at first). The address provided from the 'addr' field is somewhat off.. In my perception. If I use it as it is then I overwrite my running kernel code at some point. I have interpreted 'addr' as the starting address of the free memory available, which then spans the amount of bytes specified in the 'len' field.
As of now I'm using a hack (multiplying 'addr' by 4, haha I know) but I would like to know why the offset is off?
Thank you very much in advance.
My grub-probed free memory address is off. Why?
- gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: My grub-probed free memory address is off. Why?
Hi:
GRUB doesn't map your kernel's executable image as reserved in the memory map. It's just supposed to tell you about which ranges of RAM are usable for the kernel. The kernel itself should handle protecting its physical frames in RAM.
GRUB doesn't map your kernel's executable image as reserved in the memory map. It's just supposed to tell you about which ranges of RAM are usable for the kernel. The kernel itself should handle protecting its physical frames in RAM.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Re: My grub-probed free memory address is off. Why?
Of course, that makes sense.
What is the best way of deducing the size of the running footprint of the kernel? I mean, before anything has been allocated and so on.
What is the best way of deducing the size of the running footprint of the kernel? I mean, before anything has been allocated and so on.
Re: My grub-probed free memory address is off. Why?
If you're referring to getting the size of your executable, I suppose what most of us here do is use the linker script to determine the size. You put a linker script entry at the end (and possibly at the start) and subtract them from each other.netrom wrote:Of course, that makes sense.
What is the best way of deducing the size of the running footprint of the kernel? I mean, before anything has been allocated and so on.
For example:
Code: Select all
SECTIONS
{
. = 0x100000;
/* ... */
KernelEnd = .;
}
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
Re: My grub-probed free memory address is off. Why?
That sounds like the way to go, but how to I access 'KernelEnd' then? I mean, how I read the value from C (or assembler)?Creature wrote:[...]You put a linker script entry at the end (and possibly at the start) and subtract them from each other.
Then the size of the kernel executable would be KernelEnd - 0x100000.
- gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: My grub-probed free memory address is off. Why?
EDIT: No need. Good luck
Last edited by gravaera on Thu Jan 21, 2010 5:51 pm, edited 1 time in total.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Re: My grub-probed free memory address is off. Why?
I'm sorry.. That was kinda embarrassing as I have used the wiki quite a lot.
Thanks again anyways.
Thanks again anyways.