- Google ajoute la prise en charge de RISC-V à l’AOSP pour étendre Android à une nouvelle architecture CPU, et passe d’une phase expérimentale à une collaboration plus large avec l’écosystème
- La prise en charge initiale s’appuie sur le profil rva22 ainsi que sur les extensions vectorielles et de cryptographie vectorielle, avec pour objectif de réunir l’ensemble de fonctionnalités nécessaire aux performances attendues par Android
- Il est déjà possible de compiler, tester et exécuter Android pour RISC-V avec Cuttlefish, mais le backend ART et les optimisations du compilateur ne sont pas encore finalisés
- D’ici fin 2023, la finalisation de l’ABI du NDK et des builds canary CI publics sont attendus, et pour 2024, un émulateur public couvrant plusieurs formats d’appareils est prévu pour les tests
- Comme le portage d’Android seul ne suffit pas, Google prépare aussi l’environnement de développement d’applications avec le projet RISE, RISC-V International et les communautés des toolchains et des bibliothèques de support
La prise en charge de RISC-V arrive sur Android
- Android est un système d’exploitation open source qui prend en charge plusieurs types d’appareils et architectures CPU, et ajoute désormais RISC-V comme nouvelle plateforme cible
- RISC-V est une architecture de jeu d’instructions (ISA) libre et ouverte, qui vise à transposer à l’écosystème matériel la logique de collaboration industrielle du logiciel open source
- Créée à UC Berkeley il y a dix ans, elle a été rapidement adoptée dans l’embarqué et les microcontrôleurs, avant de s’étendre récemment aux accélérateurs, aux serveurs et à l’informatique mobile
De l’acceptation de correctifs à une prise en charge plus mature
- Google a annoncé lors du RISC-V Summit de novembre 2022 qu’il commencerait à accepter des correctifs RISC-V pour Android
- L’objectif est désormais de dépasser la simple acceptation de correctifs pour faire mûrir la prise en charge de RISC-V dans Android
- RISC-V étant une ISA modulaire avec de nombreuses extensions optionnelles, il faut définir un ensemble initial de fonctionnalités obligatoires pour atteindre les hautes performances attendues par Android
- Le profil rva22 fait partie de cette base
- Les extensions vector et vector crypto en font aussi partie
Un environnement AOSP que l’on peut compiler et exécuter en local
- La prise en charge d’Android pour RISC-V peut être compilée, testée et exécutée en local via le périphérique virtuel Cuttlefish, comme les autres plateformes cibles de l’AOSP
- Le code associé est disponible sur google/android-riscv64
- Exemple d’exécution :
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
- Une fois le système lancé, il est possible d’interagir avec l’appareil via vncviewer
Des optimisations restent encore à faire
- Les correctifs actuels permettent de compiler et d’exécuter une expérience Android Open Source Project de base, mais l’ensemble n’est pas encore totalement optimisé
- Le travail sur le backend d’optimisation ART d’Android Runtime est toujours en cours
- L’AOSP, les projets externes et les compilateurs ne sont pas encore au niveau où ils exploitent pleinement les extensions ratifiées les plus récentes tout en générant un code entièrement optimisé et compact
- L’extension vector est citée en exemple
- À ce stade, l’objectif est davantage de permettre l’expérimentation et la collaboration que de fournir un environnement produit finalisé
Feuille de route pour les tests développeurs et l’émulateur
- La finalisation de l’ABI du NDK est attendue d’ici fin 2023
- Des builds canary seront également bientôt proposés sur la CI publique d’Android
- Il est aussi prévu de prendre en charge l’exécution RISC-V sur x86-64 et ARM64 afin de faciliter les tests d’applications Android riscv64 sur les machines hôtes
- En 2024, un émulateur public avec un ensemble complet de fonctionnalités est prévu pour tester des applications sur différents formats d’appareils
- D’après l’annonce de collaboration avec Qualcomm, le premier format visé devrait être celui des objets connectés portables
Collaboration écosystème et projet RISE
- Le simple portage du système d’exploitation Android ne suffit pas ; il faut aussi préparer l’écosystème logiciel qui l’entoure
- Google collabore avec la communauté et avec RISE
- Le projet RISE a été créé pour accélérer la disponibilité logicielle sur des cœurs processeur RISC-V à hautes performances et sobres en énergie, capables d’exécuter des systèmes d’exploitation de haut niveau
- Son périmètre couvre non seulement Android, mais aussi Linux et d’autres systèmes d’exploitation
- Les domaines d’application visés incluent également le calcul haute performance
- Les entreprises participantes sont Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head et Ventana
Standardisation et voies de contribution
- Google continue d’accroître ses investissements dans RISC-V International, au-delà de son statut existant de membre Premium et de sa participation au conseil d’administration
- Plusieurs contributeurs jouent un rôle clé dans des comités horizontaux, des groupes de travail et des comités techniques, participant à la conception et à la ratification des spécifications
- La prise en charge de RISC-V dans Android dépend de contributions étendues, depuis la toolchain LLVM jusqu’aux bibliothèques de support de base
- Les principales ressources pour contribuer et tester sont les suivantes
- google/android-riscv64 : méthodes pour compiler et tester la prise en charge de RISC-V dans Android, problèmes connus, et possibilités de contribution à l’AOSP, à la toolchain et aux bibliothèques de support
- RISC-V Android SIG : liste de diffusion pour suivre l’avancement et proposer des idées ou des retours
- Google cherche à permettre aux développeurs Android qui écrivent du code natif de cibler facilement cette nouvelle plateforme, tout comme les développeurs Java et Kotlin peuvent viser une nouvelle plateforme
1 commentaires
Avis sur Hacker News
On s’attend à ce que les développeurs se préparent ? C’est une mauvaise approche. Comme pour la transition M1 d’Apple, la base devrait être un travail proche de zéro, puis des optimisations optionnelles ensuite
Il suffit de se rappeler quand Google disait de tester les applis Android sur x86, puis de nouveau sur MIPS. Au final, il ne s’est rien passé, et les développeurs ne vont pas perdre leur temps
Apple a loué aux développeurs des systèmes DTK pour 500 dollars afin qu’ils puissent manipuler du matériel ARM et porter leurs applis. On était loin d’un travail nul, il fallait rendre le matériel, et au départ il n’y avait même pas de crédit de 500 dollars pour l’achat d’un produit final. Cela n’a été corrigé qu’après une contestation prévisible
Google fournit à la place un émulateur logiciel, donc c’est bien plus simple à utiliser et cela évite toute la logistique complexe du matériel. En pratique, ceux qui doivent vraiment se préparer sont les gens qui créent des applis NDK ou qui assurent la prise en charge du matériel RISC-V
Les applis Java/Kotlin n’ont pas besoin d’être portées, donc de mon point de vue on est proche d’un travail nul
MIPS n’a jamais donné l’impression d’être fortement poussé par Google, c’était plutôt quelque chose qui existait, sans plus
En plus, cet article vise davantage les fabricants d’appareils que les développeurs d’applis, en parlant des builds AOSP et des patchs en attente. Ce n’est pas un texte qui demande aux développeurs d’applications de faire quoi que ce soit, et il se termine plutôt par : « nous verrons comment permettre aux développeurs Android natifs de cibler facilement une nouvelle plateforme, comme le font déjà les développeurs Java et Kotlin »
x86 reste largement utilisé grâce aux Chromebook. Si vous n’utilisez pas le NDK, il n’y a rien à faire côté développeur pour cette nouvelle cible
Ici, « you » reprend juste la formulation du titre, cela ne vise aucune personne en particulier
Est-ce que cela rend nécessaire l’extension C à laquelle Qualcomm s’oppose autant ?
Voir le sous-fil associé : https://news.ycombinator.com/item?id=37996820
Le document récent de Qualcomm est https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS... ; ils y affirment que l’extension Zics qu’ils proposent, qui « rend RISC-V un peu plus proche de aarch64 », ainsi que les sauts longs 32 bits, donnent une meilleure densité de code que RV64GC, sans les inconvénients de l’extension C qu’ils critiquent depuis longtemps
Si Qualcomm décide de fabriquer un Snapdragon RISC-V sans extension C, il est difficile de voir comment les applis Android NDK qui utilisent cette extension fonctionneraient. À moins d’une forme de trap suivie d’émulation, ce serait absurdement lent
Si Google impose RV64GC ou RV64G_Zics, cela pourrait trancher la question
Cela dit, retirer ou modifier les instructions C n’est pas une option une fois le déploiement réel lancé, et comme on est encore surtout dans une phase de test sur émulateur, ils ne s’en soucient peut-être pas trop
La vraie question, c’est pourquoi
Référence : https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...
À part ça, quand j’ai découvert le nouvel émulateur AOSP, j’ai cru pour une raison quelconque qu’il fallait lancer
acloudpour utiliser l’émulateur Cuttlefish dans AOSP au lieu de Goldfish. Maisacloudrefusait de s’exécuter si ce n’était pas sur UbuntuJ’ai même essayé un hack
LD_PRELOADpour modifier la sortie de la fonctionuname, mais ensuite il essayait d’exécuterdpkg. J’utilise NixOSL’ancien émulateur était vraiment pénible à faire fonctionner correctement, et le nouveau a beaucoup d’avantages
Pourtant, je n’avais étrangement jamais compris qu’il suffisait d’exécuter directement
launch_cvdJ’espère que « Android for RISC-V » aura plus de succès que « Android for x86 », qui a été un désastre complet. J’ai encore une tablette Lenovo x86 sous Android
Cela dit, même en lisant cet article, cela n’inspire pas énormément confiance. J’ai beaucoup d’espoir, mais peu d’attentes
Je m’inquiéterais plutôt d’un ralentissement du support ARM
Tout le monde n’est pas un Américain aisé avec un MacBook ARM
Il y a quelques années, Android était assez répandu non pas dans les téléphones ou les tablettes, mais dans le secteur embarqué nécessitant des écrans tactiles graphiques ; aujourd’hui, il est devenu presque uniquement orienté téléphones, et dans une certaine mesure tablettes
La raison est que, contrairement aux fabricants de téléphones et de tablettes, les petites entreprises n’arrivaient pas à suivre les nouvelles évolutions d’Android, très complexes, et sont donc parties progressivement
Je ne connais pas bien la situation, mais existe-t-il déjà des téléphones majeurs implémentant RISC-V ? Et cela nécessite-t-il des changements sur toute la pile ? J’imagine que ce n’est pas juste une question de remplacer le système d’exploitation
Je ne suis pas certain de voir où tu places la frontière entre la « pile » et le « système d’exploitation ». Tu peux préciser un peu ?
Je n’ai pas encore essayé le port AOSP pour le LiCheePi 4A. Il faudrait que je le lance juste pour voir si ça fonctionne.
Il est plus facile de télécharger Minecraft depuis le Play Store que d’amorcer toute la toolchain nécessaire pour faire tourner PolyMC
Parmi les choses à installer sur du RISC-V, Google Android serait mon tout dernier choix
Si on peut l’éviter, faire tourner Android est un choix idiot, et si l’on change d’architecture avec l’occasion de passer à du Linux natif, c’est encore plus vrai.
Le problème, c’est la banque. En Suède au moins, on dépend encore de BankID mobile. Il est nécessaire, par exemple, pour des achats en ligne de plus de 20 dollars, et il ne fonctionne que sur iOS et Android
Par exemple, une solution existante permettant de faire tourner Android efficacement dans KVM, ou quelque chose qui fournirait les fonctionnalités du noyau Android et un serveur RPC en espace utilisateur.
Si ce n’est pas le cas, alors il faut malgré tout faire tourner Android pour accéder aux applications mobiles, et cela devient pratiquement indispensable
Si l’on n’a pas de smartphone, ou qu’on ne veut pas en utiliser un, on peut recevoir un petit appareil servant à l’authentification. Il est étrange que la Suède semble imposer la possession d’un smartphone à toute personne ayant un compte bancaire, surtout quand il doit y avoir beaucoup de personnes âgées qui n’en ont pas