Informe de progreso de Asahi Linux 7.1

 (asahilinux.org)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En Linux 7.1, Asahi Linux está avanzando al mismo tiempo en la ampliación del soporte para M3, la compatibilidad con la beta de macOS 27, la decodificación de video AVD y los cambios de m1n1 1.6.0
  • En la beta para desarrolladores de macOS 27 Golden Gate, la entrada de arranque de Asahi desapareció de Startup Disk y del selector de arranque, pero las particiones y los datos seguían ahí, y pudo recuperarse configurando la bandera de arranque de APFS
  • Un cambio en el firmware del SMC modificó valores de retorno de la gestión de batería y provocó apagados de emergencia bajo ciertas condiciones; el kernel downstream lo maneja para ambos ABI de firmware desde la versión 7.0.12
  • En la familia M3 ya funcionan en Linux el audio, el cambio de frecuencia de CPU, la planificación big.LITTLE, sensores SMC, PCIe, WiFi, Bluetooth, NVMe, teclado y trackpad, pero todavía no está en la etapa de soporte del Asahi Installer
  • AVD avanzó hacia la decodificación por hardware de AVC con firmware propio y un driver V4L2 en lugar del firmware de Apple, y m1n1 1.6.0 ahora exige Rust para compilar stage 2, con un impacto importante para las distribuciones

La entrada de arranque de Asahi que desapareció en macOS 27

  • La entrada de Asahi que aparece en el selector de arranque al mantener presionado el botón de encendido del Mac o en la app Startup Disk no es en realidad una partición del sistema operativo
  • Como las herramientas de arranque de Apple solo manejan “instalaciones válidas de macOS” dentro de un contenedor APFS, Asahi Installer crea un contenedor APFS de 2.5 GB y usa una configuración mínima de macOS con m1n1 insertado como si fuera el kernel
  • Este método funcionó sin cambios desde macOS 12 hasta macOS 26, y Apple también corrigió parcialmente un bug de sus herramientas que aparecía solo al arrancar un binario raw en lugar de un kernel XNU real
  • Después de la beta para desarrolladores de macOS 27 Golden Gate, algunos usuarios se encontraron con que la entrada de Asahi desaparecía de Startup Disk y del selector de arranque
    • Al revisar con diskutil, las particiones relacionadas con Asahi seguían en el disco y no hubo pérdida de datos
    • En la misma máquina, si se usaban las herramientas de arranque de macOS 26, Asahi seguía pudiendo arrancar
  • El instalador de macOS configura metadatos de APFS antes de reiniciar, y tras investigar más se vio que este valor era una bandera que marca un volumen como arrancable
    • Las herramientas de arranque anteriores a macOS 27 ignoraban esta bandera
    • Si se configuraba manualmente la bandera en el contenedor APFS de Asahi, volvía a aparecer en el selector de arranque de macOS 27
  • En instalaciones nuevas de Asahi, Asahi Installer ahora configura esta bandera automáticamente
  • También se agregó un modo de instalación para reparar instalaciones existentes
    • Si después de instalar la beta para desarrolladores de macOS 27 ya no se puede acceder a Asahi, hay que ejecutar de nuevo el instalador y usar la opción “Fix macOS 27 boot picker compatibility”
  • También se creó una herramienta para corregir el problema desde Linux, pero hace falta más información de pruebas antes de distribuirla automáticamente
    • Para probarla, antes de actualizar a macOS 27 hay que clonar el repositorio asahi-fix27 y compilarlo y ejecutarlo en Linux
    • Si después, en macOS, el volumen de Asahi puede elegirse como destino de arranque, entonces funcionó
    • Los resultados y problemas pueden compartirse en los canales de la comunidad de Asahi

Cambio de firmware del SMC y apagados de emergencia del driver de batería

  • macOS 27 incluye actualizaciones de firmware para todos los periféricos que usan firmware global, incluido el SMC
  • El SMC se encarga de la gestión de batería, y el driver de power supply de Linux se comunica con él para obtener información sobre el estado de carga, voltaje, tiempo restante de descarga y estado de la batería
  • Ese mismo driver también configura, mediante la interfaz de firmware del SMC, los umbrales para iniciar o detener la carga con el fin de prolongar la vida útil de la batería
  • El firmware SMC de macOS 27 cambió una interfaz de gestión de batería de un retorno entero de 32 bits a un retorno de 1 byte
  • Debido a este cambio, el driver de Asahi interpretaba bajo ciertas condiciones que había una falla de batería y disparaba un apagado de emergencia para proteger el sistema
  • El parche ya se aplicó en el kernel downstream, y desde 7.0.12 el driver de power supply maneja ambos ABI de firmware

Advertencia sobre instalar la beta para desarrolladores

  • Los dos problemas aparecidos en macOS 27 muestran que una beta para desarrolladores realmente es una beta para desarrolladores
  • No se recomienda instalar una beta para desarrolladores en una máquina de producción
  • Hasta ahora, los dos problemas que ocurrieron por suerte fueron pequeños, pero no hay garantía de que los próximos también lo sean
  • Las actualizaciones de firmware global son prácticamente permanentes, y para revertirlas hay que hacer un DFU restore a la máquina
  • Desde Asahi consideran que, como ellos usan máquinas de sacrificio para pruebas, los usuarios no necesitan poner en riesgo hardware costoso ni datos importantes

Avances en el soporte para la familia M3

  • Las plataformas informáticas y el diseño y validación de IC consumen mucho tiempo y dinero, así que no resulta razonable hacer cambios innecesarios en diseños ya existentes
  • El proyecto Asahi partió de la suposición de que Apple no seguiría introduciendo cambios incompatibles de forma continua en la plataforma y en los IC, y salvo grandes bloques del SoC que cambian más entre generaciones, como la GPU, eso en general se ha cumplido

  • Salida de audio

    • El audio en laptops con Apple Silicon usa varios IC y bloques del SoC
    • El estándar de facto de la industria para IC de audio es I2S, un bus basado en I2C optimizado para datos de audio
    • El controlador I2S de Apple y Apple NCO, una fuente de reloj estable, no han cambiado desde M1
    • Apple usa el mismo chip amplificador para parlantes y audífonos en casi todas las máquinas Apple Silicon
    • Al agregar soporte para parlantes y jack de audífonos en máquinas M3, el trabajo necesario consistió sobre todo en pequeñas adiciones al Devicetree y archivos de configuración para asahi-audio y speakersafetyd
    • Las máquinas M3 ya ofrecen salida de audio de alta calidad en Asahi Linux

  • Frecuencia de CPU y planificación big.LITTLE

    • Las máquinas M3 también ya soportan el cambio de frecuencia de CPU y una planificación de tareas big.LITTLE adecuada
    • Apple no cambió la forma de manejar el cambio de frecuencia de CPU desde el M2 base
    • Los SoC M3, M3 Pro, M3 Max y M3 Ultra funcionan con el driver cpufreq existente solo con cambios en el Devicetree
    • Las tareas se colocan de forma más inteligente en núcleos de eficiencia o de rendimiento según los requisitos, y los núcleos suben o bajan la frecuencia según la carga
    • Este cambio mejora tanto el ahorro de energía como el rendimiento

  • Sensores y dispositivos clave

    • Como el firmware del SMC no difiere mucho entre máquinas, el soporte para sensores de hardware del SMC también solo necesitó algunos cambios en el Devicetree
    • En las máquinas de la familia M3 también funcionan en Linux los drivers de PCIe, WiFi, Bluetooth, NVMe, teclado, trackpad y otros bloques clave del SoC
    • Una parte importante de este trabajo fue realizada por Yureka, que ha venido trabajando con m1n1 y Linux en máquinas de la familia M3
    • Aún hace falta más trabajo para habilitar el soporte del Asahi Installer en máquinas M3, pero el avance va rápido

Decodificación de video AVD y firmware propio

  • Gran parte del hardware complejo de la plataforma Apple Silicon usa blobs de firmware complejos
  • Muchos firmwares se basan en RTKit, un framework parecido a un RTOS que Apple usa para ofrecer una interfaz más o menos estandarizada entre el kernel y varios bloques de hardware
  • Algunos bloques, como DCP y AOP, se basan en RTKit pero añaden encima otra abstracción llamada EPIC
  • También hay casos como los chipsets Broadcom de WiFi/Bluetooth, que usan firmware de terceros no controlado directamente por Apple
  • Apple Video Decoder, o AVD, usa un firmware con una estructura distinta, que no es ni RTKit ni EPIC

  • Estructura de AVD y problemas del enfoque anterior

    • El hardware AVD se parece a un ARM Cortex-M3 que controla unidades de hardware de función fija para decodificar cuadros de video AVC (H.264), HEVC (H.265), VP9 y AV1 en SoC recientes
    • El Cortex-M3 ofrece una interfaz para que XNU apunte a los datos de video y ejecuta un blob de firmware que configura el hardware decodificador real
    • Apple coloca juntos el firmware de AVD y los datos de configuración dentro del kext de AVD
    • Como cada SoC usa una variante de AVD ligeramente distinta, eso generaba un problema logístico: Asahi Installer tenía que seguir y actualizar continuamente los cambios en los offsets de los datos de firmware dentro del kext

  • Enfoque con firmware propio

    • El firmware AVD que carga XNU no se verifica en el Cortex-M3
    • Cuando recibe la señal, simplemente ejecuta desde el vector de reset, así que corre lo que sea que esté cargado ahí
    • Como la función del firmware es básicamente abstraer el hardware del decodificador de video, se puede programar directamente desde el driver de Linux siempre que se instalen los manejadores de interrupciones de cada bloque de hardware
    • Como es código estándar para Cortex-M3, el firmware de AVD puede ejecutarse en un emulador
    • QEMU permite ejecución paso a paso e inspección de operaciones de bus y registros
    • Jamie, R y Eileen ya habían hecho trabajo conjunto en el pasado para hacer ingeniería inversa de los comandos y formatos de datos necesarios para los decodificadores AVC y VP9
    • El kext de XNU también aplica tunables específicos para cada revisión de AVD
    • No está completamente claro qué hace exactamente cada uno de esos valores
    • Su aplicación se parece a reproducir escrituras MMIO de XNU
    • Hay que rastrear cada revisión de AVD, cada conjunto de tunables y a qué revisiones se aplica
    • Como eso es difícil de mantener de forma satisfactoria en un driver del kernel Linux upstream, también es más apropiado dejar esa parte en el firmware

  • Driver V4L2 para AVC

    • El nuevo colaborador sofus creó un firmware AVD personalizado básico que instala los manejadores de interrupciones y aplica los tunables de cada variante
    • A partir de eso, escribió un driver V4L2 funcional para hardware AVC
    • El hardware puede decodificar video AVC codificado a 10 bits hasta 4K
    • Funciona bien con software que implementa la V4L2 Request API
    • Mantener el firmware simple y sin estado, y dejar que el espacio de usuario y el kernel se encarguen del parseo de datos de video y de programar el decodificador, facilitará más adelante soportar otras API de aceleración de video como VA-API o Vulkan Video
    • Todavía queda trabajo antes de ofrecer soporte AVD a los usuarios
    • AVD también soporta VP9, HEVC y en algunos SoC AV1, pero eso aún no está implementado
    • También hay que probar y reflejar en el driver ciertas quirks de algunos dispositivos
    • Se apunta a un formato distribuible en un plazo no muy lejano

Lanzamiento de m1n1 1.6.0

  • Se etiquetó m1n1 1.6.0, y desde la perspectiva de las distribuciones es una versión con mucho impacto
  • Esta versión exige por primera vez Rust para compilar stage 2
  • Antes, Rust solo se usaba al compilar con soporte para chainloading
  • El m1n1 stage 1 reemplaza al kernel XNU en las herramientas de arranque de Apple, y solo se usa para montar la EFI System Partition y desde ahí hacer chainload de m1n1 stage 2
  • Al decidir mover la inicialización de GPU a m1n1, el driver del kernel dejó de necesitar manejar valores de punto flotante presentes en los datos de inicialización del hardware de Apple y el binding de Devicetree también se simplificó mucho
  • La próxima versión del driver de GPU que se enviará a la Linux Kernel Mailing List dependerá de la premisa de que m1n1 realiza esa inicialización
  • El código para parsear el Apple Device Tree también fue portado a Rust, y se usa en casi todas las demás partes de m1n1

  • Compilación y objetivo

    • Como m1n1 es en la práctica firmware, usa Rust no_std y el objetivo aarch64-none-softfloat
    • Para evitar arrastrar dependencias innecesarias, se puede pasar BUILDSTD=1 a make y así compilar core y alloc sin instalar toda la toolchain softfloat

  • Preparación para M3, M4 y A18 Pro

    • La versión 1.6.0 también incluye varias mejoras para el soporte de la familia M3
    • Soporte para el controlador SPMI
    • Soporte para la inicialización de PCIe
    • Soporte para tunelizar directamente DebugUSB del UART de hardware del SoC mediante kisd
    • El tunelizado del UART por DebugUSB puede ofrecer casi la misma funcionalidad que Central Scrutiniser
    • Una parte considerable de este trabajo también fue contribución de Yureka
    • También está en marcha el trabajo base para el soporte de M4 y A18 Pro, es decir, MacBook Neo
    • Se maneja mejor el modo de arranque no macOS de Apple
    • Se soportan los nuevos metadatos de power domain en el Apple Device Tree

Patrocinio y colaboradores

  • Asahi Linux agradece a sus patrocinadores en GitHub Sponsors y Open Collective
  • Gracias a ese apoyo pueden seguir trabajando en funciones incompletas de M1 y M2, soporte para M3, M4 y A18 Pro, y apoyo para nuevos colaboradores

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones en Hacker News

  • La frase “el estándar de facto de la industria para los IC de audio es I²S, un bus basado en I²C optimizado para datos de audio” no es correcta. I²S no tiene relación con I²C
    Es cierto que la mayoría de los chips I²S tienen una interfaz I²C, porque I²S solo transporta datos de audio sin procesar y no incluye señales adicionales como control de volumen o configuración del reloj
    Pero esa es una interfaz separada y podría ser SPI en lugar de I²C. De hecho, SPI es más cercano a I²S que I²C

    • Correcto, I²S se parece mucho más a SPI
      La razón por la que ambos siguen un esquema de nombres parecido es que Philips Semiconductor (hoy NXP) creó ambos
    • I²S es un diseño sorprendentemente simple. No hay handshake de protocolo; simplemente fluye PCM sin procesar
      Me gusta que esté diseñado para que no haya problemas de compatibilidad aunque el transmisor y el receptor usen profundidades de bits de muestreo distintas en ambos sentidos
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • Es realmente asombroso que un pequeño grupo de personas motivadas logre resolver problemas como estos

    • Muchos problemas no se han resuelto en absoluto. Por ejemplo, la interfaz de administración de energía PSCI de Apple Silicon sigue siendo un misterio
      Otros devicetrees de Linux tienen código PSCI, pero nadie sabe cómo lo implementó Apple. Por eso, durante casi 5 años, los usuarios de Asahi han dependido de hacks para evitar que la batería se siga agotando y, hasta donde sé, todavía no hay una solución prometedora
      Ese es el lado luminoso y oscuro de la ingeniería inversa. Es genial que estos dispositivos tengan drivers nativos de Vulkan 1.2, pero llegar hasta ahí tomó años. Incluso ahora, 7 años después del lanzamiento de Apple Silicon, quedan problemas sin resolver y la mayoría del hardware más reciente no está soportado en general. Al final volvemos a la lección que los usuarios de Linux siempre han repetido: los drivers propietarios no son buenos

  • Me preocupa especialmente la parte en la que el CM3 no verifica el firmware que carga XNU y, cuando llega una señal, empieza a ejecutarlo desde el vector de reset sin importar cuál sea su contenido real
    El logro de haber escrito firmware personalizado contra un objetivo propietario y en constante cambio es inmenso, más de lo que se puede expresar con palabras, pero aparte de esperar que Apple no siga rompiendo deliberadamente los sistemas operativos de terceros, no parece poco probable que introduzca firmas de hardware en los blobs de firmware o en los datos que se suministran al hardware durante el runtime para programarlo. Desde el punto de vista de Apple, podría ser una preocupación de seguridad razonable. Aun así, espero que esta apuesta salga bien

  • Me pregunto si esto se quedará para siempre solo como un “remix” de Fedora. ¿Llegará algún día el soporte upstream para poder correr una distribución basada en Debian?
    Creo que la última vez que usé una distribución basada en RPM fue hace casi 20 años

    • Están subiendo parches a upstream, así que eventualmente los drivers necesarios entrarán en Linux upstream
      Por supuesto, el fork del kernel también es open source, así que nada impide tomar un root de Debian aarch64 y compilar uno mismo el kernel de Asahi, o tomar la compilación de Fedora y armar Debian en estos equipos. Solo que requiere algo de trabajo
      Si Ubuntu te parece bien, también existe Ubuntu Asahi: https://ubuntuasahi.org/
      Buscando, también encontré este documento en la wiki: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • Me dio risa este comentario porque mis gustos son lo contrario. Yo prefiero las distribuciones basadas en RPM y uso Fedora como principal en casi todos lados. También uso Fedora Asahi Remix en mi Mac Studio M1 Ultra, y solo ocasionalmente Ubuntu y Debian en algunas instancias en la nube
      Así que entiendo las ganas de seguir usando una distribución específica que ya conoces. Es menos trabajo y hay que recordar menos diferencias sutiles en la estructura. Aun así, cuando no queda otra que usar una distribución nueva, como cuando Asahi al principio salió solo para Arch Linux ARM, nunca me arrepentí del pequeño aprendizaje que saqué de ahí
    • Arch todavía se puede usar, y también existe Ubuntu Asahi
      Están trabajando mucho en upstream precisamente para que todas las distribuciones puedan portarse con mayor facilidad
      https://ubuntuasahi.org/
    • El Bananas Team está trabajando para hacer funcionar Debian estándar en Apple Silicon, y también hay una forma de instalarlo ahora agregando repositorios no oficiales: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      Todavía no lo he instalado personalmente
    • linux-asahi también está disponible en Void Linux
      https://voidlinux.org/download/#arm%20platforms
      Es un paquete normal de Linux dentro de la distribución: https://github.com/void-linux/void-packages/tree/master/srcp...

  • Me da gusto ver que el soporte para M3 avanza bien
    La primera vez que se mencionó que empezarían a trabajar en agregar soporte para M3 fue en febrero
    “Desde hace bastante tiempo, m1n1 cuenta con soporte básico para dispositivos de la serie M3. Lo que faltaba eran los devicetrees de cada dispositivo y los parches de drivers del kernel de Linux para soportar las características y cambios de hardware específicos de M3 que difieren de M2. Siempre estuvo la intención de concretar este trabajo cuando el conjunto de parches existente fuera más manejable”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • Me entusiasma que estén trabajando en el driver AVD

  • ¿Al usar ffmpeg o VLC en una Mac M1 o superior, se usa AVD?

  • Asahi podría ser una alternativa viable, pero con este nivel de financiamiento y un equipo tan pequeño, parece inevitable que el ritmo de desarrollo sea demasiado lento.
    Como dice el artículo, ya hay trabajo base establecido y también resultados, pero al final cada año salen nuevas Mac con chips nuevos y un montón de microcontroladores y cambios en la GPU, así que es imposible ponerse al día. Por eso el equipo de Asahi también se está enfocando más en los modelos M1 y M2.
    Aun así, hasta ahora en ambos siguen pendientes los problemas de administración de energía en reposo y la implementación de Alt-DP, lo que impide que mucha gente migre. Para cuando esos problemas estén pulidos, el valor de los equipos también habrá caído bastante.
    Es un milagro que un grupo reducido haya logrado tanto, pero pese a la amplia cobertura mediática, al final parece que la pasión y la motivación del equipo han disminuido, y da la impresión de que ni siquiera la M1 Air llegará a estar terminada.

    • Más que “el ritmo de desarrollo es inevitablemente demasiado lento”, cuando llegó el nuevo equipo de liderazgo anunciaron que priorizarían subir el trabajo existente upstream por encima de agregar soporte para hardware más reciente.
      Subir los cambios al kernel tomó tiempo.
      Ahora anunciaron en febrero que empezaron a trabajar en M3, y el avance se ve bien.
      “Además de lo anterior, en los dispositivos de la serie M3 ya funcionan en Linux PCIe, WiFi, Bluetooth, NVMe, el teclado, el trackpad y otros drivers de bloques clave del SoC. La mayor parte de este trabajo estuvo a cargo de Yureka, quien desde hace un tiempo ha estado hackeando de forma muy activa tanto m1n1 como Linux en dispositivos de la serie M3. Todavía falta bastante para que Asahi Installer empiece a dar soporte a estos dispositivos, pero el progreso es rápido, ¡así que estén atentos!”
      Esto se parece más a gente talentosa haciendo trabajo meticuloso que a una catástrofe.
    • Si cada ciertos años pueden apuntar a un solo modelo y lograr que funcione bien, eso es mucho mejor que no tener ninguna alternativa.
      El soporte para M1 hoy es bastante usable, y parece que al menos parte del trabajo se trasladará a dispositivos futuros. No todo es color de rosa, pero tampoco es un proyecto destinado al fracaso.

  • Sería genial que Apple financiara a un equipo pequeño, publicara como open source parte de la documentación y los drivers, y ayudara a Asahi.
    Claro, sé que no lo hará, pero se vale soñar. Para Apple sería calderilla, y con eso su hardware se consolidaría aún más como el estándar de facto entre los ingenieros de Silicon Valley.

  • Me pregunto cuánto han usado modelos de lenguaje grandes últimamente en Asahi. Para la ingeniería inversa son una herramienta realmente potente; ¿han escrito algo al respecto?

  • Me da curiosidad cómo es el proceso de desarrollo/CI de este proyecto.
    Al final, ¿cargan manualmente el build en hardware específico cada vez, o hay etapas en las que se puede automatizar hasta cierto punto?

    • m1n1 hace muchas cosas bastante interesantes en este sentido: https://asahilinux.org/docs/sw/tethered-boot/
      Coloca una capa muy delgada entre el hardware real y el kernel, sin afectar las operaciones de entrada/salida del hardware, y permite controlar y automatizar de forma remota la carga del kernel y la depuración.