Seemingly corrupt Multiboot info structure?

[torii]

Hi all, its been a while since I last posted anything here.
I am working on parsing a Multiboot1 info header in my kernel, however some of the information is seemingly corrupt.
I believe I am checking against the correct bits in the flags field, however this is the only thing I can think of that explains it.

Certain fields, such as framebuffer information and boot device information appears to be invalid. I have attached a screenshot of the output, and the link to my kernel's source code. Any help solving this would be appreciated!

https://github.com/Toriiiiiiiiii/Solkern

mb issues.png (4.04 KiB) Viewed 2643 times

[iansjack]

Code: Select all

uint32_t vbe_mode; 
uint32_t vbe_interface_seg;
uint32_t vbe_interface_off;
uint32_t vbe_interface_len;

These should be uint16_t.

[torii]

I can confirm that after changing this, I am still receiving a similar output - the framebuffer appears more reasonable but the boot drive fields do not appear correct.

[torii]

ugh never mind, turns out i was greatly misinterpreting drive numbers. I was loading the image as a cdrom with grub, which explains the drive number assignment of 0xe0. Im still not entirely sure why the partition number is 0xff though, I would've thought it would be 0x00?

[iansjack]

I don't know the authoritative answer to that, but I'm guessing that - as cd roms don't have partitions - it's setting the partition numbers all to -1.

[Octocontrabass]

Im still not entirely sure why the partition number is 0xff though, I would've thought it would be 0x00?

The spec says unused partition bytes will be set to 0xFF. Optical discs usually aren't partitioned.