O conflito entre o que você diz sobre o bootloader estar na ROM e estar no MBR talvez se deva ao bootloader ser usado por qualquer código que funcione como fazer o mínimo para carregar no código para fazer o computador fazer algo útil, incluindo cada estado em uma inicialização de várias etapas.
Assim, o estado inicial é ter um computador, que é um dispositivo programável, mas não sabe como carregar o software a ser executado porque ele não tem nenhum software carregado. (E, portanto, o boot de extrai-se de seus bootstraps ).
Historicamente, havia algumas soluções diferentes para esse problema, mas hoje em dia começamos com algum código na ROM (na maioria das vezes estritamente EEPROM), o que é suficiente para ver diferentes dispositivos e testá-los encontra um que é inicializável.
(É por isso que muitos sistemas arrancarão um CD ou DVD se você colocar um disco do instalador do SO dentro e fora do disco rígido, o BIOS [o código na ROM, incluindo o código do qual estamos falando e algumas outras coisas de baixo nível que começam as coisas] estão definidas para olhar para a unidade de CD / DVD primeiro, em seguida, em um disco rígido, se não encontrar nada, tweakers muitas vezes configurá-lo para ignorar a unidade de CD / DVD, a menos que manualmente solicitado para que não perca tempo criando um disco não inicializável que foi deixado na unidade).
Este código na ROM é às vezes chamado bootloader .
Quando ele sabe qual unidade observar, ele irá olhar para o MBR, que contém informações sobre as principais parções - como você pode olhar posteriormente em / ou / boot ou C: / (em um sistema Windows) se você não tiver sequer sei qual parte do disco era qual partição, não importa como cada partição foi montada? - e algum código com instruções adicionais para executar. (Incidentalmente, isso explica por que alguns sistemas operacionais - como o Windows - só podem ser instalados em uma partição primária, os detalhes dessas partições estão no MBR e essa é a única informação de partição que o gerenciador de inicialização leu e não carrega o EBR para aprenda sobre as partições lógicas, no que diz respeito a essas partições ainda não existirem).
Esse código executável é também chamado bootloader . Quando nos preocupamos em distinguir entre isso e o que vem a seguir, ele é chamado de gerenciador de inicialização primário (a menos que estejamos fazendo nosso próprio BIOS, ignoramos o bit da ROM como fora de nosso controle).
Esse código será muito pequeno, pois há apenas cerca de 400 bytes para ele se encaixar, então, para fazer qualquer coisa real, ele carregará mais alguns códigos, que podem ser maiores, já que não precisa lidar com essa restrição.
Este código é também conhecido como bootloader . Quando nos preocupamos em distinguir entre este e o que veio antes, ele é chamado de gerenciador de inicialização secundário .
Esse código talvez seja o estágio final do processo. Seria se você tivesse apenas um sistema operacional ou se todos os sistemas operacionais em seu sistema usassem carregadores de inicialização compatíveis (por exemplo, duas instalações do Linux que usam o GRUB, portanto, o que o GRUB foi atualizado pode oferecer para inicializar em qualquer um deles) apresenta menus (se desejado) carrega em um kernel e passa o controle sobre o sistema operacional.
No caso em que você tem um sistema operacional que não é compatível com esse gerenciador de inicialização, ele pode ser carregado em cadeia. Por exemplo. se você tiver o Windows e o Linux na mesma máquina, a opção GRUB para carregar o Windows carregará, de fato, outro carregador de inicialização que só sabe sobre a (s) instalação (ões) do Windows e passará para ele. Embora este tenha sido um estágio terciário no processo, ele ainda é chamado de gerenciador de inicialização secundário , porque não sabe nem se importa que haja outro carregador de inicialização secundário em execução antes dele. Este também seria o caso de uma instalação do Linux que usasse um tipo diferente de bootloader secundário.
Principalmente quando falamos sobre o bootloader em termos de Linux, geralmente não queremos dizer o código da ROM (não é parte do Linux ou alterado pela instalação do Linux). Quando fazemos update-grub , estamos alterando o carregador de inicialização secundário, que normalmente está em / boot de uma instalação específica. Quando fazemos install-grub , estamos mudando e também o bootloader primário no MBR, para que ele tenha código suficiente para saber onde / boot (talvez iniciando um RAID de software) e carregue e execute isso quando em si é executado.
Então, em resumo, você estava incorreto quando disse que a ROM era parte da memória principal * porque é separada. (De fato, RAM é tomada como antônimo para ROM ). Você estava correto em dizer que havia um gerenciador de inicialização lá e no MBR, porque são dois passos do processo e ambos são chamados por esse nome. E a resposta para "Fazer um sistema operacional diferente armazena seu gerenciador de inicialização em lugares diferentes?"é" principalmente ", porque se os bootloaders secundários incompatíveis ocultam outros bootloaders (se você instalar o Windows após instalar o Linux) ou chainload no outro se solicitado (se você corrigir essa situação, ou instalar o Linux após o Windows), mas O SO pode compartilhar um gerenciador de inicialização secundário se ele for compatível (se você instalar o Linux depois de outro Linux que usa o mesmo tipo de carregador de inicialização secundário e puder ver o outro Linux [às vezes, o software RAID confunde as coisas e torna necessário o carregamento em cadeia).
* Nos dias em que um programaticamente usaria ROM e RAM, isso era diferente. Em um ZX Spectrum, por exemplo, a ROM seria 16kiB e incluiria um interpretador BASIC, assim como lhe forneceria o ponto de partida para carregar algo em 48kiB ou 128KiB (paged) ou RAM, (nesse caso, é essencialmente inicializar que o interpretador BASIC e então usando isso para inicializar o que estava na fita), havia um monte de funções do interpretador BASIC que os programas na RAM poderiam usar (por que escrever uma função trigonométrica quando o computador já tem uma em uma posição conhecida? especialmente quando você tem apenas 48KB para que todo o seu código seja executado). Essa ROM também era visível da mesma forma que a RAM, apenas em endereços diferentes. Nesse caso, a ROM era tanto uma parte da memória principal quanto a RAM, mas não gravável. Atualmente você praticamente ignora a ROM quando passa da primeira fase de inicialização.