My kernel code is overwriting grub's memory map table.

[j4cobgarby]

When my kernel is loaded by grub, it begins reading the multiboot info. First, the memory limits, and then the memory map. My problem is that the reported address of the memory map is 0x100a4, which happens to be in the middle of my kernel code.

What I assume is happening is that grub is creating the table, then loading my kernel source right over it, but why is it doing this? Surely it knows how big my kernel is, and should know not to do this. What possible fixes are there? Can I tell grub to load the kernel elsewhere?

[PeterX]

Grub Legacy or Grub2?

Greetings
Peter

[Octocontrabass]

What I assume is happening is that grub is creating the table, then loading my kernel source right over it, but why is it doing this?

GRUB is designed to load the operating system above 1MB. I wouldn't be surprised if it assumes you will never request a load address below 1MB and doesn't validate the request.

What possible fixes are there?

Tell GRUB to load your OS at 1MB or higher.

Can I tell grub to load the kernel elsewhere?

Yes.

Without seeing your code, I can't point you at exactly what you need to change, but it'll probably be one of the addresses in your linker script.

[j4cobgarby]

What I assume is happening is that grub is creating the table, then loading my kernel source right over it, but why is it doing this?

GRUB is designed to load the operating system above 1MB. I wouldn't be surprised if it assumes you will never request a load address below 1MB and doesn't validate the request.

What possible fixes are there?

Tell GRUB to load your OS at 1MB or higher.

Can I tell grub to load the kernel elsewhere?

Yes.

Without seeing your code, I can't point you at exactly what you need to change, but it'll probably be one of the addresses in your linker script.

It seems that my kernel is being loaded at 1MB. Here's my linker script:

Code: Select all

ENTRY(_start)

SECTIONS
{
    /* start putting code at 1MB, apparently this is a
     * normal place for kernel code to be loaded from*/
    . = 0x100000;

    /* multiboot header has to be early on in the image so
     * that grub finds it */
    .text BLOCK(4K) : ALIGN(4K)
    {
        *(.multiboot)   /* first the multiboot header */
        *(.text)        /* now the actual entry code */
    }

    /* now the uninitialised data */
    .bss BLOCK(4K) : ALIGN(4K)
    {
        *(.bss) /* just the stacks */
    }
}

Is it the linker script that informs grub of where to load the kernel?

[Octocontrabass]

The linker script determines what values the linker will put in the ELF headers, and GRUB can read the ELF headers to determine where to load your kernel. The multiboot header can also contain a load address, though, and I can't recall off the top of my head which one takes priority when both are present.

According to your linker script, your kernel will be loaded at 0x100000. Is 0x100a4 really in the middle of your kernel code?

[j4cobgarby]

The linker script determines what values the linker will put in the ELF headers, and GRUB can read the ELF headers to determine where to load your kernel. The multiboot header can also contain a load address, though, and I can't recall off the top of my head which one takes priority when both are present.

According to your linker script, your kernel will be loaded at 0x100000. Is 0x100a4 really in the middle of your kernel code?

You know, it's possible that I misread some address. In hindsight I'm not sure if it was in the middle of my code...
At least I've learnt that I can move my kernel around by using the linker script, I was never really that solid on how the linker script worked, so thanks!

[PeterX]

The linker script determines what values the linker will put in the ELF headers, and GRUB can read the ELF headers to determine where to load your kernel. The multiboot header can also contain a load address, though, and I can't recall off the top of my head which one takes priority when both are present.

According to your linker script, your kernel will be loaded at 0x100000. Is 0x100a4 really in the middle of your kernel code?

You sure are the expert, but maybe the content of "multiboot" is the reason?

Greetings
Peter

[j4cobgarby]

The linker script determines what values the linker will put in the ELF headers, and GRUB can read the ELF headers to determine where to load your kernel. The multiboot header can also contain a load address, though, and I can't recall off the top of my head which one takes priority when both are present.

According to your linker script, your kernel will be loaded at 0x100000. Is 0x100a4 really in the middle of your kernel code?

You sure are the expert, but maybe the content of "multiboot" is the reason?

Greetings
Peter

I haven't specified a load address in the header, so that's probably not it here.