Como um carregador de inicialização e um kernel interagem depois que o kernel é carregado na memória?

Question

Estou um pouco confuso sobre o papel do bootloader e sua interação com o kernel, especialmente quando se fala de ARM Llnux. Depois que o Kernel é carregado na RAM, existe algum trabalho para o gerenciador de inicialização? Por exemplo, veja as mensagens de log aqui:

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
.
.   
.

Existe algum papel do bootloader após as linhas " Starting Kernel ... acima? Ou o bootloader está sempre ativo ocupando alguns recursos de memória e CPU?

Se ele permanecer ativo, faz sentido ter um gerenciador de inicialização mais simples para inicialização rápida. Apenas um palpite embora?

    

Answer 1

Não, eu não acredito que exista algo mais pelo qual o gerenciador de inicialização seja responsável, uma vez que ele transfere o controle para o Kernel Linux, que então inicializa, sondando o próprio hardware e iniciando todos os serviços configurados para fazer então.

Se você der uma olhada no projeto Linux From Scratch (LFS) , especificamente na seção "< href="http://www.linuxfromscratch.org/lfs/view/stable/chapter08/grub.html"> 8.4 Usando o GRUB para configurar o processo de inicialização ". Dando uma olhada no arquivo de configuração básico do GRUB:

$ 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
}

Observe a linha linux ... ? Isso está carregando o kernel do Linux. Quando o GRUB invoca essa linha, basicamente é feito.

Ele continua sendo executado?

Nenhum GRUB não persiste além de executar seu trabalho de carregar o kernel do Linux. Uma vez feito isso, libera qualquer RAM que estivesse consumindo enquanto estava sendo executada.

    

Answer 2

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.
...

LEIAME do U-Boot

Então, nada de u-boot permanecerá após o boot do kernel.