Dự án Asahi Linux đạt tiến bộ trên USB3, hướng tới hỗ trợ loa, đèn nền bàn phím

Dự án Asahi Linux phát triển USB 3 theo hướng hỗ trợ loa và đèn nền bàn phím
Bởi Michael Larabel cho Apple vào ngày 22 tháng 11 năm 2022, lúc 1. 10 giờ tối. m. Giờ Chuẩn Miền Đông5 Bình luận
Dự án Asahi Linux đạt tiến bộ trên USB3, hướng tới hỗ trợ loa, đèn nền bàn phím
Nhóm Asahi Linux gần đây đã phát hành báo cáo trạng thái tháng 11 năm 2022 của họ, trong đó nêu bật những phát triển nguồn mở gần đây liên quan đến hỗ trợ Linux cho các thiết bị Apple Silicon M1/M2

Nhờ cộng đồng nguồn mở, kỹ thuật đảo ngược, tiến trình tốt vẫn đang được thực hiện để hỗ trợ đầy đủ SoC dựa trên Arm hiện đại của Apple và các hệ thống trong Linux. Một số cột mốc Asahi Linux gần đây nhất trong nỗ lực lâu dài này bao gồm

Trước đó, Asahi Linux đã vận hành các cổng Thunderbolt dưới dạng USB2; . Việc mong đợi một số sự cố hỗ trợ USB3 là điều bình thường

- Mặc dù loa tích hợp trên MacBook, MacBook Pro và MacBook Air vẫn bị tắt theo mặc định, chúng tôi đang nỗ lực để kích hoạt chúng một cách an toàn

Sau khi thiết kế ngược codec tai nghe CS42L84, hỗ trợ giắc cắm tai nghe hiện đang hoạt động trên nhiều loại thiết bị

- Chức năng hỗ trợ đèn nền bàn phím

- Những nỗ lực không ngừng trong lĩnh vực quản lý năng lượng

- Các cải tiến liên tục được thực hiện cho trình cài đặt Asahi Linux

- Như đã báo cáo trước đây trong các bài báo, trình điều khiển AGX Gallium3D Mesa và trình điều khiển nhân DRM, cả hai đều được viết bằng Rust, vẫn đang được tích cực phát triển để hỗ trợ đồ họa Apple Silicon


AMD Rembrandt so với. Apple M2 và Điểm chuẩn cho Intel Alder Lake Linux


Bạn có thể đọc toàn bộ báo cáo tình hình tháng 11 tại AsahiLinux. tổ chức
5 bình luận

Hiển thị hỗ trợ của bạn. Trang web này chủ yếu được hỗ trợ bởi quảng cáo. Quảng cáo là thứ đã cho phép trang web này được duy trì hàng ngày trong hơn 18 năm qua. Chúng tôi cố gắng hết sức để đảm bảo chỉ những quảng cáo sạch, có liên quan mới được hiển thị, khi phát hiện thấy bất kỳ quảng cáo khó chịu nào, chúng tôi sẽ cố gắng loại bỏ chúng càng sớm càng tốt. Nếu bạn muốn xem trang web không có quảng cáo trong khi vẫn hỗ trợ công việc của chúng tôi, vui lòng xem xét Phoronix Premium không có quảng cáo của chúng tôi .

Dự án Asahi Linux đạt tiến bộ trên USB3, hướng tới hỗ trợ loa, đèn nền bàn phím

Được viết bởi Michael Larabel trên Apple vào ngày 22 tháng 11 năm 2022 lúc 01. 10 giờ tối Múi giờ miền Đông. 5 bình luận

Dự án Asahi Linux đạt tiến bộ trên USB3, hướng tới hỗ trợ loa, đèn nền bàn phím

Nhóm Asahi Linux đã xuất bản báo cáo trạng thái tháng 11 năm 2022 nêu bật tiến trình nguồn mở gần đây về việc hỗ trợ các thiết bị Apple Silicon M1/M2 trong Linux

Tiến bộ tốt tiếp tục được thực hiện khi hỗ trợ đầy đủ SoC dựa trên Arm hiện đại của Apple và các hệ thống trong Linux nhờ cộng đồng mã nguồn mở, kỹ thuật đảo ngược. Một số cột mốc mới nhất của Asahi Linux trong nỗ lực lâu dài này bao gồm

- Nhờ trình điều khiển PHY hoạt động, chế độ USB3 cho các cổng Thunderbolt nên khá chắc chắn. Trước đó, Asahi Linux đã vận hành các cổng Thunderbolt dưới dạng USB2. Một số trục trặc trong hỗ trợ USB3 sẽ được dự kiến

- Loa MacBook / MacBook Pro / MacBook Air tích hợp vẫn bị tắt theo mặc định nhưng tiến trình đang được thực hiện để có thể kích hoạt nó một cách an toàn

- Hỗ trợ giắc cắm tai nghe hiện đang hoạt động trên nhiều loại thiết bị sau khi thiết kế ngược codec tai nghe CS42L84

- Hỗ trợ đèn nền bàn phím hiện đang hoạt động

- Tiếp tục công việc xung quanh quản lý năng lượng

- Tiếp tục cải tiến bộ cài đặt Asahi Linux

- Như đã báo cáo trong các bài viết trước, trình điều khiển nhân DRM do Rust viết và trình điều khiển AGX Gallium3D Mesa tiếp tục được phát triển tích cực để hỗ trợ đồ họa Apple Silicon


Apple M2 so với. AMD Rembrandt so với. Điểm chuẩn Intel Alder Lake Linux


Báo cáo tình hình tháng 11 đầy đủ có thể được đọc qua AsahiLinux. tổ chức

5 bình luận

  • Nếu đây là lần đầu tiên bạn truy cập, hãy nhớ xem Câu hỏi thường gặp bằng cách nhấp vào liên kết ở trên. Bạn có thể phải đăng ký trước khi bạn có thể đăng bài. Nhấp vào liên kết đăng ký ở trên để tiến hành. Để bắt đầu xem tin nhắn, hãy chọn diễn đàn mà bạn muốn truy cập từ lựa chọn bên dưới

Thời gian cho một báo cáo tiến độ quá hạn khác. Bản cập nhật tháng này được đóng gói với sự hỗ trợ phần cứng mới, các tính năng mới và các bản sửa lỗi cho các điểm yếu lâu nay, cũng như một nhánh nhân mới nhất với sự hỗ trợ đã được chờ đợi từ lâu cho hệ thống treo và bộ điều khiển hiển thị

Nếu bạn chưa quen với Asahi Linux, hãy xem thông báo phát hành trước đây của chúng tôi để biết hướng dẫn cài đặt và thông tin chung

USB3, Chương 1

Cho đến thời điểm hiện tại, Asahi Linux mới chỉ hỗ trợ USB2 trên cổng Thunderbolt. Mặc dù bộ điều khiển USB2/3 phần cứng đã được Linux hỗ trợ khá tốt và bộ điều khiển cổng Type-C cũng dựa trên phần cứng được hỗ trợ một phần hiện có, vẫn còn thiếu một phần lớn. trình điều khiển PHY

Các máy Apple Silicon M1 trở lên sử dụng phần cứng PHY do Apple thiết kế (hoặc do Apple tùy chỉnh?) có tên là “Apple Type-C PHY” (ATCPHY) hỗ trợ các chế độ USB3, DisplayPort và TB3/USB4. Phần cứng này chịu trách nhiệm biến dữ liệu giao thức USB3/DP/TB thành tín hiệu trên dây. Vì chúng ta đang xử lý các tín hiệu tốc độ rất cao (lên đến 20Gbps mỗi cặp), nên PHY phải rất phức tạp và có rất nhiều nút analog cần được hiệu chỉnh riêng. Với USB2, bạn có thể thoát khỏi việc có các cài đặt chung hoạt động cho mọi thiết bị, nhưng điều đó sẽ không hoạt động đối với USB3 và các giao thức tốc độ cao khác

Công việc của trình điều khiển PHY là định cấu hình phần cứng vật lý với các cài đặt dành riêng cho chip cụ thể của bạn, được hiệu chỉnh tại nhà máy và quản lý cấu hình lại của toàn bộ phần cứng PHY khi bật và tắt các chế độ khác nhau. Trên thực tế, điều này có nghĩa là một số lượng lớn các lần chọc đăng ký "ma thuật", bao gồm một số lần chọc có dữ liệu thay đổi đến từ các eFuse do nhà máy viết. Sven đã làm việc chăm chỉ để thiết kế ngược tất cả những thứ này và bản phát hành mới này bao gồm trình điều khiển ATCPHY mới của anh ấy với hỗ trợ cho chế độ USB3

Ngoài việc tự điều khiển PHY, trình điều khiển PHY phải phối hợp rất cẩn thận với trình điều khiển bộ điều khiển USB (dwc3) và trình điều khiển bộ điều khiển cổng Type C (tipd). Khi các thiết bị được kết nối và ngắt kết nối, sẽ có một cuộc đàm phán phức tạp phải xảy ra, cuối cùng dẫn đến quyết định về giao thức nào sẽ chạy trên dây nào. Thông tin này phải được truyền tới PHY (bao gồm cả những thứ như hướng bạn cắm cáp) để nó có thể định tuyến tín hiệu một cách thích hợp và chỉ sau khi mọi thứ đã được khởi tạo theo đúng thứ tự, bộ điều khiển USB mới có thể được hiển thị. Để làm cho vấn đề trở nên phức tạp hơn, phần cứng khá thất thường và nếu có sự cố xảy ra, bộ điều khiển có thể bị khóa hoặc không hoạt động

Chúng tôi nghĩ rằng chế độ USB3 sẽ khá chắc chắn, nhưng bạn có thể gặp một số trục trặc khi thực hiện nhanh những việc như cắm nóng thiết bị vào thời điểm này. Tin tốt là, vì việc chuyển đổi chế độ khi bạn cắm nóng cáp liên quan đến việc đặt lại hầu hết mọi thứ nên mọi sự cố tạm thời thường có thể được giải quyết bằng cách chỉ cần ngắt kết nối và kết nối lại thiết bị. Hoạt động thực tế của USB3 phải ổn định sau khi được kết nối, nhưng hãy cho chúng tôi biết nếu bạn gặp bất kỳ sự cố nào

USB3, Chương 2x7 Gen3. 1415

Điều đó bao gồm các cổng Thunderbolt/USB4… nhưng câu chuyện về USB còn thiếu một chút nữa. các cổng Type A và non-Thunderbolt Type C trên Mac Studio và iMac. Các cổng bổ sung này (tồn tại trong các kết hợp khác nhau tùy thuộc vào chính xác kiểu phần cứng bạn có) được xử lý bởi bộ điều khiển ASMedia PCIe USB3. Đây chỉ là một bộ điều khiển USB PCIe xHCI tiêu chuẩn đã được hỗ trợ tốt bởi trình điều khiển tiêu chuẩn trong Linux, nhưng câu chuyện có một bước ngoặt của Apple. bộ điều khiển cần phần sụn được trình điều khiển tải lên trên nền tảng Apple Silicon

Thông thường, loại phần cứng này dự kiến ​​sẽ xuất xưởng cùng với bộ nhớ Flash chứa phần sụn để chạy bộ điều khiển. Tuy nhiên, Apple không phải là một fan hâm mộ cuồng nhiệt của các ký ức Flash ngẫu nhiên và vì lý do chính đáng. chúng có thể bị xâm phạm, bị hỏng và rất khó xác minh cũng như triển khai khởi động an toàn cho. Vì lý do này, các kỹ sư của Apple đã giảm dần số lượng bộ nhớ Flash phần sụn trên các nền tảng này và trong trường hợp này, họ quyết định chỉ giao hàng mà không có nó và yêu cầu nhân tải lên phần sụn khi khởi động

Đây có vẻ là một vấn đề đơn giản, và thực sự phần lớn việc tải lên chương trình cơ sở thực tế là (mặc dù bước nhảy đăng ký không có giấy tờ cần thiết để làm điều này không dễ để tìm ra và thực hiện công việc một cách đáng tin cậy…), nhưng cuối cùng chúng tôi phải suy nghĩ lại hoàn toàn về cách thức

Hóa ra, chương trình cơ sở ASMedia được nhúng bên trong nhị phân nhân macOS XNU, vì vậy chúng tôi cần giải nén nó để cung cấp cho Linux. Chúng tôi biết điều này sẽ xảy ra, vì vậy chúng tôi đã cất giữ một bản sao của hạt nhân đó trong /boot/efi/asahi/ để sử dụng trong tương lai trong trình cài đặt của chúng tôi. Nhưng kernel ở định dạng img4 và được nén bằng thuật toán lzfse do Apple phát triển, vì vậy cuối cùng chúng tôi phải gửi gói này dưới dạng một gói mới để cho phép người dùng Asahi hiện tại nâng cấp liền mạch và tự động trích xuất chương trình cơ sở

Trong khi đó, quá trình tương tự phải xảy ra trên macOS bên trong Asahi Linux Installer, đối với các bản cài đặt mới. macOS tất nhiên đi kèm với khung nén riêng hỗ trợ lzfse và chúng tôi có thể sử dụng nó trực tiếp từ Python với ctypes… ngoại trừ có một nhược điểm khác. Hóa ra là trong khi điều này hoạt động trên macOS, thì recoveryOS không đi kèm với libffi, thứ mà Python cần để làm cho ctypes hoạt động. Vì vậy, cuối cùng chúng tôi phải cung cấp một bản sao của libffi (từ gói Homebrew) cùng với trình cài đặt, để làm cho tất cả điều này hoạt động trơn tru bất kể bạn đang chạy trình cài đặt từ macOS hay recoveryOS

Như thể vẫn chưa đủ, phần sụn này còn khiến chúng tôi thiết kế lại hoàn toàn cơ chế phần sụn của nhà cung cấp trong Asahi. Thấy chưa, cho đến bây giờ chúng ta chỉ tải phần sụn từ hệ điều hành đã khởi động, sau khi initramfs đã hoàn thành công việc của nó. Điều này hoạt động đủ tốt cho phần sụn WiFi và Bluetooth, nhưng mọi người thường mong đợi bàn phím của họ hoạt động bên trong initramfs và bàn phím đó có thể được kết nối với một trong các cổng ASMedia xHCI. Trên hết, cơ chế cài đặt chương trình cơ sở của nhà cung cấp mà chúng tôi thiết kế ban đầu là không phù hợp, trong đó phần cứng WiFi/BT có thể được nhân phát hiện trước khi chương trình cơ sở sẵn sàng trong lần khởi động đầu tiên (đây là lý do tại sao đôi khi bạn bị hỏng WiFi . Đã đến lúc cho một sự thay đổi lớn

Cơ chế mới được mô tả trong trang cập nhật, nhưng đây là ý chính. Chúng tôi đã thay đổi định dạng gói chương trình cơ sở từ tarball thành kho lưu trữ cpio, làm cho initramfs tải nó trước mọi thứ khác vào tmpfs, sau đó sử dụng tmpfs mount trên hệ thống tệp gốc cuối cùng để giữ nó. Điều này cũng liên quan đến việc thêm đường dẫn tải chương trình cơ sở mới vào nhân trong một bản vá. Kết quả cuối cùng là một hệ thống mạnh mẽ hơn và thậm chí an toàn hơn về mặt pháp lý, vì initramfs có thể đảm bảo rằng phần sụn được tải trước khi udev khởi động (và do đó trước khi bất kỳ trình điều khiển nào có thể tải yêu cầu nó) và nó không bao giờ tồn tại bên trong hệ thống tệp gốc . g. linux-firmware), có nghĩa là các bản sao lưu hệ thống tập tin gốc sạch sẽ không chứa các đốm màu không thể phân phối lại. Hơn nữa, vì kho lưu trữ là cpio, điều này cho phép bộ tải khởi động tải nó dưới dạng initramfs bổ trợ khi khởi động, có nghĩa là nó có thể hoạt động với các trình điều khiển tích hợp và loại bỏ hoàn toàn mọi điều kiện cuộc đua có thể xảy ra. Mặc dù hiện tại chúng tôi không làm điều này theo mặc định trong Asahi Linux, nhưng đây là cấu hình được hỗ trợ nếu bạn định cấu hình lại /boot của mình để gắn trực tiếp phân vùng hệ thống EFI và cài đặt hạt nhân cũng như bộ tải khởi động của bạn ở đó (chúng tôi sẽ cung cấp hướng dẫn về cách thực hiện việc này . Nếu cpio không được tải bởi bộ tải khởi động, tập lệnh initramfs sẽ tìm và tải nó cho bạn, vì vậy cả hai cấu hình đều có kết quả tương tự

Phù. Đó là một cuộc phiêu lưu chỉ để tải một số chương trình cơ sở ASMedia. Nhưng cùng với đó, WiFi khởi động lần đầu hiện đã hoạt động ổn định trên tất cả các máy và chúng tôi tự tin hơn nhiều vào thiết kế quản lý phần sụn trong tương lai

Tiến bộ âm thanh, theo dõi ♪

Còn về loa, tôi nghe bạn hỏi? . Trong nhiều tháng nay, chúng tôi đã có trình điều khiển loa hoạt động, nhưng chúng tôi chưa kích hoạt chúng vì lý do chính đáng. bởi vì chúng tôi rất nghi ngờ rằng bạn có thể phá hủy loa của mình nếu không có hệ thống an toàn và giới hạn âm lượng phức tạp hơn. Hóa ra… những nghi ngờ đó là đúng. Tôi đã quyết định chọn một chiếc cho nhóm và chạy một số thử nghiệm trên MacBook Air M2 của mình và ngay cả với một số giới hạn âm lượng hợp lý, tôi đã nhanh chóng quản lý để làm nổ các loa tweeter của mình. Ối. Điều tốt là chúng tôi chưa bật loa

Thử nghiệm này đã giúp chúng tôi xem xét kỹ hơn những gì cần thiết để điều khiển loa một cách an toàn và câu trả lời phức tạp hơn nhiều so với những gì bạn có thể mong đợi. Loa siêu nhỏ hiện đại yêu cầu phần mềm EQ tinh vi để có âm thanh tốt, nhưng chúng cũng yêu cầu các mô hình an toàn tinh vi. Thông số an toàn quan trọng nhất đối với loa siêu nhỏ là nhiệt độ của cuộn dây âm thanh. bạn không muốn làm tan chảy mọi thứ. Nhưng mức độ nóng của loa phụ thuộc vào mức năng lượng được truyền vào loa. Hầu hết các nguồn âm thanh không có nhiều năng lượng ở dải cao, điều đó có nghĩa là loa tweeter thường không nhận được nhiều năng lượng đầu vào. Nhưng một số đầu vào nhất định (như sóng vuông tần số cao) có thể cung cấp công suất tối đa cho các loa tweeter và nhanh chóng vượt quá ngưỡng an toàn của chúng. Tất nhiên, bạn có thể giới hạn âm lượng ở mức an toàn đã biết, nhưng điều này sẽ dẫn đến việc giảm đáng kể âm lượng tổng thể và để lại nhiều khoảng trống không sử dụng cho hầu hết các tín hiệu âm thanh và nhạc thông thường

Vậy ta phải làm sao? . Cung cấp năng lượng này cho một mô hình dựa trên các đặc tính vật lý của loa, chúng ta có thể ước tính nhiệt độ cuộn dây âm thanh (và nhiệt độ nam châm, cần thiết cho một mô hình hoàn chỉnh) và áp đặt giới hạn âm lượng nếu nhiệt độ tăng quá cao. Đây chính xác là những gì macOS làm và những gì chúng tôi sẽ phải triển khai trên Linux

Loại mô hình an toàn này không mới. nó đã phổ biến trên điện thoại Android, nơi nó thường được triển khai trong phần sụn DSP. Nhưng tất nhiên, hệ sinh thái Linux dành cho máy tính để bàn thậm chí còn chưa có khung cơ sở dữ liệu EQ của loa, chưa kể đến các mô hình an toàn. Sự tụt hậu vĩnh viễn của âm thanh Linux lại xuất hiện. Kế hoạch là gì? . Điều này sẽ giúp giải quyết vấn đề khỏi các trình nền âm thanh và hệ thống con riêng lẻ, những hệ thống con này có thể trực tiếp mở thiết bị đầu ra và gửi dữ liệu tới thiết bị đó (mặc dù chúng sẽ không thể sử dụng các điều khiển âm lượng phần cứng, nhưng vì định dạng dữ liệu là PCM 24 bit,

Apple bắt đầu sử dụng mô hình an toàn này trên dòng máy tính xách tay M1 Pro/Max và các mẫu MacBook Air và Pro 13" M1 không triển khai mô hình này. Tuy nhiên, vì bộ khuếch đại loa hỗ trợ tính năng phản hồi, chúng tôi dự định phát triển và triển khai mô hình an toàn của riêng mình cho những bộ khuếch đại đó. Hóa ra nhiệt độ cuộn dây âm thanh của loa có thể được ước tính từ thực tế là đồng có hệ số nhiệt độ, vì vậy điện trở của nó thay đổi theo nhiệt độ. Bằng cách đưa tín hiệu thử nghiệm vào loa và sử dụng phản hồi điện áp/dòng điện, chúng ta có thể tính toán điện trở cuộn dây và xem nhiệt độ cuộn dây âm thanh tăng như thế nào đối với một đầu vào nguồn nhất định, sau đó sử dụng dữ liệu này để lấy các hằng số phù hợp cho mô hình an toàn mới. Bởi vì nếu chúng ta có thể vượt qua Apple trong trò chơi của chính họ, tại sao không? . )

Do đó, loa vẫn bị tắt cho đến bây giờ, nhưng chúng tôi đang đến đó

Tiến bộ âm thanh, theo dõi ♫

Trong khi đó, povik đã làm việc chăm chỉ trên hệ thống con âm thanh. Anh ấy đã thiết kế ngược codec tai nghe CS42L84 mới và hoàn toàn không có giấy tờ được sử dụng trong dòng MacBook Pro 14"/16" cũng như Mac Studio và MacBook M2. Điều này có nghĩa là chúng tôi hiện có hỗ trợ giắc cắm tai nghe trên bảng. Anh ấy cũng đã tải phần lớn công việc này lên nhân Linux và giữ cho số lượng bản vá xuôi dòng của chúng tôi ở mức thấp

Ngoài ra, chúng tôi hiện đang vận chuyển gói dwc32 tích hợp đúng cách này vào PulseAudio/PipeWire và các máy chủ âm thanh tương tự, để giúp điều khiển âm lượng và cắm nóng liền mạch. Gói này cũng sẽ được sử dụng với hỗ trợ loa sắp tới, để chuyển đổi thiết bị hoạt động bình thường. Trong thời gian chờ đợi, tất cả những gì bạn phải làm để giắc cắm tai nghe hoạt động tốt là nâng cấp các gói của bạn và khởi động lại. Điều khiển âm lượng phần cứng giờ đây sẽ được tự động ánh xạ tới điều khiển âm lượng trên máy tính để bàn của bạn mà không cần bất kỳ cài đặt thủ công nào

Trong khi thử nghiệm thay đổi âm thanh này và các thay đổi âm thanh khác, chúng tôi đã gặp phải nhiều lỗi và hồi quy PulseAudio dẫn đến trải nghiệm rất kém cho người dùng (đầu ra ngừng hoạt động sau khi không hoạt động hoặc cắm nóng, v.v. ). Cấu hình DSP loa sắp tới của chúng tôi dù sao cũng dựa trên PipeWire và chúng tôi nhận thấy rằng chỉ cần thay thế PulseAudio bằng PipeWire hôm nay sẽ khắc phục được tất cả các sự cố lạ và nếu không thì dường như hoạt động hoàn hảo. Do đó, chúng tôi cũng đang thêm PipeWire làm phần phụ thuộc vào gói dwc33 của mình, điều đó có nghĩa là những người dùng hiện tại của hình ảnh Máy tính để bàn Asahi Linux sẽ được nhắc xóa PulseAudio và thay thế bằng PipeWire khi họ nâng cấp. Nắm lấy tương lai

Đèn nền, Sách I

Tất cả các bạn đã kêu gọi nó. Nhờ công việc của ChaosPrincess, chúng tôi hiện có hỗ trợ đèn nền bàn phím. Điều này hoạt động trơn tru với KDE, vì vậy máy Mac Asahi của bạn giờ đây có thể tỏa sáng trong bóng tối

Đây là nỗ lực kỹ thuật đảo ngược và trình điều khiển đầu tiên của ChaosPrincess và tôi rất hài lòng với kết quả này. Mặc dù đây là một trình điều khiển rất đơn giản, nhưng họ đã làm rất tốt khi vạch ra những ẩn số của phần cứng để làm cho nó trông giống như một trình điều khiển phù hợp chứ không phải là một bản hack được thiết kế ngược. Đây là điều chúng tôi cố gắng đạt được khi tìm hiểu cách thức hoạt động của phần cứng và thật vui khi thấy những người mới tiếp cận phương pháp này. Để trích dẫn kinh nghiệm của họ kỹ thuật đảo ngược

  1. chạy m1n1
  2. chọc vào macos
  3. đập đầu vào bàn nhiều
  4. ??????
  5. lợi nhuận, đôi khi

Có thể bàn phím MacBook của chúng tôi mang lại ánh sáng cho bóng tối

Đèn nền, Quyển II

Nhưng còn độ sáng màn hình thì sao?

A, chúng ta đang đến đó. Như bạn có thể biết, cho đến nay Asahi Linux hoàn toàn không có trình điều khiển hiển thị. Thay vào đó, chúng tôi dựa vào bộ đệm khung thời gian khởi động do bộ tải khởi động thiết lập (iBoot trên máy tính xách tay, m1n1 trên máy tính để bàn). Điều này có nghĩa là Linux chỉ lấy một đoạn bộ nhớ và ghi pixel vào đó – không VSync, không lật bộ đệm, không thay đổi chế độ, không DPMS và không hỗ trợ điều khiển đèn nền. Vì việc bật đèn nền gây hao pin rất lớn, nên chúng tôi đã thêm một mẹo nhỏ để hỗ trợ tắt đèn nền bằng cách tắt chân GPIO cấp nguồn cho đèn nền theo đúng nghĩa đen, nhưng không cần phải nói rằng đó không phải là trải nghiệm người dùng tốt nhất (và nhiều người dùng đã

Để hỗ trợ đầu ra màn hình đúng cách, chúng tôi cần trình điều khiển cho bộ đồng xử lý DCP của Apple và chương trình cơ sở của nó. Trước đây chúng ta đã nói về DCP và giao diện bị nguyền rủa như thế nào. Kể từ đó, Alyssa đã viết trình điều khiển DRM KMS nhân Linux cho DCP và Janne đảm nhận việc bảo trì, đồng thời anh ấy đã liên tục bổ sung các tính năng, bao gồm hỗ trợ kiểm soát độ sáng. Với điều đó, DCP cuối cùng cũng đủ tốt cho những người dùng ưa mạo hiểm lái xe hàng ngày trên các hệ thống M1 (sắp có hỗ trợ M2)

Điều này sửa rất nhiều tính năng bị thiếu từ lâu, bao gồm khả năng điều khiển màn hình> 1080p mà không cần hack bộ nạp khởi động, kiểm soát độ sáng, VSync (trên Wayland), chuyển đổi độ phân giải, v.v. Nó cũng mở đường cho hỗ trợ hiển thị bên ngoài (vẫn chưa hoàn thiện) (qua Type C/DisplayPort) mà Sven đang nghiên cứu và là yêu cầu đối với trình điều khiển GPU tăng tốc sắp tới của Lina. Tiến triển

Tuy nhiên, nó đi kèm với một số cảnh báo. trình điều khiển phức tạp và có khả năng gây ra lỗi và hồi quy, đồng thời nó cũng có thể làm giảm hiệu suất trên một số thiết lập, vì nó thực sự được sử dụng cùng với khả năng tăng tốc GPU (trình điều khiển bộ đệm khung simpledrm có một số tối ưu hóa hiển thị phần mềm mà DCP thiếu) và máy khách . Nó cũng có một số hạn chế khi được sử dụng với các máy khách cũ như Xorg - cụ thể là không có hỗ trợ cho các ngắt VBlank thực sự và không rõ liệu phần cứng/phần sụn có hỗ trợ điều này hay không. Điều này phá vỡ trình quản lý cửa sổ của XFCE4 khi bật tổng hợp. Vì những lý do này, chúng tôi không bật DCP theo mặc định cho tất cả người dùng mà thay vào đó, biến nó thành một tính năng chọn tham gia. Làm thế nào, bạn yêu cầu?

Sống trên các cạnh

Với các trình điều khiển tiên tiến và mới như DCP, chúng tôi có nguy cơ làm giảm trải nghiệm của người dùng hiện tại. Trong khi rất nhiều người háo hức chờ đợi những tính năng mới này, nhiều người khác đang hàng ngày lái Asahi với các nhân hiện có và muốn trải nghiệm của họ được duy trì ổn định. Chúng tôi có kho lưu trữ gói phát triển (dwc34), nhưng nó thường chứa các gói bị hỏng và không dành cho người dùng cuối, đồng thời rất khó chuyển đổi qua lại giữa kho lưu trữ này và kho lưu trữ dwc35 thông thường (vui lòng không sử dụng dwc34,

Đây là những gì chúng tôi đang làm thay vào đó. Bắt đầu với bản phát hành này, chúng tôi sẽ gửi một gói hạt nhân dwc37 mới, chứa các trình điều khiển và cấu hình chưa được coi là đủ ổn định để cung cấp cho tất cả người dùng của chúng tôi. Gói này có thể được cài đặt song song với gói dwc38 hiện có và sẽ trở thành mục khởi động mặc định, nhưng bạn luôn có thể quay lại hạt nhân không cạnh bằng cách sử dụng các tùy chọn khởi động nâng cao trong GRUB. Để sử dụng nó, chỉ cần nâng cấp các gói của bạn, cài đặt nó và cập nhật cấu hình GRUB của bạn

$ sudo pacman -Syu
$ sudo pacman -S linux-asahi-edge
$ sudo update-grub

Vì đây là kernel mới nhất, chúng tôi yêu cầu bạn vui lòng không báo cáo sự cố với nó vì đây là lỗi mới trên trình theo dõi của chúng tôi (chúng tôi đã biết về rất nhiều lỗi trong số đó. ). Thay vào đó, vui lòng để lại nhận xét về lỗi trình theo dõi này, sau khi xác minh rằng đó không phải là sự cố đã biết được đề cập ở nơi khác trong chuỗi. Chúng tôi sẽ xử lý các sự cố theo thời gian, khi trình điều khiển trưởng thành và cuối cùng được nâng cấp lên nhân chính

Lưu ý rằng dwc37 theo dõi cây nhân giống như dwc38 và chúng tôi chỉ thay đổi cấu hình thời gian xây dựng để bật hoặc tắt một số tính năng nhất định. Để tránh làm hỏng hệ thống của bạn, nếu bạn đã cài đặt nó, bạn phải luôn nâng cấp song song cả hai gói (chỉ cần tipd1 là được). Không làm như vậy có thể khiến bạn gặp sự cố cây thiết bị và có thể khiến một trong hai nhân không thể khởi động được

Những người đủ háo hức để nhấp vào liên kết trước đó có thể đã nhận thấy điều gì đó khác được đề cập ở đó… yup, có One More Thing™

ý tưởng nhàn rỗi

Bên cạnh DCP, một trong những tính năng được yêu cầu nhiều nhất là “quản lý năng lượng”. Điều đó thực sự thú vị, bởi vì chúng tôi đã quản lý năng lượng ngay từ đầu. Chia tỷ lệ tần số CPU, PM thời gian chạy thiết bị (đối với các thiết bị được chọn), PM tự động phần cứng… ngay cả trước khi phát hành bản này, người dùng đã có thể có hơn 10 giờ thời gian chạy nhàn rỗi. Với DCP và DPMS hiển thị phù hợp, thời lượng đó hiện lên tới hơn 30 giờ (bật nguồn, tắt màn hình)

À, nhưng khi mọi người nói "quản lý năng lượng", ý của họ thường là "đình chỉ". Hãy xem, các nền tảng x86 cũ (trong đó “cổ” có nghĩa là “mọi thứ trước năm 2015 hoặc lâu hơn”) không có khả năng quản lý năng lượng nhàn rỗi thực sự hợp lý như Apple Silicon Macs. Thay vào đó, họ triển khai chế độ “treo” hoặc “S3” toàn cầu để tắt hầu hết phần cứng, chỉ bật nguồn RAM, vì đó là cách duy nhất để không ngốn hoàn toàn pin của máy tính xách tay trong vài giờ trên những máy đó

Rất may, các hệ thống dựa trên SoC như điện thoại thông minh đã có khả năng quản lý năng lượng tốt hơn nhiều trong một thời gian dài, thậm chí Intel và Microsoft cũng đã tham gia và hiện hỗ trợ một thứ mà họ gọi là “S0ix” hoặc “Chế độ chờ hiện đại”. Trên các nền tảng có khả năng quản lý điện năng chi tiết thực sự, bạn không cần phải “treo” hệ thống để tiết kiệm điện. Bạn chỉ cần để máy nghỉ là đã tiết kiệm điện rồi

Tất nhiên, "để máy không hoạt động" có thể là một điều khó khăn nếu không có một chút trợ giúp từ hệ điều hành. Trên Linux, tương đương với S0ix được gọi là “s2idle” (Tạm dừng để không hoạt động) và nó thực hiện chính xác những gì được ghi trên hộp thiếc. nó thực hiện các chuyển động tạm dừng hệ thống, nhưng sau đó chỉ để phần cứng ở trạng thái không hoạt động thay vì đi qua phần sụn nền tảng để thực sự kích hoạt tạm dừng toàn hệ thống. Điều quan trọng, điều này đóng băng không gian người dùng và buộc một số thiết bị nhất định ở chế độ năng lượng thấp, điều đó có nghĩa là s2idle có thể đảm bảo tiết kiệm năng lượng, trong khi việc chỉ để các ứng dụng chạy sẽ không. Một số người đã báo cáo mức tiêu hao pin cao trên các máy Asahi Linux khi không hoạt động và điều này hầu như luôn xảy ra do không gian người dùng hoạt động kém gây ra một số lượng lớn các lần đánh thức hoặc khiến CPU bận rộn. s2idle giải quyết vấn đề này

s2idle không yêu cầu bất kỳ trình điều khiển hoặc hỗ trợ đặc biệt nào, nhưng nó yêu cầu hoạt động (i. e. ít nhất là không bị lỗi) tạm dừng/tiếp tục hỗ trợ trong trình điều khiển. Đối với chúng tôi, điều này đã bị chặn trên chipset WiFi, cơ chế này yêu cầu một cơ chế mới để đi vào cái mà nó gọi là tạm dừng S3 (có tên khó hiểu; nó ánh xạ tới s2idle tại đây) trên các máy Apple không được trình điều khiển hiện có hỗ trợ và sẽ gây ra . Sau khi triển khai tính năng này và một số tính năng trình điều khiển nhỏ khác, s2idle hiện hoạt động trên các máy Apple Silicon. Tính năng này hiện đã được bật trong nhân dwc37, vì vậy nếu bạn chuyển đổi, bạn sẽ thấy các tùy chọn tạm dừng bật lên một cách kỳ diệu trong môi trường máy tính để bàn của mình

Mặc dù s2idle vẫn hoạt động nhưng nó vẫn ở giai đoạn sơ khai và chúng tôi chưa khắc phục được tất cả các vấn đề về trình điều khiển. Đây là những gì hoạt động

  • NVMe đang tắt
  • WiFi chuyển sang chế độ S3
  • Hiển thị (DCP) chuyển sang DPMS (đèn nền & màn hình tắt hoàn toàn)
  • Cổng nguồn DARTs & khôi phục trạng thái khi tiếp tục
  • CPU ở trạng thái nhàn rỗi nông
  • Tắt nguồn một số thiết bị linh tinh (i2c/spi/etc)
  • Đánh thức qua nút nguồn hoặc mở nắp

Và ít nhất những thứ này được biết là bị mất hoặc bị hỏng

  • Không có CPU sâu/tắt nguồn nhàn rỗi (cũng ảnh hưởng đến thời gian chạy bình thường, bị chặn khi thay thế PSCI)
  • USB2/3 bị hỏng (bộ điều khiển được đặt lại và bạn có thể cần phải kết nối lại thiết bị khi tiếp tục; vui lòng không tạm ngưng với các ổ USB được gắn. )
  • Một số thiết bị linh tinh chưa thực sự bị treo (e. g. bàn phím/bàn di chuột sẽ đệm các lần nhấn phím và có thể bị hỏng)
  • Không có nguồn đánh thức thay thế (bàn phím/chuột/v.v.)

Chúng tôi sẽ giải quyết một số vấn đề này theo thời gian, nhưng chúng tôi muốn cho mọi người cơ hội dùng thử s2idle ở trạng thái hiện tại. Như đã đề cập trước đó, vui lòng báo cáo bất kỳ sự cố nào trong sự cố trình theo dõi linux-asahi-edge

Cuối cùng, máy Mac Apple Silicon hỗ trợ chế độ tạm dừng giống như S3 thực sự, đưa toàn bộ hệ thống vào trạng thái ngủ sâu hơn và đây là những gì macOS sử dụng để tạm dừng. Mặc dù điều này có thể giúp tiết kiệm nhiều điện năng hơn, nhưng việc triển khai sẽ phức tạp hơn và phụ thuộc vào một số điều mà chúng tôi chưa giải quyết được. Hiện tại, vì vẫn còn nhiều cơ hội để giảm mức tiêu thụ điện năng s2idle, chúng tôi sẽ tập trung vào điều đó trong tương lai. Trong tương lai, chúng tôi có thể triển khai tạm ngưng “đầy đủ” nếu chúng tôi thấy nó mang lại lợi ích đáng kể so với s2idle được quản lý đúng cách

Lặp lại trình cài đặt

Chúng tôi cũng đang phát triển bộ cài đặt Asahi Linux cho người dùng mới. Để ngắn gọn câu chuyện dài, chúng tôi đã khắc phục nhiều điểm khó khăn trong các phiên bản trước (chẳng hạn như sự cố tính toán giới hạn an toàn cho việc thay đổi kích thước macOS gây ra lỗi thay đổi kích thước) và chúng tôi cũng đã cải thiện cách diễn đạt của một số lời nhắc để . Hy vọng rằng nó sẽ mang lại trải nghiệm mượt mà hơn và ít khó hiểu hơn cho mọi người

Ngoài ra, chúng tôi đã quảng cáo hỗ trợ M2 cho những người không chuyên. Chúng tôi cam kết hỗ trợ 12. 4 trên M2, giống như 12. 3 trong gia đình M1. Xin nhắc lại, khi chúng ta nói về các phiên bản chương trình cơ sở, chúng ta đang nói về chương trình cơ sở được ghép nối với hệ điều hành mà trình cài đặt cài đặt cùng với Asahi Linux. Điều này không liên quan đến phiên bản macOS của bạn và trình cài đặt tương thích với tất cả các phiên bản macOS hiện tại, từ 12. 3 đến 13. x

Ngoài ra còn có hai tính năng trình cài đặt mới. nó có thể khôi phục một số cài đặt bị hỏng và nó có thể nâng cấp phiên bản m1n1 giai đoạn 1 của bạn. Đôi khi, người dùng không thực hiện đúng hướng dẫn sau khi cài đặt (bước 2) và điều đó có thể khiến họ rơi vào vòng lặp khởi động. Mặc dù điều này có thể dễ dàng khắc phục bằng cách tắt hệ thống và thử lại, nhưng thực hiện bất kỳ điều gì khác (như chọn một hệ điều hành khởi động khác) có thể khiến cài đặt ở trạng thái kỳ lạ khiến bạn khó thử lại mà không xóa sạch phân vùng và cài đặt lại từ đầu. Trình cài đặt hiện cung cấp một tính năng mới để sửa chữa "cài đặt chưa hoàn tất", về cơ bản thực hiện lại bước cuối cùng của quy trình và nhắc người dùng thực hiện lại các hướng dẫn sau khi cài đặt mà không yêu cầu cài đặt lại đầy đủ

Cơ chế tương tự này cũng hữu ích để khôi phục từ các trường hợp hiếm hoi khi quá trình nâng cấp macOS của Apple bị rối và phá vỡ cài đặt Asahi Linux của bạn bằng cách xóa hoặc tạo lại Chính sách khởi động của nó. Chúng tôi rất hiếm khi thấy điều này xảy ra (nếu bạn tìm được cách sao chép nó một cách đáng tin cậy, vui lòng cho chúng tôi biết. ). Người dùng giờ đây có thể yên tâm rằng giải pháp rất đơn giản nếu điều này xảy ra. chỉ cần chạy lại trình cài đặt (tipd3 từ macOS hoặc recoveryOS) và chọn tùy chọn sửa chữa khi được nhắc (tình huống giống với cài đặt chưa hoàn tất)

Tính năng nâng cấp m1n1 mới được sử dụng để nâng cấp phiên bản m1n1 giai đoạn 1 của bạn. Có hai giai đoạn của m1n1 trong bản cài đặt Asahi Linux và giai đoạn thứ hai luôn được nâng cấp thông qua các gói Linux và là giai đoạn quan trọng nhất để thêm các tính năng mới. Giai đoạn đầu tiên được cài đặt từ recoveryOS và không thể nâng cấp từ Linux và công việc của nó chỉ là tải giai đoạn thứ hai. Vì đó là tất cả những gì nó làm, nó hiếm khi cần phải nâng cấp. Tuy nhiên, điều này đôi khi có thể hữu ích để khắc phục các lỗi hiếm gặp và chúng tôi đã xác định được sự cố có thể gây ra lỗi khởi động liên tục sau khi tắt máy không sạch trong một số trường hợp hiếm gặp. Cách giải quyết rất đơn giản (chỉ cần khởi động bằng cách giữ nút nguồn và chọn lại Asahi, thao tác này sẽ xóa lỗi), nhưng phiên bản m1n1 mới sẽ khắc phục hoàn toàn sự cố này, vì vậy chúng tôi khuyên bạn nên nâng cấp. Chỉ cần chạy trình cài đặt như bình thường (_______23) từ macOS hoặc recoveryOS và chọn tùy chọn khi được nhắc. Nếu bạn chạy nó từ recoveryOS được ghép nối với bản cài đặt Asahi của bạn (nghĩa là giữ nút nguồn trong khi Asahi là hệ điều hành khởi động mặc định và chọn Tùy chọn), nó thậm chí sẽ tránh được bước khởi động lại bắt buộc thông thường

Cuối cùng, có một tính năng thử nghiệm mới chỉ dành cho chuyên gia để cài đặt m1n1 (chỉ ở chế độ proxy) vào ổ USB ngoài. Như chúng tôi đã nhiều lần nói máy Apple Silicon không hỗ trợ USB boot. Tuy nhiên, Apple làm giả điều này bằng cách sao chép các tệp khởi động hệ điều hành (nhân, bộ tải khởi động, chương trình cơ sở) từ ổ USB vào một phân vùng dành riêng trên bộ lưu trữ NVMe nội bộ. Trình cài đặt hiện có thể tận dụng cơ chế này ngay cả với tư cách là HĐH của bên thứ ba và thực hiện cài đặt m1n1 “hoàn toàn bằng USB” mà không yêu cầu phân vùng lại bộ nhớ trong. Nếu bạn quyết định thử điều này, bạn có thể rút ổ USB sau khi cài đặt hoàn tất và thật thú vị là máy sẽ tiếp tục khởi động nguội vào m1n1 cho đến khi bạn chọn một hệ điều hành khởi động khác từ bộ chọn khởi động (chúng tôi đã nói với bạn, thứ khởi động bằng USB . ). Một ổ USB như vậy không tự động di động sang các máy Mac khác, nhưng về lý thuyết, việc sử dụng tùy chọn “cài đặt sửa chữa” của trình cài đặt sẽ cho phép bạn tạo một ổ USB m1n1 nước ngoài có khả năng khởi động trên máy Mac mới, mặc dù chúng tôi chưa thử nghiệm nó và ở đó

Thật không may, vì m1n1 giai đoạn 1 không có hỗ trợ máy chủ lưu trữ USB, điều này sẽ không giúp chúng tôi cài đặt Asahi Linux “hoàn toàn bên ngoài” thực sự… có ai muốn bắt đầu làm việc trên ngăn xếp Rust USB và trình điều khiển bộ điều khiển máy chủ xHCI không?

phần kết

Như thường lệ, đối với những người dùng hiện tại, bạn có thể nhận được tất cả các tính năng mới chỉ bằng cách nâng cấp hệ thống của mình với tipd5 và sau đó khởi động lại. Điều này xử lý việc di chuyển sang cơ chế phần sụn mới và mọi thứ khác. Chúng tôi muốn giữ mọi thứ đơn giản cho mọi người. Lần này, chúng tôi cũng khuyên bạn nên chạy tipd6 để đảm bảo bộ tải khởi động GRUB của bạn được cập nhật (đây không phải là một phần của nâng cấp gói thông thường) và lưu ý bản cập nhật m1n1 giai đoạn 1 tùy chọn nhưng được đề xuất đã nói ở trên

Đây có lẽ là thời điểm tốt để nhắc nhở mọi người vui lòng cập nhật các bản cài đặt Linux của bạn. Ở giai đoạn đầu của macOS Ventura betas, chúng tôi đã phát hiện ra một sự cố khiến Linux không thể khởi động được sau khi nâng cấp. Chúng tôi đã sửa lỗi này từ nhiều tháng trước trong một bản cập nhật gói, nhưng chúng tôi vẫn khiến người dùng nâng cấp lên Ventura ngày hôm nay (hoặc thậm chí là 12 phiên bản mới nhất). x macOS, hiện cũng gặp vấn đề tương tự) và kết thúc với các bản cài đặt Linux không thể khởi động vì chúng chưa bao giờ nâng cấp vào thời điểm đó. Mặc dù các loại sự cố khiến bản nâng cấp macOS làm hỏng Linux nghiêm trọng như thế này hiếm khi xảy ra (ngày càng tăng theo thời gian) và chúng tôi thử nghiệm các bản beta để phát hiện sớm, chúng tôi dựa vào việc người dùng luôn cập nhật hệ điều hành của họ để tránh sự cố. Vui lòng cập nhật. Các bản cập nhật Arch Linux có thể trở nên khá khủng khiếp nếu bạn không thực hiện một bản nào trong một thời gian dài, vì vậy đó càng là lý do để làm như vậy

Ồ, à, đúng rồi, GPU. Đúng. Làm sao chúng ta có thể quên. Này Lina? . Không bào chữa