OSDev.org

Posted: **Sun Dec 17, 2006 6:31 pm**

Some time ago, when I was trying to build a free page stack to help in memory management, I eventually gave up because, when I wanted to know which pages were free without memory management, I didn't know what could I assume about *where* GRUB has loaded it's structures and the modules, so I didn't know where to put the stack...

I thought about starting in the uppermost longword of memory available, but I just don't know what I can assume about the location of the modules and the multiboot structures... So if I have many many modules loaded can I assume, for example, that the modules were loaded just above the kernel (page aligned if the header flags tells so)...

The obvious solution would be to look at the multiboot structures... in which case I have to check each page one by one to see if it's free or not! I think the multiboot should have a more defined behaviour... for example, it should specify that the kernel *must* be loaded above 1M (no section loaded below 1M), that the boot loaded should not write anything above 1M apart from the kernel and kernel modules (thus it's datastructures should be always written below 1M) and the modules should be placed exactly above the highest kernel section by default (aligned to a 4KB or 4MB page boudary if the kernel requires so)...

If the programmer wants to have some control about where (s)he wanted the modules loaded, the spec should provide a mechanism to override the default behaviour...

JJ

Posted: **Mon Dec 18, 2006 2:53 am**

At this point, i have set the multiboot header to include a BSS section up to the 4MB mark. That means GRUB wont load modules there and consequently, this area is free for your use. You can always detect the location of modules later and mark the relevant pages as appropriate.

But thats just one thing i know i can control... and its enough for me

Posted: **Mon Dec 18, 2006 4:18 am**

If you read the multiboot memory map, the memory chunks containing the modules and other structures are marked as non-free, are they not? I think they are, but I haven't tested it. You could iterate the chunks and only care about the ones marked free, aligning (shrinking) them on page boundaries, and thereby get a list of free pages.

About the stack. I include it in the .bss section (NASM code):

Code: Select all

SECTION .text

multiboot_entry:
	; ...
	; Setup the stack pointer at the end, it grows downwards:
	MOV		ESP, stack_end
	; ...

SECTION .bss

stack_begin:
	; Reserve 4 KiB stack space, it is enough for me:
	RESB	4096
stack_end:

Posted: **Mon Dec 18, 2006 5:04 am**

With my OS, I copy the necessary multiboot structures to a known location before initialising my paging mechanism - in fact, they go in to a single 4MB-aligned space, making it easy to page in my kernel and the structures once paging is enabled.

HTH
Adam

Posted: **Mon Dec 18, 2006 10:17 am**

Walling wrote: If you read the multiboot memory map, the memory chunks containing the modules and other structures are marked as non-free, are they not? I think they are, but I haven't tested it.

You haven't tested, but I have looked at the structures with the Bochs debugger... They aren't included in the memory map IIRC (that's pretty likely that I'm remembering correctly, cause I did it exactly in order to know whether the modules were indicated as "reserved" or not)...

Walling wrote: You could iterate the chunks and only care about the ones marked free, aligning (shrinking) them on page boundaries, and thereby get a list of free pages.

Yes, that would be a very good solution...

I think I'm going to define a standard to load *my* kernel(s) and include something like this...
We don't need to pass a count of available RAM... We only need to pass a map indicating what pages are "reserved for IO or out of RAM", what pages are "used by boot loader structures", what pages are "used by RM-vital data" (IVT, BDA, BIOS code, DOS kernel if the loader runs from DOS, etc) and what pages are "free for alocation"; so that the kernel can select the important ones and the useless ones, accordingly to it's needs...
Then, there needs to be structures describing the module locations (they exist in multiboot), the kernel command line string, IO memory intervals, and so on...

The problem of multiboot is that there is no uniform datastructure that makes the memory allocator initialization easy... instead, the information about (un)used memory is split among a bunch of structures that need to be processed each time we want to decide whether to call a page "free for allocation" or "not free for alocation"...

Now about AJ's response:

AJ wrote: With my OS, I copy the necessary multiboot structures to a known location before initialising my paging mechanism - in fact, they go in to a single 4MB-aligned space, making it easy to page in my kernel and the structures once paging is enabled.

Right... that's an alternative solution I hadn't remembered before...
Just align .bss limit to a 4MB page baundary and copy everything inside it... then we don't need to bother with MB structures any more... But I don't like this approach very much!

JJ

OSDev.org

About multiboot modules...

About multiboot modules...