u-boot implémente un environnement EFI et peut lancer les exécutables EFI.
C'est le standard maintenant sur toutes les plateformes x86 et ARM64 et il n'y a aucune raison de faire autre chose pour RISC-V.
De mon point de vue de développeur, cela facilite pas mal le travail, on développe une fois un bootloader compatible EFI et il fonctionne partout en ayant juste besoin de le recompiler.
Open Firmware faisait presque la même chose, mais la standardisation n'est pas allée assez loin, par exemple, les versions PowerPC et SPARC utilisent des formats d'exécutables différents, ce qui oblige à avoir une édition de liens différente. Plein de choses n'étaient pas exposées de la même façon dans le device tree, ce qui entraîne beaucoup de code spécifique à chaque plateforme.
Avec EFI, tout est beaucoup mieux standardisé et c'est vraiment facile de faire tourner un bootloader sur n'importe quelle plateforme. Les "boot services" permettent d'afficher facilement un menu à l'écran, de trouver où est le rootfs et le noyau qu'on veut charger, et même de faire du boot en réseau.
Clairement, sur la version ARM de Haiku, c'est ce qui a permis de débloquer la situation qui n'avançait pas depuis 15 ans à essayer d'implémenter des drivers pour chaque cible qu'on a essayé d'utiliser. À chaque fois il fallait tout recommencer: nouveau pilote pour le port série, puis pour l'affichage, et pour les supports de stockage... tout ça avant d'avoir même pu commencer à charger le noyau et à avoir un quelconque outil de debug un peu pratique.
Avec EFI, on passe par le "firmware" (u-boot la plupart du temps sur les cartes ARM) qui va se charger pour nous de tous ces détails. Et donc notre bootloader n'a plus besoin d'aucun code spécifique à chaque plateforme.
La seule "bizarrerie" est le choix d'avoir des exécutables au format PE (le même que les .exe de Windows) plutôt que des ELF (comme Linux). Mais c'est un problème à régler une fois (avec un convertisseur de ELF vers PE) pour toutes les plateformes, et c'est juste un format de fichier.
Je ne tente même pas la comparaison avec u-boot avant EFI, ou y'avait... rien. Linux prenait le contrôle total de la carte, et devait venir avec ses propres drivers, toute la complexité étant donc dans le noyau Linux, et dupliquée dans tous les autres OS. Ou avec le BIOS sur les PC ou il faut comprendre 30 ans d'histoire de l'informatique et des machines à base de x86 (mode protégé, mode réel, utilisation d'instructions spéciales INT pour appeler les fonctions du BIOS, un peu de PCI pour trouver où se trouve la carte graphique...) avant de pouvoir faire quoi que ce soit.
Pour les systèmes à base de BIOS et de VESA, le serveur graphique de Haiku se retrouve à embarquer un émulateur de CPU x86 pour pouvoir appeler des fonctions VESA une fois que l'OS est lancé, sans devoir retourner en mode réel. Et on a rien inventé, on a repris quelque chose développé dans X11.
Et du côté du matériel, c'est pas mieux puisque les cartes graphiques qui embarquent un BIOS VESA ne fonctionnent que sur les machines x86. EFI permet de régler ce problème (comme le faisait Open Firmware) en définissant un format de bytecode qui sera interprété par le firmware. Résultat, on peut brancher une carte graphique PCI express sur un système avec un processeur RISC-V ou ARM64, et ça fonctionne, y compris pour afficher le bootloader sur l'écran.
Donc, oui, UEFI est nouveau et un peu plus compliqué, mais il règle tout un tas de problèmes et rend la vie beaucoup plus facile aux gens qui ont besoin d'interagir avec le bootloader.
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 7.
u-boot implémente un environnement EFI et peut lancer les exécutables EFI.
C'est le standard maintenant sur toutes les plateformes x86 et ARM64 et il n'y a aucune raison de faire autre chose pour RISC-V.
De mon point de vue de développeur, cela facilite pas mal le travail, on développe une fois un bootloader compatible EFI et il fonctionne partout en ayant juste besoin de le recompiler.
Open Firmware faisait presque la même chose, mais la standardisation n'est pas allée assez loin, par exemple, les versions PowerPC et SPARC utilisent des formats d'exécutables différents, ce qui oblige à avoir une édition de liens différente. Plein de choses n'étaient pas exposées de la même façon dans le device tree, ce qui entraîne beaucoup de code spécifique à chaque plateforme.
Avec EFI, tout est beaucoup mieux standardisé et c'est vraiment facile de faire tourner un bootloader sur n'importe quelle plateforme. Les "boot services" permettent d'afficher facilement un menu à l'écran, de trouver où est le rootfs et le noyau qu'on veut charger, et même de faire du boot en réseau.
Clairement, sur la version ARM de Haiku, c'est ce qui a permis de débloquer la situation qui n'avançait pas depuis 15 ans à essayer d'implémenter des drivers pour chaque cible qu'on a essayé d'utiliser. À chaque fois il fallait tout recommencer: nouveau pilote pour le port série, puis pour l'affichage, et pour les supports de stockage... tout ça avant d'avoir même pu commencer à charger le noyau et à avoir un quelconque outil de debug un peu pratique.
Avec EFI, on passe par le "firmware" (u-boot la plupart du temps sur les cartes ARM) qui va se charger pour nous de tous ces détails. Et donc notre bootloader n'a plus besoin d'aucun code spécifique à chaque plateforme.
La seule "bizarrerie" est le choix d'avoir des exécutables au format PE (le même que les .exe de Windows) plutôt que des ELF (comme Linux). Mais c'est un problème à régler une fois (avec un convertisseur de ELF vers PE) pour toutes les plateformes, et c'est juste un format de fichier.
Je ne tente même pas la comparaison avec u-boot avant EFI, ou y'avait... rien. Linux prenait le contrôle total de la carte, et devait venir avec ses propres drivers, toute la complexité étant donc dans le noyau Linux, et dupliquée dans tous les autres OS. Ou avec le BIOS sur les PC ou il faut comprendre 30 ans d'histoire de l'informatique et des machines à base de x86 (mode protégé, mode réel, utilisation d'instructions spéciales INT pour appeler les fonctions du BIOS, un peu de PCI pour trouver où se trouve la carte graphique...) avant de pouvoir faire quoi que ce soit.
Pour les systèmes à base de BIOS et de VESA, le serveur graphique de Haiku se retrouve à embarquer un émulateur de CPU x86 pour pouvoir appeler des fonctions VESA une fois que l'OS est lancé, sans devoir retourner en mode réel. Et on a rien inventé, on a repris quelque chose développé dans X11.
Et du côté du matériel, c'est pas mieux puisque les cartes graphiques qui embarquent un BIOS VESA ne fonctionnent que sur les machines x86. EFI permet de régler ce problème (comme le faisait Open Firmware) en définissant un format de bytecode qui sera interprété par le firmware. Résultat, on peut brancher une carte graphique PCI express sur un système avec un processeur RISC-V ou ARM64, et ça fonctionne, y compris pour afficher le bootloader sur l'écran.
Donc, oui, UEFI est nouveau et un peu plus compliqué, mais il règle tout un tas de problèmes et rend la vie beaucoup plus facile aux gens qui ont besoin d'interagir avec le bootloader.