Where do you load your kernel?

[RuneOfFire]

Where do you load your kernel?

EDIT: I'm talking about virtual memory, by the way.

I was wondering about the .text, .data, and .bss sections. Some people load them next to each other (eg. .text = 0xC0000000 .data = 0xC0001000 .bss = 0xC0002000). Some people spread them out a bit in memory, and put the BSS in their heap (eg. .text = 0xC0000000 .data = 0xD0000000 .bss = 0xE0000000).

Should the BSS be loaded in the beginning of the heap?
Considering the .text, .data, and .bss sections will likely never be 256MB in length, wouldn't it be better to put it all as close together as possible in memory? It'd also save page tables...

[df]

bss should always follow data unless the linker specifically did something else...

bss IS part of .data, its just zeroed. imo they should be treated the same as a single section.

[mr. xsism]

slightly off topic:

how would you load your kernel to 1MB physical with BIOS? I am speaking especially of the floppy drive.

Would it be easier to load it to a lower address and then have a 2nd stg bootloader move it to 1MB in pmode?

I can do this in 1 stage already but there is a 64KB limit. In this i mean: 0xFFFF:0xFFFF is 0x100000+64KB.

Any bright ideas about this?

[Pype.Clicker]

my own kernel is loaded in conventionnal ram (<1MB) and i play with segment bases to make it appear at virtual address 0. I discourage anyone to do the same as it's more a nuisance to need logical2absolute conversions everywhere, but at least it allowed me to load it anywhere easily from realmode, even through a classical DOS program...

Note that as it's a microkernel, it should not grow enough to consume more than the 512K available for realmode (keeping BIOS areas untouched). All that have to be there is the memory management, multithreading and the module drivers required to access the root partition where more modules/servers will be found to run the full system.

[Candy]

I load my kernel (plain ELF file with page-aligned code and data) to 0x20000 real-mode location, and then use paging to map the code (starting at 0x21000) to 0xF0000000, and map the data (from 0x24000, but is dynamic) to 0xF4000000. The BSS directly follows the data, and the heap is directly after the bss (well... 12 byte space between them...)

Aside from that, there are a few static data structures that automatically get pages mapped there when I use them. These are the smaller static tables that I use, 4k per processor (even though I don't support SMP yet, it's useful to get all processor-dependant stuff out of the way to ease SMP implementation) in the address space and the process & thread table.

The thread table starts at 0xFE000000 and has a potential for 0x1000000 bytes, enough for 16k threads (which should suffice). The process table is higher up, at 0xFF120000 iirc, and expands up to some higher space, haven't decided on the size nor the max for the process table.

Processor dependant is at 0xFF0vv000 where vv is the APIC ID of the processor, and it's directly accessible using the GS segment. Since I cannot tell GCC to use GS for those data (somehow I cannot figure out whether it even supports this) the first word is a pointer to itself, but in the DS segment. This is then used by gcc to access those variables.

As well as mapping in the GDT, the IDT, the BDA, sometime soon the EBDA, and the E820 memory map, it's all together a quite nice memory structure IMO.

Also, from FC000000 (or F8000000 with PAE) the page tables start.

HTH, Candy

[mr. xsism]

Note that as it's a microkernel, it should not grow enough to consume more than the 512K available for realmode (keeping BIOS areas untouched). All that have to be there is the memory management, multithreading and the module drivers required to access the root partition where more modules/servers will be found to run the full system.

true, halfix has a goal of being no more than 64KB. This has always been a goal for halfix, but i was thinking for like laoding plugi modules and such. But i will be loading them in pmode so i'll have enough access to memor to do that. Thanks guys.

[MrASCII]

I believe ( please correct me when I?m wrong ) that you can load your kernel in stage1 to 2MB linear ( odd megabytes only ), OR you enable A20 and then copy it to 1MB linear. But since a good A20 routine can be a bit large, it may not fit in a 512byte sector ( including a FAT12 loader? )... Therefore, I?m using a 2nd stage loader, which loads the actual kernel, and does some other stuff, like detecting VESA and it?s LFB, etc etc.

So, I think it CAN be done in stage1, but is a bit harder to do.

[RuneOfFire]

I've already got a FAT12 bootloader (2 stages) and I load the kernel file into conventional memory, process the COFF header, and copy the sections to 1MB. Everything works great; I was more concerned about the virtual addresses of certain parts of the kernel.

The text, data, and bss are all loaded contiguously at 1MB and mapped to 0xC0000000. I use the virtual memory at 0xE0000000 - 0xF0000000 for the heap. 0xF0000000 - 0xFFFFFFFF holds things such as the page tables and directory (with the last entry self-mapped for easy modification), APIC mapped memory, the GDT, IDT, etc.