Howto "boot" a C/C++ Kernel

[yomega]

Hi,

i'm very interested in developing around on some own os playground I've read now thousands of tutorials, but one problem does not seem to solve in my mind:

OK i can write a bootloader that is 512 bytes big and that does a lot of assembler fun. OK -> understood. It's definately "easier" to write a Kernel in C or C++ (like described here: http://www.invalidsoftware.net/os/).

But how on earth do i mix that together? I want to have a tiny little bootloader that simply loads my kernel.

I'm sure i'm just stupid, but thank you for your help

Greetings,
Stephan

[amirsadig]

you can use grub bootloader, but should be sure that your kernel compiled to start at 0x100000. also grup booted in protected mode, that mean you kernel should be compiled as 32bit code (default with gcc and ld linker).

if you want a real mode OS, you can search the internet or here in this forum FAQ http://www.osdev.org/osfaq2/

Is there an easier way to boot my kernel

[Curufir]

Hmm. Link the kernel in plain 32-bit binary format.

In your bootloader just concentrate on loading the kernel, setting up a basic flat GDT, kill interrupts and jump to your kernel. That should be sufficient to get you going.

However you've written a bootloader, proved you can do it, learnt about real mode addressing and (Presumably) understand what's going on. So quit worrying about how your OS gets loaded (USE GRUB) and move on to the more interesting stuff (EVERYTHING ELSE) .

[yomega]

Hi guys,

thanx for the replies.

I've read some grub tutorials but (correct me if i am wrong cause i'm a newbie) it seems to me that grub loads some FAT12 drivers and opens the kernel in a specified directory on the disk/floppy.

Isn't there an easy "1 2 3 go" bootloader without all these things? A bootloader which simply loads up an adress in his own 512 byte space so i can write my own fs driver and so on?

Sorry for my own stupidity ::)

Greetings,
Stephan

[Solar]

It doesn't get any easier than GRUB, which is why we recommend it.

Check out http://www.osdev.org/osfaq2/index.php/GRUB and http://www.osdev.org/osfaq2/index.php/BareBones for an introduction on how to make your kernel get booted by GRUB.

(Both pages assume GRUB 0.94; I haven't tried GRUB 2 yet as my kernel is currently on ice.)

[Pype.Clicker]

well, consider the followings:
- the advantage of having a FAT driver is that you don't have to design your own "where's file X" method. Even home-made loaders tend to have FAT built in. You can update one file without having to rebuilding the whole boot disk (that will eventually hold a few howtos, system tools etc. once you'll be done)
- the kernel you're writing is 32 bits, so the loader has to set-up a well-known 32 bits environment. Trying to remove that from the loader will really makes your kernel design odd.
- at some point you'll like to know how much memory your system has, etc. Looking at the FAQ, you'll see this is *not* a trivial problem and here again, GRUB can help you because it had the option of asking the BIOS it while in real mode :=)

The only thing that could stem 'against' GRUB is that i'm not sure it's possible to ask it to setup a VESA mode (easier to do in realmode than in pmode

[Solar]

Haven't tried to do it, but GRUB does offer a flag to demand VESA modes to be set, and the Multiboot data structure has fields to report back the actual screen mode.

[Pype.Clicker]

hmm ... i can see

vbeprobe [mode]    Command
Probe VESA BIOS EXTENSION information. If the mode mode is specified, show only the information about mode. Otherwise, this command lists up available VBE modes on the screen. See also testvbe

but that's a grub-shell command and will be quite useless for the booted program

+-------------------+
72 | vbe_control_info | (present if flags[11] is set)
76 | vbe_mode_info |
80 | vbe_mode |
82 | vbe_interface_seg |
84 | vbe_interface_off |
86 | vbe_interface_len |
+-------------------+
The fields vbe_control_info and vbe_mode_info contain the physical addresses of VBE control information returned by the VBE Function 00h and VBE mode information returned by the VBE Function 01h, respectively.

The field vbe_mode indicates current video mode in the format specified in VBE 3.0.

The rest fields vbe_interface_seg, vbe_interface_off, and vbe_interface_len contain the table of a protected mode interface defined in VBE 2.0+. If this information is not available, those fields contain zero. Note that VBE 3.0 defines another protected mode interface which is incompatible with the old one. If you want to use the new protected mode interface, you will have to find the table yourself.

The fields for the graphics table are designed for VBE, but Multiboot boot loaders may simulate VBE on non-VBE modes, as if they were VBE modes.

from the Multiboot standard

The graphics fields of Multiboot header

All of the graphics fields are enabled by flag bit 2. They specify the preferred graphics mode. Note that that is only a recommended mode by the OS image. If the mode exists, the boot loader should set it, when the user doesn't specify a mode explicitly. Otherwise, the boot loader should fall back to a similar mode, if available.

The meaning of each is as follows:

mode_type
Contains 0 for linear graphics mode or 1 for EGA-standard text mode. Everything else is reserved for future expansion. Note that the boot loader may set a text mode, even if this field contains 0.
width
Contains the number of the columns. This is specified in pixels in a graphics mode, and in characters in a text mode. The value zero indicates that the OS image has no preference.
height
Contains the number of the lines. This is specified in pixels in a graphics mode, and in characters in a text mode. The value zero indicates that the OS image has no preference.
depth
Contains the number of bits per pixel in a graphics mode, and zero in a text mode. The value zero indicates that the OS image has no preference.

Okay, so basically, you tell GRUB which mode you request as 1600x1200x32, and grubs does what needed to locate that mode's number and setup the mode. And then you check the mode info reported by the vbe_info block of GRUB to know if it worked or not ...

[yomega]

Thanx guys i finally managed to install Grub and i got it to "try" to load my kernel. But if always fails with an:

"-error 13 : invalid or unsupported executable file format"

I tried that: http://osdev.neopages.net/tutorials/bas ... ?the_id=12 and this: http://www.invalidsoftware.net/os/ kernel.

I followed exactly that tutorials.

I use djgpp with ld and nasm under windows. I really dunno what to do....

Thanks in advance for answering all these silly questions.

Greetings,
Stephan

[Neuromancer]

Which format do you use? Remember that u cannot have a flat-binary kernel if you do not use the AOUT kludge.
Use an ELF format instead.

[yomega]

Hi,

thanks for the reply.

If i understood it correctly it's all about the nasm compile line:

"nasm -f aout kernel_start.asm -o ks.o"

I tried that "aout" format. There is no error while linking but the kernel does not work.
So if i use "elf" the linker does not recognize the file format.
If i use "coff" the linker cannot find the entry point.

So i'm really confused about that ???

I use all this compilers from the djgpp package (including nasm). Is there maybe the problem?

Greetings,
Stephan

[Neuromancer]

When u use the ELF format in NASM, u get a ELF object file format. You have to link it with LD or another linker.

Example:

Code: Select all

nasm -f elf -o main.o main.asm
ld -T linker.ld -o kernel.bin main.o

[yomega]

Hi,

ok now managed to use the elf format i switched to my linux box (in vmware). Compiling worked fine, execution failed same way :-/

I will try after the Germany - "Lettland" football game to establish an "assembler only" kernel. To test around.

I'm thankful for any ideas.. Thanks guys!

Greetings,
Stephan

[yomega]

Ah and this: 101277359 is my icq# if someone wanna chat around with me

[Solar]

You could try having a look at http://www.pro-pos.org/cgi-bin/viewcvs. ... firststep/. That's about as bare-bones a GRUB booting kernel as it gets - it does nothing more but setting up a kout object (castrated cout) and prints data from the multiboot data structure to screen. Tried and tested to work with GCC / GAS / LD. If you fail to get it to run, it's your tools to blame.

If you find it useful, feel free to use it as Public Domain.