Ubuntu sur RISC-V via une carte HiFive Unmatched : ça marche

Ubuntu sur RISC-V via une carte HiFive Unmatched : ça marche

Et après ?

Avatar de l'auteur
David Legrand

Publié dans

Hardware

30/08/2021 7 minutes
16

Ubuntu sur RISC-V via une carte HiFive Unmatched : ça marche

Fin juin, Canonical annonçait une grande nouvelle : Ubuntu a été porté sur l'architecture RISC-V. En plus des Raspberry Pi, la distribution prend en charge les cartes de développement HiFive de SiFive. Nous avons mis la main sur l'une d'entre elles pour effectuer de premiers tests, signifiant l'ouverture d'un dossier au long cours.

Cela fait quelques mois maintenant que nous parlons de l'architecture RISC-V ici ou là. La raison est simple : il s'agit de l'un de nos sujets phares de la rentrée, qui sera traité... sous diverses formes.

RISC-V et SiFive à la conquête du monde

Alors qu'ARM est désormais un champion de l'offre grand public à travers les appareils mobiles et autres solutions embarquées, il veut monter en puissance dans les ordinateurs et les datacenters. Nous nous penchons sur cette alternative ouverte – l'étape d'après pour certains – qui pourrait à nouveau bouleverser l'informatique telle qu'on la conçoit. Au point que des acteurs comme Intel s'y penchent sérieusement.

Le géant américain a en effet fait revenir Sunil Shenoy, qui était vice-président de SiFive, une société qui développe des solutions autour de l'architecture RISC-V avec qui elle est désormais partenaire. Selon certaines rumeurs, un rachat serait même d'ores et déjà envisagé.

Canonical a de son côté annoncé s'associer à l'entreprise pour proposer des images d'Ubuntu consacré aux cartes de développement HiFive, ce qui implique de disposer d'une distribution moderne et complète, avec de nombreux paquets compilés pour une architecture RISC-V, ouvrant ainsi de nouvelles possibilités. 

Nous avons donc récupéré un modèle Unmatched (HF105) auprès de SiFive pour la tester. Elle est vendue 580 euros.

Transfert de l'image et première connexion

Nous ne reviendrons pas ici sur les caractéristiques ou le fonctionnement de la carte, qui feront l'objet d'un article dédié. Notre intérêt pour RISC-V s'exprimera en effet au long cours, sur plusieurs mois et à travers de longues séries de tests et analyses sur différentes solutions disponibles et autres projets en cours. Patience, donc. 

SiFive HiFive Unmatched
La SiFive Unmatch et son SoC Freedom U740

Pour commencer l'installation d'Ubuntu, il faut récupérer l'image adaptée à notre modèle. Celle d'Ubuntu 21.04 (Server) se trouve ici. Pour rappel, un forum de discussion dédié est disponible par là. On peut utiliser une carte SD ou un SSD M.2 comme périphérique de stockage, mais le boot passe forcément par la carte SD pour le moment.

SiFive recommande un modèle de classe A1 et d'éviter ceux de classe A2 qui posent parfois problème. Attention néanmoins au modèle choisi qui peut avoir un impact important sur les performances.

Ainsi, une carte SD comme la SanDisk Ultra de 32 Go est peu coûteuse, mais ses débits séquentiels sont proches de 40 Mo/s en lecture et 30 Mo/s en écriture, tombant à 5 Mo/s et 0,5 Mo/s sur des accès aléatoires 4K. Lors de nos premiers essais, tout était ainsi très lent, la mise à jour du système ayant mis près d'une heure. 

Nous avons donc opté pour un modèle Extreme Plus. Elle est vendue un peu plus cher, 15 euros environ pour 32 Go (SDHC), mais il s'agit toujours d'un modèle de classe A1 contrairement aux modèles de 64/128 Go (A2, SDXC). Elle est néanmoins certifiée U3 et V30 promettant de meilleurs débits.

En pratique, ils sont effectivement plus élevés, même si c'est encore loin d'être au niveau d'un HDD/SSD :

SanDisk Ultra 32 Go microSDSanDisk Extreme Pro 32 Go microSD
Les performances de la SanDisk Ultra 32 Go (à gauche) de la SanDisk Extreme Pro 32 Go (à droite)

Le transfert de l'image est simple. Sous Windows il peut être effectué via balena Etcher qui gère la décompression et la copie vers un tel périphérique de stockage (connecté via un adaptateur USB). Sous Linux, on peut utiliser dd. Dans ce second cas, Canonical préconise les commandes suivantes (remplacer XX par l'ID de votre périphérique) :

xz -dk focal-preinstalled-server-riscv64+unmatched.img.xz dd if=focal-preinstalled-server-riscv64+unmatched.img of=/dev/disk/by-id/XXX

Une fois l'image transférée, on insère la carte SD dans le lecteur, on alimente la carte mère (ATX 24 pins) et on y connecte les périphériques. Deux modes de contrôle sont possibles par défaut : via la console et le port microUSB (UART), ou en connectant une carte graphique, un clavier et une souris. Ubuntu ouvre aussi la voie de l'accès SSH.

Vous pouvez ainsi commencer par une mise à jour du système. Malgré notre carte SD plus rapide, elle a tout de même nécessité une bonne demi-heure, notamment à la mise en place de nouveaux noyaux :

sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove

Avec ou sans carte graphique ?

Pour ce premier essai nous avons été au plus simple : un clavier/souris sans fil et une Radeon RX 550. Celle-ci fait partie des modèles recommandés par SiFive, sans doute du fait de son « ancienneté » et de ses pilotes open source. Elle a aussi l'avantage de ne pas nécessiter de connecteur d'alimentation PCIe complémentaire. 

SiFive HiFive Unmatched

Une fois tous les éléments branchés et le bouton Power pressé, on voit les LED d'état s'activer. Le démarrage est un peu long, ce qui est classique avec une carte de développement. Il faut en effet ne pas oublier que l'on est là dans un produit qui doit permettre de comprendre et débugger, avec tout ce que cela implique. Pas d'un nouveau mini PC clé en main à placer sur votre bureau ou à utiliser sous votre TV. 

D'ailleurs, le petit ventilateur présent sur le SoC tourne assez vite et n'est donc pas silencieux. La carte n'est pas spécialement optimisée de manière à être économe en énergie au repos 24 watts sans carte graphique, 32 watts avec. Mais en pleine charge CPU sur l'ensemble des cœurs, cela change à peine : 26/34 watts.

Quid des performances ?

La performance de ces derniers est assez limitée comme le montrent nos tests OpenSSL et 7zip :

OpenSSL - Signatures/s RSA 4096 bits :

  • 1T : 11
  • 4T : 42

OpenSSL - Vérifications/s RSA 4096 bits :

  • 1T : 802
  • 4T : 3 202

7-Zip Benchmark :

  • Compress : 1 615 MIPS
  • Decompress : 3 418 MIPS
  • Total : 2 516 MIPS

Des chiffres qui positionnent la puce au-dessus d'un cœur de Raspberry Pi 400

Compilez votre première application pour RISC-V !

Cette plateforme se destine donc avant tout aux développeurs qui veulent faire leurs premiers pas sur RISC-V sans dépendre d'un émulateur, et veulent se frotter à un réel SoC, sans se limiter à de micro-cartes.

Ubuntu a l'avantage de proposer nombre de ses paquets précompilés pour cette architecture, mais vous pouvez aussi créer votre propre application. Par exemple, le célèbre « Hello, World ! » avec le compilateur gcc. Pour cela, utilisez un éditeur, nativement présent ou à installer, comme nano dans notre cas pour éditer un fichier source :

sudo apt install nano gcc
nano hello.c

Placez-y le code suivant : 

#include <stdio.h>

int main ()
{
    printf("Hello, World !\n");

return 0;
}

Compilez ce code avec gcc puis exécutez le :

gcc -o hello hello.c
./hello

Vous avez créé votre première application pour RISC-V !

Hello World RISC-V

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

RISC-V et SiFive à la conquête du monde

Transfert de l'image et première connexion

Avec ou sans carte graphique ?

Quid des performances ?

Compilez votre première application pour RISC-V !

Fermer

Commentaires (16)


J’ai bien fait de ne craquer sur l’achat de cette carte. Mais j’espère tellement de cette architecture que je le surveille avec grande attention.


Disons qu’à moins de vouloir développer pour RISC-V ce n’est pas le genre de produits à viser. C’est de la production de niche pour un public ciblé avec pas mal d’éléments pour debug. Pas vraiment de quoi se faire un NAS ou un serveur avant tout. Mais c’est déjà mieux que les précédentes solutions et on peut faire pas mal de choses côté E/S donc ça avance dans le bon sens.


Votre lecteur SD est vraisemblablement limité, sur ce modèle de cartes j’obtiens généralement 90 Mo/s en écriture et dans les 150 Mo/s en lecture séquentielle (comme la plupart des testeurs).


Deux fois plus que les performances annoncées ? Je ferai des tests complémentaires pour vérifier. Mais cela changera peut de choses sur ce qui compte : les débits en écriture.


https://framagit.org/Wax/zenbench



Outil de bench multicore en parallèle.


De mémoire tu as déjà donné le lien, mais je ne suis pas très bon client pour les benchs trop théoriques (qui fournissent plein de chiffres mais avec peu de sens), surtout qu’on est pas trop dans le cas d’une plateforme où la montée en coeur est un enjeu essentiel vu le niveau de performances relevé.


Ce n’est pas du tout le même usage mais je me suis procuré un kit Maixduino, également à base de Risc-V mais beaucoup plus petit : Le K210.
On le trouve autour de 20€ avec la caméra & l’écran.



Linux ne fonctionne pas dessus (c’est plutôt un microcontrôleur) mais ça reste infiniment plus puissant qu’un arduino et permet de tester plein de chose - et découvrir le risc-v :-)


HAIKU est pratiquement fonctionnel sur cette architecture donc c’est une bonne excuse pour s’en procurer une (du moins plus que pour ubuntu…) :fumer:


Oui comme dit il y a déjà pas mal de micro cartes RISC V (certains avec des SoC Freedom de SiFive d’ailleurs), mais les besoins sont assez différents tout comme la conso/perf :D




jeannot31 a dit:


HAIKU est pratiquement fonctionnel sur cette architecture donc c’est une bonne excuse pour s’en procurer une (du moins plus que pour ubuntu…) :fumer:




Aux dernières nouvelles c’était loin d’être fini, mais de toutes façons je vois mal l’intérêt d’un système de ce genre pour une carte de développement, surtout avec ces performances et toutes les limitations que ça va impliquer sur les usages type multimédia & co. Autant attendre des produits “consumer”



David_L a dit:


De mémoire tu as déjà donné le lien, mais je ne suis pas très bon client pour les benchs trop théoriques (qui fournissent plein de chiffres mais avec peu de sens), surtout qu’on est pas trop dans le cas d’une plateforme où la montée en coeur est un enjeu essentiel vu le niveau de performances relevé.




framagit était en panne juuuuste au moment où j’avais versé le lien la dernière fois.



Le script en question mesure quantifie la vitesse des flux de sortie de logiciels de compression, en monotâche, puis en 2 threads, 3, 4, etc, et ça permet de facilement évaluer la puissance de traitement, mais aussi d’évaluer la scalabilité multiprocesseur.



Ce script m’a permis de mettre en évidence que le Ryzen R9 5900X souffre de problème de scalabilité dès le 11ème fil d’exécution, ce qui place le sweet spot à 12C/24T, et m’a conforté dans le choix d’un 5900X plutôt qu’un 5950X.



Je versais ce script dans la discussion générale, car il est justement passionnant sur un nouveau processeur. Situer la puissance de traitement d’un processeur Risc-V par rapport à un Ryzen, mais quelle idée géniale, et quantifier sa scalabilité multicoeur, miam.



OB a dit:


Ce n’est pas du tout le même usage mais je me suis procuré un kit Maixduino, également à base de Risc-V mais beaucoup plus petit : Le K210. On le trouve autour de 20€ avec la caméra & l’écran.
Linux ne fonctionne pas dessus (c’est plutôt un microcontrôleur) mais ça reste infiniment plus puissant qu’un arduino et permet de tester plein de chose - et découvrir le risc-v :-)




J’ai un maixbit (même base) depuis environ 1 an (mince, 1 an 12 déjà…) mais c’est surtout la partie AI qui est intéressante.



Cherche ici https://github.com/orgs/sipeed/repositories pour les sources de Linux et ici https://dl.sipeed.com/shareURL/MAIX/K210_Linux/Firmware pour les ressources des cartes Maix. Tu peux aussi compiler ta “distribution” chez toi ou la faire compiler chez eux (si tu arrives à passer l’épreuve du captcha en chinois)


La scalabilité d’un “processeur” ne dépend pas seulement de lui-même mais aussi du logiciel qui l’exploite (aussi bien applicatif que l’OS, et en particulier son scheduler/ordonnanceur), et de la bande passante de la mémoire et/ou du stockage (voire du réseau) si le logiciel en question en demande dans des proportions importantes.



Les Ryzen ont une architecture plutôt straight-forward avec un seul contrôleur mémoire (contrairement aux Threadrippers basés sur Zen1), sous forme d’arbre (contre l’architecture en anneau chez Intel pendant un temps (et peut-être encore aujourd’hui ?)) et pas de partage d’unité de calcul entre cœur comme sur Bulldozer. Il n’y aucune raison que les cœurs en eux-mêmes ne soient pas scalables, à part pour des raisons qui leur sont extérieures : refroidissement insuffisant donc moins de boost, cache L1, L2 ou L3 trop petits pour l’application (juste le L3 sur Zen* qui est partagé entre cœur, L1 et L2 sont dédiés à un seul cœur sur cette architecture) ou bande passante (mémoire, stockage, réseau) insuffisante pour nourrir plus de cœurs.



Et justement dans le cas de l’outil de bench que tu considères, ça doit certainement consommer pas mal de bande passage du stockage et dans une moindre mesure de la mémoire.
Fait tourner un test purement CPU et tu verras que les Ryzen sont parfaitement scalables.



Et même dans le cas des Threadrippers en Zen1, si l’application est designée de sorte a prendre en considération l’architecture avec deux contrôleurs mémoires, ça sera tout aussi scalable.



Et enfin, comme l’a dit @David_L, les benchs théoriques sont pas vraiment la réalité. Bien sûr qu’il peut t’arriver de devoir compresser ou décompresser des fichiers ou de faire d’autres calculs parallélisable mais de nos jours, un CPU travaille rarement pour une seule application, tout simplement car on, en tant qu’utilisateur, utilise plusieurs applications en même temps, mais aussi car l’OS fait aussi tourner tout un tas d’autres services en taches de fond.



* sur les Ryzen 5900X et 5950X, il y a deux caches L3 (un par CCD) ce qui peut amener le même genre de soucis que deux contrôleurs mémoires mais tes tests n’ont pas relevé de problème dans la linéarité des performances de 8 jusqu’à 11 coeurs donc pas là que se situe le goulot d’étranglement pour ton bench en particulier.


Comme dit par d’autres, la “scalabilité” dépend autant du logiciel que du CPU. J’ai des outils de mesure de perf qui encaissent d’être lancés sur 256 threads en bi-CPU avec une montée en puissance des scores. Je n’ai pas 256x le 1T parce que la fréquence baisse au fil de la montée en threads, mais ça grimpe à chaque étape. Par contre si tu fais de la compression vidéo… ça coince rapidement.



On ne peut tirer une telle conclusion d’un unique benchmark, encore moins lorsqu’ils sont si théoriques. Au mieux tu peux en tirer que tel CPU ne convient pas à tel usage précis qui dépend de tel facteur. Rien de plus. Bon après, si c’est juste pour conforter un choix, c’est autre chose.



Concernant les tests ici fait, tu vois bien l’écart entre le 1T/4T et tu peux comparer à du Ryzen qu’on a déjà testé tant sur 7z que OpenSSL (mais sur un OS/compilation différent, forcément). De toutes façons comme dit, la perf n’est pas l’objectif premier d’une telle carte. Je donne surtout ces résultats à titre d’information, mais de là à en tirer des généralités sur RISC-V…



Wax a dit:


Le script en question mesure quantifie la vitesse des flux de sortie de logiciels de compression, en monotâche, puis en 2 threads, 3, 4, etc, et ça permet de facilement évaluer la puissance de traitement, mais aussi d’évaluer la scalabilité multiprocesseur.




Le script est intéressant pour la compression, mais il y a beaucoup d’autres charges de travail possibles. Et les benchs sont surtout intéressants si tu peux comparer ton utilisation à l’un des benchs.
Je préfère le site openbenchmarking, qui donne des infos sur des charges de travail en BDD, en FS, en compression, quand on connait sa charge estimée, on peut se faire une idée.



Si on regarde sur les SBC, la charge CPU est maintenant suffisamment faible pour le “fond de panier” pour que ce qui importe est uniquement les capacités média ou autres selon utilisation.



J’ai deux cartes RISC: une maix et une loongson. La maix est pas mal mais elle consomme quand même du fait des unités présentes, et reste limitée côté perfs, la loongson consomme (très) peu, a une sacré patate face aux concurrents (Cortex-m0) mais je n’en n’ai pas l’utilité vu les autres limitations (RAM notamment).



Pour ces deux cartes, on est encore aux démos, en-dessous de ce qu’était la RPI à sa sortie (2012? déjà?)



Les CPU/MCU RISC vendus pas cher sont très simple, sans “fioritures” comme le cache, le MMU, … ce qui les rends comparables aux processeurs des années 80 dans leur conception en fait. Ce qu’on attend, ce sont les CPU comme ceux de cette carte avec un peu plus d’optimisations (OOE, Cache, pipelines, …)



Finalement, le coeur du CPU est simplifié pour RISC, mais il ne peut pas se hisser aux niveau des derniers ARM/Intel/AMD sans ajouter l’énorme complexité et la pléthore de transistors qui gravitent autour des unités de calculs.


Sur la page du produit il est bien indiqué “Jusqu’à 170 Mo/s”. En pratique avec de la copie de gros fichiers j’arrive effectivement à ce chiffre. Mais uniquement avec un bon lecteur microSD.


Tu parles d’un modèle à plus de 32 Go (et donc pas A1) je suppose ?