[ Navigation ]
General:
About me.
Progress / Status
News
Documentation:
Design.
Development.
User.
Downloads:
Disk Images.
Sourcebase.
|
[ Documentation :: Citadel Microkernel Design ]
[ Citadel Boot Sequence ]
Introduction:
Why have an entire page dedicated to the Citadel boot sequence? (From Machine POST to Citadel uK)
Well, The Citadel boot sequence is slightly different.
It is a 4 Step process.
Step #1 - Bootloader Stage 1.
Step #2 - Bootloader Stage 2.
Step #3 - Bootstrap Kernel.
Step #4 - Citadel Microkernel.
Bootloader Stage 1
As we all know, A computer doesnt start with all those handy features you are used to, instead,
The Computer starts off with POST, Power-on-self-test. After it has verified that all core components
after functioning adequetely, the BIOS jumps to the Memory location 0x0007C00. This process is HARDCODED
into the Machine's BIOS. Of course, at first initialization there will be nothing at that location, so
before the BIOS executes that jump, it scans your system for a Bootable disk. Be it a Floppy, Hard drive
or CDROM, they all must have a compatible Bootsector. Once this Bootsector is found, it is automatically
loaded into Memory, yep - you guessed it, loaded into Memory Location 0x7C00.
The Bootloader must be exactly 512bytes in Size and the last 2bytes of the Bootloader must be 0xAA55.
The 0xAA55 identify the Sector as a valid Bootloader. However, Not ALL BIOSes check for this,
although most do.
If we were loading the Citadel Kernel from the Disk 'raw', then 512bytes would be more than enough,
however we are loading the Citadel Kernel using the FAT12 Filesystem so 512bytes gives us just enough
room to fetch the next stage and jump to that location.
This is S1BL's purpose, simply to fetch the next stage from the Disk by navigating the FAT12 Filesystem.
The Bootloader is hardcoded to search the Disk for the file, CBOOT.BIN and to load it to Memory
Location 0x7E00. Once the load is complete, a far jump is performed to get the code at 0x7E00 executing.
CBOOT.BIN is the second stage Bootloader and Bootstrap Kernel combined.
The S2BL is stored at Offsets 0x000 to 0x1FF.
The Bootstrap Kernel is stored from 0x200 onwards.
Bootloader Stage 2
The purpose of the second stage Bootloader is simple, to get the processor operating in 32bit Protected Mode. It does this by loading the neccessary GDT structures and setting the required bits in the Control Registers.
GDT_DPL0_CODE / GDT_DPL0_DATA
GDT_DPL3_CODE / GDT_DPL3_DATA
Once the processor is operating in 32bit Protected Mode, another far jump is made.
If you recall, the S2BL is only 512bytes in Length, loaded at location 0x7E00. The S2BL performs a far jump to location 0x8000, Home of the Bootstrap Kernel.
Bootstrap Kernel
The Bootstrap Kernels purpose is to fetch the Microkernel, and load it to 1MB Location in Memory. The BKL
will also setup Paging and the adequete virtual Mappings for which the Microkernel needs to execute correctly.
The reason for this is simplicity. This Bootstrap Kernel can be seen as part of the second stage boot
process. why simplicity? Well, the entire Kernel is programmed in C, which is a lot nicer to debug and
stare at for long periods of time than Assembly is, also - Loading files and managing things is a lot
easier under C than it is for me under Assembly. AND... finally, being inside 32bit PM means there are
no real-mode 64k Segment boundries to worry about.
Once the Microkernel has been loaded to 1MB Memory Location, Paging is enabled and Virtual Location
3GB aliased to Physical Memory location 1MB. For more information on Paging and Virtual Memory, you should
go to the Memory Management Doc.
Citadel Microkernel
The purpose of the Citadel Microkernel, is to provide reliable and fast control of the System.
The first things that the Microkernel does once executed, is reinitialize the IDT and GDT, aswell as
Paging. This way, incase something happens to erase the up to the first MB of Memory, the Kernel can
continue functioning since it is no longer relying on early structures.
Once that is complete, the Kernel will begin installing the Handlers for Hardware that it requires,
such as the Intel Programmable Interrupt Timer and Intel FDC. The PIT and FDC are particularly important.
The PIT is needed to drive the system Scheduler and the FDC is needed to load the first few Servers,
to provide basic things like Keyboard Input and Textmode Video output.
Once the core Drivers are installed into the Handler, Initialization of the Memory Managers begins.
Following that, The Kernel loads a few core programs needed for System startup and begins Multitasking /
Scheduler Initialization (IPC is included here). Once that is complete, the Kernel is up and running, and the Programs will begin
execution and initialization of any further components.
|
Hosting provided by ASM Hackers.net
Optimal Resolution: 1280x1024 32bpp.
muK-based OSes:
BeOS
QNX
L4
NextSTEP
Mac OS X
Minix
|