L'implémentation de UEFI est fournie par U-Boot. Je ne comprend pas pourquoi tu parles de firmware fermé. C'est un logiciel libre, U-Boot.
En plus de ça, il transmet un device tree au système lors de son lancement, et ce, qu'on utilise l'interface EFI ou pas. Mais le device tree, ça dit juste "il y a à l'adresse 42 un périphérique qui s'appelle LM90". Il faut fournir un pilote pour ce périphérique. Ce qui bien sûr ne pose pas problème pour un système d'exploitation comme Linux, mais ça en pose pour les bootloaders. On parle par exemple de GRUB, de Refind, etc. Qui permettent d'avoir un menu permettant de choisir quel OS on veut démarrer, les options qu'on veut passer au noyau, etc.
Sans EFI, chacun de ces projets devrait récupérer le device tree et forunir ses propres drivers. Pour les ports série, pour l'affichage sur l'écran, pour utiliser des périphériques USB (comme un clavier), pour lire des secteurs depuis un disque, ...
C'est juste irréaliste de s'attendre à ce que chaque bootloader fasse tout ce travail sur chaque carte ARM ou RISC-V qui existe.
Alors on a deux solutions:
Abandonner l'idée d'avoir un bootloader un peu avancé. Ce sera seulement u-boot avec son interface en ligne de commande sur un port série uniquement, et puis on démarre directement un noyau Linux. Pas de dual boot, pas de moyen facile de changer les options du noyau si on a cassé un truc, etc.
Ou alors, il faut bien une interface un peu standardisée avec des trucs simples comme "affiche un pixel sur l'écran", "récupère les entrées au clavier", "charge un secteur depuis un disque" pour pouvoir avoir un outil simple qui se lance avant l'OS, et que cet outil n'aie pas besoin d'implémenter lui-même des drivers spécifiques pour tout le matériel comme ce serait le cas avec un device tree.
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Premiers pas avec la carte Visionfive 2. Évalué à 4.
L'implémentation de UEFI est fournie par U-Boot. Je ne comprend pas pourquoi tu parles de firmware fermé. C'est un logiciel libre, U-Boot.
En plus de ça, il transmet un device tree au système lors de son lancement, et ce, qu'on utilise l'interface EFI ou pas. Mais le device tree, ça dit juste "il y a à l'adresse 42 un périphérique qui s'appelle LM90". Il faut fournir un pilote pour ce périphérique. Ce qui bien sûr ne pose pas problème pour un système d'exploitation comme Linux, mais ça en pose pour les bootloaders. On parle par exemple de GRUB, de Refind, etc. Qui permettent d'avoir un menu permettant de choisir quel OS on veut démarrer, les options qu'on veut passer au noyau, etc.
Sans EFI, chacun de ces projets devrait récupérer le device tree et forunir ses propres drivers. Pour les ports série, pour l'affichage sur l'écran, pour utiliser des périphériques USB (comme un clavier), pour lire des secteurs depuis un disque, ...
C'est juste irréaliste de s'attendre à ce que chaque bootloader fasse tout ce travail sur chaque carte ARM ou RISC-V qui existe.
Alors on a deux solutions: