O conflito entre o que você diz sobre o carregador de inicialização estar na ROM e no MBR talvez se deva ao uso do carregador de inicialização para qualquer código que funcione como fazer o mínimo para carregar o código para fazer o computador fazer algo útil, incluindo cada estado em uma inicialização de vários estágios.
Portanto, o estado inicial é ter um computador, que é um dispositivo programável, mas não sabe como carregar o software para executar porque não tem nenhum software carregado. (E, portanto, inicialize a partir de suas próprias instruções ).
Historicamente, havia algumas soluções diferentes para esse problema, mas hoje em dia começamos com algum código na ROM (provavelmente estritamente EEPROM), o que é suficiente para fazer com que ele olhe para diferentes dispositivos e tente-os até encontrar um que seja inicializável.
(É por isso que muitos sistemas inicializam um CD ou DVD se você colocar um disco de instalação do SO no e a partir do disco rígido, caso contrário, o BIOS [o código na ROM, incluindo o código do qual estamos falando e outros coisas de nível básico que iniciam as coisas] deve definir primeiro a unidade de CD / DVD e, em seguida, o disco rígido, se não encontrar nada; os tweakers costumam configurá-lo para ignorar a unidade de CD / DVD, a menos que seja solicitado manualmente. não perde tempo girando um disco não inicializável que foi deixado na unidade).
Este código na ROM às vezes é chamado de gerenciador de inicialização .
Quando souber em qual unidade olhar, ele analisará o MBR, que contém informações sobre as principais partições - como você pode ver mais tarde / ou / boot ou C: / (em um sistema Windows) se nem sequer sabe qual parte do disco era qual partição, não importa como cada partição foi montada? - e algum código com mais instruções para executar. (Aliás, 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 carregador 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 nem existem).
Esse código executável também é chamado de gerenciador de inicialização . Quando nos preocupamos em distinguir isso e o que vem a seguir, ele é chamado de carregador de inicialização primário (porque, a menos que esteja criando nosso próprio BIOS, ignoramos o bit ROM como fora de nosso controle).
Esse código será muito pequeno, pois há apenas cerca de 400 bytes para caber, então, para fazer algo real, ele carregará mais código, que pode ser maior, pois não precisa lidar com essa restrição.
Esse código também é conhecido como gerenciador de inicialização . Quando nos preocupamos em distinguir entre isso e o que veio antes, ele é chamado de carregador de inicialização secundário .
Esse código talvez possa ser a etapa final do processo. Seria se você tivesse apenas um sistema operacional ou se todos os sistemas operacionais em seu sistema usassem gerenciadores de inicialização compatíveis (por exemplo, duas instalações Linux que usem GRUB, portanto, o que foi atualizado pela última vez no GRUB pode oferecer inicialização em um deles) apresenta menus (se desejado) carrega em um kernel e passa o controle sobre o sistema operacional.
No caso de você ter um sistema operacional incompatível com esse carregador de inicialização, ele pode ser carregado em cadeia. Por exemplo, se você possui Windows e Linux na mesma máquina, a opção GRUB para carregar o Windows de fato carrega outro gerenciador de inicialização que apenas conhece as instalações do Windows e passa para ele. Embora esse tenha sido um estágio terciário no processo, ele ainda é chamado de carregador de inicialização secundário , porque não sabe nem se importa que havia outro carregador de inicialização secundário em execução antes dele. Esse também seria o caso de uma instalação do Linux que usasse um tipo diferente de carregador de inicialização secundário.
Principalmente quando falamos sobre o gerenciador de inicialização em termos de Linux, geralmente não queremos dizer o código ROM (ele não faz parte do Linux ou foi alterado pela instalação do Linux). Quando fazemos isso update-grub, estamos alterando o carregador de inicialização secundário, que normalmente está no / boot de uma instalação específica. Quando o fazemos install-grub, estamos mudando e também o gerenciador de inicialização primário no MBR, para que ele tenha código suficiente para saber onde está / boot (talvez iniciando um RAID de software conforme ele avança) e o carregará e executará quando for executado. .
Portanto, em resumo, você estava incorreto quando disse que a ROM fazia parte da memória principal * porque é separada. (De fato, a RAM é considerada como antônimo da ROM) Você estava certo ao dizer que havia um gerenciador de inicialização lá e no MBR, porque são duas etapas do processo e às vezes são chamadas por esse nome. E a resposta para "OS diferentes armazenam seu gerenciador de inicialização em lugares diferentes?" é "principalmente", porque se você carregadores de inicialização secundários incompatíveis ocultam outros carregadores de inicialização (se você instalar o Windows após a instalação do Linux) ou carregam em cadeia para o outro se solicitado (se você corrigir essa situação ou instalar o Linux após o Windows), mas um SO pode compartilhar um carregador de inicialização secundário, se eles forem compatíveis (se você instalar o Linux após outro Linux que use o mesmo tipo de carregador de inicialização secundário e ele puder ver o outro Linux [às vezes o RAID de software confunde as coisas e torna necessário o carregamento em cadeia).
* Nos dias em que se usava programaticamente tanto a ROM quanto a RAM, isso era diferente. Em um ZX Spectrum, por exemplo, a ROM seria 16kiB e incluiria um intérprete BASIC, além de fornecer o ponto de partida para carregar algo no seu 48kiB ou 128KiB (paginado) ou RAM (nesse caso, é essencialmente inicializado no aquele intérprete BASIC e, em seguida, usando-o para inicializar o que estava na fita), havia várias funções do intérprete BASIC que os programas na RAM podiam usar (por que escrever uma função trigonométrica quando o computador já possui uma em uma posição conhecida especialmente quando você tem apenas 48kB para executar todo o seu próprio código). Essa ROM também era visível da mesma maneira que a RAM, apenas em endereços diferentes. Nesse caso, a ROM fazia parte da memória principal como a RAM, mas não era gravável.
A small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)segundo ele. A memória principal é composta de duas partes, RAM e ROM. Eu só quero saber se o chamado bootloader é instalado por parte ROM da memória principal ... @Sergey