Cher journal,
Je t'avais déjà dit que RISCV était desktop-ready grâce au travail de Western Digital sur la carte HiFive Unleashed.
Mais tu trouvais sans doute qu'un «pc» à plus de 3000€ c'était un peu cher.
Du coup tu seras sans doute ravi d'apprendre que Western Digital remet le couvert avec le portage de Linux (+Busybox) sur un petit processeur (très gros microcontrôleur) chinois -> le kendryte K210.
Pour cela, Western Digital a utilisé le kit Maix Go produit par la société Sipeed et que tu peux te procurer pour environ 50€ (avec écran, boîtier, caméra wifi, et quelques autres babioles sympa).
Le Kendryte est un processeur un peu bizarre car il ne possède pas de MMU. C'est cependant un microcontrôleur relativement puissant puisque son cœur est un dual-core 64bits (RV64GC) cadencé à 400Mhz.
Ce qui en fait un composant qui est le cul entre deux chaises : plus vraiment un microcontrôleur mais pas encore un microprocesseur.
# MMU-less
Posté par David Marec . Évalué à 3.
Je vois qu'il s'appuie sur version récente de la µClibc: µClibc-ng.
Par contre, je n'ai pas compris le sens de ceci:
[^] # Re: MMU-less
Posté par benoar . Évalué à 3. Dernière modification le 04 décembre 2019 à 00:22.
Moi non plus ça m'a paru étrange. Déjà, le lien vers le code kernel est mauvais, il y a eu une nouvelle série et c'est :
http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-nommu.5
L'exemple du patch pour accéder aux timers par MMIO, sans SBI :
http://git.infradead.org/users/hch/riscv.git/commitdiff/f9713fbf4f067f364c9556451a6af290bc9846c8?hp=ecfa7427c0fc83cb4fadc4d54393fd2c64035fb2
Et pour les IPI :
http://git.infradead.org/users/hch/riscv.git/commitdiff/e4ca96402c2a2a3d7d77b8bba46a25ec7b4315e6?hp=f9713fbf4f067f364c9556451a6af290bc9846c8
D'après ce que je comprends, il (Christoph Hellwig) a séparé l'utilisation du SBI (CONFIG_RISCV_SBI) de NOMMU afin de potentiellement pouvoir l'utiliser même en S-mode, car à priori rien n'empêcherait d'utiliser les MMIO dans ce mode : je suppose qu'avec un OS en S-mode dans lequel on a confiance, on pourrait autoriser l'utilisation de ces mappings directement.
Mais c'est vraiment une hypothèse d'un mec qui n'y connaît pas grand chose à RISC-V.
[^] # Re: MMU-less
Posté par David Marec . Évalué à 3.
Oui c'est ça, je l'avais lu à l'envers. Ils disent que leur travail profitera aussi aux systèmes RISC-V avec MMU.
# Monté de RISC-V suite a la perte de confiance dans les USA
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4.
RISC-V (et l'open-source/hardware) profite a fond de l'incertitude que Trump engendre un peu partout dans le monde et surtout bien entendu en Chine. Le mouvement open-hardware était lancé mais balbutiant et surtout très lent. La guerre commerciale des USA avec la Chine mais aussi l'Amérique Latine et même l'Europe pousse tous les pays a tenter de se libérer un maximum de la dépendance vis à vis des USA.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# TTY-ready ?
Posté par Anonyme . Évalué à 3.
Mais celui-ci n'est pas non plus desktop-ready, même avec i3wm il va galérer vu qu'il ne possède pas de framebuffer et qu'il est bien plus petit qu'un Sifive U.
Bref, c'est plus costaud qu'une Hifive1 et plus accessible une Hifive Unleashed mais sans un GPU basique on ne peut toujours pas considérer que la sortie écran puisse rendre la carte desktop-ready.
[^] # Re: TTY-ready ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Surtout sans MMU… on a arrêté de faire ça sur le desktop depuis… Windows 95?
[^] # Re: TTY-ready ?
Posté par Kerro . Évalué à 4.
Effectivement, ça n'existe plus depuis Windows 95.
Les 286 ont une MMU et un début de mémoire virtuelle, mais pas utilisées par Microsoft. Windows 95 ne fonctionnait pas dessus.
Les 386 ont une MMU et la mémoire virtuelle. C'était le processeur minimum requis pour Windows 95.
[^] # Re: TTY-ready ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 05 décembre 2019 à 12:09.
Oui, aucune chance que le Kendryte K210 devienne un proc «desktop-ready». Déjà on peu s'interroger sur l’intérêt d'avoir Linux sur ce genre de processeur.
C'est surtout pour la gloire, et pour occuper les équipes de western digital le temps qu'ils reçoivent leur propre proc RISC-V
Mais bon ça fait parler de Linux et du RISC-V. C'était aussi pour montrer qu'il est possible d'avoir un proc RISC-V physique aujourd'hui. Et pour montrer que les Chinois sont maintenant dans la course en matière de SoC.
J'ai plus qu'une balle
[^] # Re: TTY-ready ?
Posté par David Marec . Évalué à 5.
Il me semble que la µClibC n'implémente ni
fork
niclone
, parce c'est ducopy-on-write
de pages sous Linux. On ne programme pas de la même façon pour un OS sans adressage virtuel, sans pagination.Sans espace d'adressage unique pour un processus, le risque est grand en cas de bug de corrompre tout le système.
On risque d'avoir un bon paquet de daemon/services, voire de logiciels, qui ne fonctionnent pas sur les architectures sans MMU.
Et si on n'a pas accès à l'écosystème linux, autant y coller un OS temps réel, AMHA.
Oui, ça change des journaux habituels de LinuxFr.
FreeBSD aussi bosse pas mal sur RISC-V, mais rien n'existe pour permettre une gestion sans MMU sur ce noyau..
[^] # Re: TTY-ready ?
Posté par Anonyme . Évalué à 4.
Effectivement, même les pages des portages de Debian ou NetBSD sur Motorola 68k précisent que leurs ports ne fonctionnent pas sur les modèles sans MMU.
C'est dommage car en y regardant mieux (parce que oui j'ai dit une grosse connerie), le MCU LCD de ce processeur chinois n'est pas mauvais pour une GUI purement 2D. On était pas loin du desktop-ready.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.