Loading kernel made in GCC from bootloader.

[Thunderbirds747]

Hi,
I can't get the kernel written in GCC to work with my bootloader. The file is krnl32.sys. Instead of booting directly, it just gets stuck in an infinite loop.
Any suggestions?
Sincerely,
Timo.

[matt11235]

L̶e̶t̶ ̶m̶e̶ ̶j̶u̶s̶t̶ ̶l̶o̶o̶k̶ ̶i̶n̶t̶o̶ ̶m̶y̶ ̶c̶r̶y̶s̶t̶a̶l̶ ̶b̶a̶l̶l̶ ̶t̶o̶ ̶l̶o̶o̶k̶ ̶a̶t̶ ̶y̶o̶u̶r̶ ̶c̶o̶d̶e̶.̶.̶.̶

Can you post some relevant code?

[iansjack]

Any suggestions?

Well, to answer in the style of the question, you've done something wrong.

[eryjus]

Well, to answer in the style of the question, you've done something wrong.

I'm having a god laugh at this... My first reaction would have been: "fix the problem."

[Thunderbirds747]

L̶e̶t̶ ̶m̶e̶ ̶j̶u̶s̶t̶ ̶l̶o̶o̶k̶ ̶i̶n̶t̶o̶ ̶m̶y̶ ̶c̶r̶y̶s̶t̶a̶l̶ ̶b̶a̶l̶l̶ ̶t̶o̶ ̶l̶o̶o̶k̶ ̶a̶t̶ ̶y̶o̶u̶r̶ ̶c̶o̶d̶e̶.̶.̶.̶

Can you post some relevant code?

Here.

[Schol-R-LEA]

As an aside here, are you using a VCS such as git, Subversion, mercurial, or bazaar, and do you have an offisite repo for the code (o, say, CloudForge or Github)? I would strongly recommend both, for a number of reasons. If nothing else, it would mean that you could give us a link to the repo rather than an archive file, and we'd be able to see the latest updates as the project progresses.

EDIT: OK, I have taken a look at the files kernel.asm and krnl.c, and will look at some of the others later, but I can tell you right now that either I'm confused about what you are doing, or you are.

The main thing that strikes me here is that the boot loader has a) a multiboot header, and b) no boot signature byte, meaning that it should be used as an entry point for a multiboot loader such as GRUB. However, in other respects, it looks like a typical hand-rolled boot loader - the code is 16-bit, and sets up the A20 line and a GDT, which wouldn't be necessary if it were meant to boot from GRUB (the Multiboot spec is such that the loader should always put the system into protected or long mode before the hand-off to the OS).

I think we need to hear what you think is going on, and how you expect it to work. Some details on your development methods (especially your linker script) would be useful here as well. I know that you have had problems trying to get the boot block loaded into an image and/or a live disk (your posts about dd and other tools), but it looks like there are other problems here as well.

[Thunderbirds747]

As an aside here, are you using a VCS such as git, Subversion, mercurial, or bazaar, and do you have an offisite repo for the code (o, say, CloudForge or Github)? I would strongly recommend both, for a number of reasons. If nothing else, it would mean that you could give us a link to the repo rather than an archive file, and we'd be able to see the latest updates as the project progresses.

EDIT: OK, I have taken a look at the files kernel.asm and krnl.c, and will look at some of the others later, but I can tell you right now that either I'm confused about what you are doing, or you are.

The main thing that strikes me here is that the boot loader has a) a multiboot header, and b) no boot signature byte, meaning that it should be used as an entry point for a multiboot loader such as GRUB. However, in other respects, it looks like a typical hand-rolled boot loader - the code is 16-bit, and sets up the A20 line and a GDT, which wouldn't be necessary if it were meant to boot from GRUB (the Multiboot spec is such that the loader should always put the system into protected or long mode before the hand-off to the OS).

I think we need to hear what you think is going on, and how you expect it to work. Some details on your development methods (especially your linker script) would be useful here as well. I know that you have had problems trying to get the boot block loaded into an image and/or a live disk (your posts about dd and other tools), but it looks like there are other problems here as well.

OK, Schol-R-LEA, this is what is going on with the system. I copy KRNL32.SYS and KRNLDR.SYS to the virtual drive, then 'mkbt' the bootloader onto a floppy, then I turn on Bochs, set up the virtual floppy, and when I click Start, it shows only the messages from boot and sometimes, the kernel loader.

[eryjus]

As an aside here, are you using a VCS such as git, Subversion, mercurial, or bazaar, and do you have an offsite repo for the code (o, say, CloudForge or Github)? I would strongly recommend both, for a number of reasons.

You seem to be stepping over this very important suggestion. One of these days you are going to come across a situation where you are going to want to go back and review old code for some reason or another (or worse, recover it). In my case it was a 2-disk failure (within minutes of each other) of my SAN RAID set. It was a hard lesson and I would hate for you to learn it first hand.

[Schol-R-LEA]

OK, Schol-R-LEA, this is what is going on with the system. I copy KRNL32.SYS and KRNLDR.SYS to the virtual drive, then 'mkbt' the bootloader onto a floppy, then I turn on Bochs, set up the virtual floppy, and when I click Start, it shows only the messages from boot and sometimes, the kernel loader.

Ah, yes, turnabout is fair play. I should be more specific: can you explain some of the different parts of the code, why you wrote them the way they are, and what you expect them to do? The Multiboot header is a good place to start with this. Given that you are describing what seems to be an installation for a one-stage loader you wrote yourself, why did you use a multiboot header here?

(I have a sneaking suspicion this is going to lead to me editing several wiki pages, for clarity if nothing else...)

[Thunderbirds747]

OK, Schol-R-LEA, this is what is going on with the system. I copy KRNL32.SYS and KRNLDR.SYS to the virtual drive, then 'mkbt' the bootloader onto a floppy, then I turn on Bochs, set up the virtual floppy, and when I click Start, it shows only the messages from boot and sometimes, the kernel loader.

Ah, yes, turnabout is fair play. I should be more specific: can you explain some of the different parts of the code, why you wrote them the way they are, and what you expect them to do? The Multiboot header is a good place to start with this. Given that you are describing what seems to be an installation for a one-stage loader you wrote yourself, why did you use a multiboot header here?

(I have a sneaking suspicion this is going to lead to me editing several wiki pages, for clarity if nothing else...)

Ahem, that was from the old bootloader, I use Broken Thorn's bootloader.

[neon]

Hello,

It appears to me that other members assumed that you were using GrUB. However, it looks like the original boot loader has been modified. We also noticed the boot loader entry point appears to be missing...double check what files you are using from the original code and how they work together.

Is kernel.asm supposed to be the kernel? Why not write it in C? It should not be using any part of the boot loader.

In any case, you should note that the boot loader was designed to load PE images at 1MB (later, mapping them to 2GB virtual) whereas GCC typically targets ELF. We typically recommend using ELF if using GCC or a GCC Cross Compiler. Or just use GrUB for now since it natively supports what you are trying to do.

[Thunderbirds747]

Hello,

It appears to me that other members assumed that you were using GrUB. However, it looks like the original boot loader has been modified. We also noticed the boot loader entry point appears to be missing...double check what files you are using from the original code and how they work together.

Is kernel.asm supposed to be the kernel? Why not write it in C? It should not be using any part of the boot loader.

In any case, you should note that the boot loader was designed to load PE images at 1MB (later, mapping them to 2GB virtual) whereas GCC typically targets ELF. We typically recommend using ELF if using GCC or a GCC Cross Compiler. Or just use GrUB for now since it natively supports what you are trying to do.

FYI, kernel.asm is the Stage 2 bootloader. It compiled properly and without any errors, so was the krnl.c and its dependencies itself.
The last problem that I need to solve is the link problem. I use MinGW GCC to link, but when I try to link all of the objects into one, it gives me this" start.o: File not recognized: File format not recognized. When I checked the file it said that it is i686. Any suggestions?

Sincerely,
Tim

[neon]

Hello,

I see. kernel.asm declares the multiboot header structure so that it can fill it out for use by the kernel. You are correct, this is boot loader code (although modified.)

The last problem that I need to solve is the link problem. I use MinGW GCC to link, but when I try to link all of the objects into one, it gives me this" start.o: File not recognized: File format not recognized. When I checked the file it said that it is i686.

What is the command line that you are using and what version of Mingw are you using? If you used a tutorial to get the command lines (and linker script), what tutorial did you use?

[Thunderbirds747]

Hello,

I see. kernel.asm declares the multiboot header structure so that it can fill it out for use by the kernel. You are correct, this is boot loader code (although modified.)

The last problem that I need to solve is the link problem. I use MinGW GCC to link, but when I try to link all of the objects into one, it gives me this" start.o: File not recognized: File format not recognized. When I checked the file it said that it is i686.

What is the command line that you are using and what version of Mingw are you using? If you used a tutorial to get the command lines (and linker script), what tutorial did you use?

GCC 5.3.0

[eryjus]

Hello,

I see. kernel.asm declares the multiboot header structure so that it can fill it out for use by the kernel. You are correct, this is boot loader code (although modified.)

The last problem that I need to solve is the link problem. I use MinGW GCC to link, but when I try to link all of the objects into one, it gives me this" start.o: File not recognized: File format not recognized. When I checked the file it said that it is i686.

What is the command line that you are using and what version of Mingw are you using? If you used a tutorial to get the command lines (and linker script), what tutorial did you use?

GCC 5.3.0

You know, you are the one seeking help here.... You might take a moment to help us help you.

GCC 5.3.0

I seriously doubt typing that sequence of characters on any command line will link anything in the manner you wish.

We typically recommend using ELF if using GCC or a GCC Cross Compiler.

I also believe there is a Cross-Compiler issue. Can you please confirm that you have followed these instructions: http://wiki.osdev.org/GCC_Cross-Compiler.

Now, to the question of exact commands used to create your binaries.... If you are genuinely interested in solving this problem, the people in the best position to help you are asking for the exact bits of information needed to provide you with the advice you are seeking. Ignoring those requests is not going to get you where you want to be any faster (if at all). By the way, the exact commands will help us determine if you are actually using your cross-compiler.