Understanding the Linux kernel starts long before the first line of C code runs. Every Linux system begins life in a severely constrained execution environment, gradually transitioning from firmware-controlled initialization to a fully featured operating system. This article walks through that journey, step by step.
🧭 How to Study the Linux Kernel #
Before reading kernel source code, methodology matters more than syntax. The Linux kernel is a living system, not a linear narrative.
Key principles when studying kernel code:
-
Understand the Architecture First
Learn the major subsystems (process management, memory, file systems) before diving into implementation details. -
Map Interfaces and Responsibilities
Diagram how subsystems interact using tools like XMind or simple block diagrams. -
Follow the Execution Path
Use logs, boot parameters, or debuggers to trace control flow from entry points. -
Identify the Glue Code
Focus on callbacks, abstractions, and handoff points—these define how components truly work together.
With that mindset, we can begin where Linux itself begins.
⚡ Power-On and CPU Reset #
Pressing the power button triggers a hardware reset. On x86 systems, the CPU enters a predefined state:
- CS (Code Segment):
0xF000 - IP (Instruction Pointer):
0xFFF0 - CS Base Address:
0xFFFF0000
The CPU starts in 16-bit Real Mode, with access to only 1 MB of addressable memory. Physical addresses are calculated as:
Physical Address = Segment × 16 + Offset
This computation points execution to address 0xFFFF0, which resides in firmware. Control is now handed to the BIOS.
🧠 BIOS Initialization Phase #
The BIOS (Basic Input/Output System) performs essential system setup:
- Initializes CPU registers and chipset
- Performs POST (Power-On Self-Test)
- Detects and initializes basic hardware
- Sets up interrupt handlers
BIOS Memory Layout #
| Address Range | Purpose |
|---|---|
0x00000–0x003FF |
Interrupt Vector Table (IVT) |
0x00400–0x004FF |
BIOS Data Area |
0x07C00–0x07DFF |
Bootloader load address |
0xF0000–0xFFFFF |
BIOS ROM |
After initialization, the BIOS searches for a bootable device and loads its first sector into memory.
💾 From BIOS to the Bootloader #
The BIOS loads the first 512-byte sector of the boot device—known as the Master Boot Record (MBR)—into memory at address 0x7C00 and transfers execution to it.
This tiny code fragment has only one job: locate and load a more capable bootloader.
Because 512 bytes is far too small to load an operating system, modern bootloaders operate in multiple stages.
🚀 GRUB and the Multi-Stage Bootloader #
With GRUB2, the boot process is divided into stages:
-
boot.img
Lives in the MBR. Its only responsibility is to load the next stage. -
core.img
Contains GRUB’s core logic, filesystem drivers, and decompression support. -
Kernel and Initramfs Loading
GRUB locates the Linux kernel image and initial RAM disk and prepares the system to execute them.
As memory requirements grow, Real Mode becomes a hard limitation.
🔄 Transition from Real Mode to Protected Mode #
Real Mode restricts execution to 1 MB of memory and lacks memory protection. To continue, the CPU must switch to Protected Mode, enabling:
- 32-bit addressing (up to 4 GB)
- Memory protection and segmentation
- Structured interrupt handling
This transition is orchestrated by low-level assembly code.
🧩 The Role of head.S
#
The critical bridge between firmware and kernel C code is implemented in head.S. Its responsibilities include:
- Enabling the A20 line to access memory above 1 MB
- Creating and loading the Global Descriptor Table (GDT)
- Switching the CPU into Protected Mode by setting the PE bit in
CR0 - Initializing a basic Interrupt Descriptor Table (IDT)
Once these steps are complete, execution jumps into the kernel’s 32-bit entry point, where C code can finally run.
🏁 Summary #
The Linux boot process is a carefully staged transition:
- Hardware reset places the CPU in Real Mode
- BIOS initializes the system and loads the boot sector
- GRUB expands execution beyond firmware limits
- Assembly code establishes Protected Mode
- Control is handed to the Linux kernel
By the time the kernel’s main logic begins, the system has already crossed one of the most complex boundaries in computing—moving from raw hardware to a structured, protected execution environment.