Informe de progreso de Asahi Linux 7.0

 (asahilinux.org)
1 puntos por GN⁺ 3 일 전 | 1 comentarios | Compartir por WhatsApp
  • El soporte de Linux para Apple Silicon avanzó en varios frentes al mismo tiempo: automatización del instalador, gestión de energía, audio, pantalla y hasta la activación de M3
  • Asahi Installer cambió para separar los manifiestos de imágenes de la base de código e incorporar despliegues con GitHub workflow, lo que permite actualizarlo con más frecuencia; en la versión 0.8.0 añadió la actualización de m1n1 stage 1, soporte de instalación para Mac Pro y un modo de actualización de firmware
  • El firmware de calibración ALS ahora puede extraerse desde macOS y volver a actualizarse incluso después de la instalación; los cortes de audio por Bluetooth desaparecieron gracias al soporte de comandos de coexistencia de Broadcom, y el soporte de PMP reduce el consumo en reposo en alrededor de 0.5 W en el M1 Pro
  • El soporte de VRR todavía no puede exponerse correctamente al userspace debido a limitaciones del Apple DCP, pero cuando se fusione el pull request podrá activarse a la fuerza con un parámetro del módulo del kernel; además, el trabajo de upstream del stack de audio también incorporó una API genérica de bus keeper y soporte de tasas de muestreo adicionales para el CS42L84
  • El alcance del soporte para M3 se amplió a PCIe, dispositivos de entrada, RTC, reboot controller y NVMe, y Fedora Asahi Remix 44 mantiene su lanzamiento alineado con Fedora 44 junto con un nuevo flujo de instalación basado en Plasma

Automatización del instalador y actualización de firmware

  • Asahi Installer, que durante casi 2 años recibió pocas actualizaciones, tenía ciclos de actualización largos por un proceso de publicación manual y por depender de permisos administrativos del CDN; además, desde la etiqueta de junio de 2024 se habían acumulado muchos cambios
  • En una instalación solo UEFI se instalan únicamente m1n1 stage 1, Devicetree y U-Boot, por lo que si el Devicetree incluido en el paquete del instalador no coincide con lo que espera el kernel, el arranque puede quedar bloqueado por completo
    • Mientras avanzaba el trabajo upstream, fueron cambiando los bindings de Devicetree y se acumuló la desalineación; en kernel 6.18 también aumentaron mucho los cambios relacionados con Apple USB, así que ya no era posible arrancar medios live con 6.18 o superior
  • Los manifiestos de imágenes instalables se separaron en asahi-installer-data, lo que permite actualizarlos de forma independiente de la base de código del instalador
  • La distribución de asahi-installer ahora está automatizada con GitHub workflow
    • Los pushes a la rama main se compilan y suben automáticamente a https://alx.sh/dev
    • Los pushes de tags de GitHub se despliegan automáticamente en https://alx.sh
  • La versión más reciente, 0.8.0, actualizó el m1n1 stage 1 incluido a 1.5.2 y añadió soporte de instalación para Mac Pro junto con un modo de actualización de firmware

ALS y extracción de firmware

  • En el entorno True Tone de Apple, no basta con medir el brillo ambiental: también hay que medir las características de color de la iluminación, por lo que el procesamiento de datos ALS y la precisión de la calibración se vuelven importantes
  • Aunque el propio AOP y el controlador ALS ya funcionaban, sin datos de calibración la precisión de los datos crudos de ALS entregados por el AOP era baja
    • Esos datos de calibración son un blob binario que debe cargarse al AOP en tiempo de ejecución, y como no puede redistribuirse, hay que obtenerlo desde macOS durante la instalación
  • Asahi Installer recopila el firmware necesario para Linux, lo guarda en la EFI System Partition y luego un módulo de Dracut lo monta en subdirectorios bajo /lib/firmware/ para que los controladores puedan encontrarlo
  • Para evitar el problema de necesitar firmware adicional después de haber instalado el sistema, el instalador pasó a soportar la actualización automática del vendor firmware package
    • A partir de ALS, se puede arrancar en macOS o macOS Recovery, volver a ejecutar el instalador y seguir las indicaciones para actualizar el firmware necesario
  • El soporte de ALS y las posteriores actualizaciones de firmware requieren Asahi kernel 6.19 o superior e iio-sensor-proxy

Gestión de energía y PMP

  • El consumo en reposo siguió siendo un problema, especialmente en los SoC Pro/Max/Ultra, y la gestión de energía en esta plataforma tiene una estructura compleja en la que PMGR y PMP están estrechamente relacionados
  • PMGR se encarga de encender y apagar los dominios de energía del SoC, mientras que PMP recibe y procesa reportes de estado de energía enviados por los bloques del SoC y los núcleos de aplicación mediante memoria compartida
    • Si PMP no arranca, no puede leer esos reportes y ciertas funciones de gestión de energía tampoco pueden funcionar
  • El controlador de soporte PMP creado por chaos_princess permite que PMP reciba reportes de los bloques del SoC y de PMGR, logrando una reducción de alrededor de 0.5 W en reposo en una MacBook Pro M1 Pro de 14 pulgadas
    • Eso equivale a una reducción aproximada del 20% en el consumo en reposo
  • Todavía hace falta más trabajo para alcanzar los tiempos de reposo y suspensión al nivel de macOS, pero este cambio está mucho más cerca de ser un gran avance
  • El M1 base usa una variante antigua de PMP que no es compatible con las generaciones posteriores, y dd-dreams está trabajando en ese soporte
  • PMP aún no se ha validado en todos los dispositivos compatibles y tampoco planean habilitarlo por defecto antes de su fusión upstream
    • Los usuarios que puedan modificar el Devicetree pueden activarlo definiendo APPLE_USE_PMP en el DTS del dispositivo

Corrección de cortes de audio por Bluetooth

  • Bluetooth y WiFi comparten la misma banda de 2.4 GHz, por lo que la interferencia es común, y conexiones sensibles a la latencia y la continuidad, como los flujos de audio, necesitan una prioridad más alta
  • La configuración de coexistencia de Broadcom se maneja con comandos extendidos específicos del proveedor en el HCI de Bluetooth, pero el kernel Linux upstream no los soportaba, lo que provocaba pérdida de paquetes de audio durante escaneos Bluetooth
    • Si KDE Connect activaba un escaneo Bluetooth, podían producirse cortes de audio
  • chaos_princess añadió soporte para esos comandos al stack Bluetooth del kernel, y como BlueZ marca todos los flujos de audio como high priority, los comandos necesarios se activan automáticamente durante el streaming
  • Como resultado, los cortes de audio por Bluetooth dejaron de producirse

DCP y VRR

  • La interfaz de firmware DCP es muy grande e inestable entre versiones, y como durante ese tiempo se priorizó otro trabajo de hardware después del soporte básico de pantalla, funciones como VRR habían quedado pendientes
  • El soporte de VRR requiere intercambio de paquetes especiales entre el controlador de pantalla y el display, ajuste del vertical blanking según el tiempo de presentación de cuadros, anuncio de la capacidad VRR del display e integración con KMS
  • Durante el rastreo se descubrió que un parámetro de DCP que se ponía en 0 al energizar una pantalla externa cambiaba entre 0x300000 y 0x0 al activar o desactivar VRR
    • La pantalla de prueba tenía una frecuencia mínima de 48 Hz, y en el formato de punto fijo de DCP, 48 era 0x300000
    • Ese parámetro no era para la secuencia de energía, sino un toggle de frecuencia mínima de VRR; ponerlo en 0 antes del modeset terminaba desactivando VRR
  • La pantalla interna ProMotion de la MacBook Pro también se activa de la misma manera, pero como el panel interno no anuncia EDID/DisplayID, el controlador de Linux detecta que se trata de un LCD interno y configura estáticamente las propiedades necesarias
  • VESA DisplayPort Adaptive Sync y la API de KMS no permiten exigir un modeset para cambiar el estado de VRR, pero Apple DCP no puede evitarlo
    • Por esa limitación, no es posible exponer VRR correctamente al userspace, y KWin también ignora ese tipo de interfaz
  • Por ahora, cuando se fusione este pull request, será posible activar VRR forzado con el parámetro del módulo del kernel appledrm.force_vrr
    • Si la pantalla soporta VRR, DCP usará VRR sin avisarle a KMS ni al compositor
    • Funcionó bien en KWin, pero la experiencia puede variar en otros compositores
  • En HDMI, en cambio, no está prohibido hacer modeset entre transiciones de VRR, y otros controladores de pantalla como Intel funcionan de forma similar
    • Upstream sigue discutiendo si mantener el modo VRR siempre activado o permitir modeset durante la transición; cuando se defina esa dirección, planean exponer VRR de la forma esperada

Trabajo upstream del stack de audio y ampliación de tasas de muestreo

  • El trabajo upstream de todo el stack de audio sigue en marcha, y ya se fusionaron controladores relacionados con conectores de audífonos y amplificadores de altavoces de Cirrus Logic y Texas Instruments, periféricos I2S y cambios en el controlador DMA de Apple
  • La protección de altavoces en esta plataforma funciona haciendo que el amplificador TI envíe por I2S el voltaje y la corriente al SoC, que luego calcula la temperatura de la bobina móvil junto con los Thiele/Small Parameters del altavoz
  • En una estructura donde los pines data transmit de varios amplificadores están conectados en serie y las líneas izquierda y derecha se combinan con una OR lógica, hace falta configurar un bus keeper para que cuando un lado transmita, el otro garantice logic low
  • Antes el bus keeper se manejaba con controladores específicos de chips amplificadores y bindings dedicados de Devicetree, pero eso era demasiado limitado para upstream, así que cambió a una API genérica
    • Ahora cualquier componente ASoC configurable puede exponer la presencia de un bus keeper, y el controlador de plataforma puede aplicar en tiempo de ejecución la configuración necesaria
    • Ese conjunto de parches se fusionó en Linux 7.1
  • El soporte para chips con variantes específicas de Apple también sigue ampliándose
    • En los amplificadores de altavoces TI se agregó soporte para variantes Apple a los controladores upstream de TAS2764 y TAS2770 con relativa facilidad
    • El CS42L84 difería bastante del CS42L42, por lo que necesitó un controlador Linux independiente, que ya fue incorporado upstream
  • Si solo se seguía el rastreo de macOS, existía la limitación de exponer únicamente las funciones usadas por macOS, y por eso al principio el CS42L84 solo soportaba 48 kHz y 96 kHz
    • Esa limitación obligaba a PipeWire a remuestrear otros flujos, consumiendo más CPU y batería y reduciendo también la calidad de audio
  • Al aplicar al controlador CS42L84 otros valores comunes de tasa de muestreo tomados de la hoja de datos del CS42L42, pasó a funcionar el soporte por hardware de 44.1, 88.2, 176.4 y 192 kHz tanto en entrada como en salida del jack de audífonos
    • Ese parche se envió upstream, se fusionó en Linux 7.1 y también se retroportó a Asahi kernel 6.19.9

Ampliación del soporte para M3

  • Al árbol del kernel de Asahi también están entrando parches adicionales de habilitación de hardware para dispositivos M3
  • El alcance ya incluye PCIe, teclado y trackpad de MacBook, RTC basado en SMC, reboot controller y controlador NVMe
  • Gracias al trabajo de Michael Reeves y Alyssa Milburn, el nivel de soporte de Linux para M3 alcanzó una etapa aproximadamente similar a la del primer Asahi Linux alpha para M1
  • Aún no está lista la apertura de instalación directa en M3 con Asahi Installer, pero el trabajo sigue avanzando

Fedora Asahi Remix 44

  • A pesar del retraso de Fedora Asahi Remix 43, Fedora Asahi Remix 44 mantiene el plan de lanzarse el 28 de abril, al mismo tiempo que Fedora Linux 44 o dentro de unos pocos días
  • La nueva instalación basada en KDE Plasma aprovechará funciones nuevas de Plasma 6.6
    • Plasma Setup reemplazará al asistente de configuración basado en Calamares y ofrecerá un flujo nativo de Plasma para creación de cuentas y configuración del sistema
    • Plasma Login Manager será el greeter y session manager por defecto, reemplazando a SDDM
  • Este cambio se aplica solo a instalaciones nuevas; la configuración de quienes actualicen desde versiones anteriores de Fedora Asahi Remix no cambiará
  • Fedora Asahi Remix 44 finalizará los paquetes vendored de Mesa y virglrenderer
    • Los usuarios que todavía no hayan hecho el cambio manual pasarán automáticamente a los paquetes de Mesa y virglrenderer de los repositorios upstream de Fedora

Patrocinios y apoyo de infraestructura

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 일 전
Comentarios de Hacker News

  • CS42L84 estaba configurado en macOS para usar solo 48/96 kHz, pero al tomar otros valores de tasa de muestreo de la hoja de datos del CS42L42 y ponerlos en el driver, al parecer funcionó tal cual
    Ya entró upstream un parche que habilita 44.1/88.2/176.4/192 kHz en la entrada/salida del conector de audífonos, se fusionó en 7.1 y también se backporteó al kernel 6.19.9 de Asahi para poder usarlo de inmediato
    El rastreo del chip y la ingeniería inversa son realmente impresionantes

    • La parte más sorprendente es que si solo se soportan 48/96 kHz, PipeWire termina usando más CPU y batería por el remuestreo
      Apple es una empresa obsesionada con la eficiencia energética, así que da curiosidad por qué lo siguen dejando así
    • Poder reproducir CD/FLAC con 44.1 kHz bit-perfect parece una función realmente importante

  • Los textos técnicos y los logros del equipo de Asahi son realmente impresionantes, pero sigue preocupando un poco que esto todavía permanezca como un proyecto aparte y no como algo sostenido dentro del mainline del kernel o de distribuciones principales como Ubuntu, Debian o Fedora
    Los proyectos de ingeniería inversa pueden producir resultados útiles con relativa facilidad hasta el 80%, pero para llegar a un 95% de acabado lo bastante pulido para usuarios comunes, hace falta casi la misma cantidad de trabajo duro y minucioso adicional

    • Asahi justamente también está llevando mucho de esto upstream
      Una de las principales razones por las que el avance reciente se ha ralentizado es porque se han enfocado en reducir la cantidad de diffs, y bastante trabajo ya entró al kernel mainline
      Asahi también está sirviendo como espacio para experimentar con funciones nuevas
    • También existe la dificultad adicional de que los Mac ARM son un objetivo en movimiento
      Apple no tiene ninguna intención de ofrecer estabilidad ni soporte pensando en Asahi Linux, y tampoco tiene motivos para mantener compatibilidad a largo plazo como en la industria del PC, así que probablemente no le importará seguir haciendo cambios que compliquen la vida a Asahi
    • Lo bueno de Linux es que es software libre, así que no está atado a accionistas ni a la rentabilidad
      Uso Asahi como sistema operativo principal en una MacBook Air M1 y estoy bastante satisfecho; aunque haya detalles molestos como que en suspensión la batería baje 1% por hora, sigue siendo mucho mejor tenerlo en su estado actual que no tener nada por no estar al 100% terminado
      Tampoco siento que tenga que estar perfectamente pulido para el público general
    • El desarrollo del kernel mainline de por sí funciona así: todos trabajan en su propio fork y luego envían parches upstream
      Si Asahi parece especial es porque tiene mucho hardware raro y específico, así que necesita muchos drivers particulares; nadie desarrolla directamente en el árbol de Linus
    • La charla de 39c3 https://youtu.be/3OAiOfCcYFM también estuvo buena
      Al final, la meta es que Linux soporte Apple Silicon de forma nativa

  • Ojalá este proyecto siga ganando impulso
    La combinación de hardware de Apple + Linux se siente como el sistema operativo menos roto corriendo sobre el mejor hardware, mientras que macOS se siente cada vez más caótico por los bugs y por cambios que se voltean en cada versión

    • Quizá cambiarías de opinión si usaras Framework con Fedora
      La experiencia fue muy fluida, y con el próximo Framework 13 Pro hay expectativa de que la batería y el trackpad estén al nivel de macOS, o incluso que la batería sea mejor
    • He usado los tres sistemas operativos principales y macOS fue el que tuvo menos bugs y simplemente funcionó mejor
      Con Linux siempre terminaba aplicando parches raros por temas de compatibilidad de audio o pantalla, y Windows tenía problemas graves de batería
      Incluso parece que mucha gente a la que le gusta tunear Linux en el fondo quiere una experiencia tipo Mac pero con más posibilidades de personalización
    • En términos generales sí, pero el ecosistema alrededor de MLX está bastante bien articulado
      Aunque el I/O de disco no sea gran cosa y el sistema operativo tenga bugs, al menos en el OS más reciente el ML compila y corre
      En cambio, rocm parece estar casi listo pero luego exige paquetes precompilados o una Ubuntu de hace más de 2 años, lo cual desespera
      https://github.com/ROCm/TheRock/issues/3477
    • Hace poco usé una MacBook Air para trabajo y me cuesta estar de acuerdo con que el hardware sea de primer nivel
      Siento que gastando apenas 5 euros ya podrías conseguir un mejor teclado

  • No se entiende muy bien por qué Apple no coopera con este esfuerzo ni publica documentación
    Las razones tradicionales, como ventaja competitiva o secreto, ya parecen poco convincentes

    • La razón real quizá sea más simple
      Apple tiene márgenes altos en hardware, así que le basta con vender MacBooks a usuarios de Linux, pero en el momento en que reconozca oficialmente el soporte para Linux, eso se convierte de inmediato en una responsabilidad de soporte
      Cada kernel panic terminaría en una visita al Genius Bar y cada bug de drivers invocaría a @AppleSupport, así que para Apple quizá el mejor escenario es que siga siendo algo no oficial: venden el hardware y evitan la carga de soporte
    • Casi no hay ganancia económica y además aparece la carga de documentar Linux cada vez que cambia el hardware
      Tampoco debe ser un público muy atractivo para Apple: pequeño, ruidoso y muy crítico
    • Puede que sea mucho más fácil simplemente trazar la línea y decir no jugamos a este juego que abrirse selectivamente o romper compatibilidad con interfaces no públicas y recibir críticas por eso
      Internamente también evita seguir abriendo discusiones que no tienen relación con sus prioridades
    • Siento que esto casi roza el tema del right to repair
      Una laptop está formada por varias piezas de hardware y los drivers que las hacen funcionar, así que surge la pregunta de si lo que compré es un paquete inseparable de hardware y drivers, o si debería recibir manuales para poder rescatar una parte si la otra falla
      Apple podría argumentar que los drivers no se desgastan como engranes o motores, pero eso no significa que desaparezca el derecho a entender cómo funciona
      No sería raro que algún día aparezca un caso de prueba en tribunales donde /System/Trackpad.kext “reciba el impacto de una nave espacial”, desaparezca, y alguien exija la documentación para escribir su propio driver
    • Suena correcto
      Para Apple sería fácil dar soporte a esto, y además parece que ganaría bastante buena voluntad de la comunidad

  • Me pregunto si habría interés en una variante de Asahi Remix enfocada en una experiencia predeterminada tipo Mac
    Algo como usar cmd como tecla modificadora principal y traer por defecto atajos, tema y gestos al estilo Mac
    Se puede ajustar cualquier distribución, pero unos valores por defecto bien curados también tienen su propio valor

    • Tomar cmd como “tecla modificadora principal” es complicado
      En un entorno X/Wayland típico, para funciones del DE ya manda Cmd, mientras que a nivel de aplicaciones manda Ctrl, y cambiar eso genera bastante superposición
    • Logré dejar KDE bastante parecido
      Le pedí a Claude Code que lo implementara, hizo búsquedas web y hasta me generó los archivos de configuración
    • Un keymap centrado en Cmd me parece una batalla prácticamente perdida
      Lo intenté varias veces, pero al final acepté la vida con Ctrl y vendí mi última MacBook

  • Me da curiosidad qué llegará primero a hacer realidad la máquina de desarrollo soñada de MacBook Pro + Linux, si el hardware o el software
    Toca ver si Asahi llega primero por el lado del software, o si Framework lo logra primero por el lado del hardware

  • Una combinación de MacBook Neo + Asahi sería realmente potente

  • Da gusto ver que el soporte para M3 avanza con constancia mientras se atiende el backlog de upstream y se mejoran las herramientas
    Están entrando al árbol del kernel de Asahi parches para PCIe, teclado y trackpad de MacBook, RTC basado en SMC y reboot controller, además del soporte para el controlador NVMe, y con eso el nivel de soporte Linux para M3 ya se acerca más o menos a la etapa de la primera alpha de Asahi Linux para M1

    • A este ritmo, quizá hasta el lanzamiento del M6 apenas se vuelva realmente utilizable

  • Que en estos reportes del proyecto sigan apareciendo avances decisivos y además se señale con precisión dónde se topan los usuarios con problemas reales, da la impresión de que el equipo de Asahi ya tiene muchísima experiencia
    Dan ganas de volver pronto por completo a Asahi

  • La noticia de que M3 está cerca de alpha es excelente, y también da expectativas para el M4
    En cambio, no entusiasma nada pensar qué otra cosa irá a hacer Apple con macOS este año o el próximo