RISC-V semble avec cette annonce devenir un candidat sérieux pour reprendre le flambeau du PowerPC dans les applications spatiales/avioniques ou ARM/Intel sont exclus (pour des raisons différentes).
Mais si on veut que cela fonctionne, il est impératif que ce coup de pouce débouche sur une utilisation plus large en amont car ce n’est pas les volumes du spatial qui vont tirer l’affaire: Le PowerPC a dû son succès dans les applications critiques à des caractéristiques propres favorables (pas de cachotteries dans le ME et autres firmwares + grande variabilité de latence y compris dans des applications “machine à laver” hors OS, non pétri d’états indéfinis par souci de simplification/moindre conso) mais également au fait que l’industrie télécom a généré en amont des volumes suffisants et un gros boulot de déverminage des SoC ayant ensuite connu une seconde vie ailleurs et qui seront encore là pour des décennies.

BlackLightning a dit:

Tu pourrais détailer les raisons stp ? J’imagine que ce n’est pas une uniquement une question de blindage et de contrôle d’intégrité.

Je l’évoquais un peu plus loin: ARM est pétri d’états indéfinis faute d’implémenter toute la logique permettant d’éviter, autant que possible, qu’un code puisse dérailler de manière incontrôlée.
Intel manque désormais totalement de déterminisme et impose dans les faits de ne pas maîtriser certains aspects comme le démarrage.
Pour commencer, pas facile de se faire fournir les firmwares non signés, dont le ME indispensable au démarrage, qui le sont à la première exécution en utilisant l’ID unique du processeur qui les utilise (au moins pour leurs SoC basés Xeon ou Atom ciblant l’embarqué: On a tôt fait de remarquer qu’un dump de boot flash d’une carte collé sur une autre ne permet pas de démarrer! Impossible dans ces conditions de générer une boot flash générique donc d’industrialiser un produit).
Limitations des blob binaires nécessaires à une alternative type coreboot, qui sont en réalité une version compilée de leurs reference-code (RC pour la partie plateforme et MRC pour la partie init DDR) avec qq limites d’API bloquantes pour des usages embarqués, imposant de sous traiter cet élément clef à un vendeur de BIOS (eux ont accès aux RC que l’on refuse aux clients finaux et aux FW non signés, qu’on avait eu après pas mal de palabres avant de lâcher l’affaire en raison de la non fourniture des RC qui n’avait même pas été discutable!).
Et quand tu as signé un contrat avec un vendeur de BIOS, incluant la fourniture du source et environnements de développement… bin tu te rends compte de l’affreux patchwork qui (si cela ne venait pas de dehors, donc hors scope) ne passerait aucune revue de code interne dans l’industrie! Alors aller certifier un tas de merde pareil pour de l’avionique, même pas en rêve!