Top Qs
Linha do tempo
Chat
Contexto
Coreboot
Da Wikipédia, a enciclopédia livre
Remove ads
O coreboot, anteriormente conhecido como LinuxBIOS,[4] é um projeto em software livre que visa substituir firmware proprietário (BIOS ou UEFI) encontrado na maioria dos computadores com um firmware leve projetado para executar apenas o número mínimo de tarefas necessárias para carregar e executar um moderno sistema operacional de 32 bits ou 64 bits. Desde coreboot inicializa o hardware direto, é portado para cada chipset e placa-mãe que ele suporta. Como resultado, coreboot está disponível apenas para um número limitado de plataformas de hardware e modelos de placas-mãe. Uma das variantes Coreboot é Libreboot.
 |
 | A tradução deste artigo está abaixo da qualidade média aceitável. (Setembro de 2021) |
Remove ads
Remove ads
História
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),[5] com o objetivo de criar uma BIOS que iria inicializar rápido e tratar os erros de forma inteligente.[6] É 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.[7] CME Group, um grupo de bolsas de futuros, começou a apoiar o projeto coreboot em 2009.[8]
Coreboot foi aceito nos sete anos consecutivos (2007-2014) para o Google Summer of Code.[9][10] Além dos três primeiros modelos, todos os Chromebooks executam Coreboot.[11][12] O código do Das U-Boot foi assimilado para ativar o suporte para processadores baseados no conjunto de instruções ARM.[13]
Remove ads
As plataformas suportadas
Resumir
Perspectiva
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.[14]
Dispositivos pré-carregados com Coreboot ou um de seus derivados incluem Chromebooks baseados em x86,[15] Libreboot X200 e T400 (rebatizado Thinkpad X200 e T400, respectivamente, disponível a partir da Minifree, anteriormente conhecido como Gluglug),[16][17] OLPC XO da iniciativa One Laptop per Child e ThinCan modelos DBE61, DBE62 e DBE63.
Remove ads
Projeto
Resumir
Perspectiva
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[18] 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[19][20]). 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[21] (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
- Estágio Bootblock: prepara para obter acesso ao Flash e procura o estágio ROM para usar
- Estágio Verificação: processo de Root of trust, provendo capacidades de Verified Boot
- Estágio ROM: memória e início do chipset init (um pouco como PEI em UEFI)
- Estágio Post: estagio de finalização da execução em Cache-as-Ram para uma DRAM, carregando o estágio de RAM
- 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)
- 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[22][23], 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.
Remove ads
Desenvolvendo e depurando o coreboot
Resumir
Perspectiva
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,[24], 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[25] um exemplo. Código pode ser construído em, ou baixado para, emuladores BIOS em vez de flashear o dispositivo BIOS.
Remove ads
Payloads
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[26]
- 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[27]
- 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[28]
Remove ads
Variantes
O Libreboot foi estabelecido como uma distribuição de coreboot sem binários blobs proprietários.[29][30] 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.[31]
Endossado pela Free Software Foundation (FSF)[32], o projeto Libreboot possibilitou as modificações necessárias para as variantes completamente livres de alguns laptops ThinkPad, MacBook e Chromebook ARM.[33][34][35]
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.
Remove ads
Ver também
Referências
Leitura adicional
Ligações externas
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads