Android y RISC-V: lo que necesitas saber para prepararte

 (opensource.googleblog.com)
2 puntos por GN⁺ 2023-11-02 | 1 comentarios | Compartir por WhatsApp
  • Google está agregando soporte para RISC-V a AOSP para expandir Android a una nueva arquitectura de CPU, y lo está ampliando desde una etapa experimental hacia una colaboración más amplia con el ecosistema
  • El soporte inicial toma como base el perfil rva22 y las extensiones vector y vector crypto, con foco en definir el conjunto de funciones necesario para lograr la implementación de rendimiento que Android espera
  • Ya es posible compilar, probar y ejecutar Android para RISC-V con Cuttlefish, pero el backend de ART y las optimizaciones del compilador todavía no están terminados
  • A finales de 2023 se espera la definición del ABI de NDK y builds canary públicas de CI, mientras que para 2024 están planeados emuladores públicos para probar varios formatos de dispositivo
  • Como portar Android por sí solo no es suficiente, Google también está preparando el entorno de desarrollo de aplicaciones junto con RISE Project, RISC-V International y las comunidades de toolchains y bibliotecas de soporte

Soporte de RISC-V que llega a Android

  • Android es un sistema operativo de código abierto que soporta varios tipos de dispositivos y arquitecturas de CPU, y está agregando RISC-V como nuevo objetivo de plataforma
  • RISC-V es una arquitectura de conjunto de instrucciones (ISA) libre y abierta, un enfoque que busca llevar al ecosistema de hardware la forma de colaboración de toda la industria que ya existe en el software de código abierto
  • Desde que fue creada en UC Berkeley hace 10 años, ha sido adoptada rápidamente en el ámbito embebido y de microcontroladores, y recientemente se ha expandido a aceleradores, servidores y computación móvil

De aceptar parches a una etapa madura de soporte

  • Google anunció en el RISC-V Summit de noviembre de 2022 que comenzaría a aceptar parches de RISC-V para Android
  • Ahora está pasando de simplemente aceptar parches a una etapa de maduración del soporte de RISC-V en Android
  • Como RISC-V es una ISA modular con muchas extensiones opcionales, para ofrecer el alto rendimiento que Android espera es necesario definir un conjunto inicial de funciones obligatorias
    • Entre los criterios se incluye el perfil rva22
    • También se incluyen las extensiones vector y vector crypto

Entorno AOSP que puede compilarse y ejecutarse localmente

  • El soporte de Android para RISC-V, como otros objetivos de plataforma de AOSP, puede compilarse, probarse y ejecutarse en una máquina local con Cuttlefish Virtual Device
  • El código relacionado puede revisarse en google/android-riscv64
  • Un ejemplo de ejecución es el siguiente
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • Es posible interactuar con el dispositivo en ejecución conectándose con vncviewer

Tareas de optimización que aún quedan pendientes

  • Los parches actuales permiten compilar y ejecutar la experiencia básica de Android Open Source Project, pero todavía no está en un estado completamente optimizado
  • El trabajo del backend de optimización de ART de Android Runtime sigue en curso
  • AOSP, los proyectos externos y los compiladores aún no han llegado al punto de generar código completamente optimizado y reducido aprovechando las extensiones ratificadas más recientes
  • En esta etapa, el objetivo se acerca más a permitir la experimentación y la colaboración que a ofrecer un entorno de producto terminado

Hoja de ruta para pruebas de desarrolladores y emuladores

  • Se espera que el ABI de NDK quede definido a finales de 2023
  • También se prevé que pronto se ofrezcan builds canary en la CI pública de Android
  • Se planea soportar la ejecución de RISC-V en x86-64 y ARM64 para facilitar las pruebas de aplicaciones Android riscv64 en la máquina host
  • En 2024 están planeados emuladores públicos con un conjunto completo de funciones para probar aplicaciones en distintos formatos de dispositivo
  • Según el anuncio de colaboración con Qualcomm, se espera que el primer formato de dispositivo sea el de wearables

Colaboración del ecosistema y RISE Project

  • No basta con portar el propio sistema operativo Android; también es necesario preparar el ecosistema de software alrededor
  • Google está colaborando con la comunidad y con RISE
  • RISE Project fue creado para acelerar la disponibilidad de software en núcleos de procesador RISC-V de alto rendimiento y eficiencia energética capaces de ejecutar sistemas operativos de alto nivel
  • Su alcance incluye no solo Android, sino también Linux y otros sistemas operativos
  • Los dominios de aplicación objetivo también incluyen la computación de alto rendimiento
  • Las empresas participantes son Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head y Ventana

Estandarización y rutas de contribución

  • Google sigue ampliando su inversión en RISC-V International, más allá de su membresía Premium actual y su participación en la junta directiva
  • Varios colaboradores cumplen roles clave en comités horizontales, grupos de trabajo y comités técnicos, participando en el diseño y la ratificación de especificaciones
  • El soporte de RISC-V en Android depende de contribuciones amplias, desde el LLVM toolchain hasta las bibliotecas básicas de soporte
  • Los recursos principales para contribuir y probar son los siguientes
    • google/android-riscv64: ofrece formas de compilar y probar el soporte de RISC-V en Android, problemas conocidos y oportunidades de contribuir a AOSP, al toolchain y a las bibliotecas de soporte
    • RISC-V Android SIG: lista de correo donde se puede seguir el progreso y enviar propuestas y comentarios
  • Google está buscando cómo lograr que los desarrolladores Android que escriben código nativo también puedan apuntar fácilmente a la nueva plataforma, así como los desarrolladores de Java y Kotlin pueden hacerlo con una plataforma nueva

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-02
Opiniones de Hacker News

  • ¿Se espera que los desarrolladores se preparen? El enfoque está mal. Como hizo Apple durante la transición a M1, lo predeterminado debería ser que el trabajo sea cercano a 0, y luego permitir optimizaciones opcionales.
    Basta recordar cuando Google dijo que probaran las apps de Android en x86 y luego también en MIPS. Al final no pasó nada, y los desarrolladores no van a perder el tiempo.

    • ¿Trabajo 0? Parece que a veces la memoria se desvanece rápido.
      Apple les alquiló a los desarrolladores sistemas DTK por 500 dólares para que pudieran probar hardware ARM y portar sus apps. Estuvo lejos de ser trabajo 0; además había que devolver el hardware y, al principio, ni siquiera había un crédito de 500 dólares para usar en la compra del producto de producción. Lo corrigieron recién después de una reacción previsible.
      Google, en cambio, ofrece un emulador de software, así que es mucho más fácil de manejar y no requiere la logística complicada de dispositivos. En la práctica, quienes necesitan hacer trabajo de preparación son quienes crean apps con NDK o quienes dan soporte a hardware RISC-V.
      Las apps Java/Kotlin no necesitan portarse, así que, para mí, eso es cercano a trabajo 0.
    • Las compilaciones x86 de apps y bibliotecas de Android son muy comunes porque son el destino más habitual en el emulador.
      No creo que Google haya impulsado MIPS con mucha fuerza; más bien simplemente existía.
      Además, este artículo está más dirigido a fabricantes de dispositivos que a desarrolladores de apps, y trata sobre compilaciones de AOSP y parches pendientes. No es un texto que les pida a los desarrolladores de apps hacer algo; de hecho, al final dice que “veremos formas de hacer que para los desarrolladores nativos de Android sea tan fácil apuntar a una nueva plataforma como lo es para los desarrolladores de Java y Kotlin”.
    • En Android, MIPS prácticamente murió después de que Imagination Technologies lo adquiriera en 2013. Si no hay nuevos SoC ni nuevos teléfonos, Google tampoco puede hacer mucho.
      x86 sigue teniendo un uso amplio gracias a las Chromebook. Si no usas el NDK, no hay nada que hacer del lado del desarrollador por un nuevo destino.
    • En términos generales, no parece que esperen que los desarrolladores se preparen. El título también dice “lo que necesitas saber para prepararte”, así que suena más a que, si quieres prepararte, te ofrecen información y consejos. Tomarlo o no es opcional.
      Aquí “you” sigue la formulación del título; no se refiere a una persona específica.
    • Es porque no se lanzaron dispositivos significativos con esa arquitectura.

  • ¿Será necesaria la extensión C a la que Qualcomm se opone tanto?
    Para el subhilo relacionado, ver https://news.ycombinator.com/item?id=37996820
    El material más reciente de Qualcomm es https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS..., donde afirman que la extensión Zics que propusieron, “hacer que RISC-V se parezca un poco a aarch64”, junto con saltos largos de 32 bits, logra mejor densidad de código que RV64GC y no tiene las desventajas de la extensión C que ellos vienen cuestionando.

    • No sé por qué lo votan negativamente. Esta pregunta es, en realidad, un tema que sigue abierto.
      Si Qualcomm decide hacer un RISC-V Snapdragon sin la extensión C, es difícil ver cómo funcionarían las apps de Android NDK que usan esa extensión. Salvo que sea algo como una trampa seguida de emulación, sería ridículamente lento.
    • Parece que Qualcomm tiene algo de razón, pero también parece tener la motivación de querer más reutilización de tecnología ARM.
      Si Google impone RV64GC o RV64G_Zics, esto podría resolverse ahí.
      Dicho eso, quitar o cambiar instrucciones C no es una opción después de un despliegue real, y ahora quizá no importe tanto porque la mayoría está en etapa de pruebas con emuladores.
    • Se ve bastante parecido al conjunto de instrucciones Thumb de ARM.
      La verdadera pregunta es por qué.
      Referencia: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • Es un tema lateral, pero cuando me enteré del nuevo emulador de AOSP, por alguna razón pensé que para usar el emulador Cuttlefish en AOSP en lugar de Goldfish tenía que ejecutar acloud. Pero acloud se negaba a ejecutarse si no era Ubuntu.
    Incluso probé un hack con LD_PRELOAD para cambiar la salida de la función uname, pero después intentaba ejecutar dpkg. Yo uso NixOS.
    Hacer funcionar bien el emulador anterior era realmente engorroso, y el nuevo emulador tiene muchas ventajas.
    Pero, curiosamente, no tenía idea de que bastaba con ejecutar launch_cvd directamente.

  • Espero que “Android for RISC-V” tenga más éxito que “Android for x86”, que fue un desastre total. Todavía tengo una tablet Lenovo x86 con Android.
    Aun así, leer este artículo no me genera mucha confianza. Mis esperanzas son altas, pero mis expectativas son bajas.

    • Parece inevitable que el mercado se llene de dispositivos de consumo baratos que usen implementaciones de RISC-V como procesador principal.
      Más bien creo que habría que preocuparse más por el estancamiento del soporte para ARM.
    • Las Chromebook hoy son mayormente x86 y ejecutan apps de Android. Lo mismo pasa con el emulador de Android.
      No todos son estadounidenses ricos con una MacBook ARM.

  • Hace unos años, Android se usaba bastante en el ámbito embebido cuando se necesitaba una pantalla táctil gráfica, no necesariamente en teléfonos o tablets; pero ahora quedó casi para teléfonos y, en cierta medida, tablets.
    La razón es que, a diferencia de los fabricantes de teléfonos y tablets, las empresas pequeñas no podían seguir el ritmo de los nuevos cambios muy complejos de Android, así que se fueron alejando poco a poco.

    • Me da curiosidad saber qué están usando en su lugar.
    • Parece que DJI todavía usa Android en sus controles.

  • No entiendo bien la situación: ¿existen teléfonos importantes que implementen RISC-V? ¿Y esto requiere cambios en todo el stack? No parece ser algo de solo cambiar el sistema operativo.

    • Todavía no, pero su lanzamiento se acerca.
      No estoy seguro de dónde trazas la línea entre “stack” y “sistema operativo”. ¿Podrías explicarlo un poco más?
    • No. Pero Qualcomm está preparando procesadores RISC-V para smartwatches. No es poca cosa.
      Todavía no probé el port de AOSP para la LiCheePi 4A. Supongo que debería correrlo alguna vez solo para ver si funciona.
      Es más fácil bajar Minecraft desde Play Store que hacer bootstrap de toda la toolchain necesaria para hacer funcionar PolyMC.

  • Google Android sería mi última opción entre las cosas para instalar en RISC-V.

    • Me pregunto si, cuando RISC-V se use con frecuencia en CPUs móviles, tendrá un impacto positivo en el ecosistema, o si las grandes empresas empujarán RISC-V hacia casos de uso más corporativos y lo harán menos amigable para desarrolladores aficionados.
    • Aun así, quizá termines comprando un dispositivo RISC-V con Android preinstalado y luego lo borres.

  • Si se puede evitar, ejecutar Android es una elección tonta, y más aún si al cambiar de arquitectura existe la oportunidad de pasarse a Linux puro.
    El problema es la banca. Al menos en Suecia todavía dependemos de BankID móvil. Por ejemplo, también se necesita para compras en línea de más de 20 dólares, y solo funciona en iOS y Android.

    • ¿Hay alguna forma realista de correr un sistema operativo que no sea Android en un teléfono y aun así tener eficiencia energética, multitouch y soporte para apps de Android con aceleración por GPU?
      Por ejemplo, alguna solución lista para usar que ejecute Android de forma eficiente en KVM, o algo que proporcione funciones del kernel de Android y un servidor RPC en espacio de usuario.
      Si no existe eso, no queda otra que correr Android para acceder a apps móviles, y eso es casi indispensable.
    • En Dinamarca tenemos MitID para bancos y sitios del gobierno. A veces también se usa para autenticar compras.
      Si no tienes un smartphone o no quieres usarlo, puedes recibir un dispositivo pequeño para la autenticación. Suena raro que Suecia obligue a todos los que tienen una cuenta bancaria a tener también un smartphone. Sobre todo porque debe haber muchas personas mayores sin smartphone.