Relatório de progresso do Asahi Linux 7.1

 (asahilinux.org)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Com base no Linux 7.1, o Asahi Linux está avançando simultaneamente em ampliação do suporte ao M3, compatibilidade com o beta do macOS 27, decodificação de vídeo AVD e mudanças no m1n1 1.6.0
  • No beta para desenvolvedores do macOS 27 Golden Gate, a entrada de boot do Asahi desapareceu do Startup Disk e do seletor de boot, mas as partições e os dados permaneceram, e foi possível recuperá-la configurando uma flag de boot do APFS
  • Uma mudança no firmware do SMC alterou o valor de retorno do gerenciamento de bateria, causando desligamento de emergência em certas condições; a partir do kernel downstream 7.0.12, os dois ABIs de firmware são tratados
  • Na família M3, áudio, troca de frequência da CPU, escalonamento big.LITTLE, sensores SMC, PCIe, WiFi, Bluetooth, NVMe, teclado e trackpad funcionam no Linux, mas ainda não estão na etapa de suporte pelo Asahi Installer
  • O AVD avançou rumo à decodificação AVC por hardware com firmware próprio e driver V4L2, em vez do firmware da Apple; o m1n1 1.6.0 passa a exigir Rust para builds do stage 2, o que tem grande impacto para distribuições

Entrada de boot do Asahi desaparecida no macOS 27

  • A entrada do Asahi exibida no seletor de boot, aberto ao manter pressionado o botão liga/desliga no Mac, ou no app Startup Disk não é a partição real do sistema operacional
  • Como as ferramentas de boot da Apple lidam apenas com “instalações válidas do macOS” dentro de um contêiner APFS, o Asahi Installer cria um contêiner APFS de 2,5 GB e usa uma configuração mínima do macOS com o m1n1 colocado como se fosse um kernel
  • Esse método funcionou sem alterações do macOS 12 ao macOS 26, e a Apple também corrigiu parcialmente bugs nas ferramentas que apareciam apenas ao inicializar um raw binary em vez de um kernel XNU real
  • Após o beta para desenvolvedores do macOS 27 Golden Gate, alguns usuários tiveram um problema em que a entrada do Asahi desaparecia do Startup Disk e do seletor de boot
    • A verificação com diskutil mostrou que as partições relacionadas ao Asahi ainda estavam no disco e não houve perda de dados
    • Usando as ferramentas de boot do macOS 26 na mesma máquina, o Asahi ainda podia ser inicializado
  • O macOS Installer define metadados do APFS antes de reiniciar, e uma investigação adicional mostrou que esse valor era uma flag que marca o volume como inicializável
    • As ferramentas de boot anteriores ao macOS 27 ignoravam essa flag
    • Ao definir manualmente a flag no contêiner APFS do Asahi, ele volta a aparecer no seletor de boot do macOS 27
  • Em novas instalações do Asahi, o Asahi Installer define essa flag automaticamente
  • Também foi adicionado um modo de instalação para corrigir instalações existentes
    • Se você não conseguir acessar o Asahi após instalar o beta para desenvolvedores do macOS 27, deve executar o installer novamente e usar a opção “Fix macOS 27 boot picker compatibility”
  • Também foi criado um programa para corrigir o problema a partir do Linux, mas são necessários mais dados de teste antes da distribuição automática
    • Para testar, antes de atualizar para o macOS 27, clone o repositório asahi-fix27 e compile/execute no Linux
    • Depois, se o volume do Asahi puder ser selecionado como destino de boot no macOS, isso significa que funcionou
    • Resultados e problemas podem ser compartilhados nos canais da comunidade do Asahi

Mudança no firmware SMC e desligamento de emergência no driver de bateria

  • O macOS 27 inclui atualizações de firmware para todos os periféricos que usam global firmware, incluindo o SMC
  • O SMC é responsável pelo gerenciamento da bateria, e o driver de power supply do Linux se comunica com o SMC para obter estado de carga, tensão, tempo restante até a descarga e informações de saúde da bateria
  • O mesmo driver também define limites de início e parada de carga por meio da interface de firmware do SMC para prolongar a vida útil da bateria
  • O firmware SMC do macOS 27 alterou uma das interfaces de gerenciamento de bateria de retorno de inteiro de 32 bits para retorno de 1 byte
  • Por causa dessa mudança, em certas condições o driver do Asahi interpreta a situação como falha da bateria e inicia um desligamento de emergência para proteger o sistema
  • O patch já foi aplicado ao kernel downstream, e a partir da versão 7.0.12 o driver de power supply trata os dois ABIs de firmware

Aviso sobre a instalação de betas para desenvolvedores

  • Os dois problemas encontrados no macOS 27 mostram que um beta para desenvolvedores é, de fato, um beta para desenvolvedores
  • Não é recomendável instalar betas para desenvolvedores em máquinas de produção
  • Os dois problemas ocorridos até agora foram, por sorte, pequenos, mas não há garantia de que todos os próximos problemas também serão pequenos
  • Atualizações de global firmware são, na prática, permanentes; para revertê-las, é necessário fazer um DFU restore na máquina
  • O lado do Asahi usa máquinas sacrificáveis para testes, então não vê necessidade de usuários colocarem hardware caro e dados importantes em risco

Avanços no suporte à família M3

  • Plataformas de computador e projeto/verificação de ICs custam muito dinheiro e tempo, então mudanças desnecessárias em designs existentes não são razoáveis
  • O projeto Asahi se apoiou na hipótese de que a Apple não continuaria fazendo mudanças incompatíveis em plataformas e ICs; tirando grandes blocos de SoC que tendem a mudar a cada geração, como a GPU, isso em geral se mostrou correto

  • Saída de áudio

    • O áudio dos notebooks Apple Silicon usa vários ICs e blocos do SoC
    • O padrão de fato da indústria para ICs de áudio é o I2S, um barramento baseado em I2C otimizado para dados de áudio
    • O controlador I2S da Apple e o Apple NCO, uma fonte de clock estável, não mudaram desde o M1
    • A Apple usa os mesmos chips amplificadores de alto-falante e headset em quase todas as máquinas Apple Silicon
    • Ao adicionar suporte a alto-falantes e à saída de fone de ouvido em máquinas M3, o trabalho necessário foi principalmente pequenas adições ao Devicetree e arquivos de configuração do asahi-audio e do speakersafetyd
    • As máquinas M3 suportam saída de áudio de alta qualidade no Asahi Linux

  • Frequência da CPU e escalonamento big.LITTLE

    • As máquinas M3 também passaram a oferecer suporte à troca de frequência da CPU e ao escalonamento adequado de tarefas big.LITTLE
    • A Apple não mudou o método de troca de frequência da CPU desde o M2 básico
    • Os SoCs M3, M3 Pro, M3 Max e M3 Ultra funcionam com o driver cpufreq existente apenas com mudanças no Devicetree
    • As tarefas são posicionadas de forma mais inteligente em núcleos de eficiência ou de desempenho conforme os requisitos, e os núcleos da CPU aumentam ou reduzem o clock de acordo com a carga
    • Essa mudança traz tanto economia de energia quanto melhoria de desempenho

  • Sensores e dispositivos principais

    • Como o firmware SMC não varia muito entre máquinas, o suporte aos sensores de hardware do SMC também exigiu apenas algumas mudanças no Devicetree
    • Nas máquinas da família M3, drivers de PCIe, WiFi, Bluetooth, NVMe, teclado, trackpad e outros blocos essenciais do SoC também funcionam no Linux
    • Grande parte desse trabalho foi realizada por Yureka, que vem trabalhando no m1n1 e no Linux em máquinas da família M3
    • Ainda é necessário mais trabalho para ativar o suporte do Asahi Installer nas máquinas M3, mas o ritmo de progresso é rápido

Decodificação de vídeo AVD e firmware próprio

  • A maior parte do hardware complexo da plataforma Apple Silicon usa blobs de firmware complexos
  • Muitos firmwares são baseados em RTKit, um framework semelhante a um RTOS que a Apple usa para oferecer uma interface amplamente padronizada entre o kernel e vários blocos de hardware
  • Alguns blocos, como DCP e AOP, são baseados no RTKit e adicionam uma abstração extra chamada EPIC
  • Também há casos que usam firmware de terceiros que a Apple não controla diretamente, como chipsets Broadcom WiFi/Bluetooth
  • O Apple Video Decoder, ou AVD, usa firmware com uma estrutura própria, que não é RTKit nem EPIC

  • Estrutura do AVD e problemas da abordagem existente

    • O hardware AVD é próximo de um ARM Cortex-M3 que controla unidades de hardware de função fixa que decodificam frames de vídeo AVC(H.264), HEVC(H.265), VP9 e AV1 em SoCs mais recentes
    • O Cortex-M3 fornece uma interface para que o XNU aponte para os dados de vídeo e executa um blob de firmware que configura o hardware decodificador real
    • A Apple inclui o firmware AVD e os dados de configuração dentro do kext AVD
    • Como cada SoC usa uma variante de AVD ligeiramente diferente, surge um problema logístico em que o Asahi Installer precisa acompanhar e atualizar continuamente mudanças nos offsets dos dados de firmware dentro do kext

  • Abordagem com firmware próprio

    • O firmware AVD carregado pelo XNU não é verificado no Cortex-M3
    • Quando recebe um sinal, ele executa a partir do reset vector, portanto executa qualquer código que estiver ali
    • Como a função do firmware é basicamente abstrair o hardware decodificador de vídeo, basta instalar handlers de interrupção para cada bloco de hardware e então o driver Linux pode programá-lo diretamente
    • Por ser código Cortex-M3 padrão, o firmware AVD pode ser executado em emuladores
    • O QEMU suporta execução passo a passo e inspeção de operações de barramento e registradores
    • Jamie, R e Eileen já haviam feito engenharia reversa, em trabalho conjunto anterior, dos comandos e formatos de dados necessários para os decodificadores AVC e VP9
    • O kext XNU também aplica tunables específicos para cada revision do AVD
    • Não há certeza completa sobre o que esses valores fazem exatamente
    • A aplicação deles é próxima da reprodução de MMIO writes do XNU
    • É necessário rastrear cada revision do AVD, o conjunto de tunables e as revisions às quais eles se aplicam
    • Como isso é difícil de manter de forma satisfatória em um driver do kernel Linux upstream, também é mais adequado manter essa parte no firmware

  • Driver V4L2 AVC

    • O novo colaborador sofus criou um firmware AVD customizado básico que instala handlers de interrupção e aplica os tunables de cada variante
    • Com base nisso, escreveu um driver V4L2 funcional para o hardware AVC
    • O hardware consegue decodificar vídeos codificados em AVC de 10 bits até 4K
    • Ele funciona bem com software que implementa a V4L2 Request API
    • Manter o firmware simples e sem estado, deixando userspace e kernel responsáveis pelo parsing dos dados de vídeo e pela programação do decodificador, também facilita o suporte futuro a outras APIs de aceleração de vídeo, como VA-API ou Vulkan Video
    • Ainda há trabalho restante para oferecer suporte AVD aos usuários
    • O AVD também oferece suporte a VP9, HEVC e AV1 em alguns SoCs, mas isso ainda não foi implementado
    • Quirks de alguns dispositivos também precisam ser testados e refletidos no driver
    • A meta é chegar a uma forma distribuível em um futuro não muito distante

Lançamento do m1n1 1.6.0

  • O m1n1 1.6.0 foi tagueado, e é um lançamento de grande impacto do ponto de vista das distribuições
  • Esta versão exige Rust pela primeira vez para builds do stage 2
  • Antes, Rust era usado apenas ao compilar com suporte a chainloading
  • O stage 1 do m1n1 substitui o kernel XNU nas ferramentas de boot da Apple e é usado apenas para montar a EFI System Partition e, a partir dela, fazer chainload do stage 2 do m1n1
  • Ao mover a inicialização da GPU para o m1n1, deixou de ser necessário que o driver do kernel lidasse com valores de ponto flutuante presentes nos dados de inicialização de hardware da Apple, e o Devicetree binding também ficou muito mais simples
  • A versão do driver de GPU que será enviada futuramente à Linux Kernel Mailing List dependerá da premissa de que o m1n1 realiza essa inicialização
  • O código de parsing do Apple Device Tree também foi portado para Rust e é usado por quase todas as outras partes do m1n1

  • Build e alvos

    • Como o m1n1 é efetivamente firmware, ele usa Rust no_std e tem como alvo aarch64-none-softfloat
    • Para não trazer dependências desnecessárias, é possível passar BUILDSTD=1 ao make para compilar core e alloc sem instalar toda a toolchain softfloat

  • Preparação para M3, M4 e A18 Pro

    • A versão 1.6.0 também inclui várias melhorias para suporte à família M3
    • Suporte ao controlador SPMI
    • Suporte à inicialização de PCIe
    • Suporte a tunelamento direto de DebugUSB para o UART de hardware do SoC via kisd
    • O tunelamento de UART por DebugUSB pode oferecer quase a mesma funcionalidade do Central Scrutiniser
    • Grande parte desse trabalho também é contribuição de Yureka
    • O trabalho de base para suporte ao M4 e A18 Pro, isto é, ao MacBook Neo, também está em andamento
    • Trata melhor o non-macOS boot mode da Apple
    • Suporta os novos metadados de power domain presentes no Apple Device Tree

Patrocínio e colaboradores

  • O Asahi Linux agradece aos patrocinadores no GitHub Sponsors e no Open Collective
  • Graças ao patrocínio, é possível continuar trabalhando em recursos inacabados do M1/M2, suporte a M3/M4/A18 Pro e apoio a novos colaboradores

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • A afirmação de que “o padrão de fato da indústria para ICs de áudio é o I²S, um barramento baseado em I²C otimizado para dados de áudio” não está correta. I²S não tem relação com I²C
    A maioria dos chips I²S realmente vem com uma interface I²C, mas isso acontece porque o I²S carrega apenas dados brutos de áudio e não inclui sinais auxiliares, como controle de volume ou configuração de clock
    Mas essa é uma interface separada, e pode ser SPI em vez de I²C. Na prática, SPI é mais próximo de I²S do que I²C

    • Sim, I²S é bem mais próximo de SPI
      A razão de ambos seguirem um esquema de nomes parecido é que os dois foram criados pela Philips Semiconductor (hoje NXP)
    • I²S tem um projeto surpreendentemente simples. Não há handshake de protocolo; ele só transmite PCM bruto
      Gosto do fato de ter sido projetado para evitar problemas de compatibilidade mesmo quando transmissor e receptor usam profundidades de bits de amostragem diferentes em cada direção
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • É realmente impressionante que um pequeno grupo de pessoas motivadas consiga resolver problemas como esses

    • Muitos problemas ainda não foram resolvidos. Por exemplo, a interface de gerenciamento de energia PSCI do Apple Silicon continua sendo um mistério
      Outras device trees do Linux têm código PSCI, mas ninguém sabe como a Apple implementou isso. Por isso, os usuários do Asahi vêm dependendo há quase 5 anos de hacks para impedir que a bateria continue drenando, e, até onde sei, ainda não existe nenhuma solução promissora
      Esse é o lado bom e o lado ruim da engenharia reversa. É incrível que esses dispositivos tenham recebido um driver nativo Vulkan 1.2, mas levaram anos para chegar até esse ponto. Mesmo agora, 7 anos após o lançamento do Apple Silicon, ainda restam problemas sem solução, e a maior parte do hardware mais recente não é suportada de forma geral. No fim, isso nos leva de volta à velha lição que usuários de Linux sempre repetem: drivers proprietários não são grande coisa

  • A parte mais preocupante é que o firmware carregado pelo XNU não é validado pelo CM3, e, quando recebe um sinal, ele simplesmente começa a executar a partir do vetor de reset, independentemente do conteúdo real
    A conquista de escrever um firmware personalizado contra um alvo proprietário e em constante mudança é imensa demais para descrever, mas, deixando de lado a esperança de que a Apple não continue quebrando sistemas operacionais de terceiros de propósito, não parece improvável que ela venha a introduzir assinaturas em hardware para blobs de firmware ou para os dados fornecidos em tempo de execução à programação do hardware. Do ponto de vista da Apple, isso pode ser uma preocupação de segurança razoável. Ainda assim, torço para que essa aposta dê certo

  • Fico me perguntando se isso vai continuar para sempre apenas como um “remix” do Fedora. Será que algum dia haverá suporte upstream e será possível rodar uma distribuição baseada em Debian?
    Acho que a última vez que usei uma distribuição baseada em RPM foi há quase 20 anos

    • Como os patches estão sendo enviados upstream, no fim os drivers necessários entrarão no Linux upstream
      Claro, como o fork do kernel também é open source, nada impede você de pegar um root Debian aarch64 e compilar o kernel do Asahi por conta própria, ou usar um build do Fedora e montar você mesmo um Debian nesse hardware. Só dá um pouco mais de trabalho
      Se Ubuntu servir, também existe o Ubuntu Asahi: https://ubuntuasahi.org/
      Procurando, também encontrei esta página da wiki: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • Meu gosto é o oposto, então esse comentário me fez rir. Eu prefiro distribuições baseadas em RPM e uso Fedora como principal em praticamente todo lugar. Também uso Fedora Asahi Remix em um Mac Studio M1 Ultra, e só de vez em quando uso Ubuntu e Debian em algumas instâncias na nuvem
      Então entendo a vontade de continuar usando uma distribuição específica com a qual você já está acostumado. Dá menos trabalho, e você precisa lembrar menos das diferenças sutis de estrutura. Ainda assim, quando inevitavelmente preciso usar uma distribuição nova, como quando o Asahi saiu inicialmente só para Arch Linux ARM, nunca me arrependi do pequeno aprendizado que isso trouxe
    • O Arch ainda pode ser usado, e também existe o Ubuntu Asahi
      Estamos fazendo bastante trabalho upstream exatamente por esse motivo, para que todas as distribuições possam ser portadas com mais facilidade
      https://ubuntuasahi.org/
    • A Bananas Team está trabalhando para fazer o Debian padrão funcionar no Apple Silicon, e já existe uma forma de instalar isso hoje adicionando um repositório não oficial: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      Ainda não tentei instalar pessoalmente
    • linux-asahi também pode ser usado no Void Linux
      https://voidlinux.org/download/#arm%20platforms
      É um pacote Linux comum dentro da distribuição: https://github.com/void-linux/void-packages/tree/master/srcp...

  • É bom ver que o suporte ao M3 está avançando bem
    A primeira menção ao início do trabalho para adicionar suporte ao M3 foi em fevereiro
    “Por bastante tempo, o m1n1 já tinha suporte básico para dispositivos da série M3. O que faltava eram as device trees específicas de cada aparelho e patches de driver para o kernel Linux que dessem suporte às características e mudanças de hardware específicas do M3, diferentes do M2. Sempre houve a intenção de concretizar esse trabalho quando o conjunto de patches existente ficasse mais administrável”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • Estou ansioso porque estão trabalhando no driver AVD

  • O ffmpeg ou o VLC usam AVD em Macs com M1 ou superior?

  • O Asahi pode ser uma alternativa viável, mas com esse nível de financiamento e uma equipe tão pequena, parece inevitável que o ritmo de desenvolvimento seja lento demais
    Como o texto diz, já existe uma base pronta e há resultados disso, mas no fim sempre saem novos Macs todo ano com novos chips e inúmeras mudanças em microcontroladores e GPU, então é impossível acompanhar. É por isso que a equipe do Asahi também está focando mais nos modelos M1 e M2
    Mesmo assim, até agora ainda restam problemas de gerenciamento de energia em idle e de implementação de Alt-DP em ambos, o que impede muita gente de migrar. Quando esses problemas estiverem refinados, o valor dos aparelhos também já terá caído bastante
    É um milagre que um grupo tão pequeno tenha conseguido fazer tanto, mas apesar da ampla cobertura da mídia, parece que no fim a paixão e a motivação da equipe diminuíram, e dá a impressão de que nem o M1 Air vai ficar pronto

    • Em vez de “o ritmo de desenvolvimento inevitavelmente ser lento demais”, quando a nova equipe de liderança entrou, ela anunciou que priorizaria o upstream do trabalho existente em vez de adicionar suporte ao hardware mais recente
      Levar as mudanças para upstream no kernel levou tempo
      Agora anunciaram que começaram o trabalho no M3 em fevereiro, e o progresso parece bom
      “Além do que foi dito acima, os drivers de PCIe, WiFi, Bluetooth, NVMe, teclado, trackpad e outros blocos centrais do SoC também funcionam no Linux em dispositivos da série M3. A maior parte desse trabalho foi feita pela Yureka, e ela vem hackeando de forma muito ativa tanto o m1n1 quanto o Linux em dispositivos da série M3 já há algum tempo. Ainda há um bom caminho até começarmos a oferecer suporte a esses dispositivos no Asahi Installer, mas o avanço é rápido, então acompanhem!”
      Isso parece menos um desastre inevitável e mais pessoas talentosas fazendo um trabalho meticuloso
    • Se a cada poucos anos conseguirem mirar em apenas um modelo e fazê-lo funcionar direito, isso já é muito melhor do que não haver alternativa nenhuma
      O suporte ao M1 hoje em dia já é bem utilizável, e pelo menos parte do trabalho provavelmente vai se aproveitar em dispositivos futuros. Não é um cenário cor-de-rosa, mas também não é um projeto condenado ao fracasso

  • Seria realmente ótimo se a Apple financiasse uma equipe pequena para abrir a documentação e parte dos drivers como open source e ajudar o Asahi
    Claro que sei que isso não vai acontecer, mas sonhar ainda é de graça. Para a Apple seria troco, e isso consolidaria ainda mais seu hardware como padrão de fato entre engenheiros do Vale do Silício

  • Fiquei curioso para saber o quanto usaram modelos de linguagem de grande porte no Asahi recentemente. É uma ferramenta realmente poderosa para engenharia reversa; eles já escreveram algo sobre isso?

  • Tenho curiosidade sobre como é o processo de desenvolvimento/CI deste projeto
    No fim das contas, será que é sempre algo como carregar manualmente cada build em hardware específico, ou já existe alguma etapa em que algum nível de automação é possível?

    • O m1n1 faz bastante coisa interessante aqui: https://asahilinux.org/docs/sw/tethered-boot/
      Ele coloca uma camada bem fina entre o hardware real e o kernel, sem afetar o comportamento de I/O do hardware, ao mesmo tempo permitindo controlar e automatizar remotamente o carregamento e a depuração do kernel