Quais são as etapas reais, supondo que você tenha um conjunto de arquivos de cabeçalho c que descrevem os dispositivos mapeados na memória em seu sistema, para fazer o kernel inicial em execução? Eu sei que todo mundo inicializa a partir de um CD/pen drive USB, etc., mas como foi feito esse primeiro bootstrap?
EDIT: Devo salientar que estou falando de dispositivos ARM, na verdade, entendo o básico de carregamento via BIOS em uma máquina típica, mas digamos que estamos falando de um dispositivo personalizado?
Responder1
como foi feito esse primeiro bootstrap?
Construir (escrever e compilar cruzadamente) um programa bootstrap não é tão assustador quanto você parece sugerir.
Devo salientar que estou falando de dispositivos ARM, na verdade, entendo o básico de carregamento via BIOS em uma máquina típica, mas digamos que estamos falando de um dispositivo personalizado?
O BIOS ao qual você se refere é essencialmente uma convenção de PC. (O CP/M também tinha um BIOS, mas não estava necessariamente em memória não volátil.) As CPUs ARM normalmente não possuem nem usam um BIOS.
O processador ARM típico em uso hoje é integrado a periféricos em um único IC denominadoSoC, sistema em um chip. A memória principal, por exemplo, DRAM, e o armazenamento não volátil, por exemplo, flash NAND, são normalmente externos ao SoC para máxima flexibilidade de design. Mas normalmente há uma pequena ROM incorporada (talvez 128 KB) (memória somente leitura) para inicializar os componentes mínimos do sistema para iniciar as operações de inicialização. Uma reinicialização do processador sempre causará a execução desta ROM de inicialização. (Esta ROM é verdadeiramente somente leitura e não pode ser modificada. O código é mascarado no silício durante a fabricação do chip.)
Cada fornecedor de SoC tem seu próprio método de inicialização para carregar e executar o sistema operacional. Alguns usam leitura de hardware por meio de pinos GPIO para determinar a origem do próximo estágio da sequência de bootstrap. Outro fornecedor pode usar uma lista ordenada de memórias e dispositivos para testar um programa de bootstrap. Outra técnica é ramificar para firmware em flash NOR, que pode ser executado diretamente (ou seja, XIP, executado no local).
Um dos problemas de inicializar um sistema que usa DRAM como memória principal é a inicialização do hardware. O controlador de memória DRAM deve ser inicializado antes que o código possa ser carregado na DRAM e executado. Então, onde reside esse código de inicialização, já que não pode estar na memória principal?
Cada fornecedor tem sua própria solução. Alguns exigem que os dados de configuração da memória sejam armazenados em memória não volátil para acesso da ROM de inicialização. Alguns SoCs integraram SRAM (que não requer inicialização como DRAM) para executar um pequeno programa de bootstrap. Alguns SoCs usam flash NOR para manter um programa de inicialização XIP.
Depois que o programa de inicialização tiver inicializado a DRAM, a memória principal poderá ser usada para carregar o próximo estágio de inicialização. Pode ser um utilitário de inicialização sofisticado, como o U-Boot, ou (se o programa de inicialização for capaz) o kernel do Linux. Observe que pode haver vários programas ou estágios de inicialização que foram executados entre a redefinição do processador e a execução do sistema operacional.
Os requisitos para inicializar o kernel Linux ARM são descritos no seguinte documento:http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Versões mais antigas do Linux ARM usavam a lista ATAGs para passar informações básicas de configuração ao kernel. Versões modernas fornecem uma configuração completa da placa usando um binário compilado de uma árvore de dispositivos.
Obviamente, a questão de "como você faz um bootstrap?" não pode ser respondida sem algumas qualificações.
Assim como o BIOS do PC, a ROM de inicialização dos SoCs é proprietária e não é liberada (a menos que você assine um NDA, se for o caso). Mas a maioria dos outros códigos de inicialização são lançados sob GPL ou licença semelhante e podem ser facilmente obtidos.
TERMO ADITIVO
Como você mencionou agora que está usando um Zynq 7000 (que usa um SoC Xilinx), o Xilinx tem um tutorial em vídeo sobreComo construir uma imagem de inicialização do Linux.
Esse vídeo confirma o que já escrevi:
1. O Xilinx SoC possui uma ROM de inicialização incorporada (que é tecnicamente o primeiro estágio, mas é mais frequentemente ignorado ou descrito como estágio zero).
2. Existem "pinos de modo" para especificar a fonte do programa de inicialização para o próximo estágio.
3. A ROM de inicialização carrega um programa de bootstrap (que é tecnicamente o segundo estágio, mas geralmente descrito como “primeiro”), chamado FSBL, na SRAM incorporada. Este programa inicializa a DRAM e carrega o próximo estágio, U-Boot.
4. O U-Boot é executado a partir da DRAM e carrega o kernel do Linux.
O vídeo demonstra que o código-fonte do FSBL pode ser baixado do site Xilinx e compilado cruzadamente em algumas etapas. Não há"truque"como você alega. A construção é uma configuração direta e compilação cruzada, que considero mais simples/fácil do que o pacote de aplicativos típico.
Talvez sua confusão seja baseada na ambigüidade da mídia de inicialização, ou seja, a(s) fonte(s) das imagens de inicialização não foram especificadas. O vídeo menciona NAND flash e SDcard como possíveis dispositivos de inicialização.
A ROM de inicialização é direcionada para ler a imagem FSBL de uma mídia de origem configurada pelos pinos de modo.
O FSBL (se for como outros bootstraps que usei) foi criado para ler o U-Boot a partir de uma mídia de origem configurada. Não há alternativa de tempo de execução.
O U-Boot tenta fazer jus ao seu nome (“universal”) e pode ser configurado (usando variáveis de ambiente) para carregar imagens (e scripts) de vários dispositivos. Há também a opção interativa.
Veja também o wiki Xilinx emZynqLinux, que declara que "informações completas sobre a inicialização do Zynq podem ser encontradas noManual de Referência Técnica".