Bár a projekt vezető fejlesztője néhány hónapja visszavonult az aktív munkától, az Asahi Linux fejlesztése továbbra is határozottan halad előre. A legfrissebb fejlesztői jelentés szerint a Linux kernel 6.17 számos régóta várt komponenssel bővült, közelebb hozva a teljes értékű Linux-támogatást az Apple Silicon processzorokon. Az új SMC (System Management Controller) illesztőprogram, a DART IOMMU kiterjesztett támogatása, a Rust nyelv bevezetése az m1n1 komponenseiben, valamint a Fedora Asahi Remix fejlesztései mind mérföldkőnek számítanak ebben a hosszú távú, upstream-orientált projektben.

Az SMC illesztőprogram és új kernelkomponensek az Apple M-sorozathoz

Több évnyi egyeztetés után végre beolvasztották a fővonalas Linux kernelbe az SMC (System Management Controller) alapmeghajtót, valamint a GPIO és újraindítási vezérlőkhöz tartozó illesztőprogramokat. Ez a fejlesztés lehetővé teszi az Apple Silicon-alapú gépek számára, hogy tiszta újraindítást hajtsanak végre upstream kernelek alatt – ez fontos előfeltétele a Wi-Fi és Bluetooth meghajtók jövőbeli integrációjának.

A Linux 6.17 továbbá tartalmazza az új Device Tree-definíciókat, amelyek kulcsfontosságúak a GPU-meghajtó további fejlesztése szempontjából. Ezzel párhuzamosan a DART IOMMU (Input–Output Memory Management Unit) támogatása kiterjedt az M2 Pro, Max és Ultra chipekre is, a meghajtó immár négy szintű lapozási táblát (four-level page tables) alkalmaz, hogy kezelje az ezekben a rendszerekben elérhető nagyobb címtartományt. Az M2-szériához tartozó teljes Device Tree-csomag már megjelent a Linux 6.18-rc1 előzetesben, ezzel lefektetve az alapot a további SoC-generációkhoz.

Az m1n1 fejlesztése: a Rust nyelv belép a képbe

Az m1n1 (a Linux és az Apple firmware közti híd szerepét betöltő bootloader és hipervizor) fejlesztése szintén jelentős előrelépést mutat. Bevezetésre került egy CI-pipeline, amely automatikusan készíti és frissíti a UEFI-csomagokat, így az Asahi Installer mindig naprakész verziót használhat.

Az új m1n1 1.5.2 verzió már kompatibilis az upstream USB- és GPU Device Tree-sémákkal, és ez az első kiadás, amely részben Rustban íródott. A fejlesztők a biztonság és karbantarthatóság növelése érdekében kezdték el a C nyelvű kódok fokozatos átírását Rustra, elsőként az Apple Device Tree-kezelésnél.
A mérések szerint a teljesítmény nem csökkent, miközben a kód biztonságosabb és stabilabb lett.

tuxvdmtool – új fejlesztői segédprogram Linuxra

Az Asahi csapat korábban macOS alatt használta a macvdmtool segédprogramot az Apple Silicon eszközök újraindítására és a UART kimenet USB-n keresztüli továbbítására. Most ennek Linux-alapú újraírt változata, a tuxvdmtool vált elérhetővé, amely már lehetővé teszi, hogy a fejlesztői gép Linuxot futtató Apple Silicon eszköz is lehessen. Ez a lépés nagyban megkönnyíti az alacsony szintű hibakeresést és a firmware-szintű fejlesztést, még akkor is, ha a rendszer már Linuxot futtat.

Upstream-first: a projekt filozófiája

Az Asahi Linux továbbra is upstream-only megközelítést követ, azaz minden fejlesztést a fővonalas Linux kernelbe és a kapcsolódó nyílt forrású projektekbe integrál. Ez biztosítja a hosszú távú karbantarthatóságot és előnyöket nyújt az egész ökoszisztémának — például a Mesa projektben végzett közös munkák révén, amelyek lehetővé teszik a geometriai (geometry) és tesszellációs (tessellation) shaderek emulációját többféle mobil GPU-n, nemcsak az Apple chipjein.

„poly” – megosztott shader-emuláció minden Mesa driverhez

A jelentés kiemeli a poly nevű új kezdeményezést, amely egységesíti a shader-emulációs réteget a Mesa meghajtók között. Ennek köszönhetően a geometry- és tessellation-shaderek emulációja más platformokon – például ARM és PowerVR GPU-kon – is elérhető lesz. Ez a fejlesztés nemcsak a Vulkan és OpenGL kompatibilitást javítja, hanem a Wine/Proton alatt futtatott játékok grafikai támogatását is bővíti.

Fedora Asahi Remix és az M3 chip első jelei

A Fedora Asahi Remix immár napi buildjei készülnek a Fedora 43 kiadáshoz, és megkezdődött a Fedora 44 integráció is a KDE Plasma Setup kezdeményezés keretében. A fejlesztők szerint a visszajelzések alapján a Fedora Asahi Remix tapasztalatai közvetlenül beépülnek a Plasma Setup alkalmazásba.

Eközben megkezdődött az Apple M3 chipek támogatásának korai szakasza is: az m1n1 már képes elindítani a CPU-magokat és a perifériákat, sőt az Asahi kernel villogó kurzorig képes eljutni – ez még csak kezdet, de ígéretes alap a további fejlesztésekhez.

Az Asahi Linux csapata tehát továbbra is lendületesen halad előre; a Linux 6.17 új illesztőprogramjai, a Rustba írt kódrészek, a tuxvdmtool, valamint a poly shader-projekt mind a projekt hosszú távú célját szolgálják: teljes, stabil és natív Linux-élményt biztosítani az Apple Silicon hardvereken.

További információk a projekt jelentésében. Azaz:

A javítások folyamatosan érkeznek

Ahogy mindig, az upstream munka folytatódik. Ennek a ciklusnak a fő eseménye az SMC (System Management Controller) alapvető driverének végleges beolvasztása, miután a levelezőlistán folytatott viták egészen 2022-ig nyúlnak vissza! Az alapdriver mellett az SMC GPIO vezérlőjének és újraindító vezérlőjének driverei is beolvasztásra kerültek. Ez lehetővé teszi, hogy az upstream-be már bekerült eszközök zavartalanul újrainduljanak, és előkészíti az utat a WiFi és a Bluetooth upstream engedélyezéséhez.

A 6.17-es verzióhoz néhány Devicetree-módosítás is beolvasztásra került, amelyek előkészítik a GPU-támogatás upstreambe kerülését. Bár ezek végső soron csak egy apró részét képezik a GPU összképének, rendkívül fontosak. A Devicetree-séma határozza meg, hogy a GPU kernel driver milyen információkat kap a firmware-től a GPU megfelelő vezérléséhez. Most, hogy ez stabil, és a tulajdonságok beolvasztásra kerültek az upstream Devicetree-ekbe, ésszerűen bízhatunk benne, hogy a GPU drivernek a Devicetree-rel való interakcióját érintő részek nem igényelnek majd jelentős módosításokat.

A munka folyik az SMC további funkcióinak upstreambe kerülésén is. A hardverfigyelés, a fedélkapcsoló és a bekapcsológomb, valamint az RTC driverek mind közel állnak a beolvasztáshoz, csupán néhány apróbb problémát kell még kezelni.

Az Apple Silicon SoC-k perifériáit és IP-blokkjait (például a kijelzővezérlőt) egy DART nevű IOMMU mögé helyezik. Ezek úgy működnek, mint egy tűzfal a perifériák számára, megakadályozva, hogy a memóriacímeket hozzáférjék, amelyeket nem kellene. Az M2 Pro, Max és Ultra (T602x) SoC-k DART-jai nagyrészt kompatibilisek az alap M2-ben találhatókkal, egy kivétellel: nagyobb címteret támogatnak. Ennek támogatása négy szintű lapozótábla megvalósítását igényelte a DART driverben. Ez a változtatás, valamint az összes M2 Pro, Max és Ultra alapú eszköz Devicetree-je most beolvasztásra került, és elérhető a v6.18-rc1-ben!

És természetesen ott vannak az USB-javítások is. Úgy tűnik, szinte mindenki követte ezeket a levelezőlistán, így kihagyni nem lehet. De haladjunk tovább.

m1n1 elkezd Rust-ba kerülni

A kernel ütemének lassítása lehetővé tette, hogy végre más részeire is ránézzünk a stacknek, és fontos (és régóta esedékes) változtatásokat hajtottunk végre az m1n1-en.

Egy ideje a nem-Fedora disztribúciók telepítésére ajánlott módszer az „UEFI Only” telepítőopció használata volt, majd az adott disztribúció Asahi telepítő médiájának USB-ről történő indítása. Azonban már jó ideje nem frissítették ezt a telepítőopciót, és az általa telepített m1n1/U-Boot/Devicetree csomag több mint két éves volt. Sok minden változott azóta, és kiderült, hogy ez a csomag nem volt képes modern Asahi kernelt indítani. Hoppá.

Ennek javítására Janne hozzáadott egy CI pipeline-t az m1n1 repóhoz, amely automatikusan elkészíti az UEFI csomagot. Ezzel a lépéssel most már trivális feltölteni az elkészült artefaktumot a CDN-re, és az Asahi Installer erre mutathat. A frissítési ütem most már sokkal gyakrabban lesz, nem kétévente!

Ugyancsak kiadtuk az m1n1 v1.5.2-t. Ez a kiadás meglehetősen problémamentes, a fő változások az upstream USB és GPU Devicetree séma kompatibilitásának hozzáadása. Valószínűleg ez lesz az utolsó m1n1 kiadás, amely Rust nélkül is építhető.

Fontosnak tartjuk, hogy egy ilyen kritikus szoftver a lehető legkarbantarthatóbb, legbiztonságosabb és logikailag is helytálló legyen, különösen, mivel a láncolat gyökérbizalmát (root of trust) hivatott megalapozni egy hipotetikus Secure Boot környezetben. Az, hogy az m1n1 bizonyos komponensei C-ben íródtak, azt jelenti, hogy jelenleg egyik célt sem tudjuk teljesíteni.

Ilyen komponens volt az Apple Device Tree kezelő kód. Bár az ADT implicit módon megbízható adat, az eredeti C implementáció eléggé rendezetlen volt. Ez egy megbízhatatlan libfdt-alapú API-t eredményezett, amely sem ergonomikus, sem különösebben alkalmas nem volt az ADT adatok kezelésére.

Egy kis segítséggel a Rust szakértőnktől, chaos_princess-től, képes voltam egy helyes, idiomatikus Rust implementációt és API-t fejleszteni, amelyet visszakötöttem a meglévő C API-hoz, hogy az összes C kódunk használni tudja. Egy hibajavító kör után azt tapasztaltuk, hogy nincs sebességkülönbség a régi és az új implementáció között, még az FFI overheadjével együtt sem!

Nincs tervünk arra, hogy az egész m1n1-et Rust-ba portoljuk. A boot lánc biztonságkritikus komponensei az elsődleges fókuszunk, ezt követik azok a részek, amelyek közvetlenül profitálhatnak a C API-k átdolgozásából. Talán egy napon lesz teljesen Rust-alapú m1n1, de ha igen, az organikusan, idővel fog történni.

WoW!

Legutóbb bemutattunk 64-bites Windows alkalmazásokat WINE alatt, muvm-en kívül. Igaz, a Notepad++ nem egy különösen izgalmas példa, de fontosnak tartjuk az átláthatóságot és a reális elvárások felállítását. Most pedig itt vannak a Hollow Knight és a NieR:Automata 64-bites Windows játékok, WINE alatt, muvm-en kívül.

Hollow Knight (2017) fut muvm-en kívül M1 Pro MacBook Pro-n, Gentoo-val
NieR:Automata (2017) fut muvm-en kívül M1 Pro MacBook Pro-n, Gentoo-val

Külön köszönet chaos_princess-nek: az eszközkészlet változtatások, amelyekre legutóbb vártunk, most már integrálva vannak a Gentoo-ba, és a szükséges FEX DLL-ek automatikusan felépülnek a WINE telepítésekor.

A teljesítmény azonban 32-bites alkalmazásokhoz képest is jelentősen eltérhet. A WINE támogatása ARM64X és ARM64EC (Microsoft ABI és futtatható formátum, amely lehetővé teszi az AArch64 és amd64 kódok együttműködését) esetén még nem teljes, így sok alkalmazás egyszerűen nem működik (még). Természetesen bátorítjuk a kísérletezőket, de támogatást nem tudunk nyújtani ehhez a stackhez. Tekintse mindenki korai alfának, egy ízelítőnek a jobb dolgokból.

Fejlesztők segítése

A projekt kezdetén létrehoztuk a macvdmtool-t, hogy Apple USB-PD Vendor Defined Message-ek segítségével irányíthassunk egy tesztkészüléket. Ezek lehetővé teszik a felhasználó számára, hogy USB-n keresztül újraindítsa a Mac-et, és az SoC elsődleges UART-ját a USB porthoz irányítsa. Ezek nagyon hasznos funkciók az eszköz kezdeti beállításánál. Az újraindítás ezzel a módszerrel még a rendszer lefagyása esetén is működik, az UART hozzáférés pedig lehetővé teszi a boot logok ellenőrzését inicializált kijelző vagy USB stack nélkül. A macvdmtool az IOKit, egy macOS rendszerkönyvtár használatára épít. A macOS használata fejlesztéshez kényelmetlen, de mi lenne, ha Linuxon is meg tudnánk valósítani?

A tuxvdmtool a macvdmtool Linuxra történő újraírása, amelyet a downstream kernelünk USB-C mux chip driverének változtatásai tettek lehetővé. A tuxvdmtool ugyanazokat a funkciókat kínálja, mint a macvdmtool, azzal a kiegészítéssel, hogy a “host” rendszer Apple Silicon eszköz lehet Linux alatt! Ezáltal a fejlesztők hozzáférhetnek egy ismerős, teljes értékű Linux fejlesztői környezethez, ami megkönnyíti az eszköz korai bringup munkáját. Reméljük, hogy a tuxvdmtool több embert ösztönöz az Apple Silicon alacsony szintű bringup kipróbálására.

Bár a kernel patch-ek, amelyek szükségesek a működéshez, nem upstreamelhetők, a tuxvdmtool jövőbeli kiadása át lesz írva a Linux kernel beépített i2c dev interfészére, ami lehetővé teszi a patch-ek teljes elhagyását.

Mindenki segítése

Mindig is igyekeztünk közvetlenül együttműködni az upstream projektek fejlesztőivel Apple Silicon támogatásban, ahol lehetséges. Ez lehetővé teszi, hogy ötleteket vitassunk meg, helyes gyakorlatra vonatkozó tanácsot kapjunk, és sok esetben szélesebb körben is hasznos legyen az ökoszisztéma számára. Bár ez azt jelenti, hogy az upstream kiadási ütemezéséhez kell alkalmazkodnunk, nem kell aggódnunk elavult fork-ok fenntartása, rebase, biztonsági javítások backportolása miatt, vagy egyéb, közvetlenül nem Apple Silicon támogatással kapcsolatos feladatok miatt. Az elmúlt év világosan megmutatta, miért a „upstream-first, de főleg upstream-only” megközelítés a hosszú távon fenntartható út.

De az upstream munka nemcsak a mi hasznunkra van. Néha a munkánk más felhasználók számára is előnyös lehet más platformokon. Jó példák erre a 16K oldalakat támogató gépek helyes működtetése, valamint a PipeWire és WirePlumber fejlesztések, amelyek lehetővé teszik a DSP profilok automatikus alkalmazását minden eszközre.

Előfordul, hogy éppen ezek a felhasználók találják meg a munkánkat, és használják azt saját belátásuk szerint.

A geometriai shader-ek olyan speciális shader-ek, amelyek közvetlenül a poligonokon dolgoznak, nem a csúcsokon. Bár ma már örökölt technikának számít, egyes alkalmazások használják különböző feladatokra, például háromszögek kiszűrésére a jelenetből bizonyos szűrőfeltételek alapján.

Hasonlóképpen a tesszelláció egy grafikus technika, amely lehetővé teszi a GPU számára, hogy programozottan új poligonokkal töltse ki a felületeket. Ezt adaptív LOD, részletgazdag víz és modellek részletességének növelésére használják anélkül, hogy nagy, magas poligon-számú asseteket kellene szállítani.

A modern, nagy teljesítményű GPU-k mindkettőt támogatják dedikált hardverrel, de ez mérnöki erőfeszítést és helyet igényel a tervezett energia- és die-területi költségvetésben. A mobil GPU tervezők gyakran minimalizálják mindezt, és végül mind a geometriai shader-eket, mind a tesszellációt emulálják. Az Apple GPU-k, amelyek a PowerVR-ből származnak és eredetileg iDevice-ekhez készültek, nem kivételek.

Bár a Vulkan nem követeli meg a geometriai shader-ek támogatását, az OpenGL 3.2-től, valamint a Direct3D 10-től felfelé igen. Mivel szeretnénk támogatni az OpenGL-t és a Direct3D fordítást is, képesnek kell lennünk valahogyan végrehajtani a geometriai shader-eket.

Bár nincs közvetlen támogatásunk a geometriai shader-ekre, van támogatásunk a compute shader-ekre. Ezek segítségével a teljes geometriai shader és tesszelláció támogatás emulálható a GPU-n, így a CPU használata által okozott teljesítménycsökkenés jelentős része elkerülhető.

Természetesen ez nem olyan gyors, mint a teljes hardveres gyorsítás, de legalább lehetővé teszi, hogy az alkalmazásoknak geometriai és tesszellációs shader-támogatást hirdessünk. Ezáltal megfelelhetünk a modern OpenGL verzióknak, a Vulkan alkalmazások is használhatják a geometriai és tesszellációs shader-eket, és lehetővé teszi a Direct3D fordítást a WINE/Proton alatt futó játékokhoz.

Más mobil GPU-k is hasonló problémával küzdenek. Például az Arm GPU tervezések sem támogatják hardveresen a geometriai shader-eket vagy a tesszellációt. Erre jött a poly, Mary Guillemard projektje, amely a geometriai és tesszellációs shader emulációt megosztott kóddá alakítja, amelyet bármely Mesa driver használhat. Ez bármely Mesa GPU driverbe integrálható, így geometriai és tesszellációs shader-támogatást nyújt anélkül, hogy az emulációs kód duplikálódna.

Figyeljék a geometriai shader, tesszellációs shader és transform feedback támogatást a Panfrost-ban (az open source Arm GPU driver), valamint a KosmicKrisp-ben, a macOS-re Metal fölé rétegzett Vulkan 1.3 implementációban.

Az Akademy-n

Neal és Janne részt vettek a berlini KDE Akademy-n idén. Mint az éves KDE közösségi konferencia, lehetőséget adott arra, hogy a KDE jövőbeli munkái jól illeszkedjenek a Fedora Linux és Fedora Asahi Remix projekthez. Neal előadást tartott a Fedora KDE Plasma Desktop kiadásról, és hangsúlyosan beszélt a Fedora Asahi Remix-ről is.

Emellett sok beszélgetés folyt az új Plasma Setup alkalmazásról, amely jobb integrált élményt nyújt a Fedora KDE első indításakor. A Fedora Asahi Remix felhasználói visszajelzéseiből tanultakat közvetlenül beépítik a Plasma Setup-ba, és Neal dolgozik ezen a Fedora Linux 44-hez formális változtatásként.

M3? Valamennyire…

A kezdetekkor megjósoltuk, hogy az Apple nem fog drasztikus architektúraváltásokat végrehajtani az Apple Silicon SoC-k funkcionális blokkjain, kivéve, ha feltétlenül szükséges, és ez lehetővé teszi a kód újrafelhasználását, valamint jelentősen csökkenti a generációk közötti visszafejtést. A példánk az interrupt controller volt, ami sajnos az első dolog volt, amit az Apple végül megváltoztatott. Hoppá.

Az alapelv azonban nagyrészt igaz maradt. Annyira, hogy néhány Reddit-felhasználó felfedezte: minimális hackeléssel valójában lehet Asahi-t bootolni M3 sorozatú eszközökön!

Meglepő lehet, de az M3 nagyon alapszintű, alacsony szintű támogatása már régóta létezik. Az m1n1 képes inicializálni a CPU magokat, bekapcsolni néhány kritikus perifériát és bootolni az Asahi kernelt. A jelenlegi támogatás szintje azonban csak a villogó kurzor.