Linux – How does a bootloader and kernel interact after the kernel is loaded in memory

bootboot-loaderkernellinux

I'm a little bit confused about the role of bootloader and its interaction with kernel, especially when talking wrt ARM Llnux. Once the Kernel is loaded into RAM, is there any job left for the bootloader? For example look at the log messages here:

Thu Feb 06 18:05:34.660 2014] 
[Thu Feb 06 18:05:34.660 2014] 
[Thu Feb 06 18:05:34.660 2014] U-Boot 2013.07 (Feb 04 2014 - 14:41:40)
[Thu Feb 06 18:05:34.660 2014] 
[Thu Feb 06 18:05:34.660 2014] Memory: ECC disabled
[Thu Feb 06 18:05:34.660 2014] DRAM:  1 GiB
[Thu Feb 06 18:05:34.677 2014] MMC:   zynq_sdhci: 0
[Thu Feb 06 18:05:34.677 2014] SF: Detected N25Q128A with page size 64 KiB, total 16 MiB
[Thu Feb 06 18:05:34.708 2014] *** Warning - bad CRC, using default environment
[Thu Feb 06 18:05:34.708 2014] 
[Thu Feb 06 18:05:34.708 2014] In:    serial
[Thu Feb 06 18:05:34.708 2014] Out:   serial
[Thu Feb 06 18:05:34.708 2014] Err:   serial
[Thu Feb 06 18:05:34.708 2014] U-BOOT for Xilinx-ZC702-14.7
[Thu Feb 06 18:05:34.708 2014] 
[Thu Feb 06 18:05:34.708 2014] 
[Thu Feb 06 18:05:34.708 2014] SF: Detected N25Q128A with page size 64 KiB, total 16 MiB
[Thu Feb 06 18:05:36.285 2014] SF: 11010048 bytes @ 0x520000 Read: OK
[Thu Feb 06 18:05:36.285 2014] ## Loading kernel from FIT Image at 01000000 ...
[Thu Feb 06 18:05:36.285 2014]    Using 'conf@1' configuration
[Thu Feb 06 18:05:36.285 2014]    Trying 'kernel@1' kernel subimage
[Thu Feb 06 18:05:36.285 2014]      Description:  PetaLinux Kernel
[Thu Feb 06 18:05:36.285 2014]      Type:         Kernel Image
[Thu Feb 06 18:05:36.285 2014]      Compression:  gzip compressed
[Thu Feb 06 18:05:36.285 2014]      Data Start:   0x010000f0
[Thu Feb 06 18:05:36.285 2014]      Data Size:    4997719 Bytes = 4.8 MiB
[Thu Feb 06 18:05:36.285 2014]      Architecture: ARM
[Thu Feb 06 18:05:36.285 2014]      OS:           Linux
[Thu Feb 06 18:05:36.285 2014]      Load Address: 0x00008000
[Thu Feb 06 18:05:36.285 2014]      Entry Point:  0x00008000
[Thu Feb 06 18:05:36.285 2014]      Hash algo:    crc32
[Thu Feb 06 18:05:36.285 2014]      Hash value:   db7d8248
[Thu Feb 06 18:05:36.285 2014]    Verifying Hash Integrity ... crc32+ OK
[Thu Feb 06 18:05:36.383 2014] ## Loading fdt from FIT Image at 01000000 ...
[Thu Feb 06 18:05:36.383 2014]    Using 'conf@1' configuration
[Thu Feb 06 18:05:36.383 2014]    Trying 'fdt@1' fdt subimage
[Thu Feb 06 18:05:36.383 2014]      Description:  Flattened Device Tree blob
[Thu Feb 06 18:05:36.383 2014]      Type:         Flat Device Tree
[Thu Feb 06 18:05:36.383 2014]      Compression:  uncompressed
[Thu Feb 06 18:05:36.383 2014]      Data Start:   0x014c442c
[Thu Feb 06 18:05:36.383 2014]      Data Size:    11161 Bytes = 10.9 KiB
[Thu Feb 06 18:05:36.383 2014]      Architecture: ARM
[Thu Feb 06 18:05:36.383 2014]      Hash algo:    crc32
[Thu Feb 06 18:05:36.383 2014]      Hash value:   8aee0d02
[Thu Feb 06 18:05:36.383 2014]      Hash algo:    sha1
[Thu Feb 06 18:05:36.383 2014]      Hash value:   266e39ed71a93229a26f0cf7e9f5317b64c2e407
[Thu Feb 06 18:05:36.383 2014]    Verifying Hash Integrity ... crc32+ sha1+ OK
[Thu Feb 06 18:05:36.387 2014]    Booting using the fdt blob at 0x14c442c
[Thu Feb 06 18:05:36.387 2014]    Uncompressing Kernel Image ... OK
[Thu Feb 06 18:05:36.782 2014]    Loading Device Tree to 07ffa000, end 07fffb98 ... OK
[Thu Feb 06 18:05:36.782 2014] 
[Thu Feb 06 18:05:36.782 2014] Starting kernel ...
[Thu Feb 06 18:05:36.782 2014] 
[Thu Feb 06 18:05:37.570 2014] INIT: version 2.88 booting
[Thu Feb 06 18:05:37.867 2014] Starting Bootlog daemon: bootlogd.
[Thu Feb 06 18:05:37.910 2014] Creating /dev/flash/* device nodes
.
.   
.

Is there any role of bootloader after the lines " Starting Kernel ... above?
Or the bootloader is always active occupying some memory and CPU resources?

If it does remain active, then it makes sense to have a simpler bootloader for fast booting. Just a guess though?

Best Answer

No I do not believe there is anything further that the bootloader is responsible for, once it hands off control to the Linux Kernel, which then boots up, probing the hardware itself, and starting up all the services that are configured to do so.

If you take a look at the Linux From Scratch project (LFS), specifically the section on "8.4. Using GRUB to Set Up the Boot Process". Taking a look at a basic GRUB config file:

$ cat /boot/grub/grub.cfg
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5

insmod ext2
set root=(hd0,2)

menuentry "GNU/Linux, Linux 3.13.3-lfs-7.5" {
        linux   /boot/vmlinuz-3.13.3-lfs-7.5 root=/dev/sda2 ro
}

Notice the linux ... line? That's loading the Linux kernel. When GRUB invokes that line, it's essentially done.

Does it continue to run?

No GRUB does not persist beyond performing it's job of loading the Linux kernel. Once it's done it frees up any RAM that it was consuming while it was executing.

Related Question