Multiboot Header - Has the magic number changed?

[nekros]

Now that I have my kernel compiling and installing on my computer; I have been trying to get it to boot with grub2 like it says in the wiki. My problem is there seems to be a lack of information on how to set up the multiboot header, and apparently the magic number has changed. Can anyone point me to information on how to get this working? NOTE: I did google this.

[quok]

Now that I have my kernel compiling and installing on my computer; I have been trying to get it to boot with grub2 like it says in the wiki. My problem is there seems to be a lack of information on how to set up the multiboot header, and apparently the magic number has changed. Can anyone point me to information on how to get this working? NOTE: I did google this.

Grub2 is supposed to implement the old multiboot standard as well as the new one. At least, that was the case at some point. The new multiboot draft says the new magic number is 0x36d76289. That may or may not be correct. Documentation for grub2 (and the new multiboot stuff in general) is rather nonexistant, so your best bet would be to look at the code. Unfortunately the web interface to view the code is throwing 503 errors right now.

[zity]

As far as I can see, my kubuntu 9.10 installation uses Grub2 and it boots my kernel (which is multiboot 1 compliant) without problems..

[Owen]

A couple of months ago Grub2 had a massive bug booting Multiboot 2 kernels (It read 1kb, searched it for a MB1 header, read another kb, searched for an MB2 header... see the problem?)

Regardless, MB1 support is/is supposed to be the same as for Grub Legacy

[Love4Boobies]

That draft was never implemented and never will be. Multiboot 2 has been completely dropped and the magic value is the same as it was before. Note that hey are going to use the tagged format and add support for extra architectures in Multiboot 1.

[Owen]

The tagged format IS Multiboot 2. You cannot implement a tagged format in the context of Multiboot 1: The specification is completely inextensible.

Not to mention completely lacking in 64-bit support.

[Love4Boobies]

Okay, maybe both me and the rest of the developer folks of GRUB are wrong and you are right.

[Owen]

What I'm saying is this: You can't implement a tagged format without changing the magic number

[nekros]

In the end, I think I'll just write my own elf bootloader....

[Love4Boobies]

There's no information missing on the wiki, you're screwing it up somehow. You just have to have the header somewhere in the first 8192 of the image, 32-bit aligned.

[nekros]

I've done that with both 1 and 2 headers still says header not found.

[Love4Boobies]

Post the header and linker script.

[xvedejas]

I'm having the same problem so I'll go ahead and post *my* code

start.asm (FASM syntax)

Code: Select all

...
section '.text'
align 4
mboot:
    ; This is the GRUB Multiboot header
    dd 0x1BADB002        ; header magic
    dd 3                 ; header flags
    dd -(0x1BADB002 + 3) ; header checksum
	dd mboot
...

link.ld

Code: Select all

ENTRY(start)
phys = 0x00100000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

[XanClic]

Maybe that's not the cause of your problem - but it's definitely a thing to change.

Never put the multiboot header into your .text section (because the linker might move that header anywhere in that section). A better approach is to create a new section called ".multiboot" or something like that and to tell your linker to put that section in front of everything. That's at least what I do (and I have no problems with that though I'm still using GRUB legacy ).

[Love4Boobies]

It is not a mistake to have the multiboot header in the .text section, it is in fact the most common approach. You needn't be afraid that your header will end up in some random place because you basically end up with the assembly code generated from the C file appended to the multiboot header part. Having a separate section is inconsistent with many executable formats (e.g., a.out).

As for the linker script, look closely at ".".