Sau nhiều tháng đã trôi qua và hỗ trợ Apple M1/M2 Linux đã tiếp tục phát triển ngược dòng cũng như có nhiều công việc hơn đối với cây Asahi Linux, đây là một cái nhìn mới về hiệu suất của M2 hiện tại so với ban đầu khi bắt đầu Show Kể từ tháng 8, Asahi Linux đã hoạt động trên chức năng USB3, tiếp tục phát triển về âm thanh -- hỗ trợ loa an toàn và hỗ trợ giắc cắm tai nghe hoạt động, tiến độ đèn nền, quản lý nguồn, v.v. Ngoài ra, đã có rất nhiều công việc liên quan đến hỗ trợ trình điều khiển đồ họa Apple Silicon đang được phát triển, bao gồm trình điều khiển nhân DRM được viết bằng Rust, trình điều khiển AGX Gallium3D đang được phát triển và mã Vulkan thử nghiệm. Kể từ lần thử nghiệm đầu tiên vào tháng 8 của Asahi Linux trên Apple M2 MacBook Air, bản phân phối Asahi Linux dựa trên Arch Linux mang tất cả các bản vá lỗi mới nhất đã chuyển từ Linux 5 sang Linux 6, và các nỗ lực viết trình điều khiển và kỹ thuật đảo ngược cho Linux trên cả hai . 19 Git, KDE Plasma 5 và Linux 6. 25 đến 5, 26 và Mesa2 và nhiều bản cập nhật gói khác, từ Mesa 1 đến Mesa 22, LLVM Clang 14 cộng với GCC 12. 1Hiện tại, 0. 6 vẫn là trình biên dịch mặc định của Asahi Linux, nhưng việc chuyển sang phiên bản Linux 6 mới nhất sẽ thú vị hơn để so sánh hiệu suất. 1 trạng thái kernel và các bản vá kernel khác mà Asahi đang mang Tôi đã chạy một số điểm chuẩn mới trên MacBook Air với Apple M2, RAM 8GB và SSD Apple NVMe 256GB để so sánh trạng thái ban đầu được điểm chuẩn vào tháng 8 với Asahi. Đây là câu trả lời cho câu hỏi của độc giả Phoronix Premium hỏi về hiệu suất đã thay đổi như thế nào đối với M2 Quay trở lại vào mùa hè khi Asahi Linux giới thiệu hỗ trợ SoC Apple M2 ban đầu, tôi đã chạy nhiều điểm chuẩn của Apple M2 Linux, bao gồm cả việc xem M2 cạnh tranh như thế nào với bộ xử lý máy tính xách tay AMD và Intel. Sau nhiều tháng đã trôi qua kể từ đó và sự hỗ trợ của Apple M1/M2 Linux đã tiếp tục phát triển ngược dòng cũng như có nhiều công việc hơn đối với cây Asahi Linux, đây là một cái nhìn mới về hiệu suất của M2 hiện tại so với ban đầu tại Kể từ tháng 8, Asahi Linux đã hoạt động trên chức năng USB3, tiếp tục phát triển về âm thanh -- hỗ trợ loa an toàn và cũng hỗ trợ giắc cắm tai nghe hoạt động, tiến độ đèn nền, quản lý nguồn, v.v. Vẫn còn rất nhiều việc phải làm để hỗ trợ trình điều khiển đồ họa Apple Silicon đang phát triển cả với trình điều khiển nhân DRM do Rust viết và trình điều khiển AGX Gallium3D đang được phát triển và mã Vulkan thử nghiệm Các nỗ lực viết trình điều khiển và kỹ thuật đảo ngược cho Linux trên cả Apple M1 và M2 vẫn rất tích cực. Kể từ lần thử nghiệm đầu tiên vào tháng 8 của Asahi Linux trên Apple M2 MacBook Air, bản phân phối Asahi Linux dựa trên Arch Linux mang theo tất cả các bản vá lỗi mới nhất đã chuyển từ Linux 5. 19 Git cho Linux 6. 1 Git, KDE Plasma 5. 25 đến 5. 26, Mesa 22. 1 đến Mesa 22. 2 và nhiều bản cập nhật gói khác. GCC 12. 1 + LLVM Clang 14. 0. 6 vẫn là trình biên dịch mặc định trên Asahi Linux hiện tại trong khi để so sánh hiệu suất, khía cạnh thú vị nhất là việc chuyển sang Linux 6 mới nhất. 1 kernel state và các bản vá kernel khác nhau do Asahi thực hiện Sau khi một độc giả của Phoronix Premium hỏi về hiệu suất đã thay đổi như thế nào đối với M2, trên MacBook Air với Apple M2, RAM 8GB và SSD Apple NVMe 256GB, tôi đã chạy một số điểm chuẩn mới so sánh trạng thái ban đầu được điểm chuẩn vào tháng 8 với Asahi
Chào mừng bạn đến với một báo cáo tiến độ quá hạn dài khác. Như thường lệ, mọi thứ bận rộn hơn dự kiến… và chúng tôi có một số tin tức lớn. Chúng tôi vừa phát hành bản cập nhật Asahi Linux mới với hỗ trợ Mac Studio, Bluetooth và M2 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 Mac Studio gia nhập gia đìnhKhi Mac Studio được công bố, chúng tôi bắt đầu làm việc để M1 Ultra mới hoạt động với Asahi Linux. Điều này không khó, nhưng nó cần một số thay đổi đối với bộ tải khởi động và cây thiết bị của chúng tôi để xử lý ý tưởng về một SoC có nhiều khuôn. Điều này cuối cùng đã được triển khai cùng với những thay đổi khác, vì vậy cuối cùng chúng tôi đã chờ đợi lâu hơn một chút so với dự kiến để phát hành nó, nhưng cuối cùng thì nó cũng đã xuất hiện Bạn có thể mong đợi hầu hết phần cứng hoạt động như bạn mong muốn (ngang với Mac Mini), ngoại trừ các cổng USB phía trước trên kiểu máy M1 Max và các cổng Loại A trên tất cả các kiểu máy (các cổng này bị chặn trên chương trình cơ sở đặc biệt Một Bluetooth hoang dã xuất hiệnBluetooth đã bị lãng quên một thời gian, kể từ khi Apple chuyển sang giao diện PCIe riêng biệt mới mà dường như không có nhà cung cấp nào khác sử dụng. Nhưng tất cả đã thay đổi khi R nhận thách thức về kỹ thuật đảo ngược nó. Rất may, bản thân Bluetooth khá đơn giản, vì giao diện máy chủ đến bộ điều khiển phần lớn được chuẩn hóa. Apple đã tạo ra một biến thể chạy trên PCIe, nhưng các lớp cao hơn giống như bất kỳ bộ điều khiển Bluetooth nào khác. Sau khi R tập hợp một trình điều khiển bằng chứng về khái niệm không gian người dùng, Sven đã tiếp tục công việc và bắt đầu viết một trình điều khiển nhân phù hợp. Kể từ vài ngày trước, Bluetooth đã bắt đầu hoạt động Chúng tôi đã quyết định thực hiện và gửi trình điều khiển này thẳng tới người dùng alpha và hiện tại trình điều khiển này đã có sẵn trong các gói hỗ trợ và hạt nhân mới nhất của chúng tôi. Rất may, mặc dù phương tiện truyền tải PCIe là mới, nhưng giao diện HCI chạy trên cùng là tiêu chuẩn, do đó, khi phần khởi tạo lõi và truyền dữ liệu của trình điều khiển bắt đầu hoạt động, hầu hết các tính năng Bluetooth cũng vậy. Trình điều khiển không cần quan tâm đến bất kỳ chi tiết nào trong số đó, nó chỉ xáo trộn dữ liệu đến/từ thiết bị. Tuy nhiên, có một lưu ý. Tính năng cùng tồn tại WiFi/Bluetooth chưa được định cấu hình đúng, vì vậy bạn sẽ có hiệu suất Bluetooth kém nếu được kết nối với 2. Mạng Wi-Fi 4GHz. Chúng tôi khuyên bạn nên tắt WiFi hoặc sử dụng mạng 5GHz nếu bạn muốn sử dụng Bluetooth vào lúc này; Ngoài trình điều khiển, hỗ trợ Bluetooth là thử nghiệm lớn đầu tiên của mô hình “nâng cấp liền mạch” mà chúng tôi đang hướng tới. Mặc dù Asahi Linux vẫn là một dự án thử nghiệm, nhưng chúng tôi biết rằng chúng tôi không muốn buộc người dùng phải thực hiện các bước thủ công gian khổ để những thứ mới hoạt động. Việc bật Bluetooth liên quan đến rất nhiều thay đổi nhỏ đối với các phần khác nhau của ngăn xếp
Chúng tôi biết điều này sẽ xảy ra ngay từ đầu, vì vậy chúng tôi đã thiết kế bản phân phối tham chiếu của mình để hỗ trợ thực hiện tất cả những điều đó một cách tự động
Kết quả cuối cùng là người dùng bản phân phối tham chiếu hiện tại có thể chỉ cần nâng cấp các gói của họ, khởi động lại và Bluetooth sẽ hoạt động mà không cần bất kỳ cấu hình hoặc thay đổi nào khác. M2 ở đâyKể từ khi Asahi Linux ra đời, một trong những câu hỏi phổ biến nhất mà chúng tôi nhận được là “Còn M2 thì sao?” . Điều này ảnh hưởng như thế nào đến dự án Asahi Linux? . Chúng ta đã làm như thế nào? Chỉ sau một cuộc chạy marathon kéo dài 12 giờ, Linux đã khởi động trên M2 bằng USB, NVMe, thống kê/kiểm soát pin, tần số CPU, WiFi, v.v. Với một vài ngày làm việc nữa, chúng tôi đã có thể làm cho bàn phím/bàn di chuột hoạt động, đưa tính năng này ngang bằng với các hệ thống hiện có. Sau một số công việc tích hợp nữa, chúng tôi tự hào công bố hỗ trợ thử nghiệm cho các máy M2 trong trình cài đặt Asahi Linux Nếu bạn quyết định thử điều này trên máy M2 của mình, hãy ghi nhớ những lưu ý này
thủ thuật bàn di chuộtHãy xem điều gì đã xảy ra với bàn di chuột, vì đó là một câu chuyện thú vị. Apple MacBook trước đây có thiết kế thú vị cho các thành phần bàn phím/bàn di chuột. Mặc dù trên hầu hết các máy tính xách tay x86, chúng được gắn bên trong qua PS/2 (có thể là ảo) hoặc đôi khi là USB, Apple đã bắt đầu với USB và sau đó chuyển sang SPI. SPI là một giao thức đơn giản hơn USB, có thể tiết kiệm năng lượng cho một thiết bị ngoại vi băng thông thấp như thế này, luôn sẵn sàng đáp ứng đầu vào của người dùng. Ngay cả những chiếc MacBook Intel mới nhất (trước T2) cũng đã sử dụng SPI và thiết kế này đã được chuyển sang M1 (chúng tôi sẽ bỏ qua các máy T2 vì chúng là trường hợp đặc biệt ở đây) Apple cũng sử dụng một kiến trúc hoàn toàn khác cho bàn phím/bàn di chuột thực tế của họ. Trên nhiều máy x86, bàn phím được điều khiển bởi Bộ điều khiển nhúng, một con chip chuyên dụng trên bo mạch chủ cũng dùng để điều khiển một số tính năng quản lý hệ thống khác. Bàn di chuột thường độc lập. Ngược lại, các máy của Apple có bàn di chuột chịu trách nhiệm điều khiển bàn phím - giống như trên các máy x86, bàn phím là một ma trận công tắc thụ động, nhưng thay vì kết nối trực tiếp với bo mạch chủ, nó sẽ kết nối với bàn di chuột. Bản thân trackpad cũng khá khác thường nhờ công nghệ Force Touch của Apple. Hầu hết các máy tính xách tay khác sử dụng chip trackpad chuyên dụng của Synaptics, nhưng thay vào đó, Apple sử dụng BCM5976 của Broadcom - bộ điều khiển màn hình cảm ứng có lõi ARM nhúng, giống như thứ bạn tìm thấy trên iPhone - và ghép nối nó với bộ vi điều khiển STM32 Cortex-M3. STM32 (chạy chương trình cơ sở RTKit) chịu trách nhiệm xử lý bàn phím và các phần Force Touch của thiết kế, đồng thời đóng vai trò là giao diện người dùng cho BCM5976 kết hợp tất cả dữ liệu và triển khai một phần thuật toán giúp bàn di chuột của Apple hoạt động . Cùng với nhau, những con chip đó có khá nhiều phần sụn thông minh Sau đó, M2 xuất hiện và… giao diện SPI biến mất. Chà, không hoàn toàn biến mất… nhưng hệ điều hành không thấy nó nữa. Thay vào đó, M2 hiện có một bí mật nhỏ khác, MTP. Có… Apple đã chuyển bộ điều khiển trackpad vào SoC chính Được rồi, không chính xác. BCM5976 và STM32 vẫn còn đó, nhưng cả hai phần sụn đã bị thu hẹp đáng kể. Những con chip đó không còn chịu trách nhiệm về bất kỳ thuật toán cảm ứng đa điểm hay logic nào nữa; . M2 hiện có một bộ đồng xử lý chuyên dụng (có thể là một phiên bản ARM64 Chinook khác, chạy RTKit như thường lệ), chịu trách nhiệm xử lý phần lớn Tại sao Apple sẽ làm điều này? . Đầu tiên, bằng cách tích hợp phần sụn vào M2, điều này giúp họ linh hoạt hơn nhiều trong việc cập nhật phần sụn. Phần sụn này hiện có thể là một phần của gói mỗi hệ điều hành, có nghĩa là họ có thể giới thiệu các tính năng mới và thực hiện các thay đổi mà không gặp rủi ro về khả năng tương thích ngược với các phiên bản macOS cũ hơn. Điều đó cũng có nghĩa là quy trình nâng cấp chương trình cơ sở được tích hợp tự động với các bản nâng cấp macOS và mạnh mẽ hơn nhiều. Và tất nhiên, nó có thể cho phép họ sử dụng biến thể STM32 nhỏ hơn và tiết kiệm một số tiền Với MTP, Apple đã xử lý các giao tiếp với HĐH chính theo một cách thú vị. Mặc dù hầu hết các bộ đồng xử lý sử dụng giao diện hộp thư/RTKit chính và bộ nhớ dùng chung cho việc này, nhưng có vẻ như Apple muốn giữ mô hình “byte vào, byte ra” của giao diện SPI, vì vậy, thay vào đó, họ đã sử dụng… DockChannel. Bạn hỏi DockChannel là cái quái gì vậy? . Chip M1 đã triển khai DockChannel gỡ lỗi có thể được sử dụng làm cổng nối tiếp ảo, có thể truy cập được bằng trình gỡ lỗi nội bộ của Apple kết nối với cổng Loại C cụ thể trên các máy Mac này (mặc dù chúng tôi chưa biết giao thức này hoạt động như thế nào trên phía USB . MTP đã sử dụng lại cùng một mô-đun FIFO như một kênh byte đơn giản giữa nó và HĐH chính, với một giao thức vận chuyển HID mới chạy trên nó Tin vui là bản thân DockChannel rất đơn giản nên việc đưa nó lên không mất nhiều thời gian. Tin xấu là Apple đã quá phức tạp hóa quá trình vận chuyển HID mới (như họ vẫn làm), do đó, trình điều khiển mới có hơn 1000 dòng mã và phải xử lý những việc như tải lên chương trình cơ sở, ủy quyền GPIO và nhiều cấu trúc dữ liệu lồng nhau phức tạp. Chúng tôi cũng chưa tìm ra cách đặt lại MTP và đưa nó trở lại trạng thái khởi động mới, vì vậy chúng tôi chưa thể hỗ trợ chuyển giao giữa trình điều khiển U-Boot và Linux hoặc gỡ bỏ/thăm dò lại thiết bị trên Linux Để khiến mọi thứ trở nên đáng nguyền rủa hơn, hóa ra phần sụn cho BCM5976 được tải khi khởi động từ máy chủ. macOS lưu trữ nó dưới dạng một XML plist của tất cả mọi thứ (với các tính năng mà trình phân tích cú pháp Python XML plist không hỗ trợ) được gói trong một asn. 1 img4 và trình điều khiển cần chuyển đổi nó thành cấu trúc tuần tự hóa nhị phân (ở định dạng tuần tự hóa khác…) trước khi chuyển giao nó cho MTP trong quá trình khởi tạo, cũng như vá lỗi trong trường bInterfaceNumber với số giao diện chính xác. Không cần phải nói, chúng tôi không đặt trình phân tích cú pháp XML trong nhân Linux, vì vậy, thay vào đó, trình cài đặt Asahi Linux hiện có một mô-đun chịu trách nhiệm chuyển đổi nó sang định dạng nhị phân. Có một tiêu đề nhỏ chứa phần bù bInterfaceNumber, vì vậy Linux có thể thay đổi nó trước khi chuyển giao nó cho MTP. Phù cuộc phiêu lưu mạo hiểmSau macOS 13. 0 Ventura beta đã được phát hành, chúng tôi đã nhận được báo cáo rằng nó đã phá vỡ các bản cài đặt Asahi Linux. Từ lâu, chúng tôi đã khẳng định rằng các bản nâng cấp macOS sẽ không làm hỏng Asahi, vì hầu hết các phần sụn đều được liên kết với một HĐH (vì vậy việc nâng cấp macOS sẽ không ảnh hưởng đến Asahi). Vậy chuyện gì đã xảy ra? Mặc dù hầu hết phần sụn được gắn với hệ điều hành, nhưng có một tập hợp con nhỏ Phần sụn hệ thống được chia sẻ bởi tất cả các hệ điều hành. Điều này bao gồm phần sụn NVMe (vì lý do rõ ràng), nhưng cũng có phần sụn SMC và một số thứ liên quan đến Thunderbolt. Tuy nhiên, để duy trì khả năng tương thích với các phiên bản macOS cũ hơn, về cơ bản, Apple cam kết sẽ không bao giờ phá vỡ khả năng tương thích ngược với phần sụn cũ hơn, vì vậy chúng tôi sẽ an toàn Và chúng tôi đã… nếu không có lỗi. Thật vậy, trình điều khiển NVMe của m1n1 không gặp vấn đề gì với chương trình cơ sở được cập nhật và hoạt động ngay lập tức. Tuy nhiên, U-Boot không may mắn như vậy. Phiên bản đó đã sử dụng Phím tắt thông minh™ và hóa ra phần sụn mới không hài lòng lắm với thủ thuật nhỏ của chúng tôi. Trong khi đó, trình điều khiển Linux SMC có một lỗi hoàn toàn không được chú ý với phần sụn cũ, nhưng lại khiến phần sụn SMC mới gặp sự cố Chúng tôi hiện đã đẩy các gói linux-asahi, u-boot và m1n1 được cập nhật, vì vậy nếu bạn muốn dùng thử các bản beta mới, trước tiên hãy đảm bảo bạn thực hiện nâng cấp pacman. Nếu bạn đã nâng cấp lên bản beta và bị kẹt với hệ thống Asahi không thể khởi động, hãy làm theo các bước để khôi phục Xin lưu ý rằng những vấn đề này là do lỗi hoặc sơ suất trong mã của chúng tôi, không phải do Apple vi phạm tính tương thích và chúng tôi hy vọng những vấn đề này sẽ ngày càng ít phổ biến hơn theo thời gian. Nói chung, việc cập nhật máy Mac đã cài đặt Asahi luôn phải an toàn, đừng để lỗi cắn. -) DCP, xin vui lòngMac Mini (và giờ là Mac Studio) từ lâu đã gặp sự cố về độ tin cậy với đầu ra HDMI và một số màn hình nhất định trong quá trình khởi động. Apple đã từng thực sự khởi tạo màn hình trước khi hệ điều hành hoạt động, nhưng họ đã từ bỏ việc đó hoàn toàn với macOS 12. 0 (trên máy tính để bàn). Tuy nhiên, vì chúng tôi chưa gửi trình điều khiển bộ điều khiển hiển thị phù hợp với Asahi Linux và vì chúng tôi cần có khả năng hiển thị màn hình khởi động m1n1, U-Boot và grub, nên chúng tôi cần khởi tạo màn hình trong m1n1 để thiết lập . Điều này hoạt động tốt, nhưng vấn đề là không có trình điều khiển màn hình đang chạy tích cực trong suốt quá trình khởi động, bất kỳ sự kiện cắm nóng nào cũng sẽ khiến màn hình bị mất, vì DCP (Bộ xử lý Bộ điều khiển Hiển thị) sẽ tắt nó trong khi chờ lệnh thiết lập chế độ mới. Thật không may, có vẻ như một nhóm nhỏ màn hình có hành vi bị hỏng một cách kỳ lạ, khi thức dậy từ chế độ chờ, chúng hầu như sẽ ngắt kết nối đầu vào vài giây sau đó, sau đó kết nối lại. m1n1 sẽ khởi tạo màn hình, tiếp tục, màn hình sẽ kích hoạt sự kiện cắm nóng giả và DCP sẽ tắt tín hiệu Và vì Asahi Linux chưa gửi trình điều khiển DCP thích hợp trong nhân, điều này có nghĩa là màn hình bị hỏng hoàn toàn (điều này sẽ sớm được khắc phục, nhưng chúng tôi vẫn muốn đồ họa bộ nạp khởi động hoạt động…). Đã có một số bản vá thử nghiệm để giải quyết vấn đề này bằng cách đưa ra độ trễ khởi động dài để màn hình ổn định hoàn toàn trước khi tiếp tục, nhưng đó là một giải pháp không hoàn hảo và chúng tôi không thích ý tưởng trì hoãn khởi động cho mọi người hoặc buộc người dùng phải quyết định liệu họ có Tôi đã cố gắng tìm một số giải pháp cho vấn đề này, có lẽ là một lệnh DCP để ngăn nó phản ứng với các sự kiện cắm nóng, nhưng tôi đã cạn kiệt. Và sau đó tôi đã có một ý tưởng. Chúng ta có thể… tắt DCP không? . Có cảm giác như DCP phải duy trì và để nó ngừng hoạt động hoàn toàn sẽ phá vỡ mọi thứ. Tuy nhiên, kể từ đó, chúng tôi đã nâng cao hiểu biết của mình về cách thức hoạt động của các chế độ nguồn RTKit, cách tắt chính xác bộ đồng xử lý và cách khiến chúng hoạt động trở lại sau khi tắt nguồn hoàn toàn (mà chúng tôi sử dụng với e. g. NVMe). Vì vậy, tôi đã thử quy trình tắt máy hoàn toàn mới, được biết là tốt… và nó đã hoạt động. Khi DCP ngừng hoạt động, sẽ không có ai phản ứng với sự kiện cắm nóng màn hình. Tín hiệu HDMI cứ loanh quanh, không biết màn hình đang làm gì. Và vì quá trình tắt DCP diễn ra theo cách được kiểm soát, nên Linux có thể khôi phục nó mà không gặp bất kỳ sự cố nào đối với trình điều khiển thực, khi có sẵn Vẫn còn một cuộc đua nhỏ (nếu cắm nóng màn hình giữa thời điểm m1n1 đặt chế độ màn hình và khi tắt DCP), nhưng đó là một cửa sổ nhỏ. Trên thực tế, phương pháp mới này đã loại bỏ các sự cố hiển thị cho mọi người bị ảnh hưởng, theo như chúng tôi biết. Bản cập nhật này cũng giúp bạn có thể rút phích cắm hoặc tắt nguồn màn hình của mình khi đang sử dụng Linux mà không bị mất tín hiệu vào lần tiếp theo khi bạn bật lại màn hình. Chỉ cần cập nhật hệ thống của bạn để nhận m1n1 mới Trong khi chúng ta đang nói về DCP, các thiết bị của Apple gần đây đã trở thành mục tiêu của một phần mềm độc hại nâng cao đã sử dụng DCP để xâm phạm hệ thống. Khi chúng tôi phát triển trình điều khiển Asahi Linux DCP (vẫn chưa vận chuyển), chúng tôi đã coi DCP là có khả năng bị xâm phạm và thù địch; . Hãy yên tâm, lỗ hổng này không ảnh hưởng đến Asahi Linux, mặc dù chúng tôi sử dụng cùng một chương trình cơ sở DCP dễ bị tổn thương như macOS/iOS chuyển hướng phi tiêuM1 Pro và M1 Max/Ultra cũng giới thiệu một biến thể phần cứng DART (IOMMU) mới, chúng sử dụng cho các cổng Thunderbolt và một số phần cứng liên quan đến codec phương tiện. R đã thiết kế ngược cái này rồi, nhưng vẫn chưa có trình điều khiển phù hợp. Hóa ra M2 sử dụng biến thể IOMMU này xuyên suốt, vì vậy chúng tôi đã thêm hỗ trợ m1n1 và Linux cho nó trong quá trình phát triển M2. Điều này sẽ không tự làm cho bất kỳ thứ gì mới hoạt động trên M1 Pro/Max, nhưng nó là một yêu cầu đối với Thunderbolt và phần cứng phương tiện, vì vậy đó là một hộp nữa được đánh dấu Về cùng một chủ đề, Jannau đã gửi một bộ bản vá để thêm hỗ trợ cho biến thể DART khác trong Pro/Max ngược dòng, tách mã bảng phân trang IOMMU thành một tệp dành riêng cho Apple DART. Từ lâu, chúng tôi đã hỗ trợ các chip này trong ngã ba Asahi, nhưng việc ngược dòng đã bị chặn do những người bảo trì ngược dòng không hoàn toàn hài lòng với việc thêm các quy tắc bảng trang dành riêng cho Apple vào mã bảng trang ARM IOMMU. Chúng tôi hy vọng rằng bằng cách di chuyển tệp này sang một tệp riêng biệt, chúng tôi có thể bỏ chặn quy trình và cuối cùng nhận được hỗ trợ M1 Pro/Max ngược dòng (ít nhất là đủ để khởi động trên chip, như Linux ngược dòng đã làm trên M1; vẫn còn các trình điều khiển khác Bản cập nhật U-BootHỗ trợ U-Boot cũng đang tiến triển tốt. U Boot 2022. 07 vừa được phát hành với (gần như) hỗ trợ đầy đủ cho các mẫu M1 (bao gồm cả M1 Pro/Max/Ultra) và (nhờ Janne Grunau) hỗ trợ cơ bản cho M2. Phần quan trọng nhất vẫn còn thiếu là hỗ trợ cho bộ điều khiển PCIe USB3 đằng sau các cổng loại A trên Mac mini Hơn cả LinuxMởBSD 7. 1 được phát hành vào ngày 21 tháng 4 năm 2022, với sự hỗ trợ cho M1 và M1 Pro/Max/Ultra. Điều này bao gồm hỗ trợ cho NVMe, USB (USB 2. 0 chỉ trên các cổng loại C), WiFi, Ethernet (trên M1 mini và iMac) và Bàn phím và bàn di chuột (trên máy tính xách tay). X11 hoạt động trên bộ đệm khung ban đầu và hỗ trợ âm thanh đang được thực hiện. OpenBSD chưa hỗ trợ các mẫu M2 mới, nhưng đây là trên radar cho OpenBSD 7. 2 dự kiến ra mắt vào tháng 11 OpenBSD phụ thuộc vào trình cài đặt Asahi, trình cài đặt này cung cấp tùy chọn chỉ cài đặt m1n1 với U-Boot dưới dạng tải trọng. Điều đó cung cấp cho bạn môi trường khởi động UEFI tiêu chuẩn, giống như trên các phần cứng khác được hỗ trợ bởi OpenBSD/arm64. Tại thời điểm đó, bạn chỉ cần viết minirootXX. img hoặc installXX. img vào ổ USB, cắm nó vào máy Mac của bạn và khởi động vào trình cài đặt OpenBSD Trình cài đặt OpenBSD biết về các phân vùng kỳ diệu của Apple, vì vậy ngay cả khi bạn chọn tùy chọn đĩa lỗ (W) mặc định trong trình cài đặt, các phân vùng hệ thống sẽ tồn tại và quá trình cài đặt macOS của bạn sẽ an toàn. Trình cài đặt OpenBSD cũng tự động chọn phần sụn WiFi (từ phân vùng hệ thống EFI, nơi trình cài đặt Asahi chuẩn bị nó), vì vậy WiFi khả dụng trong khi cài đặt Một điều nữa…Tôi biết tất cả các bạn đang nghĩ gì… còn GPU thì sao?
Tin tốt. Một vài tháng trước, Asahi Lina đã tham gia nhóm của chúng tôi và đảm nhận thử thách thiết kế ngược giao diện phần cứng GPU M1 và viết trình điều khiển cho nó. Trong thời gian ngắn này, cô ấy đã xây dựng một trình điều khiển nguyên mẫu đủ tốt để chạy các ứng dụng đồ họa và điểm chuẩn thực tế, dựa trên công việc Mesa hiện có. Bằng chứng về khái niệm sử dụng m1n1 thông qua kết nối USB và chạy trình điều khiển từ xa, do đó, nó bị tắc nghẽn bởi băng thông USB, nhưng cô ấy cũng đã chứng minh rằng GPU hiển thị đúng cảnh chú thỏ bóng mờ phong cách GLMark2 ở hơn 1000FPS, ở độ phân giải 1080p. Ngăn xếp nguồn mở hoàn toàn này vượt qua 94% bộ thử nghiệm dEQP-GLES2. Không tệ Nhưng câu chuyện đó chắc chắn xứng đáng có bài viết riêng, vì vậy chúng tôi sẽ giới thiệu một bài đăng của khách mời Lina kể cho chúng tôi toàn bộ câu chuyện về trình điều khiển GPU trong tương lai gần. Giữ nguyên. Trong thời gian chờ đợi, bạn có thể theo dõi công việc của cô ấy trên YouTube nếu bạn quan tâm |
