01 - Hardware e Firmware

O entendimento profundo do sistema operacional Linux exige, antes de qualquer análise de software, a compreensão milimétrica da camada física (hardware) e da camada de microcódigo de baixo nível (firmware) que preenche o abismo entre os circuitos eletrônicos e as instruções binárias do kernel. Esta pasta serve como o alicerce fundamental de toda a arquitetura de inicialização e controle do sistema, detalhando o exato instante em que a energia elétrica é convertida em lógica digital determinística.

A interação entre o hardware e o firmware dita as regras de como o processador central (CPU) desperta de um estado de inércia completa, como a topologia de barramentos é mapeada e como a integridade dos componentes críticos é validada antes que o controle seja transferido para o gerenciador de boot (bootloader).

1. A Camada do Hardware e a Transição Elétrica-Digital

Todo o ciclo de vida de uma instância operacional Linux começa no domínio da física analógica e da engenharia elétrica. O hardware não possui a capacidade inata de compreender arquivos, partições ou estruturas de dados de alto nível. No momento zero, a máquina opera estritamente sob as leis do eletromagnetismo e da lógica booleana implementada em portas lógicas de silício.

O Despertar do Silício e o Sinal Power Good

Quando o circuito de alimentação é fechado, a Fonte de Alimentação (PSU) realiza a retificação, filtragem e estabilização das tensões elétricas nominais (+3.3V, +5V, +12V). O hardware monitora essas linhas até que alcancem níveis operacionais seguros e livres de transientes severos. Somente após essa estabilização, a fonte emite um sinal digital específico através de uma linha dedicada para a placa-mãe, conhecido como sinal Power Good (ou Power OK).

Sem o sinal Power Good, o chipset da placa-mãe (PCH - Platform Controller Hub ou o equivalente integrado em SoCs modernos) mantém a CPU em um estado perpétuo de Reset elétrico. Isso evita o comportamento errático e a corrupção de dados que ocorreriam se os transistores do processador tentassem chavear estados lógicos com tensões abaixo do limiar operacional (undervoltage).

O Estado Inicial dos Registradores e o Reset Vector

Assim que o sinal Power Good é recebido e o pino de RESET da CPU é desativado (transição de nível lógico baixo para alto), o processador é forçado a entrar em um estado de execução rigidamente predefinido por sua arquitetura microeletrônica. Em processadores da arquitetura x86/x86_64, a CPU inicia em um modo de compatibilidade legado conhecido como Real Mode (Modo Real).

No Modo Real:

• O espaço de endereçamento de memória é severamente limitado a apenas 1 Megabyte ($2^{20}$ bytes).

• Não existem conceitos de memória virtual, paginação ou privilégios de anéis de execução (Ring 0/Ring 3).

• O seletor de código (CS) e o ponteiro de instrução (IP/EIP) são carregados com valores de fábrica hardcoded.

O processador aponta imediatamente para o Reset Vector (Vetor de Reset). Na arquitetura x86, este endereço físico exato é 0xFFFFFFF0, localizado meros 16 bytes abaixo do limite superior de 4 Gigabytes do espaço de endereçamento físico de 32 bits (ou mapeado correspondentemente via decodificação de endereço no topo da memória acessível). Como a memória RAM do sistema (DRAM) está completamente vazia e ainda não foi inicializada pelos controladores de memória, a placa-mãe faz um mapeamento de espelhamento de hardware (hardware mapping), direcionando qualquer requisição de leitura nesse endereço diretamente para o chip de memória não-volátil (Flash ROM) onde reside o firmware da plataforma.

A instrução localizada no Vetor de Reset é invariavelmente um salto incondicional (far jump) para o início real do código do firmware (seja ele BIOS clássico ou UEFI).

2. A Evolução do Firmware da Plataforma

O firmware atua como o tradutor primitivo do sistema. Ele é o primeiro software executado pela CPU e possui acesso irrestrito ao hardware. Historicamente, essa camada passou por uma evolução drástica para acomodar a complexidade dos servidores e estações de trabalho modernos.

BIOS (Basic Input-Output System) Legado

O BIOS tradicional foi projetado no final da década de 1970 para o IBM PC e permaneceu como padrão por mais de três décadas. Ele opera inteiramente no Modo Real de 16 bits. Isso significa que o BIOS tem sérias limitações de desempenho e escalabilidade:

• Acesso Limitado: Incapacidade de acessar diretamente memória RAM acima de 1MB sem alternar temporariamente para modos complexos como o Modo Protegido Não-Documentado (Unreal Mode).

• Interrupções de Hardware: Dependência de vetores de interrupção de software rígidos (como as famosas interrupções INT 10h para vídeo e INT 13h para disco) para realizar operações básicas de I/O.

• Tamanho de Código: Restrições extremas de tamanho de binário, limitadas pela densidade dos chips de ROM da época.

O BIOS realiza o teste físico dos componentes (POST) e busca cegamente um setor específico no disco de boot para carregar o próximo estágio de software, sem qualquer compreensão real sobre sistemas de arquivos complexos.

UEFI (Unified Extensible Firmware Interface) Moderno

Para superar as amarras do BIOS legado, a indústria desenvolveu a especificação UEFI. Diferente do BIOS, a UEFI é essencialmente um sistema operacional miniaturizado e modular que roda nativamente em 32-bit ou 64-bit logo nos estágios iniciais de boot.

A arquitetura UEFI introduz conceitos avançados que redefinem o início do boot no Linux:

• Drivers de Firmware Modulares: A UEFI suporta drivers em bytecode EFI (EBC), permitindo que o firmware entenda nativamente partições de disco (como tabelas GPT) e sistemas de arquivos específicos (como FAT32).

• Execução em Modo Protegido/Longo: O processador abandona o Modo Real quase que imediatamente, operando com gerenciamento de memória completo e acesso a toda a memória RAM disponível no sistema.

• Segurança Nativa (Secure Boot): Introdução de infraestrutura de chaves criptográficas públicas e privadas dentro da própria NVRAM para validar a assinatura digital de binários de boot, impedindo a execução de rootkits e bootkits em nível de firmware.

3. Armazenamento de Estado: CMOS e NVRAM

O firmware não é estático; ele precisa armazenar configurações personalizadas pelo administrador do sistema (como a ordem de prioridade de boot, parâmetros de overclock, configurações de virtualização de hardware AMD-V/Intel VT-x, e chaves do Secure Boot). O armazenamento dessas informações evoluiu em conjunto com a arquitetura do firmware.

A Tecnologia CMOS Histórica

Nos sistemas com BIOS legado, as configurações eram salvas em uma pequena quantidade de memória RAM estática volátil de baixíssimo consumo, integrada ao circuito do relógio de tempo real (RTC - Real Time Clock), chamada popularmente de CMOS. Como a RAM perde seus dados na ausência de energia, a placa-mãe dependia (e muitas vezes ainda depende para o RTC) de uma bateria física de Lítio (geralmente o modelo CR2032). Se a bateria falhar ou for removida, a tensão no circuito cai, os transistores perdem a carga e o CMOS é limpo, revertendo o sistema para os padrões de fábrica de hardware.

A NVRAM Moderna (Non-Volatile RAM)

Nos ecossistemas UEFI modernos, as configurações não são mais armazenadas em circuitos voláteis dependentes de bateria para a retenção de dados. Em vez disso, utiliza-se a NVRAM, que é uma seção dedicada e eletricamente isolada dentro do próprio chip de memória Flash ROM da placa-mãe (SPI Flash).

A NVRAM armazena variáveis EFI persistentes estruturadas. No Linux, essas variáveis são de extrema relevância, pois o kernel expõe essa memória diretamente para o espaço do usuário através do subsistema efivarfs, montado rotineiramente em /sys/firmware/efi/efivars. Isso permite que ferramentas em espaço de usuário (como o efibootmgr) alterem diretamente as variáveis de boot do firmware de dentro do terminal Linux, eliminando a necessidade de reiniciar a máquina para acessar a interface visual de configuração da placa-mãe.

4. Enumeração, Descoberta de Dispositivos e o Mapeamento de I/O

Uma das tarefas mais críticas executadas na fronteira entre Hardware e Firmware é a varredura e inicialização da topologia de barramentos do sistema. O processador precisa descobrir quais periféricos estão conectados à placa-mãe, mapear seus canais de comunicação e preparar o ambiente para que o kernel Linux possa, posteriormente, assumir o controle com seus próprios drivers nativos.

Descobrimento do Barramento PCI/PCIe

O firmware executa um algoritmo de varredura profunda (bus walking) no barramento PCI Express (PCIe). Cada dispositivo conectado ao barramento possui registradores de configuração padronizados que informam ao firmware sua identidade:

• Vendor ID (ID do Fabricante): Um código exclusivo de 16 bits atribuído pela PCI-SIG (ex: 0x10DE para NVIDIA, 0x8086 para Intel).

• Device ID (ID do Dispositivo): Um código de 16 bits definido pelo fabricante para identificar o modelo exato do chip (ex: um modelo específico de controladora de rede ou GPU).

A partir dessas informações, o firmware sabe exatamente a natureza de cada componente de hardware conectado à placa-mãe.

Mapeamento de MMIO e Portas de I/O

Para que a CPU possa enviar comandos e receber dados de dispositivos de hardware (como controladoras SATA, NVMe, placas de rede e adaptadores gráficos), o firmware precisa alocar recursos de endereçamento. Isso é feito principalmente através de duas técnicas estruturais:

1. Port-Mapped I/O (PMIO): Uso de um espaço de endereço separado e instruções assembly específicas da CPU (como IN e OUT no x86). É um método legado e limitado a 64KB de endereços.

2. Memory-Mapped I/O (MMIO): O firmware reserva faixas do espaço de endereçamento da memória RAM do sistema e as atribui diretamente aos registradores físicos dos dispositivos de hardware. Quando a CPU lê ou escreve em um determinado endereço de memória mapeado via MMIO, a requisição é interceptada pelo controlador de memória e desviada através do barramento PCIe para o dispositivo correspondente, em vez de ir para os pentes físicos de DRAM.

O firmware grava essas configurações nos registradores BAR (Base Address Registers) localizados no espaço de configuração PCI de cada dispositivo. Mais tarde, quando o kernel Linux for inicializado, ele lerá essas tabelas criadas pelo firmware para saber exatamente em quais endereços de memória cada componente de hardware está escutando.

5. A Interface de Abstração: Tabelas ACPI

Para evitar que o sistema operacional precise conhecer os detalhes de fiação eletrônica específicos de cada modelo de placa-mãe existente no mercado, o firmware constrói uma interface de abstração de hardware padronizada chamada ACPI (Advanced Configuration and Power Interface).

Durante a fase de inicialização do firmware, ele analisa a topologia física da placa-mãe e constrói dinamicamente na memória RAM uma série de tabelas complexas escritas em uma linguagem de bytecode chamada AML (ACPI Machine Language). Entre as principais tabelas geradas, destacam-se:

• DSDT (Differentiated System Description Table): Contém a descrição principal do hardware da plataforma, incluindo a definição de dispositivos internos, métodos de controle de energia, linhas de interrupção e sensores térmicos.

• SSDT (Secondary System Description Table): Tabelas secundárias que complementam a DSDT, frequentemente descrevendo recursos dinâmicos como estados de energia do processador (P-states e C-states).

• MADT (Multiple APIC Description Table): Informa ao sistema operacional o número exato de núcleos de processamento físicos e lógicos presentes, bem como o mapeamento dos controladores de interrupção avançados (APIC), essencial para o funcionamento do multiprocessamento simétrico (SMP) no Linux.

O kernel Linux possui um interpretador AML nativo integrado em seu subsistema core. Logo no início do boot, o Linux localiza os ponteiros dessas tabelas ACPI na memória física, lê o bytecode fornecido pelo firmware e reconstrói internamente a árvore de dispositivos do sistema. É através da ACPI que o Linux consegue gerenciar eventos de hardware de baixo nível, como o fechamento da tampa de um notebook, a leitura de sensores de temperatura da CPU, a rotação de coolers e o envio de comandos de desligamento e suspensão elétrica (estados S3, S4, S5).

6. O Ponto de Transição: Handover para o Software de Boot

O encerramento do ciclo de execução exclusivo do Firmware se dá no momento do Handover (passagem de bastão). O firmware concluiu com sucesso a verificação do hardware básico, determinou a estabilidade elétrica do sistema, alocou os recursos iniciais de memória e barramentos, e estruturou as tabelas de dados de runtime.

Neste ponto, o firmware consulta suas variáveis de ambiente persistentes (na NVRAM ou CMOS) para determinar qual dispositivo de armazenamento em massa (SSD NVMe, Disco Rígido SATA, Unidade Flash USB ou mesmo uma interface de rede via PXE) foi designado pelo administrador como o dispositivo primário de boot.

O firmware acessa a mídia física de armazenamento, lê os primeiros blocos de dados contendo o código binário do gerenciador de boot (seja o código MBR de 446 bytes ou a imagem binária PE32+ executável da UEFI localizada na Partição de Sistema EFI - ESP) e o copia para um endereço específico de memória RAM.

Por fim, o firmware executa uma instrução de desvio de fluxo (JMP ou uma chamada de função padrão de boot da UEFI), alterando o Ponteiro de Instrução da CPU para apontar exatamente para o início do código do bootloader carregado em RAM. A partir deste microsegundo, o firmware assume um papel secundário de provedor de serviços de runtime e o controle total da CPU é entregue ao software de inicialização que, posteriormente, trará o kernel Linux à vida.