Báo cáo tiến độ Asahi Linux 7.1
(asahilinux.org)- Tính đến Linux 7.1, Asahi Linux đang đồng thời tiến hành mở rộng hỗ trợ M3, tương thích với macOS 27 beta, giải mã video AVD và các thay đổi trong m1n1 1.6.0
- Trong bản beta dành cho nhà phát triển macOS 27 Golden Gate, mục khởi động Asahi đã biến mất khỏi Startup Disk và trình chọn khởi động, nhưng phân vùng và dữ liệu vẫn còn, và có thể khôi phục bằng cách đặt cờ khởi động APFS
- Thay đổi firmware SMC đã làm thay đổi giá trị trả về của quản lý pin, gây ra tắt máy khẩn cấp trong một số điều kiện; kernel downstream từ 7.0.12 trở đi xử lý cả hai firmware ABI
- Trên dòng M3, âm thanh, chuyển đổi tần số CPU, lập lịch big.LITTLE, cảm biến SMC, PCIe, WiFi, Bluetooth, NVMe, bàn phím và trackpad đã hoạt động trên Linux, nhưng vẫn chưa đến giai đoạn hỗ trợ Asahi Installer
- AVD đã tiến gần hơn tới giải mã phần cứng AVC bằng firmware tự phát triển và driver V4L2 thay vì firmware của Apple; m1n1 1.6.0 yêu cầu Rust để build stage 2, ảnh hưởng lớn tới các bản phân phối
Mục khởi động Asahi biến mất trong macOS 27
- Mục Asahi hiển thị trong trình chọn khởi động mở bằng cách giữ nút nguồn trên Mac hoặc trong ứng dụng Startup Disk không phải là phân vùng hệ điều hành thực sự
- Công cụ khởi động của Apple chỉ xử lý “bản cài macOS hợp lệ” bên trong container APFS, nên Asahi Installer tạo một container APFS 2,5GB và dùng một cấu hình macOS tối thiểu đặt m1n1 vào như một kernel
- Cách này đã hoạt động không thay đổi từ macOS 12 đến macOS 26, và Apple cũng đã sửa một phần lỗi công cụ vốn chỉ xuất hiện khi boot raw binary không phải kernel XNU thực sự
- Sau bản beta dành cho nhà phát triển macOS 27 Golden Gate, một số người dùng gặp vấn đề mục Asahi biến mất khỏi Startup Disk và trình chọn khởi động
- Kiểm tra bằng
diskutilcho thấy các phân vùng liên quan đến Asahi vẫn còn trên đĩa và không mất dữ liệu - Nếu dùng công cụ khởi động của macOS 26 trên cùng máy, Asahi vẫn có thể boot được
- Kiểm tra bằng
- macOS Installer đặt metadata APFS trước khi khởi động lại; điều tra thêm cho thấy giá trị này là cờ đánh dấu volume có thể khởi động
- Các công cụ khởi động trước macOS 27 đã bỏ qua cờ này
- Nếu đặt cờ thủ công cho container APFS của Asahi, nó sẽ hiển thị lại trong trình chọn khởi động của macOS 27
- Với các bản cài Asahi mới, Asahi Installer sẽ tự động đặt cờ này
- Một chế độ cài đặt để sửa các bản cài hiện có cũng đã được thêm vào
- Nếu không thể truy cập Asahi sau khi cài bản beta dành cho nhà phát triển macOS 27, hãy chạy lại installer và dùng tùy chọn “Fix macOS 27 boot picker compatibility”
- Một chương trình sửa vấn đề này từ Linux cũng đã được tạo, nhưng cần thêm dữ liệu thử nghiệm trước khi phân phối tự động
- Để thử nghiệm, trước khi nâng cấp lên macOS 27, hãy clone kho asahi-fix27, rồi build và chạy trong Linux
- Sau đó, nếu volume Asahi có thể được chọn làm mục khởi động trong macOS, tức là nó đã hoạt động
- Có thể chia sẻ kết quả và vấn đề trên các kênh cộng đồng của Asahi
Thay đổi firmware SMC và việc driver pin tắt máy khẩn cấp
- macOS 27 bao gồm các bản cập nhật firmware cho mọi thiết bị ngoại vi dùng global firmware, bao gồm SMC
- SMC phụ trách quản lý pin, và driver power supply của Linux giao tiếp với SMC để lấy trạng thái sạc, điện áp, thời gian còn lại đến khi xả hết và thông tin tình trạng pin
- Cùng driver đó cũng đặt các ngưỡng bắt đầu/dừng sạc thông qua giao diện firmware SMC nhằm kéo dài tuổi thọ pin
- Firmware SMC của macOS 27 đã đổi một giao diện quản lý pin từ trả về số nguyên 32-bit sang trả về 1 byte
- Vì thay đổi này, driver Asahi trong một số điều kiện đã đánh giá là pin bị lỗi và bắt đầu tắt máy khẩn cấp để bảo vệ hệ thống
- Bản vá đã được áp dụng trong kernel downstream; từ 7.0.12 trở đi, driver power supply xử lý cả hai firmware ABI
Cảnh báo về việc cài bản beta dành cho nhà phát triển
- Hai vấn đề xuất hiện trong macOS 27 cho thấy bản beta dành cho nhà phát triển thực sự là bản beta dành cho nhà phát triển
- Không khuyến nghị cài bản beta dành cho nhà phát triển lên máy dùng cho sản xuất
- Hai vấn đề xảy ra đến nay may mắn chỉ là vấn đề nhỏ, nhưng không có gì đảm bảo các vấn đề trong tương lai cũng sẽ nhỏ
- Các bản cập nhật global firmware về cơ bản là vĩnh viễn; muốn quay lại cần DFU restore máy
- Phía Asahi sử dụng máy hy sinh để thử nghiệm, nên cho rằng người dùng không cần đặt phần cứng đắt tiền và dữ liệu quan trọng vào rủi ro
Tiến triển hỗ trợ dòng M3
- Nền tảng máy tính và thiết kế/kiểm chứng IC rất tốn chi phí và thời gian, nên việc thay đổi thiết kế cũ một cách không cần thiết là không hợp lý
- Dự án Asahi đã dựa vào giả định rằng Apple sẽ không liên tục tạo ra những thay đổi phá vỡ tương thích trong nền tảng và IC; ngoại trừ các khối SoC lớn dễ thay đổi theo từng thế hệ như GPU, giả định này nhìn chung là đúng
-
Xuất âm thanh
- Âm thanh trên laptop Apple Silicon sử dụng nhiều IC và khối SoC
- Tiêu chuẩn gần như thực tế của ngành cho IC âm thanh là I2S, một bus dựa trên I2C được tối ưu cho dữ liệu âm thanh
- Bộ điều khiển I2S của Apple và nguồn clock ổn định Apple NCO không thay đổi kể từ M1
- Apple dùng cùng các chip khuếch đại loa và headset trên hầu hết mọi máy Apple Silicon
- Khi thêm hỗ trợ loa và jack tai nghe cho máy M3, công việc cần thiết chủ yếu là vài bổ sung Devicetree nhỏ và các file cấu hình
asahi-audio,speakersafetyd - Máy M3 hỗ trợ xuất âm thanh chất lượng cao trong Asahi Linux
-
Tần số CPU và lập lịch big.LITTLE
- Máy M3 cũng đã hỗ trợ chuyển đổi tần số CPU và lập lịch tác vụ big.LITTLE phù hợp
- Apple không thay đổi cách chuyển đổi tần số CPU kể từ M2 cơ bản
- Các SoC M3, M3 Pro, M3 Max, M3 Ultra hoạt động với driver
cpufreqhiện có chỉ bằng thay đổi Devicetree - Tác vụ được phân bổ thông minh hơn vào lõi tiết kiệm điện hoặc lõi hiệu năng tùy theo yêu cầu, và các lõi CPU tăng/giảm clock theo tải
- Thay đổi này mang lại cả tiết kiệm năng lượng lẫn cải thiện hiệu năng
-
Cảm biến và thiết bị cốt lõi
- Firmware SMC không khác biệt nhiều giữa các máy, nên hỗ trợ cảm biến phần cứng SMC cũng chỉ cần vài thay đổi Devicetree
- Trên các máy dòng M3, driver cho PCIe, WiFi, Bluetooth, NVMe, bàn phím, trackpad và các khối SoC cốt lõi khác cũng hoạt động trên Linux
- Phần lớn công việc này do Yureka, người đã làm việc với m1n1 và Linux trên máy dòng M3, thực hiện
- Vẫn cần thêm nhiều việc để bật hỗ trợ Asahi Installer cho máy M3, nhưng tiến độ đang rất nhanh
Giải mã video AVD và firmware tự phát triển
- Phần lớn phần cứng phức tạp trên nền tảng Apple Silicon dùng các blob firmware phức tạp
- Nhiều firmware dựa trên RTKit, một framework giống RTOS mà Apple dùng để cung cấp giao diện phần lớn được chuẩn hóa giữa kernel và nhiều khối phần cứng
- Một số khối như DCP và AOP dựa trên RTKit nhưng đặt thêm một lớp trừu tượng tên là EPIC lên trên
- Cũng có trường hợp dùng firmware bên thứ ba mà Apple không trực tiếp kiểm soát, như chipset WiFi/Bluetooth của Broadcom
- Apple Video Decoder, tức AVD, dùng một cấu trúc firmware riêng, không phải RTKit cũng không phải EPIC
-
Cấu trúc AVD và vấn đề của cách làm cũ
- Phần cứng AVD gần với ARM Cortex-M3 điều khiển các đơn vị phần cứng chức năng cố định để giải mã khung hình video AVC(H.264), HEVC(H.265), VP9 và AV1 trên các SoC mới nhất
- Cortex-M3 cung cấp giao diện để XNU trỏ tới dữ liệu video và chạy blob firmware cấu hình phần cứng giải mã thực tế
- Apple đặt firmware AVD và dữ liệu cấu hình bên trong AVD kext
- Mỗi SoC dùng một biến thể AVD hơi khác nhau, nên phát sinh vấn đề vận hành là Asahi Installer phải liên tục theo dõi và cập nhật thay đổi offset dữ liệu firmware trong kext
-
Cách tiếp cận firmware tự phát triển
- Firmware AVD do XNU tải không được kiểm chứng trên Cortex-M3
- Khi nhận tín hiệu, nó chạy từ reset vector, nên về thực tế bất cứ mã nào nằm trong đó cũng sẽ được thực thi
- Vai trò của firmware về cơ bản là trừu tượng hóa phần cứng giải mã video, nên nếu chỉ cài đặt interrupt handler cho từng khối phần cứng thì driver Linux có thể lập trình trực tiếp
- Vì là mã Cortex-M3 tiêu chuẩn, firmware AVD có thể chạy trong emulator
- QEMU hỗ trợ thực thi từng bước và kiểm tra thao tác bus/register
- Jamie, R và Eileen trước đây đã cùng nhau reverse engineer các lệnh và định dạng dữ liệu cần cho bộ giải mã AVC và VP9
- XNU kext cũng áp dụng các tunable riêng cho từng revision AVD
- Chưa hoàn toàn chắc chắn các giá trị này chính xác làm gì
- Việc áp dụng gần giống phát lại các lệnh ghi MMIO của XNU
- Cần theo dõi từng revision AVD, tập tunable và revision đích áp dụng
- Vì khó duy trì thỏa đáng trong driver kernel Linux upstream, nên phần này cũng phù hợp hơn khi đặt trong firmware
-
Driver V4L2 AVC
- Người đóng góp mới sofus đã tạo custom AVD firmware cơ bản để cài đặt interrupt handler và áp dụng tunable của từng biến thể
- Dựa trên đó, một driver V4L2 hoạt động cho phần cứng AVC đã được viết
- Phần cứng có thể giải mã video mã hóa AVC 10-bit tối đa 4K
- Nó hoạt động tốt với phần mềm triển khai V4L2 Request API
- Giữ firmware đơn giản và không trạng thái, để userspace và kernel đảm nhiệm việc phân tích dữ liệu video và lập trình bộ giải mã, cũng sẽ giúp dễ hỗ trợ các API tăng tốc video khác như VA-API hoặc Vulkan Video trong tương lai
- Vẫn còn việc phải làm để cung cấp hỗ trợ AVD cho người dùng
- AVD cũng hỗ trợ VP9, HEVC và AV1 trên một số SoC, nhưng các phần này chưa được triển khai
- Một số quirks của thiết bị cũng cần được kiểm thử và phản ánh vào driver
- Mục tiêu là có dạng có thể phân phối trong tương lai không quá xa
Bản phát hành m1n1 1.6.0
- m1n1 1.6.0 đã được gắn tag, và đây là một bản phát hành có ảnh hưởng lớn từ góc nhìn các bản phân phối
- Phiên bản này lần đầu tiên yêu cầu Rust để build stage 2
- Trước đây Rust chỉ được dùng khi build kèm hỗ trợ chainloading
- stage 1 m1n1 thay thế kernel XNU trong công cụ khởi động của Apple, và chỉ được dùng để mount EFI System Partition rồi chainload stage 2 m1n1 từ đó
- Khi quyết định chuyển việc khởi tạo GPU sang m1n1, driver kernel không còn cần xử lý các giá trị dấu phẩy động trong dữ liệu khởi tạo phần cứng Apple, và Devicetree binding cũng được đơn giản hóa đáng kể
- Phiên bản driver GPU sẽ được gửi lên Linux Kernel Mailing List trong tương lai dựa trên giả định rằng m1n1 thực hiện bước khởi tạo này
- Mã phân tích Apple Device Tree cũng đã được port sang Rust và được sử dụng ở hầu như mọi phần khác của m1n1
-
Build và target
- Vì m1n1 trên thực tế là firmware, nó dùng Rust
no_stdvà nhắm tớiaarch64-none-softfloat - Để không kéo vào các dependency không cần thiết, có thể truyền
BUILDSTD=1chomakeđể buildcorevàallocmà không cần cài toàn bộ toolchainsoftfloat
- Vì m1n1 trên thực tế là firmware, nó dùng Rust
-
Chuẩn bị cho M3, M4, A18 Pro
- 1.6.0 cũng bao gồm nhiều cải tiến cho hỗ trợ dòng M3
- Hỗ trợ bộ điều khiển SPMI
- Hỗ trợ khởi tạo PCIe
- Hỗ trợ tunnel trực tiếp DebugUSB của UART phần cứng SoC thông qua kisd
- Tunnel UART qua DebugUSB có thể cung cấp chức năng gần tương đương Central Scrutiniser
- Phần lớn công việc này cũng là đóng góp của Yureka
- Công việc nền tảng cho hỗ trợ M4 và A18 Pro, tức MacBook Neo, cũng đang được tiến hành
- Xử lý tốt hơn boot mode non-macOS của Apple
- Hỗ trợ metadata power domain mới trong Apple Device Tree
Tài trợ và người đóng góp
- Asahi Linux gửi lời cảm ơn tới các nhà tài trợ trên GitHub Sponsors và Open Collective
- Nhờ tài trợ, dự án có thể tiếp tục các tính năng M1/M2 còn dang dở, hỗ trợ M3/M4/A18 Pro và hỗ trợ những người đóng góp mới
1 bình luận
Ý kiến trên Hacker News
Cách diễn đạt “tiêu chuẩn ngành trên thực tế của IC âm thanh là I²S, một bus dựa trên I²C được tối ưu cho dữ liệu âm thanh” là không chính xác. I²S không liên quan đến I²C
Đúng là hầu hết chip I²S đều có kèm giao diện I²C, vì I²S chỉ truyền dữ liệu âm thanh thô và không có các tín hiệu phụ như điều khiển âm lượng hay thiết lập clock
Nhưng đó là một giao diện riêng, và cũng có thể là SPI thay vì I²C. Trên thực tế SPI gần với I²S hơn so với I²C
Lý do cả hai tuân theo hệ thống tên gọi tương tự là vì Philips Semiconductor (nay là NXP) đã tạo ra cả hai
Tôi thích điểm nó được thiết kế để không gặp vấn đề tương thích ngay cả khi bên gửi và bên nhận dùng độ sâu bit mẫu khác nhau theo hai chiều
https://web.archive.org/web/20070102004400/http://www.nxp.co...
Thật đáng kinh ngạc khi một nhóm nhỏ những người có động lực lại giải được những vấn đề như thế này
Các devicetree Linux khác có mã PSCI, nhưng không ai biết Apple đã triển khai nó như thế nào. Vì vậy người dùng Asahi đã phải dựa vào một bản hack để ngăn pin cứ tiếp tục cạn trong gần 5 năm, và theo tôi biết thì vẫn chưa có hướng giải quyết nào hứa hẹn
Đây là hai mặt sáng tối của reverse engineering. Việc các thiết bị này có driver Vulkan 1.2 native là rất tuyệt, nhưng để đến được đó đã mất vài năm. Đã 7 năm kể từ khi Apple Silicon ra mắt mà vẫn còn những vấn đề chưa giải quyết, và phần lớn phần cứng mới nhất nhìn chung vẫn chưa được hỗ trợ. Cuối cùng lại quay về bài học mà người dùng Linux vẫn luôn nói: driver độc quyền không hay ho gì
Phần khiến tôi đặc biệt lo ngại là CM3 không xác minh firmware mà XNU nạp, và khi có tín hiệu thì nó bắt đầu chạy từ reset vector bất kể nội dung thực tế là gì
Thành tựu viết được firmware tùy chỉnh cho một mục tiêu độc quyền và liên tục thay đổi là tuyệt vời đến mức khó diễn tả, nhưng ngoài việc hy vọng Apple sẽ không cố tình tiếp tục làm hỏng các hệ điều hành bên thứ ba, khả năng họ đưa chữ ký phần cứng vào firmware blob hoặc dữ liệu cấp cho phần cứng khi lập trình ở runtime có vẻ không hề thấp. Từ phía Apple, đó có thể là một lo ngại bảo mật hợp lý. Dù vậy tôi vẫn hy vọng ván cược này thành công
Tôi tò mò liệu cái này có mãi chỉ là Fedora “remix” hay không. Liệu một ngày nào đó có hỗ trợ upstream để chạy được các bản phân phối dựa trên Debian không?
Lần cuối tôi dùng một bản phân phối dựa trên RPM chắc đã gần 20 năm trước
Dĩ nhiên fork kernel cũng là mã nguồn mở, nên không có gì ngăn bạn lấy root Debian aarch64 rồi tự build kernel Asahi, hoặc lấy bản build Fedora và tự cấu hình Debian trên những thiết bị này. Chỉ là hơi tốn công một chút
Nếu Ubuntu ổn với bạn thì cũng có Ubuntu Asahi: https://ubuntuasahi.org/
Tìm thử thì cũng có tài liệu wiki này: https://wiki.debian.org/InstallingDebianOn/Apple/M1
Vì vậy tôi hiểu mong muốn tiếp tục dùng một bản phân phối cụ thể mà mình đã quen. Ít việc hơn và không phải nhớ quá nhiều khác biệt tinh tế trong cấu trúc. Dù vậy, khi buộc phải dùng một bản phân phối mới, chẳng hạn như lúc Asahi ban đầu chỉ dành cho Arch Linux ARM, tôi chưa bao giờ hối tiếc về chút học hỏi thu được từ đó
Họ đang tích cực làm upstream chính xác vì lý do đó, để mọi bản phân phối có thể được port dễ dàng hơn
https://ubuntuasahi.org/
Tôi vẫn chưa tự cài thử
https://voidlinux.org/download/#arm%20platforms
Đây là gói Linux thông thường trong bản phân phối: https://github.com/void-linux/void-packages/tree/master/srcp...
Thật vui khi thấy hỗ trợ M3 đang tiến triển tốt
Lần đầu họ nhắc đến việc bắt đầu thêm hỗ trợ M3 là vào tháng 2
“Từ khá lâu, m1n1 đã có hỗ trợ cơ bản cho các thiết bị dòng M3. Phần còn thiếu là devicetree cho từng thiết bị, cùng các patch driver kernel Linux để hỗ trợ những đặc tính phần cứng riêng và thay đổi của M3 so với M2. Từ trước đến nay luôn có ý định cụ thể hóa công việc này khi patchset hiện tại trở nên dễ quản lý hơn”
https://asahilinux.org/2026/02/progress-report-6-19/
Thật đáng mong đợi khi họ đang làm driver AVD
Khi dùng ffmpeg hoặc VLC trên máy Mac từ M1 trở lên thì có sử dụng AVD không?
Asahi có thể trở thành một lựa chọn thay thế khả thi, nhưng với mức kinh phí và quy mô nhân lực nhỏ như vậy, có vẻ tốc độ phát triển không thể không chậm
Như bài viết đã nói, đã có phần nền tảng được đặt sẵn và cũng có thành quả, nhưng rốt cuộc mỗi năm lại có Mac mới ra mắt với chip mới, vô số vi điều khiển và thay đổi GPU, nên không thể bắt kịp. Vì vậy đội Asahi cũng tập trung nhiều hơn vào các mẫu M1 và M2
Dù vậy, đến nay cả hai vẫn còn vấn đề về quản lý điện năng khi nhàn rỗi và triển khai Alt-DP, khiến nhiều người không thể chuyển sang dùng. Đến lúc các vấn đề này được trau chuốt xong thì giá trị thiết bị cũng đã giảm đáng kể
Việc một nhóm ít người làm được đến mức này là một kỳ tích, nhưng bất chấp việc được truyền thông đưa tin rộng rãi, cuối cùng có vẻ nhiệt huyết và động lực của đội đã giảm đi, và có vẻ ngay cả M1 Air cũng sẽ không thể hoàn thiện
Việc upstream các thay đổi vào kernel đã mất thời gian
Giờ họ đã thông báo bắt đầu làm M3 vào tháng 2, và tiến độ cũng có vẻ tốt
“Ngoài những nội dung trên, trên các thiết bị dòng M3, các driver cho PCIe, WiFi, Bluetooth, NVMe, bàn phím, trackpad và các khối SoC cốt lõi khác cũng đã hoạt động trên Linux. Phần lớn công việc này do Yureka đảm nhiệm, và trong một thời gian cô ấy đã rất tích cực hack cả m1n1 lẫn Linux trên các thiết bị dòng M3. Vẫn còn một chặng đường dài trước khi Asahi Installer bắt đầu hỗ trợ các thiết bị này, nhưng tiến triển đang nhanh, nên hãy tiếp tục theo dõi!”
Điều này giống cảnh những người tài năng đang làm công việc tỉ mỉ hơn là sự sụp đổ
Hỗ trợ M1 dạo này khá dùng được, và ít nhất một phần công việc có vẻ sẽ được kế thừa sang các thiết bị tương lai. Không phải toàn màu hồng, nhưng cũng không phải một dự án đã được định sẵn là thất bại
Sẽ thật tuyệt nếu Apple tài trợ cho một đội nhỏ để công khai một phần tài liệu và driver dưới dạng mã nguồn mở, rồi giúp Asahi
Tất nhiên tôi biết họ sẽ không làm vậy, nhưng ta vẫn có thể mơ. Với Apple thì đó chỉ là tiền lẻ, mà làm vậy sẽ càng củng cố phần cứng của họ thành tiêu chuẩn trên thực tế của các kỹ sư Silicon Valley
Nó xuất sắc đến mức đã khiến tôi xóa Asahi và định dạng lại máy vài năm trước
https://developer.apple.com/documentation/hypervisor
https://docs.getutm.app/installation/macos/
Tôi tò mò gần đây Asahi đã tận dụng mô hình ngôn ngữ lớn đến mức nào. Đây là công cụ thực sự mạnh cho reverse engineering, họ đã từng viết gì liên quan đến chuyện này chưa?
https://asahilinux.org/docs/project/policies/slop/
Tôi tò mò quy trình phát triển/CI của dự án này trông như thế nào
Rốt cuộc mỗi lần có phải nạp build thủ công lên phần cứng cụ thể không, hay có giai đoạn nào có thể tự động hóa ở một mức độ nào đó?
Nó đặt một lớp rất mỏng giữa phần cứng thật và kernel, nhưng không ảnh hưởng đến hoạt động I/O của phần cứng, đồng thời cho phép điều khiển từ xa và tự động hóa việc nạp kernel cũng như debug