Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

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.

share|improve this answer
    
Actually, linux loads the kernel. The implied boot actually does the hand off. –  Ricky Beam Mar 8 at 9:31
    
If you look in a real (i.e. autogenerated) grub.cfg you'll notice that it loads the initrd, too. –  strugee Mar 8 at 9:48
1  
@Ricky GRUB loads and executes the kernel image. However most of the Linux kernel image is compressed, the part that GRUB loads basically decompresses and executes the rest. There are multiple stages to Linux kernel startup, each loading the next. It is correct to say that GRUB loads the overall kernel. –  Graeme Mar 8 at 11:27
    
Thanks guys, I was trying to keep it short and sweet and not confuse the OP. Bottom line is what I said 8-). If we wanted to confuse him we could explain the entire mechanics which though are correct seemed unnecessary in answering the basic Q he/she had. –  slm Mar 8 at 12:42
add comment
More About U-Boot Image Types:
------------------------------

U-Boot supports the following image types:

   "Standalone Programs" are directly runnable in the environment
        provided by U-Boot; it is expected that (if they behave
        well) you can continue to work in U-Boot after return from
        the Standalone Program.
   "OS Kernel Images" are usually images of some Embedded OS which
        will take over control completely. Usually these programs
        will install their own set of exception handlers, device
        drivers, set up the MMU, etc. - this means, that you cannot
        expect to re-enter U-Boot except by resetting the CPU.
...

U-Boot README

So, no, nothing of u-boot will remain after the kernel is booted.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.