Coreboot

O projeto coreboot começou no inverno de 1999 no Laboratório de Computação Avançada em Laboratório Nacional de Los Alamos (LANL), com o objetivo de criar uma BIOS que iria inicializar rápido e tratar os erros de forma inteligente. É licenciado sob os termos da GNU General Public License (GPL). Principais contribuintes incluem LANL, SiS, AMD, Coresystems e Linux Networx, Inc, bem como fornecedores de placas-mães MSI, Gigabyte e Tyan, que oferecem coreboot ao lado de sua BIOS padrão ou fornecer as especificações dos interfaces de hardware para algumas das suas placas-mães. Google parcialmente patrocinou o projeto coreboot. CME Group, um grupo de bolsas de futuros, começou a apoiar o projeto coreboot em 2009.

Coreboot foi aceito nos sete anos consecutivos (2007-2014) para o Google Summer of Code. Além dos três primeiros modelos, todos os Chromebooks executam Coreboot. O código do Das U-Boot foi assimilado para ativar o suporte para processadores baseados no conjunto de instruções ARM.

Arquiteturas de CPU suportadas pelo coreboot incluem IA-32, x86-64, ARM, ARM64, MIPS e RISC-V. Plataformas system-on-a-chip (SOC) suportadas incluem AMD Geode, começando com o processador Geode GX desenvolvido para o OLPC. Artec Group adicionou suporte Geode LX para a sua ThinCan modelo DBE61; que o código foi adotado pela AMD e melhorado para o OLPC depois que foi atualizado para a plataforma Geode LX, e é desenvolvido pela comunidade coreboot para suportar outras variantes Geode. Coreboot pode ser flashear em uma plataforma Geode usando Flashrom.

A partir desse desenvolvimento inicial em plataformas baseadas AMD Geode, suporte coreboot foi estendido para muitos processadores e chipsets AMD. A lista inclui processador Família 0Fh e 10h (core K8), e recentemente família 14h (núcleo Bobcat, Fusion APU). Suporte Coreboot também se estende aos chipsets AMD: RS690, RS7xx, SB600, e SB8xx.

AMD Generic Encapsulated Software Architecture (AGESA) - uma inicialização de protocolo pelo qual os dispositivos do sistema das placas-mâes AMD64 estão initializando - era código aberto no início de 2011, com o objetivo de fornecer a funcionalidade necessária para a inicialização do sistema coreboot em hardware AMD64.

Dispositivos pré-carregados com Coreboot ou um de seus derivados incluem Chromebooks baseados em x86, Libreboot X200 e T400 (rebatizado Thinkpad X200 e T400, respectivamente, disponível a partir da Minifree, anteriormente conhecido como Gluglug), OLPC XO da iniciativa One Laptop per Child e ThinCan modelos DBE61, DBE62 e DBE63.

Coreboot normalmente carrega um kernel Linux, mas pode carregar qualquer outro executável ELF stand-alone, como iPXE, gPXE ou Etherboot que pode inicializar um kernel Linux através de uma rede, ou SeaBIOS que podem carregar um kernel Linux, Microsoft Windows 2000 e posterior, e BSDs (anteriormente, o Windows 2000/XP e suporte a OpenBSD foi fornecida por ADLO). Coreboot também pode carregar um kernel a partir de qualquer dispositivo compatível, como Myrinet, Quadrics, ou interconexões SCI de cluster. Iniciando outros kernels diretamente também é possível, como o kernel do Plan 9. Em vez de carregar um kernel diretamente, coreboot pode passar o controle para um carregador de inicialização dedicado, como uma versão compativel com coreboot o GNU GRUB 2.

Coreboot é escrito principalmente em C, com uma pequena quantidade de código em assembly. Escolhendo C como linguagem de programação principal por ser fácil auditar o código, o que resulta em maior segurança. O código fonte é liberado sob a licença GNU GPL versão 2.

Coreboot executa a quantidade mínima absoluta de inicialização de hardware, em seguida, passa o controle para o sistema operacional. Como resultado, não existe um código coreboot executando uma vez que o sistema operacional assumiu o controle; em particular, System Management Mode (SMM) pode ser suportado a partir do Driver SMMSTORE. Uma característica do coreboot é que a versão x86 é executado em modo 32-bits depois de executar apenas dez instruções (quase todos as outras BIOS x86 executam exclusivamente em modo 16-bits). Isto é semelhante ao moderno firmware UEFI, que é usado em hardware PC mais recente.

Por si só, coreboot não fornece serviços de chamadas da BIOS. O SeaBIOS payload pode ser usado para fornecer chamadas de BIOS, e assim, permitir que coreboot carregue sistemas operacionais que necessitam desses serviços, como o Windows 2000/XP/Vista/7 e BSDs. No entanto, sistemas operacionais mais modernos acessam o hardware de uma outra maneira e usam apenas as chamadas da BIOS durante a inicialização e como um mecanismo de retorno.

Estágios do Coreboot

1. Estágio Bootblock: prepara para obter acesso ao Flash e procura o estágio ROM para usar
2. Estágio Verificação: processo de Root of trust, provendo capacidades de Verified Boot
3. Estágio ROM: memória e início do chipset init (um pouco como PEI em UEFI)
4. Estágio Post: estagio de finalização da execução em Cache-as-Ram para uma DRAM, carregando o estágio de RAM
5. Estágio RAM: enumeração de dispositivos e atribuição de recursos, criação de tabelas ACPI, manipulador SMM (um pouco como o estágio DXE no EFI)
6. Payload: software independente que realiza a função de Boot do sistema operacional

Inicialização da plataforma (Silicon Init)

Uma das partes mais polêmicas é a inicialização da plataforma. Em hardwares atuais, algumas documentações e dados não são completamente acessíveis ao público. Para isto, é necessário usar componentes proprietários fornecidos pela própria fabricante, sendo os Blobs Binários Proprietários.

O Intel FSP é um blob binário que fornece as informações necessárias para a inicialização de componentes da plataforma, sendo obrigatório em processadores da Intel recentes. Este contém uma abstração geral de acesso aos registradores e inicialização de componentes da Intel. O coreboot implementa um wrapper usando alguns pedaços de códigos do projeto EDK2.

Inicializando DRAM

O hardware mais difícil que o coreboot inicializa é os controladores DRAM e DRAM. Em alguns casos, a documentação técnica sobre este assunto é NDA restrito ou indisponível. Inicialização RAM é particularmente difícil, porque antes da RAM estar inicializada não pode ser usado. Portanto, para inicializar controladores de DRAM e DRAM, o código de inicialização pode ter somente os registros de propósito geral da CPU ou Cache-as-RAM como armazenamento temporário.

romcc, um compilador C que utiliza registos em vez de RAM, facilita a tarefa. Usando o romcc, é relativamente fácil fazer acessos SMBus às ROMs SPD das DRAM DIMMs, que permite que a RAM seja usada.

Com os processadores x86 mais recentes, o cache do processador pode ser usado como RAM até que a DRAM seja inicializada. O cache do processador também tem de ser inicializado no modo Cache-as-RAM, mas isso requer menos instruções do que inicializar a DRAM. Além disso, a inicialização do modo Cache-as-RAM é específica para arquiteturas de CPU, portanto mais genérica que a inicialização DRAM, que é específica para cada chipset e placa mãe.

Na maioria das plataformas atuais é necessário o uso de um blob binário MRC, sendo este o responsável pelo treinamento e inicialização da RAM, também necessário para a inicialização de dispositivos PCIe, como GPUs discretas.

Algumas plataformas da Intel como Sandybridge e Ivybridge podem inicializar com o Coreboot Native RAM Init, que foi escrito utilizando técnicas de engenharia reversa.

Desde coreboot inicializar o hardware, ele deve ser portado para cada chipset e placa-mãe que suporta. Antes de inicializar a RAM, o coreboot inicializa a porta serial (somente cache de endereçamento e registros), para que ele possa enviar texto de depuração para um terminal conectado. Ele também pode enviar códigos de byte para a porta 0x80 que são exibidos em um display de dois dígitos hexadecimais de uma placa POST conectada.

Outro suporte para portar é o produto comercial "RD1 BIOS Savior" da IOSS,, que é uma combinação de dois dispositivos de memória de inicialização que se conecta ao soquete de memória de inicialização e tem um comutador manual para selecionar entre os dois dispositivos. O computador pode inicializar a partir de um dispositivo e, em seguida, o switch pode ser alternado para permitir que o computador reprogramar ou "flash" o segundo dispositivo. Uma alternativa mais cara é um programador EPROM/flash externo.

Existem também emuladores de CPU que substituem a CPU ou se conectam através de uma porta JTAG, sendo o Sage SmartProbe um exemplo. Código pode ser construído em, ou baixado para, emuladores BIOS em vez de flashear o dispositivo BIOS.

O Coreboot pode carregar um payload, que pode ser escrita usando a biblioteca auxiliar do libpayload. Payloads existentes incluem o seguinte:

• SeaBIOS, uma pequena implementação de x86 BIOS, escrito C principalmente em 16-bit usando GNU C compiler
• EDK2, uma implementação da comunidade Tianocore livre e de código aberto da especificação UEFI
• OpenBIOS, uma implementação livre e de código aberto do Open Firmware. Abandonado atualmente
• GNU GRUB, um bootloader universal do projeto GNU, apoiado pela Free Software Foudantion
• FILO, um bootloader com suporte a boot USB
• Etherboot, ele pode inicializar um sistema operacional através da rede
• gPXE/iPXE, sucessor de Etherboot, funciona quando executado sob SeaBIOS
• Depthcharge é usado pelo Google para Chrome OS
• U-Boot, um bootloader focado em dispositivos embarcados
• LinuxBoot, uma alternativa a firmware UEFI, onde o Kernel Linux substitui o estágio de Drivers (DXE) juntamente com o estágio de Boot (BDS) utilizando o Kexec
• Um ramo do Das U-Boot foi usado pelo Google para Chromium OS no passado

O Libreboot foi estabelecido como uma distribuição de coreboot sem binários blobs proprietários. Libreboot não é um fork direto do coreboot; Em vez disso, trata-se de um esforço paralelo que trabalha em estreita colaboração e re-bases de vez em quando no mais recente coreboot como o fornecedor upstream, com patches misturados upstream sempre que possível. Além de remover o software proprietário, o libreboot também tenta tornar o coreboot fácil de usar, automatizando os processos de construção e instalação.

Endossado pela Free Software Foundation (FSF), o projeto Libreboot possibilitou as modificações necessárias para as variantes completamente livres de alguns laptops ThinkPad, MacBook e Chromebook ARM.

O Heads é uma distribuição coreboot focada em segurança e integridade do hardware utilizando técnicas modernas de Root Of Trust ao nível de firmware, tendo versões apenas para certos notebooks Thinkpads e Purism.

• Open BIOSes for Linux, por Peter Seebach
• LinuxBIOS ready to go mainstream, por Bruce Byfield
• First desktop motherboard supported by LinuxBIOS: GIGABYTE M57SLI-S4, por Brandon Howard
• Video recording of Ron Minnich's LinuxBIOS talk from FOSDEM 2007
• Coreboot Your Service, Linux Journal, Outubro de 2009
• Coreboot Documentation, Documentação oficial do Coreboot