OSDev.org

I'm trying to use an old Intel P4 machine as a test bed for learning OS development but so far every multiboot compliant kernel I've built just immediately resets the machine (like a CTRL-ALT-DEL). I've tried code from various sources (Bran's Kernel tutorial, OSDev Bare Bones tutorial, and many more) but always the same result. I even tried booting a pre-built GNU Mach kernel (also multiboot) and same result except the blinking cursor remained on the screen a lot longer. Given this, I'm assuming the reset occurs immediately after or near the end of the kernel loading into memory. But no idea why.

Any ideas?

Some additional info:
In my simplest case, I use only an assembly file (no calls to C code) with only the minimal multiboot header and a single instruction to loop forever (jmp $). Using a hex editor, I verified that the multiboot header was correct and also that the ELF entry point leads to the singe jmp instruction. Still, nothing but a reset occurs. So far the only thing I've been able to load and run from GRUB is a Linux kernel I compiled. I have a recent version of GRUB installed on a USB flash device and then booting the machine from that.

Any help or hints is much appreciated!

Hi,

crbmky wrote:In my simplest case, I use only an assembly file (no calls to C code) with only the minimal multiboot header and a single instruction to loop forever (jmp $). Using a hex editor, I verified that the multiboot header was correct and also that the ELF entry point leads to the singe jmp instruction. Still, nothing but a reset occurs. So far the only thing I've been able to load and run from GRUB is a Linux kernel I compiled. I have a recent version of GRUB installed on a USB flash device and then booting the machine from that.

There's only 3 options:

• GRUB is broken (note: because Linux doesn't use multiboot, booting Linux successfully doesn't mean that GRUB has no bugs when booting something that does use multiboot).
• The hardware is broken (if Linux boots and runs reliably then this is very unlikely)
• Your code is broken

You'd want to devise tests to rule out some of those possibilities. For example, boot it on a different computer (or emulator) to rule out broken hardware, and/or try to boot something else that does use multiboot to rule out your code, and/or try to boot your code with a completely different boot loader that supports multiboot (or possibly even just an old version of GRUB) to rule out GRUB.


Cheers,

Brendan

crbmky wrote:In my simplest case, I use only an assembly file (no calls to C code) with only the minimal multiboot header and a single instruction to loop forever (jmp $). Using a hex editor, I verified that the multiboot header was correct and also that the ELF entry point leads to the singe jmp instruction. Still, nothing but a reset occurs. So far the only thing I've been able to load and run from GRUB is a Linux kernel I compiled. I have a recent version of GRUB installed on a USB flash device and then booting the machine from that.

If so then probably it's 1st option in Brendan's list. In my Modified GRUB I use same kernel stub and expect to see that machine will have stopped. You can try Modified GRUB 2 in SYS format to load your kernel (stub). Try kernel stub from the package first. It's correct.

Have you tried GRUB + other Multiboot-compliant kernels on this test bed? You should preferably get a prebuilt image so as not to rule out a bug in the building process.

Thanks for the replies!

This confirms my thoughts exactly. The part I wasn't sure about was GRUB. That is, wasn't sure if an issue with GRUB was a possibility since it's essentially passing control over to the kernel. But I guess it's possible that's it's left the machine in a bad sate just prior to loading a multiboot kernel.

Once the kernel successfully loads and starts executing instructions, does GRUB play any role?

For now, I'll verify that the kernels run on QEMU.

crbmky wrote:Once the kernel successfully loads and starts executing instructions, does GRUB play any role?

Most boot loader, including GRUB, do not define exactly all the machine state, and the kernel is responsible for necessary re-initializations or otherwise mess with the undefined (and dirty) state left by the loader.

egos wrote:If so then probably it's 1st option in Brendan's list. In my Modified GRUB I use same kernel stub and expect to see that machine will have stopped. You can try Modified GRUB 2 in SYS format to load your kernel (stub). Try kernel stub from the package first. It's correct.

Thanks for this tip! GRUB is definitely overkill for what I'm trying to do. The website hosting these OS Boot Tools you mentioned (http://goncharov.pp.ru/en/osboot.htm) has some much simplified boot loader solutions. I'm going to try these out and see how that goes.

You can try out these boot loaders by loading Modified GRUB in SYS format by them. Just install both MBR and VBR boot loaders from OS Boot Tools and copy all files and directories from my package into root directory of system disk/partition.

Yo:

If you're developing for the x86/IBM-PC platform, and using GrUB, and finding that your kernel is "restarting" the machine, the solution is to fix your code, because there is an error in your code.

What I'm trying to tell you is that there is nothing wrong with GrUB, and your code is flawed.

--Peace out
gravaera

Where is error: jmp $ Just it's need to check Multiboot header for is it correct entry point?

So I installed legacy GRUB onto the USB device (replacing GRUB2), and was able to load and run a multiboot kernel that had previously failed. I guess this is not so surprising, yet another case of 'new' and 'old' not getting along.

Can't help but wonder what was causing the reset though... I suppose some memory corruption leading to a triple fault?

I have the same thing happen on one computer. Also a P4: http://forum.osdev.org/viewtopic.php?f=1&t=25961

crbmky wrote:Can't help but wonder what was causing the reset though...

I fixed it by rolling my own bootloader and stopped worrying ... until now!
So thank you very much!

Just kidding ... though I also can't help but wonder what is up if only that CPU of mine had JTAG or some other debugging capabilities because I don't even know whether my kernel is even reached ... though I could printf debug GRUB (ugh) or generally start debugging the issue (ugh).

But I sense a pattern you got a P4, I got a P4. But that might just be too far fetched.

Anyway good to see you also got a fix that works for you.