OSDev.org

Hello everybody

A BIG QUESTION?

As far as I know for an OS,First::after POST,MBR loads into memory in address 0x7c00 and detect File System::OK
second::OS loader(secong stage loader) loads kernel and then switches to PMode and then give control to kernel
by calling K_main() that loaded into memory before switching to PMode::OK
Third::Drivers and modules load after control has given to kernel like Time,Timer,Exceptions,Interrupts,Threads,Task,...
(I mean it's modules or managers like interrupt handler )

Is it the correct way to loads an OS and give control to Kernel and ...,if not please help me.


Nothing is bigger that victory.

Well, that's one way to do it. You don't have to switch to pmode, you don't have to name it K_main(), or you could use GRUB.

In my OS, the BIOS loads the boot sector to 0x7c00. The boot sector then loads a fixed size of 17k from the floppy (starting at 0x7e00). It then sets up halts interrupts, sets up pmode, loads the gdt, moves the kernel to 0x11000 and jumps there. The kernel then compiles the drivers (if included) and finally passes control to the user. There's no filesystem to worry about when booting (even on a hard drive, the file system exists on a separate area of the drive).

In reality, how the boot process goes depends entirely on the design of your OS.

Hi,

Administrator2004 wrote: As far as I know for an OS,First::after POST,MBR loads into memory in address 0x7c00 and detect File System::OK
second::OS loader(secong stage loader) loads kernel and then switches to PMode and then give control to kernel
by calling K_main() that loaded into memory before switching to PMode::OK
Third::Drivers and modules load after control has given to kernel like Time,Timer,Exceptions,Interrupts,Threads,Task,...
(I mean it's modules or managers like interrupt handler )

The only things that must happen are:
Step 1: somehow some code gets into memory (not always during boot, not always via a disk drive, MBR or boot sector)
Step 2: other things happen
Step 3: sooner or later the OS has booted

Anything with more detail than that is entirely OS and/or hardware specific. For example, you could have a real mode OS with the functionality of DOS that boots via an ethernet card - the OS has booted as soon as it's downloaded.

Most of the time the BIOS loads the first sector of what-ever it can find (e.g. boot CD, first floppy drive, first IDE or SCSI hard drive). Usually the MBR on the first hard drive will check the partition table, load the first sector of the partition that is marked "active" (the OS's boot sector) and load that into memory at 0x7c00 and jump to it. Once the OS's boot sector is running anything could happen.

My OS has "boot code" which may be an MBR, or a boot sector (in a partition), or a little program running on DOS, or a ROM chip in an ethernet card, or....

This boot code loads a boot image into memory, searches for my 16 bit setup code, copies the 16 bit setup code to a fixed address and jumps to it.

The 16 bit setup code detects a whole pile of stuff. It might search the boot image for code to handle a boot menu and run it (it depends on how the boot image is configured). In any case once the 16 bit setup code has detected everything it needs (and started any other CPUs), it will search the boot image for 32 bit (or 64 bit) setup code.

The 32 bit (or 64 bit) setup code configures the physical memory managers, enables paging and searches the boot image for a suitable kernel and a suitable kernel setup driver. Once these files are found it will copy them to fixed linear addresses and pass control to the kernel setup driver.

The kernel setup driver initializes the kernel itself, then starts loading device drivers and things. Eventually none of the boot code (and kernel initialization code) is left in memory.

That adds up to 5 different pieces of software before any part of the kernel is used, and 3 pieces of software before protected mode is enabled.


Cheers,

Brendan