URL: https://linuxfr.org/news/premiers-pas-avec-la-carte-visionfive-2 Title: Premiers pas avec la carte Visionfive 2 Authors: Arkem BAud, palm123, Yves Bourguignon et Ysabeau Date: 2023-05-14T14:06:20+02:00 License: CC By-SA Tags: Score: 6 Depuis plusieurs années déjà, diverses cartes permettent de tester l’architecture [RISC-V](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce). Après quelques expérimentations, voici mes premières impressions… ---- [VisionFive 2](https://www.starfivetech.com/en/site/boards) [RISC-V International](https://riscv.org/) [RVspace](https://rvspace.org/en/home) [Journal sur la Star64](https://linuxfr.org/users/bortzmeyer/journaux/une-nouvelle-carte-a-processeur-risc-v-la-star64) ---- 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](https://www.sifive.com/boards/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](https://www.sifive.com/boards/hifive-pro-p550) en partenariat avec Intel, qui produira le SOC nommé [Horse Creek](https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/What-s-in-store-for-the-latest-RISC-V-development-board/post/1448348). Les deux autres, la [Star64](https://wiki.pine64.org/wiki/STAR64) et la [VisionFive2](https://www.starfivetech.com/en/site/boards), sont presque identiques car basées sur le même SOC [JH7110](https://www.starfivetech.com/en/site/soc). Elles disposent toutes deux d’un processeur 64 bits à quatre cœurs [U74](https://www.sifive.com/cores/u74) et d’un processeur 32 bits [E24](https://www.sifive.com/cores/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](https://blog.bitsofnetworks.org/benchmarking-risc-v-visionfive-2-vs-the-world.html), 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](https://doc-en.rvspace.org/Doc_Center/visionfive_2.html), et [le SOC aussi](https://doc-en.rvspace.org/Doc_Center/jh7110.html). La prise en charge de [U-Boot](https://fr.wikipedia.org/wiki/Das_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](https://riscv.org/) travaille depuis fin 2018 en [collaboration avec la fondation Linux](https://riscv.org/about/history/#international). Outre la distribution [Debian](https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202303_Release), [Armbian](https://www.armbian.com/visionfive2/), [Fedora](https://forum.rvspace.org/t/fedora-37-on-the-visionfive-2-unofficial-build/2108), [Arch](https://forum.rvspace.org/t/arch-linux-image-for-visionfive-2/1459), [Ubuntu](https://wiki.ubuntu.com/RISC-V/StarFive%20VisionFive%202) et [FreeBSD](https://forum.rvspace.org/t/freebsd-support/1313) 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](https://github.com/starfive-tech/VisionFive2/releases). 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](https://doc-en.rvspace.org/VisionFive2/Boot_UG/VisionFive2_SDK_QSG/boot_mode_settings.html) 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](https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202303_Release), 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 : 1. Récupérer les fichiers u-boot-spl.bin.normal.out et visionfive2_fw_payload.img sur la [page GitHub officielle](https://github.com/starfive-tech/VisionFive2/releases). 2. Les placer sur un serveur TFTP connecté en Ethernet à la carte. 3. Brancher un adaptateur UART sur le GPIO de la carte : 6 GND, 8 TX, 10 RX. 4. Redémarrer la carte sans MicroSD. 5. À l’invite de U-Boot, lancer les commandes suivantes : ```bash 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 $filesize ``` Ceci 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](https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc). 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 ----------- 1. 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. 2. Le SPL (Secondary Program Layer, une partie de U-Boot) initialise la DRAM de manière à pouvoir y lire le reste du boot-loader. 3. Le binaire contenant le boot-loader complet commence par [OpenSBI](https://riscv.org/wp-content/uploads/2019/06/13.30-RISCV_OpenSBI_Deep_Dive_v5.pdf) 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. 4. [U-Boot](https://fr.wikipedia.org/wiki/Das_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. 5. Linux est le noyau officiel, aussi bien pour RISC-V que pour U-Boot, mais celui de FreeBSD [semble aussi en bonne voie](https://forum.rvspace.org/t/freebsd-support/1313). Installation sur SSD =========== L’[image expérimentale de Debian](https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202303_Release) 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, c’est comme une partition /boot, mais l’objectif à plus long terme est de se conformer au « [Generic Distro Configuration Concept](https://u-boot.readthedocs.io/en/latest/develop/distro.html) », qui consiste à utiliser U-Boot comme firmware depuis l’ISP pour démarrer un autre boot-loader, soit depuis un secteur MBR, soit depuis une 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](https://jamesachambers.com/starfive-visionfive-2-debian-ssd-boot-guide/), ç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](https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202303_Release) 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 : ```bash 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.sh ``` On 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](https://riscv.org/members/), ainsi que des clients comme l’[Union européenne](https://digital-strategy.ec.europa.eu/fr/library/recommendations-and-roadmap-european-sovereignty-open-source-hardware-software-and-risc-v) semblent s’intéresser sérieusement au RISC-V est prometteur pour le développement de cette architecture, en tout cas.