Laporan kemajuan Asahi Linux 7.1

 (asahilinux.org)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Per Asahi Linux 7.1, dukungan M3 yang diperluas, kompatibilitas dengan beta macOS 27, decoding video AVD, dan perubahan m1n1 1.6.0 sedang berlangsung secara bersamaan
  • Pada beta pengembang macOS 27 Golden Gate, entri boot Asahi menghilang dari Startup Disk dan boot picker, tetapi partisi dan data tetap ada, dan pemulihan dimungkinkan dengan mengatur flag boot APFS
  • Perubahan firmware SMC mengubah nilai balikan manajemen baterai dan memicu shutdown darurat pada kondisi tertentu; kernel downstream sejak 7.0.12 menangani kedua ABI firmware
  • Pada keluarga M3, audio, pergantian frekuensi CPU, penjadwalan big.LITTLE, sensor SMC, PCIe, WiFi, Bluetooth, NVMe, keyboard, dan trackpad sudah berfungsi di Linux, tetapi masih belum pada tahap dukungan Asahi Installer
  • AVD telah membuat kemajuan menuju decoding hardware AVC dengan firmware sendiri dan driver V4L2 alih-alih firmware Apple, dan m1n1 1.6.0 kini memerlukan Rust untuk build stage 2 sehingga berdampak besar pada distro

Entri boot Asahi yang hilang di macOS 27

  • Entri Asahi yang terlihat di boot picker yang dibuka dengan menahan tombol daya di Mac atau di aplikasi Startup Disk bukanlah partisi sistem operasi yang sebenarnya
  • Karena alat boot Apple hanya menangani “instalasi macOS yang valid” di dalam kontainer APFS, Asahi Installer membuat kontainer APFS 2.5GB dan menggunakan konfigurasi macOS minimal dengan m1n1 dimasukkan seperti kernel
  • Metode ini berfungsi tanpa perubahan dari macOS 12 hingga macOS 26, dan Apple juga telah memperbaiki sebagian bug alat yang hanya muncul saat mem-boot raw binary alih-alih kernel XNU yang sebenarnya
  • Sejak beta pengembang macOS 27 Golden Gate, beberapa pengguna mengalami masalah entri Asahi yang hilang dari Startup Disk dan boot picker
    • Hasil pemeriksaan diskutil menunjukkan partisi terkait Asahi masih ada di disk dan tidak ada kehilangan data
    • Jika alat boot macOS 26 digunakan pada mesin yang sama, Asahi masih bisa di-boot
  • macOS Installer mengatur metadata APFS sebelum reboot, dan investigasi lebih lanjut menunjukkan nilai ini adalah flag yang menandai volume sebagai dapat di-boot
    • Alat boot sebelum macOS 27 mengabaikan flag ini
    • Jika flag diatur secara manual pada kontainer APFS Asahi, entri tersebut muncul kembali di boot picker macOS 27
  • Pada instalasi Asahi baru, Asahi Installer kini mengatur flag ini secara otomatis
  • Mode instalasi untuk memperbaiki instalasi lama juga telah ditambahkan
    • Jika setelah memasang beta pengembang macOS 27 Anda tidak bisa mengakses Asahi, jalankan installer lagi dan gunakan opsi “Fix macOS 27 boot picker compatibility”
  • Program untuk memperbaiki masalah dari Linux juga telah dibuat, tetapi diperlukan lebih banyak data pengujian sebelum distribusi otomatis
    • Untuk menguji, sebelum upgrade ke macOS 27 clone repositori asahi-fix27 lalu build dan jalankan di Linux
    • Setelah itu, jika volume Asahi bisa dipilih sebagai target boot di macOS, berarti berhasil
    • Hasil dan masalah dapat dibagikan di community channels Asahi

Perubahan firmware SMC dan shutdown darurat pada driver baterai

  • macOS 27 menyertakan pembaruan firmware untuk semua periferal yang menggunakan global firmware, termasuk SMC
  • SMC bertanggung jawab atas manajemen baterai, dan driver power supply Linux berkomunikasi dengan SMC untuk memperoleh status pengisian, tegangan, sisa waktu hingga habis, dan informasi kondisi baterai
  • Driver yang sama juga mengatur ambang mulai dan berhenti pengisian melalui antarmuka firmware SMC untuk memperpanjang umur baterai
  • Firmware SMC di macOS 27 mengubah satu antarmuka manajemen baterai dari nilai balikan integer 32-bit menjadi nilai balikan 1 byte
  • Karena perubahan ini, driver Asahi dalam kondisi tertentu menilai baterai rusak dan memulai shutdown darurat untuk melindungi sistem
  • Patch sudah diterapkan di kernel downstream, dan sejak 7.0.12 driver power supply menangani kedua ABI firmware

Peringatan soal pemasangan beta pengembang

  • Dua masalah yang muncul di macOS 27 menunjukkan bahwa beta pengembang memang benar-benar beta pengembang
  • Memasang beta pengembang pada mesin produksi tidak disarankan
  • Dua masalah yang terjadi sejauh ini kebetulan bersifat kecil, tetapi tidak ada jaminan bahwa masalah berikutnya juga akan kecil
  • Pembaruan global firmware pada praktiknya bersifat permanen, dan untuk membalikkannya mesin harus di-DFU restore
  • Pihak Asahi menggunakan mesin tumbal untuk pengujian, sehingga menurut mereka pengguna tidak perlu mempertaruhkan perangkat keras mahal dan data penting

Kemajuan dukungan keluarga M3

  • Platform komputer serta desain dan verifikasi IC memerlukan biaya dan waktu besar, sehingga mengubah desain lama tanpa alasan bukanlah hal yang rasional
  • Proyek Asahi bergantung pada asumsi bahwa Apple tidak akan terus membuat perubahan yang merusak pada platform dan IC, dan selain blok SoC besar seperti GPU yang cenderung berubah tiap generasi, asumsi ini umumnya terbukti benar

  • Output audio

    • Audio pada laptop Apple Silicon menggunakan beberapa IC dan blok SoC
    • Standar industri de facto untuk IC audio adalah I2S, bus berbasis I2C yang dioptimalkan untuk data audio
    • Kontroler I2S Apple dan Apple NCO sebagai sumber clock yang stabil tidak berubah sejak M1
    • Apple memakai chip amplifier speaker dan headset yang sama pada hampir semua mesin Apple Silicon
    • Saat menambahkan dukungan speaker dan jack headphone ke mesin M3, pekerjaan yang dibutuhkan terutama berupa penambahan Devicetree kecil dan file konfigurasi asahi-audio serta speakersafetyd
    • Mesin M3 mendukung output audio berkualitas tinggi di Asahi Linux

  • Frekuensi CPU dan penjadwalan big.LITTLE

    • Mesin M3 kini juga mendukung pergantian frekuensi CPU dan penjadwalan pekerjaan big.LITTLE yang tepat
    • Apple tidak mengubah cara pergantian frekuensi CPU sejak M2 dasar
    • SoC M3, M3 Pro, M3 Max, dan M3 Ultra bekerja dengan driver cpufreq yang ada hanya dengan perubahan Devicetree
    • Pekerjaan ditempatkan lebih cerdas pada core efisiensi atau core performa sesuai kebutuhan, dan core CPU menaikkan atau menurunkan clock berdasarkan beban
    • Perubahan ini membawa penghematan energi sekaligus peningkatan performa

  • Sensor dan perangkat inti

    • Firmware SMC tidak terlalu berbeda antar mesin, sehingga dukungan sensor hardware SMC juga hanya membutuhkan beberapa perubahan Devicetree
    • Pada mesin keluarga M3, driver untuk PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, dan blok SoC inti lainnya juga berfungsi di Linux
    • Sebagian besar pekerjaan ini dikerjakan oleh Yureka, yang telah mengerjakan m1n1 dan Linux pada mesin keluarga M3
    • Masih dibutuhkan lebih banyak pekerjaan untuk mengaktifkan dukungan Asahi Installer pada mesin M3, tetapi lajunya cepat

Decoding video AVD dan firmware buatan sendiri

  • Sebagian besar hardware kompleks pada platform Apple Silicon menggunakan blob firmware yang kompleks
  • Banyak firmware berbasis RTKit, kerangka kerja mirip RTOS yang digunakan Apple untuk menyediakan antarmuka yang kurang lebih terstandarisasi antara kernel dan berbagai blok hardware
  • Beberapa blok seperti DCP dan AOP dibangun di atas RTKit dengan abstraksi tambahan bernama EPIC
  • Ada juga kasus yang memakai firmware pihak ketiga yang tidak dikendalikan langsung oleh Apple, seperti chipset Broadcom WiFi/Bluetooth
  • Apple Video Decoder, atau AVD, menggunakan firmware dengan arsitektur terpisah yang bukan RTKit maupun EPIC

  • Arsitektur AVD dan masalah pendekatan lama

    • Hardware AVD mirip ARM Cortex-M3 yang mengendalikan unit hardware fungsi tetap untuk mendekode frame video AVC (H.264), HEVC (H.265), VP9, dan AV1 pada SoC yang lebih baru
    • Cortex-M3 menyediakan antarmuka tempat XNU menunjuk data video, lalu menjalankan blob firmware yang menyiapkan hardware decoder sebenarnya
    • Apple menaruh firmware AVD dan data konfigurasinya bersama di dalam kext AVD
    • Karena tiap SoC memakai varian AVD yang sedikit berbeda, timbul masalah logistik karena Asahi Installer harus terus melacak dan memperbarui perubahan offset data firmware di dalam kext

  • Pendekatan firmware sendiri

    • Firmware AVD yang dimuat XNU tidak diverifikasi oleh Cortex-M3
    • Setelah menerima sinyal, ia mengeksekusi mulai dari reset vector, sehingga kode apa pun yang ada di dalamnya akan dijalankan
    • Karena peran firmware pada dasarnya adalah mengabstraksikan hardware decoder video, Linux driver bisa memprogramnya langsung asalkan interrupt handler untuk tiap blok hardware dipasang
    • Karena berupa kode Cortex-M3 standar, firmware AVD dapat dijalankan di emulator
    • QEMU mendukung eksekusi single-step dan inspeksi operasi bus serta register
    • Jamie, R, dan Eileen melalui kolaborasi sebelumnya telah melakukan reverse engineering atas perintah dan format data yang diperlukan untuk decoder AVC dan VP9
    • Kext XNU juga menerapkan tunable yang unik untuk tiap revisi AVD
    • Belum sepenuhnya jelas apa fungsi tepat nilai-nilai ini
    • Penerapannya kurang lebih seperti replay MMIO write dari XNU
    • Setiap revisi AVD, kumpulan tunable, dan revisi target penerapannya harus dilacak
    • Hal ini sulit dipelihara dengan memuaskan di driver kernel Linux upstream, sehingga lebih tepat menaruh bagian ini di firmware juga

  • Driver V4L2 AVC

    • Kontributor baru sofus telah membuat custom AVD firmware dasar yang memasang interrupt handler dan menerapkan tunable tiap varian
    • Berdasarkan itu, ia menulis driver V4L2 yang berfungsi untuk hardware AVC
    • Hardware tersebut dapat mendekode video encoding AVC 10-bit hingga 4K
    • Ini bekerja baik dengan perangkat lunak yang mengimplementasikan V4L2 Request API
    • Dengan menjaga firmware tetap sederhana dan stateless, serta menyerahkan parsing data video dan pemrograman decoder kepada userspace dan kernel, dukungan untuk API akselerasi video lain seperti VA-API atau Vulkan Video di masa depan juga menjadi lebih mudah
    • Masih ada pekerjaan tersisa sebelum dukungan AVD bisa diberikan kepada pengguna
    • AVD juga mendukung VP9, HEVC, dan AV1 pada sebagian SoC, tetapi belum diimplementasikan
    • Quirk pada beberapa perangkat juga masih perlu diuji dan dicerminkan di driver
    • Bentuk yang siap didistribusikan ditargetkan tidak terlalu jauh lagi

Rilis m1n1 1.6.0

  • m1n1 1.6.0 telah diberi tag, dan dari sudut pandang distro ini adalah rilis yang berdampak besar
  • Versi ini untuk pertama kalinya memerlukan Rust untuk build stage 2
  • Sebelumnya, Rust hanya dipakai saat build dengan dukungan chainloading
  • m1n1 stage 1 menggantikan kernel XNU di alat boot Apple, dan hanya digunakan untuk me-mount EFI System Partition lalu melakukan chainload stage 2 m1n1 dari sana
  • Dengan memindahkan inisialisasi GPU ke m1n1, driver kernel tidak lagi perlu menangani nilai floating-point dalam data inisialisasi hardware Apple, dan binding Devicetree juga menjadi jauh lebih sederhana
  • Versi driver GPU yang kelak akan diajukan ke Linux Kernel Mailing List bergantung pada asumsi bahwa m1n1 melakukan inisialisasi ini
  • Kode parsing Apple Device Tree juga telah dipindahkan ke Rust, dan digunakan di hampir semua bagian lain m1n1

  • Build dan target

    • Karena m1n1 pada dasarnya adalah firmware, ia memakai Rust no_std dan menargetkan aarch64-none-softfloat
    • Agar tidak menarik dependensi yang tidak perlu, BUILDSTD=1 dapat diberikan ke make sehingga core dan alloc bisa dibangun tanpa memasang seluruh toolchain softfloat

  • Persiapan untuk M3, M4, A18 Pro

    • 1.6.0 juga mencakup berbagai peningkatan untuk dukungan keluarga M3
    • Dukungan kontroler SPMI
    • Dukungan inisialisasi PCIe
    • Dukungan tunneling langsung DebugUSB dari UART hardware SoC melalui kisd
    • Tunneling UART DebugUSB dapat menyediakan fungsi yang hampir sama dengan Central Scrutiniser
    • Sebagian besar pekerjaan ini juga merupakan kontribusi Yureka
    • Pekerjaan dasar untuk dukungan M4 dan A18 Pro, yakni MacBook Neo, juga sedang berlangsung
    • Penanganan non-macOS boot mode Apple menjadi lebih baik
    • Metadata power domain baru di Apple Device Tree kini didukung

Sponsor dan kontributor

  • Asahi Linux menyampaikan terima kasih kepada para sponsor di GitHub Sponsors dan Open Collective
  • Berkat sponsor, mereka dapat terus mengerjakan fitur M1·M2 yang belum selesai, dukungan M3·M4·A18 Pro, dan dukungan bagi kontributor baru

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Pendapat Hacker News

  • Ungkapan “standar de facto industri untuk IC audio adalah I²S, bus berbasis I²C yang dioptimalkan untuk data audio” tidak akurat. I²S tidak ada hubungannya dengan I²C
    Memang sebagian besar chip I²S memiliki antarmuka I²C, karena I²S hanya membawa data audio mentah dan tidak memiliki sinyal tambahan seperti kontrol volume atau pengaturan clock
    Namun itu adalah antarmuka terpisah, dan bisa saja SPI alih-alih I²C. Dalam praktiknya, SPI lebih dekat dengan I²S daripada I²C

    • Benar, I²S jauh lebih dekat dengan SPI
      Alasan keduanya mengikuti skema penamaan yang mirip adalah karena Philips Semiconductor (sekarang NXP) membuat keduanya
    • I²S adalah desain yang sangat sederhana. Tidak ada handshake protokol, hanya PCM mentah yang mengalir
      Saya suka karena dirancang agar tidak ada masalah kompatibilitas meski pengirim dan penerima menggunakan kedalaman bit sampel yang berbeda di kedua arah
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • Sungguh mengagumkan melihat segelintir orang yang termotivasi bisa memecahkan masalah-masalah seperti ini

    • Banyak masalah sama sekali belum terpecahkan. Misalnya, antarmuka manajemen daya PSCI Apple Silicon masih menjadi misteri
      Di device tree Linux lain ada kode PSCI, tetapi tidak ada yang tahu bagaimana Apple mengimplementasikannya. Karena itu, pengguna Asahi selama hampir 5 tahun mengandalkan hack untuk mencegah baterai terus terkuras, dan sejauh yang saya tahu belum ada solusi yang menjanjikan
      Inilah sisi terang dan gelap rekayasa balik. Keren bahwa perangkat-perangkat ini mendapatkan driver Vulkan 1.2 native, tetapi butuh bertahun-tahun untuk sampai ke sana. Bahkan sekarang, 7 tahun setelah Apple Silicon dirilis, masih ada masalah yang belum terselesaikan, dan sebagian besar hardware terbaru secara umum belum didukung. Pada akhirnya kita kembali ke pelajaran yang selalu dikatakan pengguna Linux: driver proprietari itu tidak bagus

  • Bagian bahwa CM3 tidak memverifikasi firmware yang dimuat XNU, dan ketika ada sinyal ia mulai menjalankan apa pun isi sebenarnya dari reset vector, terasa sangat mengkhawatirkan
    Pencapaian menulis firmware kustom untuk target yang proprietari dan terus berubah ini benar-benar luar biasa, tetapi terlepas dari harapan agar Apple tidak sengaja terus merusak OS pihak ketiga, tampaknya cukup mungkin Apple akan memperkenalkan tanda tangan hardware untuk blob firmware atau data yang diberikan ke pemrograman hardware saat runtime. Dari sudut pandang Apple, itu bisa menjadi kekhawatiran keamanan yang masuk akal. Meski begitu, saya berharap pertaruhan ini berhasil

  • Saya penasaran apakah ini akan selamanya tetap menjadi “remix” Fedora. Apakah suatu saat dukungan upstream akan masuk sehingga bisa menjalankan distro berbasis Debian?
    Rasanya terakhir kali saya memakai distro berbasis RPM hampir 20 tahun lalu

    • Mereka mengirim patch ke upstream, jadi pada akhirnya driver yang diperlukan akan masuk ke Linux upstream
      Tentu saja fork kernelnya juga open source, jadi tidak ada yang menghalangi untuk mengambil root Debian aarch64 dan membangun kernel Asahi sendiri, atau mengambil build Fedora lalu menyusun Debian sendiri untuk perangkat ini. Hanya saja perlu usaha
      Kalau Ubuntu tidak masalah, ada juga Ubuntu Asahi: https://ubuntuasahi.org/
      Setelah mencari, ada juga dokumen wiki ini: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • Komentar ini membuat saya tersenyum karena selera saya justru sebaliknya. Saya lebih suka distro berbasis RPM dan terutama memakai Fedora hampir di semua tempat. Saya juga memakai Fedora Asahi Remix di M1 Ultra Mac Studio, dan hanya sesekali memakai Ubuntu dan Debian di beberapa instance cloud
      Jadi saya paham keinginan untuk tetap memakai distro tertentu yang sudah akrab. Pekerjaannya lebih sedikit, dan tidak perlu mengingat terlalu banyak perbedaan halus dalam strukturnya. Namun ketika terpaksa memakai distro baru, misalnya saat Asahi pertama kali hanya tersedia untuk Arch Linux ARM, saya tidak pernah menyesali sedikit pembelajaran yang didapat dari sana
    • Arch juga masih bisa dipakai, dan ada juga Ubuntu Asahi
      Mereka bekerja keras pada upstream persis agar semua distro bisa lebih mudah di-porting
      https://ubuntuasahi.org/
    • Bananas Team sedang mengerjakan agar Debian standar berjalan di Apple Silicon, dan ada juga cara memasangnya sekarang dengan menambahkan repositori tidak resmi: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      Saya sendiri belum pernah mencobanya
    • linux-asahi juga tersedia di Void Linux
      https://voidlinux.org/download/#arm%20platforms
      Ini adalah paket Linux biasa di dalam distro: https://github.com/void-linux/void-packages/tree/master/srcp...

  • Senang melihat dukungan M3 berkembang dengan baik
    Pertama kali disebutkan bahwa pekerjaan untuk menambahkan dukungan M3 akan dimulai adalah pada Februari
    “Untuk waktu yang cukup lama, m1n1 sudah memiliki dukungan dasar untuk perangkat seri M3. Yang belum ada adalah device tree untuk tiap perangkat, serta patch driver kernel Linux untuk mendukung karakteristik hardware dan perubahan khusus M3 yang berbeda dari M2. Sejak awal memang ada niat untuk menindaklanjuti pekerjaan ini begitu patchset yang ada menjadi lebih mudah dikelola”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • Menarik mendengar mereka sedang mengerjakan driver AVD

  • Jika memakai ffmpeg atau VLC di Mac M1 ke atas, apakah itu menggunakan AVD?

  • Asahi bisa menjadi alternatif yang layak, tetapi dengan dana sebesar ini dan ukuran tim yang kecil, rasanya kecepatan pengembangannya memang tak bisa tidak akan terlalu lambat
    Seperti yang disebut dalam tulisan itu, sudah ada pekerjaan fondasi yang diletakkan dan hasilnya pun ada, tetapi pada akhirnya setiap tahun muncul Mac baru dengan chip baru, begitu banyak mikrokontroler, dan perubahan GPU, jadi mustahil untuk mengejarnya. Karena itu tim Asahi juga lebih berfokus pada model M1 dan M2
    Meski begitu, hingga kini keduanya masih menyisakan masalah manajemen daya saat idle dan implementasi Alt-DP, sehingga banyak orang belum bisa beralih. Saat masalah ini sudah dipoles, nilai perangkatnya juga mungkin sudah jauh turun
    Bahwa segelintir orang bisa mencapai sejauh ini adalah keajaiban, tetapi meski mendapat liputan media yang luas, pada akhirnya semangat dan motivasi tim tampaknya menurun, dan terlihat seolah bahkan M1 Air pun tidak akan pernah selesai

    • Alih-alih “kecepatan pengembangannya memang tak bisa tidak terlalu lambat”, saat tim kepemimpinan baru masuk mereka mengumumkan akan memprioritaskan meng-upstream pekerjaan yang sudah ada daripada menambahkan dukungan untuk perangkat keras terbaru
      Meng-upstream perubahan ke kernel memang memakan waktu
      Sekarang mereka sudah mengumumkan bahwa pekerjaan M3 dimulai pada Februari, dan progresnya terlihat bagus
      “Selain hal di atas, di perangkat seri M3, driver untuk PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, serta blok SoC inti lainnya juga sudah berjalan di Linux. Sebagian besar pekerjaan ini ditangani oleh Yureka, dan selama beberapa waktu ia sangat aktif mengutak-atik perangkat seri M3 baik untuk m1n1 maupun Linux. Masih ada jalan panjang sebelum Asahi Installer mulai mendukung perangkat-perangkat ini, tetapi progresnya cepat, jadi nantikan terus!”
      Ini lebih terlihat seperti orang-orang berbakat yang melakukan pekerjaan teliti, bukan kehancuran
    • Jika setiap beberapa tahun mereka bisa menargetkan satu model saja dan membuatnya berjalan dengan baik, itu jauh lebih baik daripada tidak ada alternatif sama sekali
      Dukungan M1 belakangan ini cukup layak pakai, dan setidaknya sebagian dari pekerjaannya tampaknya akan terbawa ke perangkat masa depan. Memang tidak semuanya cerah, tetapi ini juga bukan proyek yang sudah ditakdirkan gagal

  • Akan sangat menyenangkan jika Apple mendanai tim kecil untuk membuka sebagian dokumentasi dan driver sebagai open source serta membantu Asahi
    Tentu saja saya tahu mereka tidak akan melakukannya, tetapi kita boleh bermimpi. Bagi Apple itu hanya receh, dan dengan begitu perangkat keras mereka akan makin mengukuhkan diri sebagai standar de facto bagi para engineer Silicon Valley

  • Saya penasaran seberapa banyak large language model dimanfaatkan di Asahi belakangan ini. Untuk reverse engineering, itu benar-benar alat yang sangat kuat; apakah mereka pernah menulis tentang hal itu?

  • Saya penasaran seperti apa proses pengembangan/CI proyek ini
    Pada akhirnya, apakah setiap kali build dimuat secara manual ke perangkat keras tertentu, atau ada tahap yang bisa diotomatisasi sampai batas tertentu?

    • m1n1 melakukan cukup banyak hal menarik di sini: https://asahilinux.org/docs/sw/tethered-boot/
      Ia menempatkan lapisan yang sangat tipis di antara perangkat keras nyata dan kernel tanpa memengaruhi perilaku I/O perangkat keras, sambil memungkinkan pemuatan kernel dan debugging dikendalikan serta diotomatisasi dari jarak jauh