Le conflit entre ce que vous dites sur le chargeur de démarrage se trouvant dans la ROM et dans le MBR est peut-être dû au fait que le chargeur de démarrage est utilisé pour tout code qui explique comment faire le minimum pour charger du code afin que l'ordinateur fasse quelque chose d'utile, y compris chaque dans un démarrage en plusieurs étapes.
Donc, l'état de départ est d'avoir un ordinateur, qui est un appareil programmable, mais ne sait pas comment charger le logiciel à exécuter car il n'a pas de logiciel chargé. (Et donc boot de se tirer de ses bootstraps ).
Historiquement, il y avait quelques solutions différentes à ce problème, mais ces jours-ci, nous commençons avec du code dans la ROM (principalement probablement strictement EEPROM), ce qui est suffisant pour lui permettre de regarder différents appareils et de les essayer à tour de rôle jusqu'à ce qu'il en trouve un qui soit amorçable.
(C'est pourquoi de nombreux systèmes démarrent à partir d'un CD ou d'un DVD si vous placez un disque d'installation du système d'exploitation dans et à partir du disque dur sinon, le BIOS [le code sur la ROM, y compris le code dont nous parlons et certains autres bas de niveau supérieur qui fait démarrer les choses] est configuré pour regarder d'abord le lecteur de CD / DVD, puis sur un disque dur s'il ne trouve rien, les tweakers le configurent souvent pour ignorer le lecteur de CD / DVD, sauf demande manuelle pour qu'il ne perd pas de temps à faire tourner un disque non amorçable qui a été laissé dans le lecteur).
Ce code dans la ROM est parfois appelé chargeur de démarrage .
Quand il sait quel lecteur regarder, il va alors regarder le MBR, qui contient des informations sur les partitions primaires - comment pourriez-vous regarder plus tard / ou / boot ou C: / (sur un système Windows) si vous ne l'avez même pas savez quelle partie du disque était quelle partition, peu importe comment chaque partition a été montée? - et du code avec des instructions supplémentaires à exécuter. (Incidemment, cela explique pourquoi certains systèmes d'exploitation - comme Windows - ne peuvent être installés que sur une partition principale, les détails de ces partitions sont dans le MBR et c'est la seule information de partition que leur chargeur de démarrage a lue, et il ne charge pas l'EBR sur en savoir plus sur les partitions logiques, en ce qui concerne ces partitions n'existent même pas encore).
Ce code exécutable est également appelé chargeur de démarrage . Lorsque nous souhaitons faire la distinction entre cela et ce qui vient ensuite, cela s'appelle un chargeur de démarrage principal (car à moins que nous ne fabriquions notre propre BIOS, nous ignorons le bit ROM comme hors de notre contrôle).
Ce code sera très petit car il ne contient que 400 octets environ, donc pour faire quoi que ce soit de réel, il chargera un peu plus de code, qui peut être plus grand car il n'a pas à gérer cette contrainte.
Ce code est également appelé chargeur de démarrage . Lorsque nous voulons distinguer ce qui précède, ce qu'on appelle un chargeur de démarrage secondaire .
Ce code pourrait peut-être être la dernière étape du processus. Ce serait le cas si vous n'avez qu'un seul système d'exploitation, ou si tous les systèmes d'exploitation de votre système utilisent des chargeurs de démarrage compatibles (par exemple, deux installations Linux qui utilisent toutes les deux GRUB, de sorte que celui qui a été mis à jour le dernier peut proposer de démarrer dans l'un ou l'autre), alors il présente les menus (si vous le souhaitez) charge dans un noyau, et passe le contrôle sur le système d'exploitation.
Dans le cas où vous avez un système d'exploitation qui n'est pas compatible avec ce chargeur de démarrage, il peut charger en chaîne. Par exemple, si vous avez Windows et Linux sur la même machine, l'option GRUB pour le chargement de Windows chargera en fait un autre chargeur de démarrage qui ne connaît que les installations Windows et y passera. Bien qu'il s'agissait d'une étape tertiaire dans le processus, il est toujours appelé chargeur de démarrage secondaire , car il ne sait ni ne se soucie qu'un autre chargeur de démarrage secondaire fonctionne avant. Ce serait également le cas avec une installation Linux utilisant un autre type de chargeur de démarrage secondaire.
Généralement, lorsque nous parlons du chargeur de démarrage en termes de Linux, nous ne parlons généralement pas du code ROM (il ne fait pas partie de Linux ou n'est pas modifié en installant Linux). Lorsque nous le faisons, update-grubnous modifions le chargeur de démarrage secondaire, qui se trouve généralement dans / boot d'une installation particulière. Lorsque nous le faisons, install-grubnous le modifions ainsi que le chargeur de démarrage principal dans le MBR afin qu'il ait suffisamment de code pour savoir où / boot se trouve (peut-être en démarrant un RAID logiciel au fur et à mesure) et le chargera et l'exécutera lorsqu'il sera lui-même exécuté .
Donc, en résumé, vous aviez tort lorsque vous avez dit que la ROM faisait partie de la mémoire principale * car elle est distincte. (En effet, la RAM est considérée comme antonyme de la ROM). Vous aviez raison à la fois de dire qu'il y avait un chargeur de démarrage là-bas et dans le MBR, car ce sont deux étapes du processus et les deux sont parfois appelés par ce nom. Et la réponse à "Différents systèmes d'exploitation stockent-ils leur chargeur de démarrage à différents endroits?" est "la plupart du temps", car si vos chargeurs de démarrage secondaires incompatibles masquent d'autres chargeurs de démarrage (si vous installez Windows après avoir installé Linux) ou chargent en chaîne dans l'autre si demandé (si vous corrigez cette situation, ou installez Linux après Windows), mais un système d'exploitation peut partager un chargeur de démarrage secondaire s'ils sont compatibles (si vous installez Linux après un autre Linux qui utilise le même type de chargeur de démarrage secondaire et qu'il peut voir l'autre Linux [parfois le RAID logiciel confond les choses et rend le chargement de chaîne nécessaire).
* À une époque où l'on utilisait par programme à la fois la ROM et la RAM, c'était différent. Sur un ZX Spectrum par exemple, la ROM serait de 16 Ko et inclurait un interpréteur BASIC, de sorte qu'il vous donnerait également le point de départ pour charger quelque chose dans ses 48 Ko ou 128 Ko (paginés) ou RAM (dans ce cas, il s'agit essentiellement de démarrer dans cet interpréteur BASIC et ensuite l'utiliser pour démarrer dans ce qui était sur la bande), il y avait tout un tas de fonctions de l'interpréteur BASIC que les programmes en RAM pouvaient utiliser (pourquoi écrire une fonction trig alors que l'ordinateur en a déjà une à une position connue) ? Surtout quand vous n'avez que 48 Ko pour que tout votre propre code puisse s'exécuter). Cette ROM était également visible de la même manière que la RAM, juste à différentes adresses. Dans un tel cas, la ROM faisait autant partie de la mémoire principale que la RAM, mais pas en écriture.
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)D'après lui. La mémoire principale est composée de deux parties, RAM et ROM. Je veux juste savoir si le soi-disant bootloader est installé sur la partie ROM de la mémoire principale ... @Sergey