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.

Hi,

Been awhile, this may be simplified in the future but don't expect much changes to the process.

Legacy BIOS:
- mbr (if applicable) loads bootsect
- bootsect loads nboot (contains nstart+nboot.exe)
- nstart enters protected mode, relocates & runs nboot.exe
- nboot stores the boot device number globally
- firmware mm services initialized

UEFI:
- nboot stores the boot device number globally
- firmware mm services basically just call UEFI here

Firmware independent entry point:
- int3 command loop if ndbg detected
- device tree created
- reads nboot.lst on the Boot Device
- main loop if timeout set (if gfxmenu is set, GOP or VBE is used)
- collect requested information from selected entry
- loads selected entry (kernel and any additional modules)

Boot phase 0 (can load files using firmware)

With BIOS:
- Load OS image into next available spot
- Control passed to RM entry point
- Boot information block placed at fixed low address
- Initialize serial port
- Set up text mode
- Enable A20
- Retrieve boot drive info
- Find ACPI, SMBIOS and MP tables
- Relocate some functions to low memory
- Get memory map
- Initialize RM interrupt stubs
- Enter PM
Memory allocations made at next available address in memory map. Files are loaded going back into RM and invoking the loader.

With UEFI:
- Allocate boot information block
- Record boot device path
- Set up GOP
- Retrieve ACPI, SMBIOS and MP tables
- Allocate and load OS image below 1MB
- Record PXE information
- Control passed to PM entry point
- Memory allocations and file loading are done through UEFI

Common:
- Setup page tables
- Relocate OS above 1MB
- Initialize GDT, IDT, TSS, retrieve CPU features
- Relocate boot information block
- Initialize threads, paging
- If loaded using BIOS, initialize physical memory manager, reserve low memory and mark already allocated pages as such
- Relocate stack
- Initialize heap
- If loaded using UEFI, load 8x8 and 8x14 fonts from media
- If loaded using BIOS, acquire PIC
- At this point, it would be a good idea to load a configuration file, but haven't got around to it yet
- Initialize debugger
- Load OS symbols
- If ACPI present, initialize ACPI. Otherwise register PS/2 keyboard and mouse, PCI bus and floppy controller.
- Load boot FS driver
- If loaded from network, load bus and network drivers and initialize bus drivers, retrieve DHCP information, stop UNDI
- If loaded from floppy using BIOS, load floppy controller driver
- If loaded from hard disk using BIOS, load bus and storage drivers and initialize bus drivers
- If loaded using UEFI, get memory map, map UEFI runtime, exit boot services, initialize physical memory manager, reserve pages for RM code and data, initialize RM interrupt stubs, initialize option ROMs, set up text mode, initialize interrupts
- Otherwise, free and unmap stuff from low memory and initialize interrupts
- Initialize LAPIC

Boot phase 1 (can't load files)

- Initialize other CPUs
- Enable interrupts
- Initialize timers and clock
- Load and initialize network, bus and storage drivers
- Identify the boot drive using BIOS drive info or the UEFI boot device path

Boot phase 2 (can load files natively)
- Load and initialize remaining devices
- Start thread which loads and initializes further devices as they are enumerated