Est-ce que le BIOS a une fonction spéciale qu'un autre programme ne pourrait pas effectuer ?

Vous ne comprenez pas une chose TRÈS importante. Le BIOS n'est pas un logiciel, c'est un micrologiciel. C'est la partie qui normalise la fonctionnalité au niveau matériel. C'est ce qui charge tous les autres "programmes".

Le principal problème avec l'autorisation du système d'exploitation de piloter directement le matériel concerne les améliorations. Par exemple, il a été prouvé il y a longtemps que les processeurs x86 traditionnels étaient une impasse. Les processeurs "x86" modernes ne sont pas internes x86. Au lieu de cela, ils disposent eux aussi d'un micrologiciel (dans ce cas appelé microcode) pour qu'ils apparaissent comme des processeurs x86. L'utilisation du micrologiciel est un niveau d'encapsulation. De plus, les processeurs x86 modernes doivent prendre en charge des instructions qui étaient nécessaires en raison des bizarreries présentes dans les systèmes 8086 et 268, même si elles ne sont pas beaucoup utilisées aujourd'hui.

Fondamentalement, le système d'exploitation lui-même ne se soucie pas de savoir comment fonctionne le matériel. Il voit ce que le BIOS lui montre, ce qui peut être correct ou non au niveau du matériel. Cela crée une séparation des responsabilités entre les personnes impliquées dans la fabrication et la conception d'ordinateurs et permet à chaque organisation de se préoccuper des parties qui lui sont les plus proches. La plupart des programmeurs ne savent pas comment fonctionne un processeur ou une carte mère en bas niveau et ils n'ont pas besoin de le savoir car ils programment une interface spécifiée. En revanche, les concepteurs de chipsets savent comment fonctionne une carte mère, ils programment donc également le BIOS selon une interface spécifiée. Les fabricants de cartes mères ne fabriquent en réalité pas les cartes mères à partir de zéro. Ils prennent des composants complets et les intègrent dans un système unique et ils modifient un peu le BIOS de la carte mère pour qu'il fonctionne avec les composants utilisés. Là aussi, le micrologiciel est présent car le BIOS communique avec le micrologiciel de la puce réseau ou avec le micrologiciel de la puce audio, etc.

Les mises à jour du BIOS que vous voyez ne sont souvent pas des mises à jour d'une fonctionnalité de base. Aujourd'hui, les fabricants de cartes mères doivent lancer leurs produits le plus rapidement possible, ils essaient donc de faire leurs modifications de BIOS aussi rapidement que possible, ce qui conduit souvent à des bugs. Parfois, les mises à jour du BIOS servent à corriger le micrologiciel d'un autre périphérique. Par exemple, Intel met à disposition des mises à jour du microcode de ses processeurs. Si un bug majeur est identifié dans un processeur, Intel enverra ces mises à jour aux fabricants de cartes mères qui utilisent les processeurs affectés, ils réaliseront des mises à jour du BIOS qui mettront à jour le microcode du processeur (le microcode est en lecture seule, donc cela doit être fait à chaque démarrage).

En ce qui concerne le changement de la fréquence du FSB, etc., cela se fait toujours à travers le BIOS. C'est juste que certains BIOS exposent aux programmes les composants responsables du FSB afin qu'ils puissent être modifiés par un programme. Cependant, ces programmes sont spécialisés car ils doivent savoir avec quoi ils travaillent.

Un autre point concerne les fabricants de matériel. Le matériel lui-même doit savoir où chercher des programmes. Sur des systèmes de microcontrôleurs simples (qui sont comme les ordinateurs d'il y a 30 ans en termes de capacités), vous avez un point de départ du programme. Le microcontrôleur lit toujours une seule adresse mémoire où les données sur le démarrage du programme sont stockées. Le BIOS fait cela pour les PC. Imaginez comme ce serait compliqué si le processeur accédait directement aux données sur le HDD. Il devrait savoir comment tout fonctionne, du processeur lui-même en passant par le chipset, le contrôleur HDD, et le HDD lui-même, et où sur le HDD est stocké le système d'exploitation.

Après avoir lu votre question plusieurs fois, je pense que le principal problème avec votre vision du BIOS et de sa place est à quel point le système d'exploitation est connecté au matériel sur un PC moderne. Il a été décidé que sur les PC, le système d'exploitation ne serait pas aussi étroitement connecté au matériel. Au fil du temps, cette décision s'est avérée être bonne. Jetez un œil au projet coreboot (article de Wikipédia). Ils implémentent un système d'exploitation GNU/Linux complet dans la puce BIOS de l'ordinateur. Comme vous pouvez le voir, ils rencontrent de nombreux problèmes liés aux informations disponibles sur des cartes mères spécifiques, mais ils ont leurs avantages. Leur système peut démarrer en quelques secondes seulement. Un autre ordinateur intéressant est Acorn. Leurs ordinateurs avaient un système d'exploitation complet placé dans une seule puce. Il y a aussi Apple. Leur système d'exploitation n'est pas autant lié au matériel et il est possible de créer un hackintosh, mais la relation est tout de même plus étroite que sur un PC.

En fin de compte, je pense que la principale raison de l'existence du BIOS aujourd'hui est l'ouverture de la plateforme PC. Il est très facile de fabriquer du matériel pour les PC et l'une des principales raisons de cela est qu'il n'y a pas une seule entreprise qui contrôle les spécifications des PC. Si le BIOS (ou ses remplaçants plus récents) devait être éliminé, il faudrait que quelqu'un veille à ce que les développeurs de systèmes d'exploitation et les concepteurs de matériel soient synchronisés, et cela serait extrêmement compliqué.

Il y a longtemps, les ordinateurs n'avaient pas de ROM bootstrap. On avait une interface directe pour modifier la RAM, et pouvait arrêter le CPU, changer la RAM, puis redémarrer le CPU. Donc, quand vous redémarriez le système, vous deviez vous assurer que le CPU était arrêté, entrer votre code bootstrap qui chargerait un chargeur d'amorçage de deuxième étage (2bl) à partir d'une bande de papier ou autre, puis "démarrer" votre CPU.

La ROM sauve la situation ici, évidemment. Lorsque vous allumez un système basé sur un CPU x86, il commence à s'exécuter à l'adresse FFFF:FFF0. C'est une fonctionnalité câblée du CPU x86. La ROM doit résider à cette adresse, et en effet la toute dernière partie du BIOS le fait (commençant généralement à E000:0000).

Le terme BIOS est un vestige du vieux système d'exploitation CP/M. La structure du CP/M était le BIOS ROM au niveau le plus bas, le BDOS (Basic Disk Operating System) au milieu, et le CCP (Console Command Processor) devant l'utilisateur. Le BIOS avait des routines pour effectuer des fonctions de bas niveau telles que la lecture/écriture d'un secteur de disque spécifique, la lecture d'une touche du clavier, l'écriture d'un caractère à l'écran, etc. Le BDOS utiliserait les fonctions du BIOS pour mettre en œuvre un système de fichiers, et le CCP serait le shell de commande utilisant les fonctions BDOS et BIOS. L'idée était que le BIOS contiendrait l'interface spécifique au matériel, et le BDOS et le CCP pourraient être les mêmes sur n'importe quel système CP/M.

Le BIOS contenait également le code initial exécuté par le processeur, qui initialisait le matériel requis, affichait un écran de démarrage, chargeait le 2bl du premier secteur du premier lecteur de disque et l'exécutait.

MS-DOS 1.0, étant essentiellement une implémentation x86 de CP/M, avec des fonctionnalités d'Unix ajoutées de manière maladroite à partir de la version 2.0, était structuré de la même manière. Le BIOS de l'IBM PC à ce moment-là comprenait également des améliorations telles que la commutation de mode vidéo, les fonctions graphiques et la prise en charge du disque dur dans le BIOS AT original.

Cependant, la plupart des programmes DOS n'utilisaient pas les fonctions du BIOS une fois démarrés ; ils accédaient directement au matériel pour des raisons de performance. C'était particulièrement important après l'avènement des CPU 32 bits ; le BIOS ne fonctionnait qu'en mode 16 bits plus ancien, donc l'appeler depuis le mode 32 bits entraînait une pénalité de performance supplémentaire.

Autour de 1990, l'architecture PC commençait à être étendue, et commençait à inclure de nouvelles choses comme APM, PnP et PCI. Le BIOS commençait donc à prendre en charge des fonctions supplémentaires et à devenir plus volumineux. Les PC commençaient également à utiliser des chipsets au lieu de composants discrets. L'initialisation du chipset est quelque chose qui doit être effectuée pour rendre la RAM et d'autres composants tels que le bus PCI utilisables, donc cela doit être géré par le code bootstrap du BIOS. Pour une raison quelconque, de nombreux fournisseurs de chipsets n'aiment pas documenter le fonctionnement de leurs processus de configuration.

APM était traité par des fonctions du BIOS ; c'est-à-dire que pour éteindre le système, l'exploitation devait appeler une fonction APM. L'ACPI, successeur de l'APM, est la grande chose que font les BIOS aujourd'hui. Le BIOS ACPI est responsable de la création d'un tas de tables en mémoire qui décrivent de nombreux composants matériels non plug and play. Un système d'exploitation en cours de démarrage utilise cela pour déterminer combien de CPU il y a, combien de slots de RAM le système a, si le système est un ordinateur de bureau ou portable, combien de batteries sont installées, etc. Le BIOS ACPI doit également être appelé pour éteindre le système, ou le placer en veille, etc. Il n'y a aucune raison pour que le code du système d'exploitation ne puisse pas gérer les appels ACPI, cependant.

La plupart du temps, les mises à jour du BIOS servent à corriger des erreurs ACPI, car l'ACPI est compliqué et difficile, ou à introduire un microcode amélioré. Tous les CPU modernes permettent des mises à jour du micrologiciel, et si une nouvelle mise à jour du microcode est publiée, le BIOS doit ensuite être mis à jour pour installer ce nouveau microcode. Il est possible pour un programme normal de mettre à jour le micrologiciel d'un CPU.

Les SMI sont également gérés par le BIOS. Je suis assez sûr que la plupart du matériel thermique et lié à l'alimentation d'un PC déclenche des SMI, dont les routines ajustent ensuite la vitesse du ventilateur/des CPU et/ou d'autres éléments. D'autres choses peuvent déclencher des SMI ; consultez l'article Wikipedia sur le mode de gestion du système. Mais il n'y a aucune raison pour que ce code ne puisse pas être remplacé par un code de système d'exploitation si les interfaces matérielles étaient documentées.

Les systèmes d'exploitation modernes n'utilisent pas du tout le BIOS pour l'accès au matériel, sauf pour les événements liés à l'alimentation. Certains programmes de démarrage utilisent le E/S de caractères du BIOS pour afficher du texte et le E/S de disque pour charger le code de démarrage du système d'exploitation.

J'espère que cela éclaire un peu le rôle du BIOS, et pour la plupart vous avez absolument raison sur la façon dont cela fonctionne.