Depuis plusieurs années déjà, diverses cartes permettent de tester l’architecture RISC-V. J’ai longuement hésité à sauter le pas jusqu’à l’arrivée de la Visionfive2 et de la Star64, toute deux conçues à partir du même SOC. Après quelques expérimentations, voici mes premières impressions…
Sommaire
- Choix de la carte
- Vérification
- Accès à une version plus complète du système
- Processus de démarrage
- Installation sur SSD
- Environnement graphique
- Mes impressions
Choix de la carte
C’est un choix personnel, mais qu’il s’agisse d’ARM ou de RISC-V, je passe mon chemin s’il n’y a pas au minimum une interface Ethernet et un support de stockage performant NVME ou SATA, ou au moins un connecteur PCIe, qui soient directement gérés par le SOC plutôt que par un bus USB intermédiaire. Ça fait déjà un très gros tri, car ces cartes ne sont pas les plus nombreuses.
La première carte RISC-V qui m’intéressait était la Hifive Unmatched. Son format et ses fonctionnalités étaient tentantes, mais, bien qu’assez onéreuse, elle était constamment en rupture de stock avec plusieurs mois d’attente. La société SiFive a finalement décidé de cesser sa production, et de préparer sa succession, la Hifive Pro P550 en partenariat avec Intel, qui produira le SOC nommé Horse Creek.
Les deux autres, la Star64 et la VisionFive2, sont presque identiques car basées sur le même SOC JH7110. Elles disposent toutes deux d’un processeur 64 bits à quatre cœurs U74 et d’un processeur 32 bits E24 utilisé comme coprocesseur pour effectuer des tâches basse consommation, de deux interfaces Gigabit, d’un GPU capable de rendus OpenGL et Vulkan, de ports USB 2.0 et 3.0, d’un connecteur GPIO 40 broches, est sont proposées en trois versions qui diffèrent par la quantité de RAM : 2, 4, ou 8 Go. La seule différence entre les deux cartes étant la présence d’un connecteur PCIe sur la Star64, tandis que la VisionFive2 est équipée d’un connecteur M.2 pour NVME. Le support de ce SOC très récent étant encore expérimental, j’ai choisi la VisionFive2 car je tenais à y ajouter rapidement un SSD.
D’après les benchmarks présentés sur Bits of networks, si les performances de cette carte sont nettement supérieures à celles de la Hifive Unmatched et de la première VisionFive, elles sont au niveau d’un RaspberryPi 3B en puissance brute CPU, mais très en dessous s’il y a beaucoup d’accès à la RAM. Concernant la consommation, il y a aussi une amélioration par rapport aux cartes RISC-V plus anciennes. À pleine charge, on est là aussi au niveau du RaspberryPi 3B, mais la différence entre une charge à 100 % et l’état idle est moins marquée que sur les SOC ARM. Les pilotes et la gestion d’énergie sont bien moins matures que sur ARM, cela dit, il est sans doute encore trop tôt pour tirer de réelles conclusions. Dans tous les cas, la différence avec le RaspberryPi 4 montre qu’il reste du chemin avant de concurrencer les machines ARM, pour s’en tenir à des choses comparables.
La carte est plutôt bien documentée, et le SOC aussi. La prise en charge de U-Boot semble très bonne, ainsi que celle du noyau Linux. Il est intéressant de noter à ce sujet que la fondation RISC-V International travaille depuis fin 2018 en collaboration avec la fondation Linux.
Outre la distribution Debian, Armbian, Fedora, Arch, Ubuntu et FreeBSD entre autres, sont en cours de portage sur cette carte.
Vérification
À la réception, la première pensée qui vient est de s’assurer quelle n’est pas défectueuse, et si la quantité de RAM est correcte aussi, car elle n’est indiquée ni sur la boîte, ni sur la carte.
Pour s’en assurer rapidement, deux méthodes sont possibles : soit utiliser un adaptateur USB → UART qui permet de suivre les étapes de démarrage du boot-loader (recommandé), soit flasher un système minimal qui permette au moins de lancer quelques commandes comme free, lscpu et lsblk. Dans ce dernier cas, le plus simple est d’utiliser l’image sdcard.img sur la page GitHub officielle. Cette image d’un système Linux très basique a l’avantage de fonctionner sans avoir à mettre à jour le firmware.
S’assurer que les dip-switches de la carte sont bien placés dans la configuration de démarrage par défaut, qui correspond au SPI. Pour l’instant, même pour démarrer sur une carte MicroSD, c’est la configuration pour SPI qui est utilisée.
Accès à une version plus complète du système
StarFive fournit une image expérimentale de Debian, mais il faut au minimum la version 2.11.5 du firmware parue en mars 2023 pour que la version actuelle démarre. Si comme moi, vous avez un firmware plus ancien, il faudra le mettre à jour de la manière suivante :
- Récupérer les fichiers u-boot-spl.bin.normal.out et visionfive2_fw_payload.img sur la page GitHub officielle.
- Les placer sur un serveur TFTP connecté en Ethernet à la carte.
- Brancher un adaptateur UART sur le GPIO de la carte : 6 GND, 8 TX, 10 RX.
- Redémarrer la carte sans MicroSD.
- À l’invite de U-Boot, lancer les commandes suivantes :
setenv ipaddr 192.168.120.222;setenv serverip 192.168.120.99
sf probe
tftpboot 0xa0000000 ${serverip}:u-boot-spl.bin.normal.out
sf update 0xa0000000 0x0 $filesize
tftpboot 0xa0000000 ${serverip}:visionfive2_fw_payload.img
sf update 0xa0000000 0x100000 $filesizeCeci n’est qu’une copie de la méthode fournie dans la doc officielle. Bien sûr, les variables « ipaddr » et « serverip » sont à adapter à vos besoins.
Processus de démarrage
Avant d’aller plus loin, il est intéressant de se familiariser avec le processus de démarrage de ce type de carte, et de quelques caractéristiques de l’architecture RISC-V.
Niveaux de privilège sur RISC-V
À l’exception notoire de l’architecture x86 avec ses 4, voire 5 « rings », les processeurs qui implémentent plusieurs niveaux de privilèges se contentent généralement d’un niveau superviseur pour le noyau et certaines parties du système, et d’un niveau utilisateur pour tout le reste. L’architecture RISC-V ajoute le niveau M, pour Matériel, qui se rapproche du ring -1 des x86_64, destiné à la gestion des VMs dont le système nécessite de tourner en ring 0.
Dans le cas de RISC-V, ce niveau permet aussi l’abstraction de certains accès au matériel, de manière à simplifier l’écriture de pilotes sur des implémentations variées via une couche dédiée appelée SBI pour Supervisor Binary Interface.
Les niveaux de privilège sont donc, dans l’ordre de démarrage :
M (Matériel) : Privilégié (ROM de boot, puis SBI)
S (Superviseur) : Privilégié (Boot-loader, puis noyau)
U (Utilisateur) : Non privilégié (Le reste)
Démarrage de la carte
- Le processeur démarre en mode M (Matériel) à l’adresse 0x2A00_0000 contenue dans une ROM interne au SOC. Sa principale fonction est de lire le SPL, la première étape du boot-loader en SRAM, et de l’exécuter.
- Le SPL (Secondary Program Layer, une partie de U-Boot) initialise la DRAM de manière à pouvoir y lire le reste du boot-loader.
- Le binaire contenant le boot-loader complet commence par OpenSBI qui fournit une couche d’abstraction de certains accès au matériel. Le processeur est alors passé en mode S (Superviseur), avant de passer la main à U-Boot.
- U-Boot est un boot-loader multi-architectures, très utilisé dans l’embarqué et les cartes de développement ARM et RISC-V. Il est capable d’utiliser de nombreux périphériques de stockage et systèmes de fichiers, et fournit une console de commande assez complète en cas de besoin. Sa fonction principale est de charger le noyau et ses dépendances en mémoire avant de lui passer la main.
- Linux est le noyau officiel, aussi bien pour RISC-V que pour U-Boot, mais celui de FreeBSD semble aussi en bonne voie.
Installation sur SSD
L’image expérimentale de Debian est assez simple à installer sur SSD, mais en attendant une mise à jour du firmware qui permettra le démarrage sur NVME à partir du SPI, la partie qui sert à l’amorçage doit rester sur une carte SD ou eMMC. Au minimum, une partition racine doit être crée sur le SSD. Pour cela, gdisk et fdisk sont pleinement fonctionnels. Il ne reste qu’à la formater et la monter, puis de recopier le contenu de l’image Debian dedans.
La carte utilisée pour l’installation ou une copie peut être utilisée pour l’amorçage. Seules les trois premières partitions sont nécessaires. La première contient le SPL. La seconde contient le boot-loader constitué du SBI, puis de U-Boot. La troisième est une partition EFI qui contient le noyau avec ses fichiers, et la configuration de démarrage de U-Boot. Pour l’instant, elle est utilisée comme une partition /boot, et conforme au « Generic Distro Configuration Concept » de U-Boot, mais d’après Debian l’objectif à plus long terme est d’utiliser U-Boot comme un firmware pour démarrer un autre boot-loader depuis la partition EFI, ce qui. simplifierait la gestion du démarrage pour les distributions.
Les trois fichiers à éditer pour configurer le démarrage, sont /etc/fstab, bien évidemment, mais aussi /etc/default/u-boot, et sur l’EFI, extlinux/extlinux.conf. Il est indiqué au début de ce fichier de ne pas l’éditer directement, mais comme expliqué ici, ça se fait très bien malgré tout. Remplacer simplement toutes les occurrences de /dev/mmcblk0p4 par /dev/nvme0n1p1, ou tout autre numéro de partition que vous aurez choisi d’utiliser pour la racine du système dans ces deux derniers fichiers.
Après redémarrage, on se retrouve normalement sur le SSD. Il ne reste plus qu’à ajouter les composants manquants, non disponibles sur Debian, car encore en version expérimentale chez StarFive. À ce sujet, la documentation conseille de ne pas faire directement un apt-get upgrade, car les versions de mesa et linux-libc-dev sont patchées, et différentes de la version officielle de Debian. Pour ajouter les autres binaires modifiés par StarFive, lancer :
wget https://github.com/starfive-tech/Debian/releases/download/v0.7.1-engineering-release-wayland/install_package_and_dependencies.sh
chmod +x install_package_and_dependencies.sh
sudo ./install_package_and_dependencies.shOn obtient entre autres, des versions optimisées de LibreOffice, QT, Firefox et FFMPEG.
Environnement graphique
L’image disque proposée par StarFive comprend un bureau GNOME reposant sur Wayland. Au premier lancement, j’ai eu droit à une interface rosâtre, mais fonctionnelle. D’après la documentation, lancer le script /opt/disable_monitor_color.sh et redémarrer permet de résoudre le problème de couleurs. J’ai donc tenté l’expérience pour me retrouver avec un écran bleu clair sans aucune interface de connexion… après un nouveau redémarrage, l’interface est redevenue rose et fonctionnelle, mais un changement de résolution m’a permis d’obtenir des couleurs normales. Ces problèmes étant connus, on peut s’attendre à ce qu’ils soient corrigés prochainement, dans une nouvelle version du système.
Démarré sur microSD, le lancement des applications graphiques est désagréablement lent, à tel point qu’on se demande parfois si le programme n’a pas planté. Sur SSD par contre, l’ensemble est plutôt agréable à utiliser. Le déplacement des fenêtres est assez fluide, et le lancement des applications, sans être rapide, reste acceptable. Writer m’a paru fonctionner convenablement, et Calc aussi à part de légères latences en remplissant les cellules. Firefox se comporte très bien. Le défilement des pages de LinuxFr est sans accrocs, et regarder le direct d’ARTE en plein écran (1920x1080) m’a fait rapidement oublier que je testais un système expérimental.
Mes impressions
Si l’électronique semble stable, la partie logicielle, aussi bien au niveau du firmware que des distributions, est encore très expérimentale. Il ne vaut mieux pas prévoir l’utiliser en « prod » pour l’instant, en tout cas pas sans une bonne dose de vigilance.
Les performances sont perfectibles, mais elles sont suffisantes pour tester l’architecture RISC-V dans de bonnes conditions. Les logiciels patchés fournis par StarFive montrent qu’à moyen terme, la carte devrait être utilisable en environnement graphique, mais il est encore trop tôt pour comparer RISC-V à d’autres architectures très répandues qui ont plus de maturité. Le fait qu’un nombre croissant de sociétés, ainsi que des clients comme l’Union européenne semblent s’intéresser sérieusement au RISC-V est prometteur pour le développement de cette architecture, en tout cas.
Aller plus loin
- VisionFive 2 (173 clics)
- RISC-V International (27 clics)
- RVspace (19 clics)
- Journal sur la Star64 (68 clics)
# Merci
Posté par antistress (site web personnel) . Évalué à 10.
Merci pour cette dépêche très complète, comme un certain nombre ici je suis avec attention le déploiement de l'arch RISC-V et ton retour est passionnant à lire
# En data center
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
J'ai du modifier certaine chose pour activer les 8G et pour la puissance le SoC chauffe pas mal (j'ai du fabriquer un dissipateur).
Un fois tout en place, avec un bon gros m.2, j'ai mis tout cela en ligne pour que tout le monde puisse acheter un VPS (lxc) sur ce matos.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: En data center
Posté par tao popus . Évalué à 4.
Visiblement, il n'y a toujours pas de baisse de fréquence possible, le processeur tourne donc toujours à pleine puissance, ce qui explique la surchauffe.
# UEFI
Posté par Pinaraf . Évalué à 5.
Yay, encore des machines où on va mettre de l'UEFI parce que … parce que quoi en fait ? y'a un Windows RISC-V prévu bientôt, avec uniquement le support de ce firmware ?
[^] # Re: UEFI
Posté par tao popus . Évalué à 10.
Non, ça sert à rien et pas de Windows de prévu pour l'instant sur RISC-V, et ça intéresse qui??? D'autre part, UEFI c'est uniquement fait pour continuer à utiliser du BIOS avec tous ses blobs binaires proprio. Device tree fait mieux et de façon plus propre le boulot. Ça permet une réutilisation (dans U-Boot, CoreBoot, LinuxBoot (dont le but est d'unifier le Noyau et la partie boot) et par différetnts OS embarqués libres par exemple, des informations des pilotes. Et bénéficie d'un peu de relecture par des paires, comme l'ensemble de Linux ou les spécifications de RISC-V. Et ça n'apporte rien non plus, un kernel générique basé sur Device tree, est également identique pour toutes les cartes ARMv7 aujourd'hui, UEFI n'apporte aucunement plus de portabilité.
Il n'y aura pas d'applications avant longtemps pour Windows non plus, puisqu'on sais même pas si Microsoft prévoit un portage à court terme, par contre toutes les distros majeures Linux/BSD et même Haiku fonctionnent déjà sur RISC-V, sans parler des OS embarqués qui le sont depuis encore plus longtemps. Il reste quelques JIT à (finir de) porter et c'est fondamental, on ne s'en rend pas forcément compte, mais le travail est quasi achevé
Il faut savoir que si les spécifications de l'ISA RISC-V sont ouvertes et libre de droit, ça n'est pas toujours le cas des implémentations. Il en existe tout un tas d'ouvertes, mais pas celles de SiFive utilisées dans le SoC de la VisionFive 2, malheureusement.
Le firmware est donné au goutte à goutte, par JH, la doc est inexistante et les firmware ne semble pas top (déjà pas de baisse de fréquence possible), il y a beaucoup de travail de hackers pour que cela fonctionne.
Sinon, le SoC T-Head TH1520 de la LicheePi4A est bien plus intéressant, non seulement l'implémentation des (4 également) cœurs + de différents cœurs annexes (comme le DSP basé sur du RISC-V aussi) sont ouvertes (les sources en Verilog sont dispo sur github entre autre), contrairement aux cœurs de SiFive, mais en plus les performances sont supérieures, et il y a des processeurs vectoriels intégrés et le GPU (PowerVR aussi, mais gamme au dessus, pilotes en cours d'ouverture aussi) est un poil plus performant également. L'intégration mainline est en court, le travail fait sur l'AllWinner D1, également basé sur les cœurs et différents autres composants de T-Head permet d'avoir déjà une base. Une version 64 cœurs à également été développée et les premières implémentations devrait être disponibles d'ici 1 ou 2 mois. Les performances d'après les quelques personnes qui ont put les tester sont alléchantes :).
[^] # Re: UEFI
Posté par Arkem . Évalué à 1.
Je n'ai vu aucune mention d'uEFI à propos de cette carte. Si tu as des infos, ça m'intéresse. Sinon, il y a bien l'EFI qu'il est prévu de prendre en charge, mais c'est juste un partition de démarrage. Je ne vois pas en quoi ça pose problème.
[^] # Re: UEFI
Posté par Pinaraf . Évalué à 5.
L'article parle clairement d'une partition EFI, je suppose pour désigner une partition d'UUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B sur une table GPT, ie une "EFI System Partition".
Si le but est d'utiliser une partition ESP pour ne pas y stocker des exécutables EFI mais plutôt pour y stocker des fichiers arbitraires, mea culpa dans ce cas, mais c'est un détournement dégueulasse.
Je pensais qu'il s'agissait plutôt de ce genre d'utilisation d'u-boot, dans l'exemple ici pour le projet Fedora qui souhaiterait ne pas se poser la question et avoir un environnement UEFI au démarrage, y compris sur les x86 à BIOS…
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GOETDM5SWINBX5ZDV37SWMHIPRRUVVTT/
Et si on est dans ce cas, je trouve ça terriblement triste. J'ai déjà goûté de loin à de l'OpenFirmware, et de plus près à du PetitBoot, et je trouve PetitBoot extraordinaire par rapport à l'enfer d'un UEFI. (Et quand j'aurai du temps libre, je finirai ce que je compte bidouiller sur PetitBoot et j'en ferai un journal, promis.)
Je ne comprends pas pourquoi on s'imposerait cette calamité sur des plateformes qui n'ont clairement pas mérité ça.
[^] # Re: UEFI
Posté par Arkem . Évalué à 2.
D'accord, je comprends mieux ton point de vue.
Je ne suis pas aussi connaisseur que toi sur le sujet. Dans la doc où j'ai découvert de projet, il est question d'une image EFI de GRUB, logée dans la partition EFI, et qui serait exécutée par U-Boot. Quand tu as parlé d'UEFI, j'ai pensé que tu parlais du firmware de la carte.
En tout cas, je serai très intéressé de découvrir PetiBoot si tu écris un journal dessus.
[^] # Re: UEFI
Posté par Pinaraf . Évalué à 4.
Une image EFI de grub implique qu'un environnement UEFI tourne, avec tous ses "Boot Services" et tout le toutim.
D'ailleurs ton lien sur OpenSBI mentionne bien l'idée de reprendre EDK2, implémentation libre d'UEFI…
[^] # Re: UEFI
Posté par Arkem . Évalué à 2.
Je n'avais pas creusé le sujet aussi loin.
Merci pour ces précisions
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . É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.
[^] # Re: UEFI
Posté par tao popus . Évalué à 3.
Non, ça n'est pas le standard, c'est un des standard, l'autre étant device tree, qui garanti une meilleure portabilité, des pilotes plus légers etc, et qui ne favorise pas les firmwares fermés. Comme je disais les
Aucun rapport, les firmwares restent spécifiques à chaque plateforme, comme dans le cas du BIOS, ils sont juste fermé et ça paraît donc transparent pour l'utilisateur, mais il n'y a pas de miracle, il faut bien initialiser et communiquer avec les différents composants. Device tree utilise une interface unifiée, stable et légère, facilement gérable, contrairement à UEFI. Une initialisation via device tree, permet également de démarrer de façon transparente sur différent type de cartes ayant la même architecture de processeur, c'est ce qui est utilisé par exemple par Arch Linux ARM. UEFI c'est un retour à l'ère de BIOS, il faut bien prendre conscience de ça.
[^] # Re: UEFI
Posté par xcomcmdr . Évalué à 3. Dernière modification le 19 juin 2023 à 15:04.
L'EFI ayant été vendu comme un tout nouveau monde par rapport au BIOS antédiluvien (qui avait d'énormes soucis), c'est ballot !
Je suis pas du tout expert sur le sujet, mais alors pourquoi l'EFI et toute la complexité qui va avec, sans parler du Secure Boot, partition GPT, la disparition du legacy mode, etc… ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: UEFI
Posté par tao popus . Évalué à 2. Dernière modification le 20 juin 2023 à 18:27.
C'est l'industrie liée au BIOS et à Windows qui le met en avant, pour pouvoir continuer à cacher le code de leur pilotes pourris, pas les développeurs Linux. Linux utilise Device Tree par défaut, comme u-boot, Apache Nutt-X et pas mal d'autres systèmes.
[^] # Re: UEFI
Posté par xcomcmdr . Évalué à 1.
ça ne répond en rien à ma question.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
La complexité est surtout pour les utilisateurs, pour plusieurs raisons. Pour les développeurs, le BIOS, non merci…
Quelques raisons:
Quand aux autres sujets:
[^] # Re: UEFI
Posté par xcomcmdr . Évalué à 2.
Voilà, l'UEFI n'a rien à voir avec le BIOS ou l' "industrie du BIOS", ni le device tree.
Merci. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: UEFI
Posté par pulkomandy (site web personnel, Mastodon) . É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:
[^] # Re: UEFI
Posté par Pinaraf . Évalué à 3.
Alors je ne suis pas beaucoup intervenu dans ce fil, mais note bien que ma déception est quant au choix d'UEFI, pas quant au choix d'avoir un firmware ou non. Je maudis les cartes ARM "nues".
D'ici quelques semaines (le temps de finir le remplacement de mon serveur actuel un peu limite) je n'aurai plus que des cartes ARM64 équipées d'un Petitboot. Et pour le coup, ça me semble répondre au problème bien plus proprement qu'un UEFI : au lieu d'avoir une réinvention de toute la pile de stockage, le réseau, l'affichage et je ne sais combien d'autres pilotes, on prend un noyau Linux et on le colle dans l'EEPROM, et une simple appli en espace utilisateur, remplaçable/bidouillable à souhait, s'occupe d'afficher un menu, charger l'OS cible…
[^] # Re: UEFI
Posté par nonas . Évalué à 2.
Il existe quoi comme carte ARM64 un peu péchu et bien prise en charge upstream ?
Tu utilises quoi comme carte avec petitboot ?
[^] # Re: UEFI
Posté par xryl669 . Évalué à 3.
Je pense pas que device tree ait le moindre lien avec UEFI. Le device tree, c'est juste une description, binaire, de ce que la machine a comme périphériques. Le device tree n'a aucun "driver", aucun code, rien n'est exécuté sur/avec le device tree.
Le device tree est utilisé par linux, une fois démarré pour savoir quel driver installer et lancer (il faut donc qu'ils soient compilé dans l'image Linux, ou via des modules dans le initrd / rootfs).
L'UEFI, c'est un OS avant l'OS. Il implémente un mini OS suffisant pour démarrer un vrai OS (et accessoirement, valider que le vrai OS est bien celui qui est autorisé). C'est, fonctionnellement, comme u-boot, pas étonnant que u-boot ait implémenté les API UEFI.
Les drivers de ce mini OS sont spécifiques à ta machine, il n'est pas question d'avoir tous les drivers du monde comme linux, il faut juste pouvoir faire les opérations de base, c'est à dire pouvoir charger des données d'un support de stockage, démarrer la mémoire et le CPU, accessoirement afficher quelque chose (via un écran ou un port série ou le réseau) et passer la main.
Quelque soit la machine, l'API de ces drivers est standardisée en UEFI (contrairement à u-boot, où c'est de l'open source, comprendre: chacun sa sauce), donc c'est plus simple pour les vendeurs d'OS et les fabricants de matériels. C'est inutile pour une carte avec un microcontrolleur où les composants physiques sont connus et fixes (ici, u-boot suffit avec ses drivers spécifiques), mais pour un PC où chaque composant provient d'un fabricant différent inconnu avant l'assemblage (mémoire, carte réseau, GPU, etc…), c'est indispensable.
# au final...
Posté par Psychofox (Mastodon) . Évalué à 6.
…toutes ces cartes de developpement c'est bien mignon mais ça reste de la pollution électronique.
Pauvres en performances, les gens achètent la nouvelle à la mode, se font 2-3 projets diy ou mini serveur…puis une autre sort et ils l'achètent. L'ancienne termine au mieux dans un tiroir ou revendue, pour dans quelques années finir dans cette vaste blague de filières de recyclages…qui les amènera tout droit dans les décharges à ciel ouvert au Ghana, Nigeria et d'autres pays africains où les habitants s'intoxiquent et contaminent leur sols en tentant de subsiter de l'extraction de l'or et du cuivre.
Acheter ces nombreuses cartes, que dis-je gadget, c'est se rendre complice de ce désastre quand il y a déjà tant de matériel bien plus puissant déjà à disposition sur le marché de seconde main.
[^] # au final... ou entre temps ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Ça s'est à moyen terme non ? Mais sur le long terme que peut-on espérer ? Ayant cru comprendre que l'architecture de ces plateformes est plus ouvertes j'anticipe, peut-être naïvement, qu'elles puissent permettre à plus d'acteurs d'entrer sur le marché ; partant, plus d'intelligences seraient au travail pour améliorer les choses ; de là à prévoir un point de croisement en termes d'efficacité entre architectures fermées et libres… Rêves brumeux d’ignorant peut-être.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: au final... ou entre temps ?
Posté par Psychofox (Mastodon) . Évalué à 10.
Ça n'a rien de openhardware. Les instructions risc sont peut-être ouvertes et ne nécessite pas de payer des royalties à Arm, mais t'as toujours besoin de firmware pour les différents composants des cartes, qui resteront vraisemblablement fermés. Pour l'utilisateur final concrètement ça ne va pas nous amener du hardware complètement libre par magie.
La stratégie des entreprises comme SiFive, c'est de faire de la R&D sur du RISC, démontrer qu'ils peuvent faire quelque chose de correct, pour dans le futur être rachetés par un des géant qui voudrait ne plus être dépendant d'Intel ni de payer de royalties à Arm pour leurs propre hardware, que ce soit du serveur pour du cloud ou de l'IOT/embarqué.
L'objectif ce n'est pas du tout de développer des solutions desktops/laptops ouvertes pour l'utilisateur final.
[^] # Re: au final... ou entre temps ?
Posté par tao popus . Évalué à 6.
Dans le cas des cœurs SiFive, c'est un peu vrai, mais quasiment tout est déjà mainliné sur cette carte (en grande partie à coup de reverse), donc, non pas de firmware fermé, sur les procs de T-Head, ils travaillent eux même à l'intégration dans Linux par contre et font du assez bon travail.
Il n'y a pas que SiFive qui fait du RISC-V, niveau perfs les T-Head sont meilleures, et ont différentes finalités : processeurs pour desktop (le TH520, 4 cœurs, GPU, NPU, VPU, etc…), pour serveurs (un 64 cœurs), et d'autres déclinaisons, mais il existe différents autres acteurs faisant des cœurs RISC-V ouverts, dont les pilotes libres existent. Le but pour les sociétés asiatiques et européennes étant en partie de se débarrasser de leur dépendance à l'industrie de la Silicon Valley (en grande partie financée par l'armée) et de ses pressions sur les industriels et états. C'est aussi pour ça que la fondation RISC-V à déménagé en Suisse il y a quelques années.
Il y a également CAES qui à sorti NOEL-V en verilog, sous license GPL pour les satellites de l'ESA, ceux de l'Académie des sciences de Chine (Xianshan, etc…) et plus généralement des universités autour du monde, des amateurs éclairés, ou des sociétés. Au niveau de l'embarqué Espressif à sorti plusieurs SoC RISC-V également avec leur framework ESP-IDF complètement ouvert. Les SoC GD32V ont des pilotes ouverts aussi. Par contre le BIOS est complétement fermé, peu de carte x86/x86_64 ont la totalité de leur pilotes libres.
[^] # Re: au final... ou entre temps ?
Posté par xryl669 . Évalué à 2. Dernière modification le 22 juin 2023 à 18:32.
Espressif, le firmware n'est pas ouvert, tu te trompes, tu confonds avec esp-idf qui est ouvert, mais qui se repose sur:
1. Le code en ROM (vérifie les scripts de l'éditeur de lien, tu verras, en gros, la libc est en ROM, la gestion des MMU est en ROM, etc…)
2. Des librairies statique en .a précompilés (pour le WIFI, le Bluetooth, le SOC, l'implémentation bas niveau de FreeRTOS, etc…) qui seraient, sous linux, des binaires firmwares.
Mais après tout, on s'en fiche un peu qu'il soit ouvert, vu que tu peux pas le modifier de toute façon (tu peux pas changer l'architecture du CPU, ni le hardware, ni le plan mémoire, ni…). C'est une plateforme très ouverte et documentée par rapport à la concurrence, type STM32 ou autre, mais certainement pas libre.
RISC-V sur ESP32-C est pas plus ouvert que le Tensilica LX7 des ESP32-S.
[^] # Re: au final...
Posté par Arkem . Évalué à 10. Dernière modification le 24 mai 2023 à 08:32.
On peut dire ça d'à peu près tout ce que les gens "consomment" pour se faire plaisir, ou pour du confort en général.
Si ça ne t'intéresse pas plus que ça, et que ça finit rapidement dans un tiroir, ce n'est pas une bonne idée que tu en achète une, je suis d'accord.
Mais pour quelqu'un qui y trouve une réelle utilité, parce que c'est beaucoup plus rapide et efficace qu'une VM sous QEMU pour expérimenter une architecture, par exemple, ça ne me paraît pas si stupide. Tout dépend de ce qu'on en fait, et de la durée d'utilisation.
Quand aux machines plus puissantes, je n'en veux pas chez moi pour mes serveurs perso, car c'est la consommation électrique que je vise en premier, et les machines ARM que j'utilise remplissent suffisamment mes besoins pour ne pas avoir à les remplacer de si tôt.
Après, les choses qu'on achète par curiosité, et qu'on utilise pas ou très peu, il y en a de toutes sortes, et c'est un désastre, je suis d'accord. Mais même s'il est évident que certains produits polluent plus que d'autres, c'est la personne qui évalue mal ses besoins ou ses envies qui pose le plus problème dans ce cas, à mon avis.
Mes deux cents…
[^] # Re: au final...
Posté par Psychofox (Mastodon) . Évalué à 0. Dernière modification le 24 mai 2023 à 09:35.
Machine plus puissante n'induit pas forcément une conso énergétique plus importante de manière significative. D'autant plus si tu concentres sur un emachine ce que tu peux faire en plusieurs petites SBCs parce qu'une seule n'est pas suffisante. Une fois que tu commences à empiler les SBC, leur ajouter du stockage, avoir des I/O et éventuellement un écran, l'intérêt énergétique disparait comparé à une machine unique sur laquelle tu peux mutualiser. Leur intérêt réside essentiellement dans la présence de l'interface GPIO.
Mais pour revenir au critère d'évaluation, regardes du côté des enthousiastes autour de toi et comptes ceux qui utilisent encore leur vieille raspberry pi 1 et 2 et compare avec ceux qui les ont remplacés par des pi 3 puis des pi4 ou n'importe lesquelles de leurs alternatives.
Mon commentaire t'emmerdes parce que t'as créé ce journal et tu te sens visé, mais qu'est-ce que tu espères pouvoir faire à long terme avec une carte de ce type? Tu le dis toi même c'est "suffisant pour tester". Donc si t'es un dev et que tu dois maintenir l'archi RISC d'une appli quelconque, pourquoi pas. Si t'as besoin de t'interfacer avec du hardware via les GPIO, pourquoi pas. Pour le commun des mortels et les curieux. Bof.
[^] # Re: au final...
Posté par Arkem . Évalué à 5.
J'aime bien recycler du vieux matériel, donc ça ne me pose pas de problème. L'un de mes petits serveurs était un vieux portable avec un écran HS qui a duré plus de 10 ans alors qu'il m'a posé toutes sortes de problèmes dés le début. Cela dit, la carte ARM qui a finit par le remplacer avec des performances qui dépassent mes besoins consomme deux fois moins en charge utile (>90% du temps) avec deux disques durs en RAID, contre un seul sur le portable, les deux sans écran, bien entendu. Ça fait maintenant 3-4 ans qu'elle tourne 24/7 sans problème, et je la trouve bien plus pratique à l'usage que mon vieux portable.
J'ai répondu en mon nom car mon cas est celui que je connais le mieux, mais je ne me suis pas spécialement senti visé, même si avec le recul, j'avoue que ma réponse donne cette impression. À l'exception des ARM, mes machines ont presque toujours été achetées d'occasion. Sauf défaut vraiment bloquant, je les utilise longtemps et j'ai souvent aidé d'autres personnes à faire durer les leurs, donc même si je comprends tes arguments, je ne me sentais pas spécialement visé avant que tu n'aborde le sujet…
Quand au commun des mortels, ce serait dommage de l'empêcher de s'intéresser à toutes sortes de choses dont il ne fait pas son métier, je trouve…
Au fait, j'ai dit qu'elle était suffisante pour tester à cause de l'aspect expérimental. J'espère bien pouvoir en faire quelque chose de plus quand la partie logicielle sera plus mature, sinon je ne l'aurais pas achetée !
# Coquille
Posté par Arkem . Évalué à 6.
Désolé, je me suis mélangé les pinceaux à propos du "Generic distro configuration" de U-boot. Ce n'est pas l'objectif recherché, mais la méthode utilisée actuellement. D'après la documentation de Debian pour VisionFive, le prochain objectif serait d'utiliser le même bootloader - GRUB pour les systèmes Linux - pour toutes les architectures.
Dans ce cas, U-boot remplacerait uEFI sur les plateformes qui ne l'implémentent pas pour démarrer le boot-loader de la distribution.
J'ai corrigé le texte pour éviter toute confusion.
# Merci !
Posté par loll . Évalué à 4.
Merci pour ce retour d'expérience.
Cette carte est actuellement une cible d'une version HAIKU donc dès que fonctionnelle, elle sera commandée :-)
[^] # Re: Merci !
Posté par Arkem . Évalué à 1.
Merci pour cette info, et pour le lien. Je serai curieux de voir comment le portage sur RISC-V évolue sur Haiku.
# Ubuntu marche
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Il parait : https://news.itsfoss.com/ubuntu-riscv-visionfive-2/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.