O primeiro passo para
desenvolver um bootloader é ter um kernel para ser carregado, mas aí
temos o velho problema do ovo e da galinha, porque sem o bootloader
também não temos como desenvolver o kernel.
A solução mais simples é implementar um kernel simplíssimo que sirva somente para testar o funcionamento do bootloader, Fiz isto escrevendo um código de 10 linhas em Assembly e montei como binário no NASM. Dei-lhe o nome de pkernel, de pico-kernel (1 milhão de vezes menor que o microkernel, ou seja minúsculo).
O pkernel recebe o segmento de vídeo através de AX durante o boot e o usa para acessar a memória de vídeo diretamente, onde ele “roda” um caractere na coluna 70. Na verdade se o pkernel for carregado e receber o endereço de vídeo corretamente, entrará em um loop infinito que ficará alterando um caractere na tela.
Tendo um kernel passamos ao desenvolvimento do bootloader, que deve inicialmente verificar os requisitos mínimos para carregar o kernel, como o tipo do processador, se realmente está no Modo Real, o modo de vídeo atual e a quantidade de memória instalada.
Feito isso ele aloca um bloco no heap do programa para ser usado como “espaço de execução” e um buffer intermediário onde é lido o arquivo do kernel.
Como o espaço de execução está acessível como uma variável normal ao bootloader, não seria necessário o uso do buffer, mas posteriormente o kernel será carregado para a memória superior e o bootloader nativamente não pode acessar aquele endereço, o buffer é necessário para ler o arquivo de kernel. Também, as rotinas de manejo de arquivos no TP somente conseguem ler blocos de no máximo 64KB. Portanto já implementei o uso de um buffer desde o início para facilitar posteriormente.
Após o kernel ser lido do arquivo através do buffer e copiado para o ambiente de execução, é feito um salto para ele através de um procedimento simples em Assembly.
Nesse estágio do desenvolvimento o kernel é carregado para a memória convencional e executado ali em Modo Real, sem muita dificuldade.
Depois de tê-lo funcionando revisei o código e criei uma outra versão, que faz a mesma coisa porem melhor organizada.
Download dos fontes e binários:
A solução mais simples é implementar um kernel simplíssimo que sirva somente para testar o funcionamento do bootloader, Fiz isto escrevendo um código de 10 linhas em Assembly e montei como binário no NASM. Dei-lhe o nome de pkernel, de pico-kernel (1 milhão de vezes menor que o microkernel, ou seja minúsculo).
O pkernel recebe o segmento de vídeo através de AX durante o boot e o usa para acessar a memória de vídeo diretamente, onde ele “roda” um caractere na coluna 70. Na verdade se o pkernel for carregado e receber o endereço de vídeo corretamente, entrará em um loop infinito que ficará alterando um caractere na tela.
Tendo um kernel passamos ao desenvolvimento do bootloader, que deve inicialmente verificar os requisitos mínimos para carregar o kernel, como o tipo do processador, se realmente está no Modo Real, o modo de vídeo atual e a quantidade de memória instalada.
Feito isso ele aloca um bloco no heap do programa para ser usado como “espaço de execução” e um buffer intermediário onde é lido o arquivo do kernel.
Como o espaço de execução está acessível como uma variável normal ao bootloader, não seria necessário o uso do buffer, mas posteriormente o kernel será carregado para a memória superior e o bootloader nativamente não pode acessar aquele endereço, o buffer é necessário para ler o arquivo de kernel. Também, as rotinas de manejo de arquivos no TP somente conseguem ler blocos de no máximo 64KB. Portanto já implementei o uso de um buffer desde o início para facilitar posteriormente.
Após o kernel ser lido do arquivo através do buffer e copiado para o ambiente de execução, é feito um salto para ele através de um procedimento simples em Assembly.
Nesse estágio do desenvolvimento o kernel é carregado para a memória convencional e executado ali em Modo Real, sem muita dificuldade.
Depois de tê-lo funcionando revisei o código e criei uma outra versão, que faz a mesma coisa porem melhor organizada.
Download dos fontes e binários:
- LoadLOS.001 - Versão funcional;
- LoadLOS.002 - Versão reestruturada;
Próximo - Boot, fase 4 - Entrando no Modo Protegido >>
<< Anterior - Boot, fase 2 - Requisitos
Nenhum comentário:
Postar um comentário
Obs.: Após escrever seu comentário, inscreva-se por e-mail para seguir os próximos comentários. Ou assine a postagem de comentários (Atom).