OSDev.org

Hi all,

I wanted to know the internals of the computer arch and OS. So I've been reading stuff online, books (in fact only one book modern operating systems). I came across OS dev wiki. I found the material that has been put together very useful. I decided to test few programs in the tutorials.

So I used the asm kernel code (http://wiki.osdev.org/Real_mode_assembly_bare_bones), on qemu.

assembled it using nasm Then, as mentioned here http://wiki.osdev.org/Bare_bones#Using_ ... Bootloader, I used qemu's built-in bootloader It just aborted! (just printed Aborted!)

But when I used with out the -kernel option (qemu kernel.bin) it launched the VM with the kernel running (figure attached).
1. Can someone please tell me what could the problem be when the -kernel option is used.

At the end of the code it had the following lines: I read that bios needs the signature "0xAA55" at the end. Why do we need this in the kernel code here. does this mean that the kernel is itself a bootloader here. But aren't we using the qemu built-in bootloader. I expected the qemu built-in bootloader to load the kernel. I removed the above part in the code (removed signature) and tried qemu kernel.bin it could not load the kernel. It ended up as shown in the attached figure kernelLoadError.png.

2. Can someone explain what exactly is happening here. Why are we using the above code when we are using the qemu built-in bootloader. And why is the code not working when I remove the signature part from the code.

Hope the question is clear.

Thanks.

qemu's -kernel option requires a linux- or multiboot-compliant image, and the real-mode barebones is neither of that. That leaves the other booting mechanisms: booting from CD, which requires an el-torito bootblock (or disk image) inside an ISO-9660 filesystem, or the good old floppy or harddisk boot, which are the only cases where the first sector is loaded and the last two bytes checked against 55 AA. I think its obvious in which of the three categories your image falls.

I haven't checked the manual, but I can safely guess here that specifying an image without telling what kind of image it is defaults to harddisk, making it "magically" work. Try running qemu -fda kernel.bin and you'll notice it'll work just the same.

Combuster wrote:Try running qemu -fda kernel.bin and you'll notice it'll work just the same.

Thanks for the answer. I used -fda and it ran perfectly.

So let me see if I got it right, because the kernel in barebones is neither a linux- or multiboot-compliant image, the built-in bootloader does not load the kernel. And then It tries to boot from harddrive (which seems to be the default option) and finds the first sector ending with AA55, takes it as the boot sector and starts booting from this sector. Did I get it correctly. Sorry if I'm being a pain in the a**. Just want to understand things correctly.

Thanks.

It's not A then B, but A or B. As you observed, if you pass it via -kernel it doesn't become a harddisk image as a backup, it just complains. Conversely, if you tell it that it is a harddisk image it will not look for a multiboot header.

Ohh, I get it now. Thanks a lot.

I don't use QEMU, but since the -kernel option expects a linux or multiboot kernel, it would have to be protected mode code, so the real-mode barebones would probably not work even if you stuck a multiboot header on it.