Nighpher, je vais essayer de répondre à votre question, mais pour une description plus complète du processus de démarrage, essayez l' article IBM .
Ok, je suppose que vous utilisez GRUB ou GRUB2 comme chargeur de démarrage pour des explications. Tout d'abord, lorsque le BIOS accède à votre disque pour charger le chargeur de démarrage, il utilise ses routines intégrées pour l'accès au disque, qui sont stockées dans la célèbre interruption de 13h. Le chargeur de démarrage (et le noyau lors de la phase d'installation) utilisent ces routines lorsqu'ils accèdent au disque. Notez que le BIOS fonctionne en mode réel (16 bits) du processeur, donc il ne peut pas adresser plus de 2 ^ 20 octets de RAM (2 ^ 20 pas 2 ^ 16 car chaque adresse en mode réel est composée de segment_address * 16 + offset , où l'adresse de segment et le décalage sont tous deux de 16 bits, voir http://en.wikipedia.org/wiki/X86_memory_segmentation ). Ainsi, ces routines ne peuvent pas accéder à plus de 1 Mo de RAM, ce qui constitue une limitation stricte et un inconvénient majeur.
Le BIOS charge le code du chargeur de démarrage directement à partir du MBR - les 512 premiers octets de votre disque et l'exécute. Si vous utilisez GRUB, ce code est GRUB stage 1. Ce code charge GRUB stage 1.5, qui se trouve soit dans les 32 premiers Ko d'espace disque, appelé région de compatibilité DOS, soit à partir d'une adresse fixe du système de fichiers. Il n'a pas besoin de comprendre le système de fichiers pour ce faire, car même si l'étape 1.5 est dans le système de fichiers, c'est du code "brut" et peut être directement chargé dans la RAM et exécuté: http://www.pixelbeat.org/ docs / disque / . La charge de stage1.5 du disque vers la RAM utilise les routines d'accès au disque du BIOS.
Stage1.5 contient les utilitaires du système de fichiers, afin qu'il puisse lire le stage2 du système de fichiers (enfin, il utilise toujours le BIOS 13h pour lire du disque vers la RAM, mais maintenant il peut déchiffrer les informations du système de fichiers sur les inodes, etc. et obtenir le code brut de la disque). Les BIOS plus anciens peuvent ne pas être en mesure d'accéder à l'ensemble du disque dur en raison des limitations de leur mode d'adressage de disque - ils peuvent utiliser le système Cylinder-Head-Sector, incapable de traiter plus de 8 premiers Go d'espace disque: http: //en.wikipedia. org / wiki / Secteur-culasse .
Stage2 charge le noyau dans la RAM (à nouveau, en utilisant les utilitaires de disque du BIOS). S'il s'agit d'un noyau 2.6+, il contient également des initramfs compilés, donc pas besoin de le charger. S'il s'agit d'un noyau plus ancien, le chargeur de démarrage charge également une image initrd autonome dans la mémoire, afin que le noyau puisse le monter et obtenir des pilotes pour le montage du système de fichiers réel à partir du disque.
Le problème est que le noyau (et le disque virtuel) pèsent plus de 1 Mio, donc pour les charger dans la RAM, vous devez charger le noyau au premier 1 Mio, puis passer en mode protégé (32 bits), déplacer le noyau chargé en haute mémoire (gratuit le premier 1 Mio pour le mode réel), puis revenir à nouveau en mode réel (16 bits), obtenir le disque virtuel du disque au premier 1 Mio (si c'est un initrd séparé et un noyau plus ancien), éventuellement basculer à nouveau en mode protégé (32 bits), placez-le à sa place, revenez éventuellement en mode réel (ou non: /programming/4821911/does-grub-switch-to-protected-mode ) et exécutez le code du noyau. Avertissement: je ne suis pas entièrement sûr de l'exhaustivité et de l'exactitude de cette partie de la description.
Maintenant, lorsque vous exécutez enfin le noyau, vous l'avez déjà et le ramdisk chargé dans la RAM par le chargeur de démarrage , afin que le noyau puisse utiliser les utilitaires de disque de ramdisk pour monter votre véritable système de fichiers racine et pivoter la racine vers lui. Les pilotes ramfs sont présents dans le noyau, il peut donc bien sûr comprendre le contenu d'initramfs.