Page 1 of 1

Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 11:30 am
by 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! :D

https://github.com/Toriiiiiiiiii/Solkern
mb issues.png
mb issues.png (4.04 KiB) Viewed 2675 times

Re: Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 1:05 pm
by 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.

Re: Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 1:11 pm
by 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.

Re: Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 1:37 pm
by 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?

Re: Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 2:03 pm
by 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.

Re: Seemingly corrupt Multiboot info structure?

Posted: Wed Jun 25, 2025 3:23 pm
by Octocontrabass
torii wrote: Wed Jun 25, 2025 1:37 pmIm 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.