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

Posté par (page perso) . Licence CC by-sa.
50
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/-23).

    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 (+20/-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é à 6 (+6/-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 (+16/-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é à 9 (+8/-0).

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

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

          Posté par . Évalué à 4 (+3/-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 (+11/-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 (+11/-12).

            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 (+14/-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é à 7 (+5/-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é à 4 (+3/-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é à 8 (+7/-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 (+14/-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 . Évalué à 4 (+4/-1).

              Merci de l'info et de la rectification :)

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

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

              Ouais enfin nVidia verrouille tout et tant qu'il ne sera pas possible de faire de reclocking nouveau ne sera qu'une blague permettant d'avoir quelque chose d'affiché à l'écran à l'installation avant de mettre leur pilote propriétaire.

              Par rapport à AMD qui publient le code de leurs drivers, ca a quand même rien à voir. Sous GNU/Linux si on veut maximiser le code libre, y'a aucune question à se poser entre ces deux fabricants.

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

                Posté par . Évalué à 2 (+1/-0). Dernière modification le 09/08/18 à 01:43.

                nouveau ne sera qu'une blague permettant d'avoir quelque chose d'affiché à l'écran à l'installation avant de mettre leur pilote propriétaire

                faux. avec VESA, pas besoin de nouveau pour afficher le POST, uboot, GRUB, un tty ou faire une install.
                et le changement dynamique de fréquence fonctionne très bien sur Fermi et Kepler avec nouveau, pour Maxwell et Pascal ça va arriver mais en l'état c'est déjà exploitable pour de la bureautique/multimédia. Mais bon si tu tiens au tout libre, les cartes-mères, les CPU et les cartes graphiques actuelles contiennent leur firmware proprio, même chez AMD.

                Par rapport à AMD qui publient le code de leurs drivers, ca a quand même rien à voir.

                AMD a une petite équipe de devs pour Linux et ils ont décidé de publier ça en libre mais on reste encore loin des fonctionnalités des pilotes propriétaires des deux concurrents (exemple : l'overclocking et undervolting sont fastidieux) et en dehors de l'architecture x86_64 y a pas grand chose de fait (ça avance doucement pour l'archi Power9 mais en l'état c'est utilisable qu'avec une R9 290, ni Polaris, ni Vega).

        • [^] # 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é à -1 (+0/-1).

              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.

              C'est pourtant exactement ce que permet le device tree.

              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é".

              Le dtb est compilé, et chargé en mémoire à une adresse passée au kernel, du coup, là encore, c'est exactement ce que fait le device tree.

              • [^] # Re: Fragmentation risk

                Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 27/08/18 à 14:34.

                Tu te méprends sur ce qu'est la découverte de périphérique.

                Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.

                C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.

                Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence. Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.

                Le device tree permet une plus grande souplesse :

                • Grâce à la surcharge, c'est facile de définir un SoC et ensuite les cartes mères qui se basent dessus sans trop se répéter ;
                • Possibilité de le mettre à jour indépendamment du noyau ;
                • Possibilité de partager un device tree avec différents OS ou chargeurs de démarrage (cas de U-boot et Linux) ;
                • Si les cartes mères permettent (via des GPIO par exemple) de dire quelle carte mère tu utilises, tu peux facilement charger le device tree correspondant à la bonne carte. C'est cela qui autorise une image unique pour plusieurs cartes, le chargeur de démarrage peut sélectionner la bonne description du matériel en fonction d'un élément discriminant.

                Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.

                • [^] # Re: Fragmentation risk

                  Posté par . Évalué à 0 (+0/-0). Dernière modification le 27/08/18 à 16:56.

                  Tu te méprends sur ce qu'est la découverte de périphérique.

                  Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.

                  C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.

                  C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.

                  La discussion plus haut était juste sur le kernel, mais même pour un OS entier, c'est possible. Debian et Fedora (les premiers exemples qui me viennent en tête, il y en a surement plein d'autres) utilisent une seule image pour toutes les cartes supportées. La seule différence étant le device tree justement.

                  Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence.

                  C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.

                  A noter que le côté statique est quand même soumis à débat. Il n'y a pas (à ma connaissance) d'équivalent aux overlays avec ACPI.

                  Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.

                  Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.

                  Le device tree permet une plus grande souplesse :

                  • Grâce à la surcharge, c'est facile de définir un SoC et ensuite les cartes mères qui se basent dessus sans trop se répéter ;
                  • Possibilité de le mettre à jour indépendamment du noyau ;
                  • Possibilité de partager un device tree avec différents OS ou chargeurs de démarrage (cas de U-boot et Linux) ;
                  • Si les cartes mères permettent (via des GPIO par exemple) de dire quelle carte mère tu utilises, tu peux facilement charger le device tree correspondant à la bonne carte. C'est cela qui autorise une image unique pour plusieurs cartes, le chargeur de démarrage peut sélectionner la bonne description du matériel en fonction d'un élément discriminant.

                  Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.

                  La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT. Il y a plein de boards qui n'implémentent pas ça. Par contre, ca pose la question plus philosophique de ce qu'est l'OS et de s'il doit inclure l'UEFI et le BIOS sur un PC. J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.

                  • [^] # Re: Fragmentation risk

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

                    C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.

                    Bien sûr, mais les cartes ARM du moins au début recouraient bien moins au PCIe et USB, préférant les bus non découvrables à la place. Alors que la plupart des composants dans le PC finissent par passer par ces bus à un moment ou un autre.

                    Cela change beaucoup sur la manière de prendre en charge le matériel.

                    C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.

                    Dans un cas c'est fourni par le constructeur lui même, dans l'autre c'est souvent au développeur de l'ajouter de son côté que ce soit au sein du noyau lui mee ou du chargeur de démarrage.

                    Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.

                    Je sais ce qu'est un device tree, j'en écris régulièrement.
                    Justement je mentionnais qu'en l'absence de device tree, c'est à dire si tu essayes de démarrer ton noyau avec juste ce qui est fourni de base par le constructeur de la carte, bah tu ne booteras pas ou en mode très dégradé. Car le constructeur ne te fourni pas en dur le device tree qui va bien, tu dois l'ajouter toi même quelque part.

                    Alors que quand je monte mon PC, je n'ai rien à faire. Je démarre mon noyau sans besoin d'ajouter une description du matériel avec mon système. Car cette découverte est faite et fourni automatiquement à mon système.

                    La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT.

                    Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.

                    J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.

                    L'OS au sens strict du terme se réfère en effet au système noyau + espace utilisateur quelque soit l'architecture. Mais il me semble pertinent de considérer le chargeur de démarrage dedans. Après tout Fedora, Windows ou macOS ont leur propre chargeur de démarrage qui est géré comme n'importe quel logiciel. Et d'autant plus que nous avons dans un cas (pour PC) un chargeur de démarrage universel (il fonctionne pour à peu ès n'importe quel PC sans soucis) et de l'autre nous avons un chargeur de démarrage (que ce soit U-boot ou autre) qui doit être particulier pour l'initialisation de base et sélectionner le bon device tree à envoyer au noyau.

                    • [^] # Re: Fragmentation risk

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

                      Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.

                      Oui, effectivement. Mais on est quand même un peu loin de l'affirmation de départ que c'est impossible de compiler une image du kernel générique.

                      Après, je comprends pas pourquoi on voudrait faire qu'une board ARM soit comme un PC justement. Un PC, c'est aussi un temps de boot catastrophique, une standardisation qui impose un use case (quand des CPUs ARM vont d'un contrôleur de disque dur à un serveur rackable) et un gros machin horrible qui tourne sous le kernel, est troué de partout et dit absolument rien de ce qu'il fait vraiment. On a rien sans rien…

                      • [^] # Re: Fragmentation risk

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

                        Un PC, c'est aussi un temps de boot catastrophique

                        Ça vejmarie en a déjà parlé dans ses journaux. C'est un problème de code séquentiel totalement sous-optimal dans le POST. Linuxboot est bien plus réactif que les BIOS/UEFI propriétaires.

                        une standardisation qui impose un use case (quand des CPUs ARM vont d'un contrôleur de disque dur à un serveur rackable)

                        Pourtant la gamme de processeurs x86 va du microcontroleur (Intel Quark) au serveur rackable à base de Xeon. AMD ne descend pas jusqu'au microcontroleur mais produit des SoC basse consommation (Rysen Embedded) et va jusque Epyc.
                        Le use case dont tu parles c'est surtout dû à la licence x86 verrouillée par Intel qui n'a pas le même système économique que ARM Holdings. Ça n'a rien à voir avec la "standardisation" PC.

                        et un gros machin horrible qui tourne sous le kernel, est troué de partout et dit absolument rien de ce qu'il fait vraiment.

                        C'est pourquoi Libreboot ne prend plus en charge de processeurs x86 récents. Ça n'a rien à voir avec le standard PC non plus, ni avec le BIOS.
                        Puis ARM propose aussi sa boite noire, Trustzone, que AMD utilise dans son PSP.

          • [^] # Re: Fragmentation risk

            Posté par . Évalué à 8 (+7/-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é à 5 (+2/-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é à 2 (+0/-0). Dernière modification le 30/08/18 à 10:03.

              Avec les composants montés en surface, on arrive à faire des puces de mémoire NOR de moins de 5 mm²

              5mm² c'est peut-être acceptable pour un PC mais pas pour un smartphone ! C'est pour ça que je demandais si les technos de fabrication des SoCs étaient les mêmes que celles des flash NOR (de sorte qu'on puisse imaginer que la NOR soit intégrée dans le SoC lui-même)

              l'avantage d'une puce séparée c'est de pouvoir la remplacer ou la réécrire si ça brique

              Ouais bof, ce n'est quand même pas à la portée de tout le monde de dessouder/resouder la flash sans tout casser. On peut aussi imaginer que le SoC intègre une première bootrom minimaliste (non reprogrammable, déclenchable sur certains triggers) capable de booter sur USB et permettant de débricker la machine. Les SoC Allwinner disposent d'un tel mode

              • [^] # Re: Fragmentation risk

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

                5mm² c'est peut-être acceptable pour un PC mais pas pour un smartphone

                Je parlais de la taille du boitier, la puce est plus petite à l'intérieur et ce n'est pas du FinFet, seulement du planaire et dans une lithographie assez grosse puisqu'il n'y a pas de contraintes de place ou de dissipation donc on peut espérer une bien meilleure densité dans un SoC/microcontroleur pas trop en retard (par exemple, le Allwinner H6 est encore en 28nm tandis que Qualcomm commence enfin à mettre en FinFet toutes ses gammes de Snapdragon).
                Donc oui c'est parfaitement faisable, juste que la NAND prendra toujours moins de place à même capacité de stockage.

                Ouais bof, ce n'est quand même pas à la portée de tout le monde de dessouder/resouder la flash sans tout casser.

                On peut réécrire in-situ, pas besoin d'extraire le composant. Puis j'utilise sciemment le terme "extraire" parce que comme pour les processeurs, il existe des supports même pour des boitiers sans broches.
                Enfin, c'est pas à la portée de tout le monde (rien ne l'est vraiment) mais même la brasure à air chaud ça demande davantage de méthode que de technique et le coût du matériel n'est pas exorbitant. C'est aussi compliqué que changer une roue ou faire une vidange.
                Ce qui n'est pas à portée de l'amateur c'est de travailler sur du boitier BGA. Un rebillage ça se fait avec du matos industriel. Et malheureusement ces boitiers sont de plus en plus utilisés même pour des composants où c'est inutile comme la NAND ou les microcontroleurs.

                Les SoC Allwinner disposent d'un tel mode

                Oui, je connais le FEL Mode (J'ai un SBC et une tablette ayant un A20). Certes ça évite le brick complet si l'intégrateur n'a pas exposé les I/O via JTAG ou SWD pour reprogrammer l'EEPROM intégrée ou accéder à la console de debug mais ça ne permet toujours pas la découverte de matériel, seulement de démarrer à distance sur une image créé avec le device tree spécifique à ce matériel.

        • [^] # Re: Fragmentation risk

          Posté par . Évalué à 5 (+3/-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 (+9/-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é à 5 (+4/-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é à 8 (+7/-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.

    • [^] # Re: Clap de fin

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

      Et il a aussi été effacé de la Wayback machine! Heureusement que LinuxFR.org est là pour faire travail de mémoire…

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Envoyer un commentaire

Suivre le flux des commentaires

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