This translation is older than the original page and might be outdated. See what has changed.

FIXME This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)

O carregador de inicialização (Bootloader)

O Bootloader é um software executado sempre que o dispositivo de hardware é ligado. É um código de máquina executável e, portanto, ARQUITETURA-especifica. É bastante específico do dispositivo, porque sua principal tarefa é inicializar todos os detalhes de hardware de baixo nível. O carregador de inicialização pode estar contido em um EEPROM (raramente) ou diretamente no armazenamento flash (mais comum).

Sendo um software, o gerenciador de inicialização é considerado parte do firmware, mas o gerenciador de inicialização não faz parte do OpenWrt!
Somente em ocasiões raras as mudanças no configurações do carregador de inicialização ou o código do carregador de inicialização é necessário para inicializar/instalar o OpenWrt
Existem vários gerenciadores de inicialização sob diversas licença(s) de software

A principal função do carregador de inicialização é inicializar o hardware, transmitir uma abstração do hardware inicializado, uma descrição do hardware e executar o Kernel. (Um exemplo técnico muito bom pode ser visto aqui. (Deadlink - encontre outra fonte ou outro exemplo FIXME) Depois disso, o carregador de inicialização está pronto e não é mais necessário na memória. A maioria dos gerenciadores de inicialização oferece Funções adicionais.

Não é. Não é necessário um carregador de inicialização para inicializar o Linux. O uso de um (ou vários) gerenciadores de inicialização seguidos para carregar em cadeia (ou bootstrap) um Kernel não é uma necessidade categórica, é apenas um método muito astuto para iniciar um sistema operacional. A principal vantagem do OpenWrt é que a existência de um gerenciador de inicialização oferece aos usuários e desenvolvedores possibilidades adicionais para restaurar um dispositivo.

Alguns gerenciadores de inicialização ou implementação de gerenciadores de inicialização universais vêm com algumas limitações implementadas pelo OEM, como:

  • uma limitação deliberada do tamanho do kernel/firmware
  • fazer o carregador de inicialização esperar um certo formato de firmware exótico
  • incapacidade do gerenciador de inicialização de executar o ELF no formato binário
  • a necessidade de algum “valor mágico” obscuro estar presente e corrigir
  • O que você disser

As razões são variáveis, desde a simples inaptidão dos criadores até a sabotagem voluntária das tentativas dos usuários de executar o software livre em sua própria propriedade.

O carregador de inicialização pode ser mais ou menos sofisticado e não oferece muitas funções adicionais. Em muitas situações, funções adicionais dariam ao usuário uma enorme vantagem; portanto, a maioria dos gerenciadores de inicialização os oferece, como:

  • Novo firmware flash, consulte generic.flashing
  • O carregador de inicialização pode validar dados no armazenamento flash e, por exemplo, se o firmware falhar na aprovação de um CRC, o gerenciador de inicialização presumiria que o firmware está corrompido e aguardaria o upload de um novo firmware pela rede. Claro, isso também significa que toda vez que você altera algo no flash, é necessário atualizar esse valor de CRC ...
  • Isso também pode ser acionado configurando uma variável de espera de inicialização ou por um comando executado no console serial
  • Um CLI (aka console serial), que geralmente pode ser acessado somente através da porta serial. Existem várias maneiras de acessar o console serial na porta no sistema de destino, como o uso de um servidor de terminal, mas a maneira mais comum é conectá-la a uma porta serial no host. Além disso, você precisará de um programa de emulação de terminal no sistema host, como cu ou kermit.
  • Depois que o gerenciador de inicialização tiver cumprido sua função principal - carregar o Kernel em cadeia - ele não será mais executado. Portanto, para brincar com ele, é necessário fazer o login antes de carregar o Kernel e você também pode impedir o carregamento do Kernel, ou seja, para parar o processo de inicialização.
  • Inicializar a partir do USB
  • Como o Kernel requer o módulokmod-fs-ext4 para ler/gravar em um sistema de arquivos EXT3, portanto, um carregador de inicialização exige que esse módulo faça o mesmo. GRUB2 tem essa funcionalidade implementada, portanto, com ela, você pode configurar comodamente suas opções de inicialização e também atualizar e manter seu sistema operacional. Os carregadores de inicialização leves que usamos com o OpenWrt geralmente não possuem essa funcionalidade. Mas veja flash.layout para referência adicional. Uma exceção é a implementação U-Boot do dockstar. Ele não apenas inicializa o USB (como todo o restante do hardware), mas também utiliza o USB e também entende o sistema de arquivos EXT2. Assim, o dockstar pode ser inicializado diretamente de um disco rígido/pendrive formatado em ext2 conectado a qualquer uma de suas portas USB.
  • Inicialização pela rede funcionalidade via BOOTP ou PXE ou DHCP ou NFS ou TFTP

processo de inicialização deve fornecer uma descrição mais detalhada de todo o procedimento de inicialização. O gerenciador de inicialização é o começo.

Comparação de carregadores de boot

Por favor, use templates para criar e manter esses artigos. ATM são quase sem manutenção, sem estrutura e quase inúteis

An embedded bootloader fulfills the same functionality as the BIOS plus GNU GRUB together on a PC.

  • BIOS proprietary the BIOS of your PC is nothing else but a bootloader!
  • UEFI proprietary successor want-to-be of the BIOS
  • coreboot GPLv2 successor of the BIOS, alternative to UEFI based on the Linux kernel;
    support for x86, x86-64 and ARM. There is no MIPS support.
    Coreboot does only “a little bit of hardware initialization”
  • GNU GRUB GPLv2
  • Das U-Boot GPLv2 arguably the richest, most flexible, and most actively developed FOSS bootloader available
  • RedBoot mod GPL
  • CFE BSD like by Broadcom; the orange color means, the OEM is not obliged to deliver the source code
  • Adam2 proprietary for AR7/UR8
    • pspboot proprietary the only slightly compatible successor of Adam2.
  • brnboot unknown sometimes called AMAZON Loader.
  • bootbase unknown used by the ZyXEL Prestige 660HW-xx and Prestige 660M-xx devices (and probably other ZyXEL products). http://www.ixo.de/info/zyxel_uclinux/
  • jboot unknown
  • myloader unknown
  • pp_boot unknown
  • yamon unknown by Imagination Technology; the Linux kernel can only be booted when it is in SREC format.
  • Breed - Breed booatloader
  • VxWorks' own bootloader - most Atheros devices (There is a description of the basic workings on the Netgear WGT624 page.)
  • NetBoot - the standard loader in DWL7100AP allows to boot firmware image via network from TFTP server direct to RAM
  • ThreadX - D-Link uses OS called ThreadX on lowend 1MiB Flash storage & 8MiB RAM models. They have custom boot loader that doesn't output anything sensible to serial port but does have recovery mode so you can upload firmware using browser.
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2020/10/24 22:15
  • by malves