[3] When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM (in embedded Linux devices), then load the bootloader into RAM for later execution.
[2] In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard.
[2] For each of these stages and components, there are different variations and approaches; for example, GRUB, systemd-boot, coreboot or Das U-Boot can be used as bootloaders (historical examples are LILO, SYSLINUX or Loadlin), while the startup scripts can be either traditional init-style, or the system configuration can be performed through modern alternatives such as systemd or Upstart.
[7] IBM PC compatible hardware is one architecture Linux is commonly used on; on these systems, the BIOS or UEFI firmware plays an important role.
[7] For example in a system with an i.MX7D processor and a bootable device which stores the OS (including U-Boot), the on-chip boot ROM sets up the DDR memory controller at first which allows the boot ROM's program to obtain the SoC configuration data from the external bootloader on the bootable device.
[12] The first stage bootloader, which is a part of the MBR, is a 512-byte image containing the vendor-specific program code and a partition table.
[6] After this step, the active partition's boot record is read into RAM and executed as the second stage bootloader.
[6] The job of the second stage bootloader is to load the Linux kernel image into memory, and optional initial RAM disk.
After a menu entry is chosen and optional parameters are given, GRUB loads the linux kernel into memory and passes control to it.
), clears the Block Started by Symbol (BSS) then invokes decompress_kernel() (located in ./arch/i386/boot/compressed/misc.c) to decompress the kernel.
It sets up interrupt handling (IRQs), further configures memory, mounts the initial RAM disk ("initrd") that was loaded previously as the temporary root file system during the bootloader stage.
[14] The initrd, which acts as a temporary root filesystem in RAM, allows the kernel to be fully booted and driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk).
[14] initrd contains the necessary modules needed to interface with peripherals,[14] e.g SATA driver, and support a large number of possible hardware configurations.
[19] According to Red Hat, the detailed kernel process at this stage is therefore summarized as follows:[15] At this point, with interrupts enabled, the scheduler can take control of the overall management of the system, to provide pre-emptive multi-tasking, and the init process is left to continue booting the user environment in user space.