Multiboot versions

[xDanielx]

Hello,

I'm trying to read a memory map from the Multiboot structure. I took the multiboot.h, boot.S, and kernel.c sample files from the Multiboot 0.6.96 spec, and I took the linker script from the Bare Bones tutorial. I then did

Code: Select all

gcc -o boot.o -c boot.S
gcc -o kernel.o -c -nostdlib -nostartfiles -nodefaultlibs kernel.c
ld -T linker.ld -o kernel.bin boot.o kernel.o
qemu -kernel kernel.bin

The memory map that I get doesn't look right at all:

Code: Select all

flags = 0x4f                                                                                        
mem_lower = 640KB, mem_upper = 392192KB
boot_device = 0x8001ffff
cmdline = kernel.bin
mods_count = 0, mods_addr = 0x106000
mmap_addr = 0x9000, mmap_length = 0x78
 size = 0x14, base_addr = 0x00, length = 0x00, type = 0x0
 size = 0x14, base_addr = 0x00, length = 0x9f4000, type = 0x0
 size = 0x14, base_addr = 0x00, length = 0xf00000, type = 0x0
 size = 0x14, base_addr = 0x00, length = 0x1000000, type = 0x0
 size = 0x14, base_addr = 0x00, length = 0x17ffd0000, type = 0x0
Halted.

I also tried booting with GRUB 0.97, but got the same output.

I suspect that it's an issue with different versions of Multiboot, but I'm confused about this and haven't been able to find much information online. What versions of multiboot are there, and which versions are incompatible? What version does GRUB 0.97 implement? What version does QEMU's built-in bootloader use? Where can I get the multiboot.h header, or at least the spec, for versions other than 0.6.96?

Or perhaps I have made a mistake of some other sort?

Thanks,
Daniel

[Combuster]

64-bit linux? GCC Cross-Compiler

[xDanielx]

I tried building gcc with --target=i386-elf, rebuilding the kernel, and running with qemu-system-i386. I still get the same funny output.

[gerryg400]

The multiboot.h header that comes with Grub defines its structures in terms of 'unsigned long'. This doesn't always work because long is not always 32bit.. Those structure members should be uint32_t (or similar) and use a 'packed' attribute to ensure that the code compiles on different compilers.

Debugging this is pretty simple. Cast the table to a char *, print out the entire table byte by byte then inspect. You'll soon see what the problem is.

[xDanielx]

The multiboot header from GRUB 0.9.7's source did the trick. Apparently the associated multiboot version is 0.6.93. And unlike 0.6.96, it also seems to work with qemu's bootloader.

Thanks for the input.

[Love4Boobies]

Hmm, there are no significant differences between the two versions of the Multiboot specification, esp. not anything that breaks compatibility. This might be a bug in QEMU. Could you provide more details or a test case to see whether it's the case for a bug report?

[xenos]

Which version of QEMU are you using? I remember there have been a few bugs with loading multiboot kernels directly with QEMU's -kernel option in versions 0.13.0 and before, but as far as I know they are fixed in the newest version 0.14.0. This is the memory map my kernel reports me when I boot it with QEMU 0.14.0 and the -kernel option:

Code: Select all

Multiboot Info:	Magic: 0x2badb002, Address: 0xc0009500, Flags: 0x0000004f
Memory map of length 0x00000078 at address 0x00009000
Mem: 0x0000000000000000-0x000000000009f3ff, Type: 0x01
Mem: 0x000000000009f400-0x000000000009ffff, Type: 0x02
Mem: 0x00000000000f0000-0x00000000000fffff, Type: 0x02
Mem: 0x0000000000100000-0x0000000007ffcfff, Type: 0x01
Mem: 0x0000000007ffd000-0x0000000007ffffff, Type: 0x02
Total memory:	131072 kB

[Love4Boobies]

I'm using the latest (0.14.1) but I still find it surprising that an old Multiboot header worked for him, as they're not really all that different. On an unrelated note, I wonder whether there will be a -kernel2 option for Multiboot 2 kernels... Not that Multiboot 2 will be released anytime soon, it's been "in the works" for a couple of years now.

[Neolander]

Multiboot 2 is like Duke Nukem Forever : it's going to take 14 years with a development team switch in the last year, and in the end the product will still be horrible