OSDev.org

I'm using Qemu to run the bootloadr. Ok, I have a 1.44m floppy image and on it is a stage1 bootloader. If I just have the kernal pasted right below the bootloader will somebody outline a function that will load and execute the kernel.

This depends on the file system that you are using, and the file format of the kernel.

Unless, you mean the bootloader (at sector 0) loads and executes a "kernel" at sector 1? (Please please not this.)

Need more details, please

Yes,the kernal starts at the 2nd sector.What's the problem.

You can use it to load extra sectors for booting as needed (Some systems do this for some reason.), I highly recommend it not being a Kernel ,though.

It is very hackish, and does not use any file system of any type. It is much more better to treat the kernel as its own task/program for design purposes for cohesion. There is no possible way to do this by reading/writing random sectors off disk.

Also, some/most/mabey all filesystems use certain sectors for specific purposes. For example, FAT12's first FAT table is located directly after the number of reserved sectors after the bootsector, or directly after the bootsector. Reading/Writing random sectors may make a file system impossible to design and develop on that system.

A system without a filesystem has almost no nice way to treat "files" and "programs", as there is no standard structure for their storage on disk. Hence, say goodbye to Program Management - A core function in any OS.

I am sure many members here can come up with countless of reasons why this would be very bad for a kernel.

If you still wish to continue, This might help you.

lol had I not read some of the guides thats probably what I would have done , yeah Im guessing if you went that route you would want to be thinking about making your own filesystem and a way to keep track of where files are?

Must admit the whole sectors 1 to x thing seems nice and simple but Im guessing it would be a knightmare to know what was where on disk?

Not to mention the fact that your kernel would be very difficult to install on a hard drive (you'd need a "kernel partition") and next to impossible to update.

In my OS, the kernel is a binary just like any other, except it's always executed at startup. Because I use GRUB I don't need to write FAT code, or any ELF code, but all that can easily be put into a second-stage loader, which should not be ELF.

1st stage loader loads the second stage (which is a pure binary), second stage loader has FAT and ELF code, loads up the kernel (if the kernel is a higher-half kernel in the second stage loader you could also set that up), and then jumps to the entry point (which the ELF header provides).

If any of this is confusing, just ask

Actually now that you tell me about the problems I'm going ahead and writing my own disk image tool that will have the features that I want so I can not have to do that.

Hi,

@crazygray1: I want you to look at things from a different perspective...

All boot loaders need to put the computer into some sort of state that the next stage can rely on. The details for this "transition state" are important, but what any specific boot loader does is mostly irrelevant (as long as it sets up this "transition state"). For the latest version of my OS this transition state goes something like this:

• - A20 must be enabled
  - the boot image must be at 0x00100000
  - the "boot script" must be at 0x00070000
  - a correct "pre-boot data structure" must be at 0x00060000, and must include a map of areas in the physical address space and other information (see the file "inc/boot/peds.inc" for exact requirements and details for this data structure).
  - an (optional) list of faulty RAM areas must be at 0x00050000 (if present)
  - the boot loader is responsible for selecting and setting up a default video mode (where maximum resolution and maximum colour depth allowed is determined by the "boot script")
  - the second stage code must be at 0x00030000
  - the boot loader must be in 32-bit protected mode (with "flat" segments) when it jumps to the second stage
  - all AP CPUs shall be left in their default "wait-for-SIPI" state
  - the state of all other hardware is undefined

@Neon: My "1440 KB floppy boot loader" doesn't use any file format and data is stored in contiguous sectors following the boot loader, and I don't see any problem with this at all. I haven't decided what a native "hard disk boot loader" will do yet. To be honest I really do like the idea of having a seperate boot partition, as it keeps the data needed during boot isolated from (potentially buggy and/or insecure and/or non-fault tolerant) file system code.


Cheers,

Brendan

@Neon: My "1440 KB floppy boot loader" doesn't use any file format and data is stored in contiguous sectors following the boot loader, and I don't see any problem with this at all.

There is no problem with that

The bootloader does not need to have any file format. The Kernel should, though.