A Cadeia de Boot do Linux Embarcado

July 30, 2026 · – visitantes

Da última vez, escrevi sobre DFU como uma forma de gravar firmware via USB. Aquele post deixou de lado uma pergunta que merece ser respondida por si só: o que realmente acontece entre apertar o botão de energia e o aparecimento de um prompt de shell? O DFU é apenas um ramal desse caminho, então vale a pena percorrer o caminho inteiro pelo menos uma vez.

As etapas

Desenhada como um fluxograma Mermaid, a cadeia (com o lugar do DFU nela) fica assim:

flowchart TD
    A[Power-on / Reset] --> B[Boot ROM<br/>immutable, on-chip]
    B --> C{Valid image on<br/>boot media?}
    C -->|No / forced| D[ROM recovery mode<br/>UART / USB]
    C -->|Yes| E[SPL<br/>first-stage bootloader]
    E --> F[U-Boot<br/>second-stage bootloader]
    F --> G{Enter DFU?}
    G -->|Yes| H[DFU mode<br/>waiting for firmware over USB]
    G -->|No| I[Load kernel + device tree]
    I --> J[Linux kernel]
    J --> K[Mount root filesystem]
    K --> L[init / systemd]

E renderizada:

Boot ROM

Gravada no silício no momento da fabricação — nada nela pode ser alterado depois disso. Sua única tarefa é encontrar algo inicializável em uma de um pequeno conjunto de mídias de boot (eMMC, SD, flash QSPI, às vezes USB) de acordo com pinos de modo de boot ou eFuses, e saltar para lá. Se não conseguir encontrar nada válido, a maioria dos SoCs recorre, nesse estágio, a um modo mínimo de recuperação via UART ou USB — o primeiríssimo ponto em que é possível se comunicar com o chip.

SPL

Abreviação de Secondary Program Loader (o termo usado pelo U-Boot; outros fabricantes o chamam de FSBL ou algo parecido). Ele roda a partir de uma pequena quantidade de SRAM no próprio chip, antes mesmo de a DRAM ser inicializada, então precisa ser minúsculo. Sua principal tarefa é exatamente essa: inicializar a DRAM e depois carregar nela o próximo estágio — o U-Boot completo.

U-Boot propriamente dito

Esse é o bootloader que a maioria das pessoas tem em mente quando fala em "bootloader". Ele tem drivers, um shell, variáveis de ambiente, suporte a rede e um interpretador de comandos. É também onde o DFU realmente reside — rodar dfu 0 mmc 0 (ou algo parecido) faz o U-Boot entrar em modo DFU em vez de continuar o boot normal, e é esse o modo com o qual o dfu-util conversa do lado do host. Caso contrário, ele carrega a imagem do kernel e o blob da device tree na memória e salta para o kernel.

Kernel e espaço de usuário

O kernel se descomprime, ativa o console, sonda o hardware usando a device tree que recebeu, e monta um sistema de arquivos raiz — geralmente o mesmo cartão eMMC ou SD do qual o bootloader inicializou, às vezes NFS durante o desenvolvimento. Uma vez montado o sistema de arquivos raiz, o kernel passa o controle para o PID 1 — geralmente o systemd em uma imagem construída com o Yocto — e é aí que o "espaço de usuário" realmente começa.

Por que isso importa para o DFU

O DFU só faz sentido quando se vê onde ele se encaixa: é um desvio que o U-Boot pode tomar em vez de carregar o kernel, não algo separado grudado por cima. É também por isso que o DFU não consegue resgatar todos os modos de falha — se a própria boot ROM não conseguir encontrar um SPL válido, você nunca chega ao U-Boot, e passa a depender de qualquer modo de recuperação que a boot ROM ofereça (o que varia bastante entre fabricantes e é um bom tema para outro post).

Leitura adicional

U-Boot: Generic SPL framework — como o SPL é construído e pelo que ele é responsável.
Trusted Firmware-A: Firmware Design — o fluxo de boot multiestágio mais elaborado (BL1/BL2/BL31/BL32/BL33) usado em muitos SoCs Arm modernos com uma cadeia de boot seguro, que fica abaixo do U-Boot nessas plataformas.

Leituras Relacionadas

O Que É um Device Tree? — como o hardware é descrito ao kernel
O Que É DFU? — gravar firmware por USB quando não há outro caminho