L’équipe de développement a confirmé que la prochaine mouture de la distribution supportera RISC-V64, la version 64 bits de l’architecture RISC-V.
Rappelons que cette ISA (instruction set architecture) est open source et libre de droits. RISC-V gagne en visibilité et en attraction avec le temps, du fait de son ouverture et de la possibilité de s’en servir pour des puces adaptées à différents besoins, comme l’embarqué ou les serveurs hautes performances.
L’inclusion dans Debian devrait entrainer un nouvel élan, même si Debian 12 est sortie le mois dernier et qu’il faudra attendre environ deux ans pour la version 13. Tous les distributions basées sur Debian, Ubuntu en tête, devraient ainsi reprendre ce support et le diffuser d’autant plus largement.
Commentaires (14)
#1
Bonne nouvelle.
Maintenant, il y a 2 ans pour proposer des systèmes ayant les épaules pour faire des postes de travail multi-core / multithread / multisocket basés sur cette architecture.
Et si les concepteurs pouvaient proposer une approche équivalente au BIOS et autres UEFI afin de ne pas tomber dans le piège des images système incluant les firmwares spécifiques à chaque plateforme (coucou les plateformes ARM). On pourrait poser la distro de son choix.
#2
C’est malheureusement dans l’autre sens que cela fonctionne, à tous les niveaux : il faudra plein de systèmes d’exploitation déjà existants pour qu’un constructeur s’essaie éventuellement à produire en masse du matériel économiquement accessible (d’abord) & techniquement fonctionnel (ensuite).
L’ère des inventeurs “fous” des 70s n’existe plus.
#2.1
Il n’y a pas pléthore d’OS dans ce monde non plus. Dans la bureautique, les plus présents sont Windows, IOS et Linux. Windows, historiquement, a eu du mal à passer à ARM (ça s’est fait dans la douleur, d’après moi); mais il n’est pas en reste avec son expérience IA64. Pour Apple, cela me semble être dans leurs gênes: PowerPC, 386, ARM; ce devrait être plus facile de s’adapter. En ce qui concerne Linux, c’est dans sa nature d’être multiarchitectural; ça pose moins de problème.
Il est évident que les logiciels natifs devront être adaptés également et que cela jouera en la faveur de l’acceptation “grand public”.
Je ne connais pas du tout ARM, mais en ce qui concerne RISC-V, une des difficultés pour un OS c’est qu’il doit s’adapter à chaque implémentation de l’ISA. RISC-V est très modulaire dans son approche. Donc, il y a un ISA de base qui doit être présent sur chaque implémentation et les extensions qui peuvent y être adjointes. La base concerne principalement les instructions sur les entiers. Donc les autres fonctionnalités (telles que les multiplications, divisions, les registres de statut et de contrôle, etc.) ne sont pas forcément présentes. Ce qui complique un peu les choses. C’est donc dire qu’un OS orienté vers RISC-V devra être limité à certaines unités de calculs.
Ce qui semble être le cas avec Debian, qui utilise des modèles plus ou moins identiques dans leur implémentation (RV64GC à minima). Et qui, je ne me trompe pas, couvre les besoins nécessaires à une machine de type bureautique (i.e. RV64GC = RV64IMADZifencei). Mais pas en de serveurs tels qu’on les conçoit actuellement: les extensions Sdef ou Hghi (pour la super/hyper-vision) ne semblent pas être reprises dans les modèles d’unités énumérées chez Debian.
https://wiki.debian.org/RISC-V
#2.2
Oui Debian vise bien le RV64GC, c’est à dire RV64IMAFDC_Zicsr_Zifencei. Les CPUs récents prennent également en charge Zba et Zbb (l’ancienne extension B sur les manipulation au niveau bits), pour le moment il est prévu de les prendre en charge par des libraries optimisées (notamment via iFUNC) maintenant que depuis le noyau Linux 6.3 les fonctionnalités du CPU sont exposées via le syscall hwprobe.
#2.3
Merci de tes précisions
#3
Ce serait surtout la pire des conneries à faire… A croire que Microsoft et Intel avaient qq anciens du DOS à occuper avant le retraite pour spécifier cet immondice. Il ne faut vraiment pas avoir mis son nez dans le sujet un jour pour dire une connerie pareille!!!
#3.1
(rester poli … rester poli …)
La façon dont c’est mis en oeuvre, je suis d’accord, c’est vraiment pas beau.
Par contre, la fonctionnalité est PRIMORDIALE. C’est ça le plus important. J’en ai plus que marre de ne pas pouvoir choisir l’OS que j’utilise sur mon matériel (ARM j’entends) parce qu’il n’a pas d’image à flasher pour ma plateforme. Pour les plateformes Risc-V, y’a un coup à jouer.
#3.2
RISC-V est fait pour les ordinateurs de bureau, les serveurs et pour le HPC, pas pour les smartphones.
#3.3
C’était au début. Mais depuis l’ajout de l’extension C (ainsi que le standard RV32E dans une autre mesuure), RISC-V me semble adapté pour des smarpthones également.
La phrase dans la spécification qui me fait dire ça :
“The philosophy of RVC is to reduce
code size for embedded applications and to improve performance and energy-efficiency for all
applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches
25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly
the same performance impact as doubling the instruction cache size”
( The RISC-V Instruction Set Manual / Volume I: Unprivileged ISA / Document Version 20191213 / §16.1 )
#4
SURTOUT PAS, le BIOS a rempli son rôle en son temps mais ça a finit en énorme fourre-tout non documenté, propriétaire et à moitié buggué tandis que l’UEFI suit exactement le même chemin en proposant en plus des fonctions redondantes avec le BIOS, ex: int 15h e820 vs GetMemoryMap() qui retournent des résultats différents…
Pour le boot : Il suffit simplement que le matériel propose une manière de booter à peu près simple, genre un noyau appelé X dans une partition Y
Pour l’énumération du matériel : devicetree, par contre je crois qu’il faut qu’il soit compilé contrairement aux overlays ce qui n’est pas terrible pour tester différentes distrib, il doit sûrement y avoir un moyen pour rendre ça plus dynamique avec l’initramfs mais je laisse les experts le dire
#5
Plutôt d’accord en effet, il y a eu une certaine standardisation “de fait” mais c’était tout de même le farwest lorsque les nouveautés apparaissaient. Mais je crois que c’était surtout du au fait que le marché était en plein essor et qu’il fallait faire les choses et “qu’on verrait après”.
C’est-à-dire ? Parce que pour moi, l’UEFI est tout de même une tentative d’uniformiser (avec version) un système de base embarqué. Je peux être d’accord pour dire que les documents de spécifications sont imbuvables. (Je n’ai jamais réussi à lire entièrement et en avoir une notion globale. C’est vraiment écrit pour ceux qui sont dedans toute la journée) Mais je pense qu’il est tout de même plus “facile” de suivre ces lignes conductrices commune que d’avoir pléthore d’implémentations de BIOS (parfois incompatibles)
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/15_System_Address_Map_Interfaces/Sys_Address_Map_Interfaces.html
La réponse à ta frustration (surtout le point 15.2)
#6
OK, on est d’accord sur ce point… Mais si côté ARM c’est le bazar, c’est surtout car ils ont mal utilisé ce qu’ils avaient à dispo afin de faciliter la détection matérielle: Les device-tree permettent d’assurer la fonctionnalité, il aurait suffi de les intégrer d’une manière standardisée au matériel pour tout ce qui est pluggable et dans un coin read-only de la bootflash pour ce qui est intégré à la mobo (ou sbc). Tous les boot-loader permettent le merge de device-tree depuis des lustres.
Quand on compare un u-boot à un BIOS/UEFI, franchement, l’élégance de conception va clairement au 1er (idem entre Linux et windows).
Un UEFI actuel, mélange des reference code du fondeur (Intel/AMD), d’EDK2, du code legacy de l’intégrateur (AMI, Phoenix, Insyde se partageant un marché rendu captif par les fondeurs x86), c’est quand même un nb de lignes de code comparable au kernel Linux. Avec des monceaux de cochonneries qui ne passeraient aucune revue de code interne dans l’industrie… mais y échappe car c’est justement un composant externe!
#6.1
Je n’ai jamais mis mon nez là dedans, mais en effet ça a la réputation d’être bien sale
(”ACPI was designed by a group of monkeys high on LSD” - Torvalds).
Mais on semble être bien d’accord qu’il manque vraiment un équivalent ARM (en terme de fonctionnalité).
#7
En fait, ça ne manque pas vraiment. C’est juste que les device-tree (DT, cad le standard hors x86/ACPI côté ARM/PowerPC/MIPS et sans doute RiscV) permettant de déclarer/décrire le matériel (fonctionnalités, mappings interne registres de config et irq…) sont trop souvent… dans le soft plutôt qu’attachés au matos (et lisibles d’une manière standardisée) pour permettre une configuration adaptée au matériel d’un OS générique: On économise du matos (genre petites flash spi pour contenir les bouts de DT à merger par le boot loader avant de les filer à l’OS afin qu’il démarre en sachant quel matos est présent) mais derrière vogue la galère…
Le pb d’ARM est en fait que cela dépasse… ARM, qui n’est généralement que le coeur d’un SoC ou chacun ajoute ses propres IP comme il le veut, avec un beau bazar à la clef. La pression sur les prix y est aussi pour qq chose, la moindre économie de bout de chandelle étant moins négligeable que dans le monde PC.
C’est d’ailleurs le point fort de Raspberry que d’avoir un bon suivi Linux, car chez les concurrents c’est pas fait au delà d’une distro customisée en début de commercialisation et abandonnée juste après. Et en l’état c’est bien du travail!