OSDev.org

Ok so this is more or less a place to post your OS boot and init proccess.
Im looking for better ways to.

My OS (As of now):
MBR loads Bootloader
Bootloader loads Kernel directly with very minaimal info passed to kernel (VGA mode and Memory map(still working on kernel handeling of mem map lol))
Kernel inits all hardwear and loads
(Planned):
Kernel reads a few config files and loads shell or gui or runs start up script depending on hwo it is configured,
if no configuration it then boots into KernelSHell (KSH)

Legacy boot:

• GRUB/Syslinux loads shim kernel and main kernel as module
• Shim kernel reads Multiboot memory map and looks for RSDP
• Shim kernel maps main kernel and hands info to main kernel on (new) stack
• Main kernel unmaps shim kernel and reads new info from stack arg
• Then traditional UNIX boot (init hardware, find root, run /sbin/init)

UEFI boot:

• UEFI loads UEFI shim kernel (UEFI executable)
• Shim kernel loads main kernel
• Shim kernel reads memory map and RSDP from System Table
• Shim kernel maps main kernel and puts args on stack
• Then same as above

Separating shim and main kernel allows me to separate low and high half kernels, and to adapt to different boot environments. But beyond that, there is not a whole lot of difference to what you wrote. It is completely normal to require configuration to load the correct boot partition and init program.

Regardless of legacy boot, UEFI boot or GRUB boot, a binary image is loaded from the file system and put into memory. For legacy boot, the second stage loader gets some vital information from BIOS and puts it in to the "system segment" which reside at a fixed physical address. For UEFI boot, ACPI tables, memory map and video mode are passed from UEFI and then moved to the "system segment". The 64-bit UEFI loader exists long mode and goes back to protected mode. All loaders will turn off paging if enabled and enter protected mode.

The next step is the same. The binary image is searched for the kernel device, the device is mapped to selector 0x18, and then control is passed to the kernel. The kernel will init all device drivers in the binary image. Either 32-bit paging or PAE paging is setup, and then all drivers are remapped high. After the drivers are started, the binary image is searched for servers (which are started) and for applications that are autostarted.

Configuration of the binary image is done by a tool which use a config file that lists which drivers, services and applications should be put into the image. IOW, the kernel is not rebuilt to change configuration, rather every device driver has it's own file that the linker creates.

Current OS Only supports UEFI Using the Official EDK2 Implementation:
(Based on the comments inside the main boot file)

- Initialize Global Variable (gBS, gST, gImageHandle)
- Allocate NULL Page so that it won't be included in the available memory inside the memmap
- Init Boot Graphics (G.O.P)
- Preallocates an area for the Multiprocessor Init Trampoline inside the low memory
- Queries the boot device and partition

- Initialize System Heap (So that we can map the kernel using 2MB Pages and have less TLB usage)
- Loads the kernel and imports all the required libraries and custum imported files mentionned in the "FIMPORT" Section.
- Load boot.nos (A file that includes a list of the boot driver locations and their attributes)
- Read the boot drivers (make sure they are there before the kernel starts up)
- Fill "InitData" that will be passed to the kernel with all the required data
- Get the memory map and put the pointers in the init data too
- Disable BIOS watchdog timer
- Exit boot services()

- Setup a prestartup allocation entries (to be replaced after boot with the new optimized and full memory allocator) with new page table
- SetVirtualAddressMap()
Finally...
- NosEntryPoint()

I don't. 512 bytes is all I need.

I'm having fun with bootBASIC which is a BASIC interpreter in a single sector. (It's not actually my OS.) The above statement is wrong; I've been trying to add a way to load and save programs, and there's just no way to free up enough space for it. Not within my abilities, anyway. I'm looking at removing a statement to make room for an absolutely minimal bit of code to load the next sector. Attempting to write minimal disk code showed me why Grub uses some sectors after the MBR; it's about the only sane way to get more code into a first-stage bootloader.