Journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V

Posté par (page perso) . Licence CC by-sa
46
10
juil.
2018

Cher journal,

As-tu aimé la campagne de microsoft «Get the facts» contre Linux ?

Alors tu aimeras certainement la campagne «Understand the facts» de la société Arm contre Risc-V ;)

Risc-V est un set d'instructions libre pour processeur appelé aussi ISA (Instruction Set Architecture).

C'est la base d'un processeur, ce qui est nécessaire au compilateur pour générer un exécutable. À partir de ce set d'instructions, un concepteur de silicium / designer fpga peut créer un cœur de processeur et y connecter toutes sortes de périphériques.
Jusqu'ici les concepteurs de microprocesseurs gardaient bien jalousement leurs sets d'instructions verrouillés pour eux même. Jusqu’à ce que l'université de berkeley se penche sur le sujet et lance un set d'instructions libre nommé Risc-V. C'est la même équipe qui a lancé le nouveau langage de description matériel Chisel pour «remplacer» les vieillissants VHDL et Verilog.

C'était il y a 10 ans.

Risc-V était encore considéré comme un joujou d'étudiants boutonneux il y a deux trois ans. Mais depuis la fondations Risc-V a fédéré quelques grands noms de l'informatique comme NVIDIA, Google, Qualcomm, Samsung, Western Digital, …
Et plusieurs processeurs Risc-V sont maintenant produit (massivement ?) sur le marché.
Risc-V commence donc à faire sérieusement de l'ombre au mastodonte Arm en venant marcher sur ses plate-bandes. C'est pourquoi Arm tente de contrecarrer (muhahaha) la déferlante avec une superbe campagne «get the fact» à la Microsoft.

En y réfléchissant deux secondes, c'est tellement gros que je me demande presque si le site vient vraiment de Arm !

  • # petite remarque

    Posté par . Évalué à -10 (+3/-21).

    Tu es malheureusement en train de propager leur vision de la chose et donc de faire leur boulot de PR…

  • # arm-basics.com

    Posté par (page perso) . Évalué à 10 (+19/-0).

    Et le plus beau dans tout ça, c'est qu'ils ont «oublié» d'enregistrer le nom de domaine arm-basics. Du coup il y a une version concurrente du site https://www.arm-basics.com/.

    ARM architecture : Understand the facts

  • # Com commerciale...

    Posté par . Évalué à 5 (+5/-2).

    En même temps, quand un système concurrent menace ton business model, une campagne de com semble être une solution normale pour une grosse boîte… Après, on peut critiquer le contenu, puisque malgré la puissance marketting qu'il peut y avoir derrière une telle campagne, les arguments sonnent plutôt creux, voire presque désespérés. Mais bon, c'est quand même une réaction attendue ; tu prétends que tu fais mieux, moins cher, plus sérieux que tes concurrents. Il est probable qu'en même temps ARM développe plusieurs stratégies (juridiques, commerciales, industrielles…) pour tenter d'endiguer le phénomène. Il est même possible qu'ils envisagent également de changer de modèle et de passer à d'autres jeux d'instruction ; une entreprise est en général beaucoup moins idéologue qu'un quidam moyen, elle changera d'avis si elle pense qu'il y a plus d'argent à se faire dans un sens que dans l'autre.

    • [^] # Re: Com commerciale...

      Posté par . Évalué à 10 (+15/-0).

      Moi ce qui me fait marrer c'est que c'est surtout une vraie reconnaissance pour Risc-V.

      Merci ARM pour la mise en lumière !

      • [^] # Re: Com commerciale...

        Posté par . Évalué à 8 (+7/-0).

        Oui, je ne connaissais pas ce projet avant aujourd'hui, c'est super cool !

        • [^] # Re: Com commerciale...

          Posté par . Évalué à 3 (+2/-0).

          Idem, et je ne suis pas prêt de l'oublier après un coup de pub aussi réussi :D

          Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things - Doug Gwyn

        • [^] # Re: Com commerciale...

          Posté par . Évalué à 10 (+9/-0).

          "super cool" je ne sais pas, mais on va dire que si ce jeu d'instruction est suivi par des géants du secteur c'est un espoir supplémentaire pour le matériel libre.

          Entendons-nous bien, RISC-V est avant tout une aubaine pour les entreprises (ou les états) : pas de royalties, liberté de refermer le code, grande souplesse dans l'application du jeu d'instruction et des possibilités d'architectures pour des besoin spécifiques.
          Nvidia et Qualcomm cherchent depuis un moment à concurrencer Intel (qui verrouille l'accès à x86) et ne sont que très peu sensibles au logiciel libre (niveau CPU ils sont bardés de blobs, niveau GPU les projets freedreno et nouveau ne bénéficient d'aucune aide de ces fabricants) donc il y a peu de chances qu'il y ait un boom (jeu de mot involontaire avec le processeur BOOM) des processeurs libres même si RISC-V venait à remplacer ARM voire x86.

          Ceci dit, cette campagne montre bel et bien que ARM Holdings prend RISC-V au sérieux et qu'ils ont désormais peur de l'outsider qui va commencer à grignoter leurs parts de marché dans le secteur microcontroleur et co-processeur (la branche Cortex-M).

          • [^] # Re: Com commerciale...

            Posté par (page perso) . Évalué à 1 (+10/-11).

            une aubaine pour les entreprises (ou les états) : pas de royalties, liberté de refermer le code, grande souplesse dans l'application du jeu d'instruction et des possibilités d'architectures pour des besoin spécifiques.

            Ouais, donc bref les avantages du libre (et en bonus du copyfree), où veux-tu en venir?
            Parce que la, on pourrait presque croire, à la façon dont tu listes les avantages du libre (et en bonus du copyfree), que tu aimes peu le libre et pas du tout le copyfree, si le libre te plait il faudrait penser à changer la forme.

            • [^] # Re: Com commerciale...

              Posté par . Évalué à 10 (+11/-0). Dernière modification le 10/07/18 à 22:25.

              Je dis seulement que les entreprises ont des intérêts qui sont différents de ceux des utilisateurs finaux et que les avantages ne sont pas forcément répercuté jusqu'au bout de la chaine de fabrication.
              Les ordinateurs Apple ou les consoles de Sony utilisent des noyaux BSD, ce ne sont pas pour autant des systèmes d'exploitation libres.
              Et ce n'est pas un jugement de valeur, je ne fais que tempérer les espérances sur la base d'expériences passées. C'est très bien pour ces entreprises mais j'attends de voir si ça profite au particulier que je suis avant de m'en réjouir, rien de plus.

              • [^] # Re: Com commerciale...

                Posté par (page perso) . Évalué à 6 (+4/-0).

                Ça ne change rien au fond du sujet, bien sûr, mais les OS d'Apple (macOS, iOS, etc.) n'utilisent pas un noyau BSD mais un noyau XNU (en revanche, une bonne partie de ce qui gravite autour du noyau a été pris chez BSD).

                • [^] # Re: Com commerciale...

                  Posté par . Évalué à 3 (+2/-0). Dernière modification le 11/07/18 à 01:05.

                  Décidémment, j'enchaine les bourdes. J'avais dans la tête que Darwin était du BSD.

                  Merci :)

                • [^] # Re: Com commerciale...

                  Posté par . Évalué à 6 (+5/-0).

                  Ça ne change quand même pas grand chose à la discussion : XNU est sous license Apache (ceci dit, tu ne dis pas le contraire). XNU, c'est un hybride entre Mach et 4.3BSD, d'après Wikipedia, ce n'est donc pas si faux…

          • [^] # Re: Com commerciale...

            Posté par (page perso) . Évalué à 10 (+13/-0).

            nouveau ne bénéficient d'aucune aide de ces fabricants

            Euh, non.
            nVidia avait embauché un gars à temps plein pour aider sur nouveau, en particulier pour les Tegra. Et nVidia fournit les infos et docs sur demande aux développeurs de nouveau (pas toujours très rapidement, mais ça a abouti de nombreuses fois).

            nVidia n'est clairement pas favorable au pilote libre, mais dire qu'ils ne font rien pour est faux.

        • [^] # Re: Com commerciale...

          Posté par (page perso) . Évalué à -3 (+1/-6).

          T'es resté enfermé dans une grotte pendant 10 ans ?? :)

  • # Serveur inaccessible

    Posté par . Évalué à 6 (+5/-0).

    Je ne sais pas si c'est pareil pour vous, mais apparemment je ne peux pas accéder au site en question. Est-ce qu'ils auraient fait un très joli rétro-pédalage ?

  • # Fragmentation risk

    Posté par . Évalué à 10 (+13/-0).

    "each implementation can be different or customized"

    Ils veulent dire "pas comme chez ARM où chaque fondeur ou fournisseur d'IP rajoute sa tambouille et personne ne fait rien pareil"?

    • [^] # Re: Fragmentation risk

      Posté par . Évalué à 6 (+5/-1). Dernière modification le 11/07/18 à 08:16.

      Exactement, sachant qu'en plus Risc-V propose un mécanisme précis (exception spécifique du processeur) pour qu'une instruction non implémentée dans ton hardware soit tout de même exécutable en software.

      • [^] # Re: Fragmentation risk

        Posté par . Évalué à 3 (+1/-0).

        À ma connaissance, tous les processeurs du marché proposent une exception spécifique… mais je ne connais pas RISC-V, peut être penses tu as une fonctionnalité en plus ?

        • [^] # Re: Fragmentation risk

          Posté par . Évalué à 2 (+0/-0).

          Non je ne sais pas, juste que je l'ai lu dans un bouquin d'introduction à Risc-V.

          Peut-être vont-ils motiver les implémentations software pour le faire à fond ?

    • [^] # Re: Fragmentation risk

      Posté par (page perso) . Évalué à 3 (+2/-0).

      C'est ce que je me demandais, quand on parle d'ARM je vois toujours une tonne d'émulation différentes ce qui me laisse penser que ça reste une architecture bien plus complexe.

      l'azerty est ce que subversion est aux SCMs

      • [^] # Re: Fragmentation risk

        Posté par . Évalué à 10 (+7/-0). Dernière modification le 11/07/18 à 11:01.

        Je ne sais pas si cela a changé, mais un des énormes problèmes de ARM est l'absence d'un équivalent au bios, qui permet la détection des périphériques. Cela rend totalement impossible d'avoir un binaire universel ARM pour Linux, par exemple.

        "La première sécurité est la liberté"

        • [^] # Re: Fragmentation risk

          Posté par . Évalué à 10 (+8/-0).

          +1
          En fait d'après ce que je comprends il y a deux soucis

          • pendant longtemps il n'y avait pas de mécanisme permettant de booter un kernel générique (sensé être en partie résolu avec le device-tree. J'ignore s'il reste encore des choses (clock tree / pinmux / …) qui ne rentrent pas dans ce mécanisme et qui exigent du code kernel spécifique à la carte-mère ?)
          • pas de moyen de stocker un bootloader minimal + device-tree (alors que les PCs ont justement une petite flash NOR pour stocker le BIOS/UEFI). ça coûte quelques centimes mais surtout ça prend de la place sur le PCB => j'ignore si les technos de fabrication des SoCs permettraient de loger l'équivalent d'une NOR de 8 Mo dans le SoC (à côté du CPU/GPU/…) ? Si c'est possible, j'avoue qu'il eût été bien que ARM l'inclue dans ses IP Cortex A* pour avoir la garantie que n'importe quel SoC basé dessus ait de quoi y loger u-boot + DTS… Et dans le cas de RISC-V idem il eût été bien que la spec dise d'une manière ou d'une autre "pour tous les SoCs 'high-end' (destinés à booter un OS, i.e. autres que microcontrôleurs) une NOR sera dispo systématiquement dans le SoC à l'adresse XXX"…
          • [^] # Re: Fragmentation risk

            Posté par . Évalué à 5 (+2/-0).

            Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner.
            Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.

            Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".

            "La première sécurité est la liberté"

            • [^] # Re: Fragmentation risk

              Posté par . Évalué à 2 (+0/-0).

              Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.

              Ben en fait il me semblait que si…
              Accessoirement si tu lis les sources de coreboot tu verras aussi des fichiers devicetree.cb qui me semblent analogues au dts/dtb => ma compréhension est que l'ACPI permet une introspection un peu dynamique via quelque chose qui ressemble à des appels systèmes alors qu'ici le DT est passé d'un bloc en paramètre au noyau et reste statique (mais je pense que ça ne change pas grand chose en pratique : ça veut essentiellement dire que tu ne peux pas swapper à chaud ton beaglebone CAPE, mais ça ne change rien pour les bus avec discovery comme l'USB…)

              • [^] # Re: Fragmentation risk

                Posté par . Évalué à 4 (+1/-0).

                Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).

                "La première sécurité est la liberté"

          • [^] # Re: Fragmentation risk

            Posté par . Évalué à 6 (+5/-0).

            pas de moyen de stocker un bootloader minimal + device-tree (alors que les PCs ont justement une petite flash NOR pour stocker le BIOS/UEFI). ça coûte quelques centimes mais surtout ça prend de la place sur le PCB

            Bien souvent sur les ordinateurs monocarte, la priorité de boot est donnée au port SPI/I²C donc il est tout à fait possible de mettre l'init sur une EEPROM comme sur un PC x86, c'est même prévu pour. Olimex travaille sur un système à base d'EEPROM contenant un uBoot qui fonctionnerait sur toutes leurs cartes ARM.

            j'ignore si les technos de fabrication des SoCs permettraient de loger l'équivalent d'une NOR de 8 Mo dans le SoC

            Avec les composants montés en surface, on arrive à faire des puces de mémoire NOR de moins de 5 mm² en format SOP ou SOIC qui peuvent accueillir un UEFI donc ÀMHA c'est faisable, d'ailleurs il y a déjà un peu de ROM pour les premières routines d'init au sein des ARM. Après l'avantage d'une puce séparée c'est de pouvoir la remplacer ou la réécrire si ça brique, pour l'intégrer proprement il faudrait exposer une interface de communication (port SPI ou I²C par exemple). Ça se rapprocherait un peu du modèle architectural d'un microcontroleur.

            Mais comme le souligne Nicolas le gros problème est le manque de système de découverte de matériel. L'UEFI est pourtant disponible sur ARM et il y a sans doute d'autres voies possibles comme Linuxboot dont vejmarie nous narre l'épopée.

            • [^] # Re: Fragmentation risk

              Posté par . Évalué à 3 (+0/-0).

              Je pense à un système beaucoup plus petit. La table dont je parle pourrait faire pas plus de qq ko. Il faut juste que l'adresse soit fixe.

              "La première sécurité est la liberté"

        • [^] # Re: Fragmentation risk

          Posté par . Évalué à 4 (+2/-0).

          Je ne pense pas qu'on puisse dire que c'est un problème ARM, c'est un problème de l'embarqué "non-PC".
          Si tu utilise un MIPS, un PPC, un RISC-V ou autre, tu as exactement le même problème..

  • # Point de vue pragmatique mais

    Posté par . Évalué à 3 (+2/-1). Dernière modification le 11/07/18 à 08:00.

    RISC-V (prononcé en anglais « RISC five » et signifiant « RISC cinq »), est une architecture de jeu d'instruction (instruction set architecture ou ISA) 64 bits RISC ouverte et libre, c'est-à-dire aux spécifications ouvertes et pouvant être utilisées librement par l'enseignement, la recherche et l'industrie.

    Libre? Est-ce que ça veut dire que chaque fabriquant va faire son propre RISC-V custom?
    Déjà qu'aujourd'hui on est pas capable d'avoir une ISO unique qui boote sur tous les bidules en ARM, j'imagine que demain ce sera encore pire avec RISC-V.

    Bon après j'imagine qu'ils ne font pas que des CPU mais aussi des GPU.

    • [^] # Re: Point de vue pragmatique mais

      Posté par (page perso) . Évalué à 8 (+7/-0).

      Le Risc-V est déjà dans le kernel Linux mainline. Il existe un proc Risc-V fonctionnant sous Linux (quad-core 64bits + un core «realtime») produit par SiFive (la boite créée par les chercheurs de Berkley): HiFive Unleashed.

    • [^] # Re: Point de vue pragmatique mais

      Posté par . Évalué à 10 (+8/-0). Dernière modification le 11/07/18 à 08:19.

      Est-ce que ça veut dire que chaque fabriquant va faire son propre RISC-V custom?

      Oui c'est le but.

      j'imagine que demain ce sera encore pire avec RISC-V

      Non c'est pas le but.

      Attention ensuite, la difficulté de booter une plateforme est rarement dûe au CPU, mais à tout ce qu'il y a autour (à commencer par le bootloader). Avec Risc-V, la partie CPU est définitivement réglée, mais ça ne changera rien au fait que chaque plateforme continuera avec ses spécificités qui feront que booter un kernel Linux n'aura rien d'évident.

      Mais c'est une brique de plus dans le bon sens.

      • [^] # Re: Point de vue pragmatique mais

        Posté par . Évalué à 6 (+3/-0).

        Si il pouvait aussi spécifier le boot loader… Linux a seulement besoin de l'horloge, d'une liaisons série, et de DRAM fonctionnelle (certain plateforme nécessite d'écrire une configuration dans le contrôleur DRAM qui utilise par défaut des valeurs conservatrices très lente), à cela il faut rajouter une table standard pour identifier les périphériques sur le bus (comme pour le PCI) et c'est bon (il faut juste une adresse mémoire + un numéro d'identification unique).

        On peut rajouter à tout ça un boot USB et/ou SD pour démarrer une première fois, et l'on a tout ce qu'il faut non ?

        "La première sécurité est la liberté"

        • [^] # Re: Point de vue pragmatique mais

          Posté par . Évalué à 8 (+6/-0).

          Spécifier la plateforme serait contraire à leur but : ils veulent juste spécifier une ISA commune cross-cible (ils visent autant un Arduino qu'un data center), et aider les concepteurs de CPU à faire leurs optimisations dans tous les cas.

          Pour illustrer, WesterDigital compte fabriquer 1 milliards de controleurs Risc-V pour mettre dans leurs disques durs, inutile de te dire que c'est du très très très "low spec", on est loin d'un kernel Linux.

          • [^] # Re: Point de vue pragmatique mais

            Posté par . Évalué à 9 (+7/-0).

            Que l'ISA soit scalable du microcontrôleur au CPU de supercalculateur, soit (et dans le cas d'un µC sans OS pas besoin de s'embêter avec une "plate-forme").
            Mais je suis d'accord qu'il serait souhaitable d'avoir une extension qui spécifie tout le nécessaire dans le cas de SoCs "haut de gamme" destinés à booter un Linux générique (ça pourrait être par exemple la garantie d'avoir un espace de stockage dans le SoC à une adresse précise pour y loger uboot + dts), histoire d'éviter la fragmentation qu'on observe chez ARM (cf. tous les smartphones qui sont bons pour la poubelle après quelques années car impossibles à maintenir, là où des PCs vieux de 15 ans fonctionnent encore parfaitement…).

            • [^] # Re: Point de vue pragmatique mais

              Posté par . Évalué à 5 (+3/-0).

              Je comprends, mais c'est pas du tout le rôle de Risc-V de spécifier ça.

              Mais les standardisations ça existe déjà : UEFI pour bootloader/initialiser le hardware, PCI (pour détecter le hardware c'est bien foutu), device tree (pour décrire le hardware d'une plateforme embarquée) etc. Tout ça ça existe déjà, et c'est pas assez utilisé par les fabricants. Alors je ne suis pas sûr qu'en en rajoutant une ça change les choses.

              • [^] # Re: Point de vue pragmatique mais

                Posté par . Évalué à 4 (+2/-1).

                UEFI n'est pas utilisé sur ARM, à ma connaissance, et n'est pas du tout rendu obligatoire par un standard quelconque. La norme PCI est un bon exemple, mais cela n'est jamais utilisé dans un SoC. le device tree ne répond pas au problème. Est-ce que l'on imagine un device-tree pour chaque combinaison de hardware pour un PC ?

                "La première sécurité est la liberté"

              • [^] # Re: Point de vue pragmatique mais

                Posté par . Évalué à 4 (+3/-1). Dernière modification le 12/07/18 à 01:06.

                Mais les standardisations ça existe déjà : UEFI

                Oui enfin bon, UEFI est pour le moins controversé (on sent la patte MS à tous les niveau, et ça sonne un peu comme "vous détestiez MS-DOS, ils l'ont mis dans votre firmware"…). La spec semble excessivement complexe, et je ne suis pas sûr d'avoir envie de ça pour quelque chose sensé être "neuf et propre" comme RISC-V :)

          • [^] # Re: Point de vue pragmatique mais

            Posté par . Évalué à 4 (+1/-0).

            "Spécifier la plateforme serait contraire à leur but"

            En fait, c'est l'inverse. Car ils rendent la gestion du logiciel, infiniment plus complexe. Et l'ISA, c'est du logiciel.

            "La première sécurité est la liberté"

    • [^] # Re: Point de vue pragmatique mais

      Posté par (page perso) . Évalué à 5 (+4/-0).

      Tiens, ça me fait au penser au jeu d'instruction SuperH que Hitachi avait libéré sous licence BSD, il y a quelque années.

      Il y avait un projet de processeur libre au dessus, le j-core.
      Je me demande ce qu'il devient …

  • # Clap de fin

    Posté par (page perso) . Évalué à 7 (+6/-0). Dernière modification le 13/07/18 à 08:11.

    Bon le site en question ne sera resté qu'une seule journée en ligne. Arm ayant assez vite compris la bourde ;)
    Du coup le site «concurrent» va lui aussi fermer ses portes ce weekend comme l'indique l'auteur dans un message sur le github.

    C'est un clap de fin pour une histoire qui nous aura fait bien rire.

    On remercie la société Arm d'avoir mis un tel coup de projecteurs sur cette architecture de processeur promise à un bel avenir.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.