The Place to Start for Operating System Developers
http://f.osdev.org/
Thanks, I must have missed it.Octocontrabass wrote:The Multiboot specification includes example code showing how to find the base address and type of each memory region. (The example code attempts to print the addresses, but it has a bug: it will not print values above 4GB correctly.)
There will be more than one free memory region.
Your kernel is located inside one of the free memory regions. You will need to use the address of the start and end of your kernel to avoid the memory containing your kernel.
You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.Caffeine wrote:I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?
Where should I put the symbols and what blocks? .text, .rodata, .data, or .bss?thewrongchristian wrote:You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.Caffeine wrote:I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?
Linker_Scripts
By way of example, here is my linker script:Caffeine wrote:Where should I put the symbols and what blocks? .text, .rodata, .data, or .bss?thewrongchristian wrote:You can put symbols in your linker script to find the limits of your kernel. The multiboot loader will load your kernel into memory according to the ELF header. SO when your kernel gets control, you know where your kernel is, and you can define symbols at the start and end of your loaded kernel, then just ignore the kernel memory ranges when making the usable memory referenced by the multiboot header available to your physical memory manager.Caffeine wrote:I'm having trouble finding where the Kernel is in memory and how I would avoid it. Which one of the address fields would I use?
Linker_Scripts
Code: Select all
SECTIONS
{
/* Begin putting sections at 1 MiB, a conventional place for kernels to be
loaded at by the bootloader. */
. = 1M;
_bootstrap_start = .;
...
/* Bootstrap code in low memory */
...
/* Rest of the kernel lives in high memory */
_kernel_offset_bootstrap = .;
. += kernel_offset;
_kernel_offset = .;
/* Next we'll put the .text section. */
.text ALIGN(4K) : AT(ADDR(.text) - kernel_offset)
...
/* Kernel code in high memory */
...
_bootstrap_nextalloc = .;
. -= kernel_offset;
_bootstrap_end = .;
Code: Select all
extern char _bootstrap_start[];
extern char _bootstrap_end[];