OSDev.org

Hi I have gone through the BRAN tutorial , and well i guess the next thing to do is make the memory manager. But for that i require 2 things
1)size of RAM
2)end of kernel in the memory

1)For the size of RAM i have come across the memory map (mmap_*) method, though i dont understand how its supposed to be used . i mean for every mmap structure ,
(if flag ==1)(RAM available)
current_size_RAM += sizeofstructure. ????

2)For the 2nd part , should I declare a variable at the end of the bss section in the linker script and then use that to determine the end of kernel??

I would be very grateful if someone could expalin this to me

You might want to look into the int 0x15, eax = 0xe820 memory detect function.. I use this in real mode and store the memory map somewhere in memory where i can get at it from protected mode. Then I can determine the size of memory and the regions of memory that I cannot use.

Try the mem_upper and mem_lower fields of the multiboot info structure.

I don't know if this is the best way through this
First of all, I found out is that GRUB usually gives one large chunk just above 1MB that corresponds to all the machine's physical memory
Thus, my code just looks for the largest chunk of memory and sets that as the memory it can use (everything below 1MB is ignored, however)
(tested under Virtual PC 2007, Bochs 2.3 and my computer (a Dell Dimension 5000 with 1GB of RAM) )
My kernel is loaded at 1MB, so I choose to ignore the range [1MB, 2MB) and leave that as "invisible" memory for the allocator (so my kernel can grow freely, it's now less than 100K )
Everything else, 2MB up to the end of physical memory is divided into 4KB each chunks (I call them pages, although I don't have paging..just Bran's transparent segmentation scheme) and these are allocated by a sbrk() system call (actually, a bit is set high into a bitmap and a pointer returned). A malloc() implementation (taken straight from K&R) splits those pages in chunks as required

The physical memory seen by the processor in your system is not necessarily the same as the DIMMs that are plugged onto you motherboard. There are many memory mapped devices at various places in the physical memory layout which are not RAM. The most obvious of these is the vga color text framebuffer at 0xb8000, but other pieces exist, such as ACPI and PCI configuration spaces. The memory map provided by grub (usually obtained from the bios int 15h e820 as mentioned above) is one of the best ways of identifying which parts of physical memory you can use, and which you can't.

From the multiboot header, you could do something like:
- iterate through each mmap entry defined as available
- start at 1MB or the start of the entry (whichever is least) and iterate up in 4kB pages.
- check each page is not 1) overlapping part of an elf section, 2) overlapping part of a grub module and 3) overlapping part of an unavailable mmap section.
- if page is really free, set it as free in your physical memory allocator.

The reason I suggest not including pages below 1MB is that some bios' report that all the memory below 1MB is free. They assume you to know what to touch and what not to. For simplicity's sake, just ignore it (most modern computers have another GB or several hundred MBs anyway).

One of the problems you have to deal with is that grub can place its multiboot information, and all the tables it references (elf sections, mmap and modules) anywhere in memory, according to the multiboot specification. In reality, in current grub legacy, they are allocated as parts of the grub program itself, below 1MB, but that is not guaranteed to remain the same. For that reason, you have to somehow protect these tables before you start using a certain bit of memory as a physical memory bitmap or something.

Regards,
John