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.
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 Albert_ . Évalué à -10.
Tu es malheureusement en train de propager leur vision de la chose et donc de faire leur boulot de PR…
[^] # Re: petite remarque
Posté par azmeuk (site web personnel) . Évalué à 10.
Mais dans le même temps, il est aussi en train de propager le point de vue opposé.
[^] # Re: petite remarque
Posté par martoni (site web personnel, Mastodon) . Évalué à 10.
Au contraire, c'est une vrai reconnaissance pour Risc-V !
J'ai plus qu'une balle
[^] # Re: petite remarque
Posté par Albert_ . Évalué à 2.
Mouhais on peut voir ca comme ca aussi :)
# arm-basics.com
Posté par martoni (site web personnel, Mastodon) . Évalué à 10.
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
J'ai plus qu'une balle
# Com commerciale...
Posté par arnaudus . Évalué à 6.
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 gUI (Mastodon) . Évalué à 10.
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 !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Com commerciale...
Posté par foobarbazz . Évalué à 9.
Oui, je ne connaissais pas ce projet avant aujourd'hui, c'est super cool !
[^] # Re: Com commerciale...
Posté par Arkem . Évalué à 4.
Idem, et je ne suis pas prêt de l'oublier après un coup de pub aussi réussi :D
[^] # Re: Com commerciale...
Posté par Anonyme . Évalué à 10.
"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 Zenitram (site web personnel) . Évalué à 1.
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 Anonyme . Évalué à 10. Dernière modification le 10 juillet 2018 à 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 flan (site web personnel) . Évalué à 7.
Ç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 Anonyme . Évalué à 4. Dernière modification le 11 juillet 2018 à 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 aiolos . Évalué à 8.
Ç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 Renault (site web personnel) . Évalué à 10.
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 Anonyme . Évalué à 4.
Merci de l'info et de la rectification :)
[^] # Re: Com commerciale...
Posté par Flaburgan (site web personnel) . Évalué à 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 Anonyme . Évalué à 2. Dernière modification le 09 août 2018 à 01:43.
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.
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 Blackknight (site web personnel, Mastodon) . Évalué à -3.
T'es resté enfermé dans une grotte pendant 10 ans ?? :)
# Serveur inaccessible
Posté par karchnu . Évalué à 6.
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 ?
[^] # Re: Serveur inaccessible
Posté par foobarbazz . Évalué à 5.
Il a l'air cassé leur site…
https://downforeveryoneorjustme.com/riscv-basics.com
[^] # Re: Serveur inaccessible
Posté par newskin . Évalué à 6.
Tu peux retrouver une copie sur archive.org
https://web.archive.org/web/20180709125728/https://riscv-basics.com/
[^] # Re: Serveur inaccessible
Posté par martoni (site web personnel, Mastodon) . Évalué à 4.
Y a un responsable com' chez Arm qui a dû se faire virer …
J'ai plus qu'une balle
[^] # Re: Serveur inaccessible
Posté par Tony Flow . Évalué à 10.
Du coup on trouve la réponse sur la campagne concurrente évoquée dans le post précédent :
Avec en référence un lien vers un article de The Register (en) expliquant la situation et la décision de stopper le site après des réactions internes.
Une campagne qui n'aura tenue que 2-3 jours en ligne… mais qui ne sera pas passée inaperçue. Belle efficacité contre-productive et joli rétro-pédalage effectivement !
# Fragmentation risk
Posté par Maclag . Évalué à 10.
"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 gUI (Mastodon) . Évalué à 6. Dernière modification le 11 juillet 2018 à 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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fragmentation risk
Posté par calandoa . Évalué à 3.
À 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 gUI (Mastodon) . Évalué à 2.
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 ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fragmentation risk
Posté par David Demelier (site web personnel) . Évalué à 3.
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.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . Évalué à 10. Dernière modification le 11 juillet 2018 à 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 karteum59 . Évalué à 10.
+1
En fait d'après ce que je comprends il y a deux soucis
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
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 karteum59 . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 mripard . Évalué à -1.
C'est pourtant exactement ce que permet le device tree.
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 Renault (site web personnel) . Évalué à 3. Dernière modification le 27 août 2018 à 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 :
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 mripard . Évalué à 0. Dernière modification le 27 août 2018 à 16:56.
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.
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.
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.
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.
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 Renault (site web personnel) . Évalué à 5.
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.
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.
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.
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.
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 mripard . Évalué à -1.
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 Anonyme . Évalué à 2.
Ç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.
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.
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 Anonyme . Évalué à 8.
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.
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 Nicolas Boulay (site web personnel) . Évalué à 5.
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 karteum59 . Évalué à 2. Dernière modification le 30 août 2018 à 10:03.
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)
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 Anonyme . Évalué à 1.
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.
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.
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 reno . Évalué à 5.
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..
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 13 juillet 2018 à 11:35.
Bien sûr. Mais qui en utilise encore ?
"La première sécurité est la liberté"
# Point de vue pragmatique mais
Posté par MTux . Évalué à 3. Dernière modification le 11 juillet 2018 à 08:00.
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 martoni (site web personnel, Mastodon) . Évalué à 8.
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.
J'ai plus qu'une balle
[^] # Re: Point de vue pragmatique mais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
On peut même faire de l'Ada sans OS ;)
[^] # Re: Point de vue pragmatique mais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 11 juillet 2018 à 10:03.
Petite précision, c'est sur le HiFive1 qui est plutôt un Arduino boosté pas sur le HiFive Unleashed qui est une toute autre bête :D
[^] # Re: Point de vue pragmatique mais
Posté par legranblon (site web personnel) . Évalué à 9.
Il y a longtemps que les Lada tournent sans OS, pas vite je te l'accorde, mais quand même !
[^] # Re: Point de vue pragmatique mais
Posté par martoni (site web personnel, Mastodon) . Évalué à 1.
On peut également faire du RUST sans os sur le kit hifive1.
J'ai plus qu'une balle
[^] # Re: Point de vue pragmatique mais
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 11 juillet 2018 à 08:19.
Oui c'est le but.
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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
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 gUI (Mastodon) . Évalué à 8.
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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par karteum59 . Évalué à 9.
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 gUI (Mastodon) . Évalué à 5.
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.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
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 oinkoink_daotter . Évalué à 5.
Il me semble qu'au moins Microsoft l'utilise sur ses "surface" (les ARM, donc "pas pro"). On le voit grâce au (UEFI) secure boot non désactivable.
[^] # Re: Point de vue pragmatique mais
Posté par karteum59 . Évalué à 5. Dernière modification le 12 juillet 2018 à 01:06.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 David Marec (site web personnel) . Évalué à 5.
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 martoni (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 13 juillet 2018 à 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.
J'ai plus qu'une balle
[^] # Re: Clap de fin
Posté par ʭ ☯ . Évalué à 3.
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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.