From 9e69a6ceeb07580fb1062cbe58bea2d830d6c816 Mon Sep 17 00:00:00 2001 From: MattTheTekie Date: Sat, 19 Jul 2025 09:48:11 -0400 Subject: [PATCH] chore: testing --- artwork/README.md | 2 +- artwork/logos/AsahiLinux_logo_reference.png | Bin 93979 -> 93980 bytes artwork/logos/AsahiLinux_logo_reference.svg | 4 +- artwork/logos/README.md | 8 ++-- artwork/logos/png_128/AsahiLinux_logo.png | Bin 5765 -> 5766 bytes .../logos/png_128/AsahiLinux_logo_darkbg.png | Bin 5310 -> 5311 bytes .../logos/png_128/AsahiLinux_logo_mono.png | Bin 3457 -> 3458 bytes artwork/logos/png_128/AsahiLinux_logomark.png | Bin 4886 -> 4887 bytes .../png_128/AsahiLinux_logomark_mono.png | Bin 2950 -> 2951 bytes artwork/logos/png_16/AsahiLinux_logo.png | Bin 848 -> 849 bytes .../logos/png_16/AsahiLinux_logo_darkbg.png | Bin 829 -> 830 bytes artwork/logos/png_16/AsahiLinux_logo_mono.png | Bin 612 -> 613 bytes artwork/logos/png_16/AsahiLinux_logomark.png | Bin 819 -> 820 bytes .../logos/png_16/AsahiLinux_logomark_mono.png | Bin 595 -> 596 bytes artwork/logos/png_1x/AsahiLinux_logo.png | Bin 33542 -> 33543 bytes .../logos/png_1x/AsahiLinux_logo_darkbg.png | Bin 31192 -> 31193 bytes artwork/logos/png_1x/AsahiLinux_logo_mono.png | Bin 22382 -> 22383 bytes artwork/logos/png_1x/AsahiLinux_logomark.png | Bin 23248 -> 23249 bytes .../logos/png_1x/AsahiLinux_logomark_mono.png | Bin 15294 -> 15295 bytes artwork/logos/png_256/AsahiLinux_logo.png | Bin 11338 -> 11339 bytes .../logos/png_256/AsahiLinux_logo_darkbg.png | Bin 10458 -> 10459 bytes .../logos/png_256/AsahiLinux_logo_mono.png | Bin 7166 -> 7167 bytes artwork/logos/png_256/AsahiLinux_logomark.png | Bin 9189 -> 9190 bytes .../png_256/AsahiLinux_logomark_mono.png | Bin 5837 -> 5838 bytes artwork/logos/png_2x/AsahiLinux_logo.png | Bin 73004 -> 73005 bytes .../logos/png_2x/AsahiLinux_logo_darkbg.png | Bin 68684 -> 68685 bytes artwork/logos/png_2x/AsahiLinux_logo_mono.png | Bin 53449 -> 53450 bytes artwork/logos/png_2x/AsahiLinux_logomark.png | Bin 49642 -> 49643 bytes .../logos/png_2x/AsahiLinux_logomark_mono.png | Bin 37270 -> 37271 bytes artwork/logos/png_32/AsahiLinux_logo.png | Bin 1479 -> 1480 bytes .../logos/png_32/AsahiLinux_logo_darkbg.png | Bin 1399 -> 1400 bytes artwork/logos/png_32/AsahiLinux_logo_mono.png | Bin 958 -> 959 bytes artwork/logos/png_32/AsahiLinux_logomark.png | Bin 1456 -> 1457 bytes .../logos/png_32/AsahiLinux_logomark_mono.png | Bin 905 -> 906 bytes artwork/logos/png_64/AsahiLinux_logo.png | Bin 2955 -> 2956 bytes .../logos/png_64/AsahiLinux_logo_darkbg.png | Bin 2742 -> 2743 bytes artwork/logos/png_64/AsahiLinux_logo_mono.png | Bin 1774 -> 1775 bytes artwork/logos/png_64/AsahiLinux_logomark.png | Bin 2645 -> 2646 bytes .../logos/png_64/AsahiLinux_logomark_mono.png | Bin 1574 -> 1575 bytes artwork/logos/src/AsahiLinux_logo.svg | 4 +- artwork/logos/src/AsahiLinux_logo_darkbg.svg | 4 +- artwork/logos/src/AsahiLinux_logo_mono.svg | 4 +- artwork/logos/src/AsahiLinux_logomark.svg | 4 +- .../logos/src/AsahiLinux_logomark_mono.svg | 4 +- artwork/logos/svg/AsahiLinux_logo.svg | 4 +- artwork/logos/svg/AsahiLinux_logo_darkbg.svg | 4 +- artwork/logos/svg/AsahiLinux_logo_mono.svg | 4 +- artwork/logos/svg/AsahiLinux_logomark.svg | 4 +- .../logos/svg/AsahiLinux_logomark_mono.svg | 4 +- artwork/website/asahilinux_laptop.svg | 4 +- content/about.md | 22 +++++----- content/blog/2021/03/11-progress-report.md | 24 +++++------ content/blog/2021/08/14-progress-report.md | 22 +++++----- content/blog/2021/10/06-progress-report.md | 6 +-- content/blog/2021/12/14-progress-report.md | 6 +-- .../2022/03/17-asahi-linux-alpha-release.md | 40 +++++++++--------- .../2022/07/18-release-and-progress-report.md | 24 +++++------ content/blog/2022/11/22-progress-report.md | 26 ++++++------ content/blog/2022/11/29-gpu-story.md | 10 ++--- .../12/07-gpu-drivers-now-in-asahi-linux.md | 2 +- content/blog/2023/03/20-road-to-vulkan.md | 14 +++--- content/blog/2023/06/06-opengl-3.1.md | 4 +- content/blog/2023/08/02-fedora-asahi-remix.md | 10 ++--- .../08/22-first-conformant-m1-gpu-driver.md | 4 +- content/blog/2024/01/11-fedora-asahi-new.md | 14 +++--- content/blog/2024/10/10-aaa-gaming-on-m1.md | 4 +- content/blog/2024/12/12-muvm-updates.md | 6 +-- content/blog/2025/02/12-passing-the-torch.md | 10 ++--- .../blog/2025/03/21-progress-report-6-14.md | 4 +- .../blog/2025/05/15-progress-report-6-15.md | 4 +- content/code-of-conduct.md | 20 ++++----- content/community.md | 2 +- content/contribute.md | 2 +- content/copyright.md | 24 +++++------ content/fedora.md | 2 +- content/governance.md | 2 +- content/merch.md | 4 +- content/support.md | 4 +- layouts/index.html | 6 +-- layouts/partials/footer.html | 4 +- static/img/asahilinux_kawaii_laptop.svg | 4 +- static/img/far_landing/far_laptop.svg | 4 +- 82 files changed, 196 insertions(+), 196 deletions(-) diff --git a/artwork/README.md b/artwork/README.md index f1fecd6..c3bea53 100644 --- a/artwork/README.md +++ b/artwork/README.md @@ -1 +1 @@ -## [Asahi Linux logos](logos/) +## [Dragon Linux logos](logos/) diff --git a/artwork/logos/AsahiLinux_logo_reference.png b/artwork/logos/AsahiLinux_logo_reference.png index f4bb2b38301ec8770ef934e5ada773e00b9b5d02..288c302d4912ab74d7208b920475472607eeb733 100644 GIT binary patch delta 22 ecmbPzk9E#H)(M$xE=7sy`FV|bTk{y#<^ce3eF=sD delta 21 dcmbPpk9GDv)(M%cj>U-?nT`2d^BLFX0RU#>2@(JR diff --git a/artwork/logos/AsahiLinux_logo_reference.svg b/artwork/logos/AsahiLinux_logo_reference.svg index 65ef168..dc07298 100644 --- a/artwork/logos/AsahiLinux_logo_reference.svg +++ b/artwork/logos/AsahiLinux_logo_reference.svg @@ -18,10 +18,10 @@ inkscape:version="1.0.1 (3bc2e813f5, 2020-09-07)" inkscape:export-xdpi="96" inkscape:export-ydpi="96">Asahi Linux logo (construction)Dragon Linux logo (construction)image/svg+xmlAsahi Linux logo (construction)Dragon Linux logo (construction)2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*vg&n4X`vF;83!05};23;+NC delta 16 XcmZqEZPlHS$?8~~n31_LUtA0TF>wW# diff --git a/artwork/logos/png_128/AsahiLinux_logo_darkbg.png b/artwork/logos/png_128/AsahiLinux_logo_darkbg.png index cd21012cba84fba849e6729398f584ca37e3e4a2..49b783bed8d12a34db6037ae89606945b84331de 100644 GIT binary patch delta 17 Ycmdm|xnFZaCYwu9VtRhw#=HO#06#GXtpET3 delta 16 Xcmdn5xleOKCaYs{Vn*i1`~VREI3ET$ diff --git a/artwork/logos/png_128/AsahiLinux_logo_mono.png b/artwork/logos/png_128/AsahiLinux_logo_mono.png index 90e09710d04520ebf53ac8c353a877131f5a26e4..84c23af085e948e4888fea98ee7045949c07a1c4 100644 GIT binary patch delta 17 YcmZpaZjzpm$>vg&n4X`vF;AEm05xm{(*OVf delta 16 XcmZpYZj_#o$?8~~n31_LUzisFF7O3j diff --git a/artwork/logos/png_128/AsahiLinux_logomark.png b/artwork/logos/png_128/AsahiLinux_logomark.png index f22de109f512575d9c293df9306a2da250c0d22a..df58631eee30ee40b2dae3f4da32a3f9a28f482b 100644 GIT binary patch delta 17 YcmbQHHeGE(CYwu9VtRhw#=I3m06K*RtpET3 delta 16 XcmbQPHcf3pCaYs{Vn*i1{1rj~Gsy-x diff --git a/artwork/logos/png_128/AsahiLinux_logomark_mono.png b/artwork/logos/png_128/AsahiLinux_logomark_mono.png index e40b784baac0b8010531dd693ac4b2924cc7a37a..90563949a9149e1a9837b0a02ee13ef22cff35a4 100644 GIT binary patch delta 17 YcmZn@Zx^4C$>vg&n4X`vF;9XU05zNi*Z=?k delta 16 XcmZn{Zxf%8$?8~~n31_LUxFI|FCGPB diff --git a/artwork/logos/png_16/AsahiLinux_logo.png b/artwork/logos/png_16/AsahiLinux_logo.png index 5255003450e7ca23151b78a4afabc222e629ba47..0994bc44f74d0a4ffdbc66c3fdaeb80fb4b746d6 100644 GIT binary patch delta 17 Ycmcb>c9CsDCYwu9VtRhw#=J*N06u943jhEB delta 16 Xcmcb}c7bg|CaYs{Vn*i1{6|axH+cq@ diff --git a/artwork/logos/png_16/AsahiLinux_logo_darkbg.png b/artwork/logos/png_16/AsahiLinux_logo_darkbg.png index e38b559fd4cc39efe76d49872bcc41df3c957b48..eaad27bd0528edfebc2b5c8c701c5e7ab5df08fd 100644 GIT binary patch delta 17 YcmdnXwvTN>CYwu9VtRhw#=P@P06XIb(f|Me delta 16 XcmdnTwwG-}CaYs{Vn*i1{PRozH5mq7 diff --git a/artwork/logos/png_16/AsahiLinux_logo_mono.png b/artwork/logos/png_16/AsahiLinux_logo_mono.png index cd1dc24fd9fa22d5d4661489e1d7eae9fe5c3dda..c19b5f8def9a25bfa441473d16937888f41cc45e 100644 GIT binary patch delta 17 YcmaFD@|0ylCYwu9VtRhw#=LKg06^3SLI3~& delta 16 XcmaFL@`PnVCaYs{Vn*i1{BMi^IlunvlunQk0mUpSLk@MiT%>dIzxp delta 18 ZcmZo~V`^(-nvlurSe%%VxiNo6697OP2Rr}( diff --git a/artwork/logos/png_1x/AsahiLinux_logo_darkbg.png b/artwork/logos/png_1x/AsahiLinux_logo_darkbg.png index 3bd91f7cd3928dc0fc679d74f0e08dd0cc28f508..482a8a13dc170fdc5f7a468214ec987622b74ce0 100644 GIT binary patch delta 19 acmccdnepal#tE5hE=7sy`FR`jvMK>!ISBRu delta 18 ZcmcclneoPF#tE6Mj>U-?nH%%7Dgjqs2!Q|q diff --git a/artwork/logos/png_1x/AsahiLinux_logo_mono.png b/artwork/logos/png_1x/AsahiLinux_logo_mono.png index c457c9f4688ee5de1320b8c0edcb0ca6f9a2b99d..14e37eb8f8102ae8c423927dbcc07656dfaa20d5 100644 GIT binary patch delta 18 ZcmaF2j`96E#tE5hE=7sy`FRWT!U0ix2mAm4 delta 17 YcmaFAj`7_(#tE6Mj>U-?nG5s70ZDTQhX4Qo diff --git a/artwork/logos/png_1x/AsahiLinux_logomark.png b/artwork/logos/png_1x/AsahiLinux_logomark.png index 85619b68a557ec79639c3b11e32c470f98aa9562..9d25b0489a8711c883f61494de94eac3b9941231 100644 GIT binary patch delta 19 acmcbxmGR#tE6Mj>U-?nH%$yq5w{%2hIQh diff --git a/artwork/logos/png_1x/AsahiLinux_logomark_mono.png b/artwork/logos/png_1x/AsahiLinux_logomark_mono.png index d199497301e3e1256cdab560025bd100e0d7fbb7..5f3bd77cfc74d92c00bd0ff73db3458fe08f2a43 100644 GIT binary patch delta 17 Ycmdm2zQ24zCYwu9VtRhw#=HP)07!fXZ~y=R delta 16 XcmdmAzOQ^jCaYs{Vn*i1`~YhJK+XpH diff --git a/artwork/logos/png_256/AsahiLinux_logo.png b/artwork/logos/png_256/AsahiLinux_logo.png index 0588c60c12da983c84b6446fafb75f75b4c08341..6a937c805264805accd480b3bb35e8382a1bd96f 100644 GIT binary patch delta 17 YcmX>VaXMl`CYwu9VtRhw#=JY)07qg6#sB~S delta 16 XcmX>daVla$CaYs{Vn*i1{5#qJKiUUT diff --git a/artwork/logos/png_256/AsahiLinux_logo_darkbg.png b/artwork/logos/png_256/AsahiLinux_logo_darkbg.png index 915f19ea325b8df4ff205a48430e81a1a1152ce8..36f027fbd59fc046e108902a9e7edd754512f21c 100644 GIT binary patch delta 17 YcmcZ=csp=HCYwu9VtRhw#=IO207tC{WdHyG delta 16 XcmcZ|cq?#1CaYs{Vn*i1{2UDcKobV= diff --git a/artwork/logos/png_256/AsahiLinux_logo_mono.png b/artwork/logos/png_256/AsahiLinux_logo_mono.png index 8b866f98d64806e1a1663868e0893874eeee0fe0..89454c7295ccf8f62a2e035a16344ff038efed39 100644 GIT binary patch delta 17 Ycmexo{@;8;CYwu9VtRhw#=HsA07+a2kN^Mx delta 16 Xcmexw{?B|uCaYs{Vn*i1{0Y(kL9PcI diff --git a/artwork/logos/png_256/AsahiLinux_logomark.png b/artwork/logos/png_256/AsahiLinux_logomark.png index 00e6823d4c9e56e25f24ca825b326f4e3c278c9d..6138d59598a664dffc7be7bc58f9e2bff5e7e668 100644 GIT binary patch delta 17 YcmaFr{>*(sCYwu9VtRhw#=LT607vo%Z2$lO delta 16 XcmaFn{?vU!CaYs{Vn*i1{BmUgKvo9$ diff --git a/artwork/logos/png_256/AsahiLinux_logomark_mono.png b/artwork/logos/png_256/AsahiLinux_logomark_mono.png index 42c8694fbea7b8f7924209d5518f92a378118a5e..f6f92d4fde3dda4fe4cd06f9866d5f4f19f49ae9 100644 GIT binary patch delta 17 YcmX@Bdro&kCYwu9VtRhw#=Lkj070n+U-?nT`2d^BMQa003k22&n)7 diff --git a/artwork/logos/png_2x/AsahiLinux_logo_darkbg.png b/artwork/logos/png_2x/AsahiLinux_logo_darkbg.png index 8bf8807359518192c88f3532fc3a6ea10fe11f31..8c5577605b1b94de469098016fee13cbd9f1753b 100644 GIT binary patch delta 22 ecmX>zgXQcDmI;|`E=7sy`FV|bTk{z2aRUHth6yMD delta 21 dcmX>*gXPQ&mI;}xj>U-?nT`2d^BM1P0{~E=7sy`FR`jqAvgdR1pY( delta 18 acmX@Lkon|7<_Vdsj>U-?nH%$?F8}~b^au+8 diff --git a/artwork/logos/png_2x/AsahiLinux_logomark.png b/artwork/logos/png_2x/AsahiLinux_logomark.png index d1f6e7129511488362c6cab7271900839b11a067..8e09627e9e01aec2c8105e84feadd2c0dc720591 100644 GIT binary patch delta 19 acmaFW%>25Uc|s1gEc|sj>U-?nH%#pCISFN-3K)Q diff --git a/artwork/logos/png_32/AsahiLinux_logo.png b/artwork/logos/png_32/AsahiLinux_logo.png index 3d35e7583dea87e36ac3031d4a8fe3df02c0fd97..f17f8387c8231b4ede826616032890e495d6ea9d 100644 GIT binary patch delta 17 YcmX@keS&*JCYwu9VtRhw#=J;Y06fqJeEvg&n4X`vF;AKq05lo}xc~qF delta 16 XcmeBT?_{5l$?8~~n31_LUz!;JEw%+j diff --git a/artwork/logos/png_64/AsahiLinux_logo.png b/artwork/logos/png_64/AsahiLinux_logo.png index ca60fe7cf0c3fdf28def5a4c5e5ed58de3269912..518b24ef9c1e46f93a99472ba2dc4f1d3de9cd30 100644 GIT binary patch delta 17 YcmeAc?-8Gn$>vg&n4X`vF;A8o05(Pi=Kufz delta 16 XcmeAX?-rks$?8~~n31_LUzQsHFTMqG diff --git a/artwork/logos/png_64/AsahiLinux_logo_darkbg.png b/artwork/logos/png_64/AsahiLinux_logo_darkbg.png index 1bb80c669d776b1ce7f3d63019fe4491ae07f07a..a693833591ef1e3668c9cc011d4b22e3132a4139 100644 GIT binary patch delta 17 Ycmdlcx?OZaCYwu9VtRhw#yk%$06V`1V*mgE delta 16 Xcmdlkx=nOKCaYs{Vn*i1d=D-FH01^E diff --git a/artwork/logos/png_64/AsahiLinux_logo_mono.png b/artwork/logos/png_64/AsahiLinux_logo_mono.png index caeb7b3bfe411a9c2a3c97b1d1b9387d907c85f9..ab1a39e6859b50123e38e1353c5df0ee892a78fe 100644 GIT binary patch delta 17 YcmaFI`<{0~CYwu9VtRhw#=HhL075$k_W%F@ delta 16 XcmaFQ`;K=)CaYs{Vn*i1{024vI{^lQ diff --git a/artwork/logos/png_64/AsahiLinux_logomark.png b/artwork/logos/png_64/AsahiLinux_logomark.png index c34311e9b40363c3c3c9ce40a84911a3629935e5..8f817f6681fe2b198748283daa00f8c9cf7492d7 100644 GIT binary patch delta 17 YcmcaAa!q7HCYwu9VtRhw#=Pg806@M6Jpcdz delta 16 Xcmca6a#dtPCaYs{Vn*i1{O6niIj9E6 diff --git a/artwork/logos/png_64/AsahiLinux_logomark_mono.png b/artwork/logos/png_64/AsahiLinux_logomark_mono.png index 4ccf8f2c2c85ade4741692ba7d977c8cb59589e9..330ec08e5120e3e04f54d02114f46e21452d2280 100644 GIT binary patch delta 17 YcmZ3+vz%u_CYwu9VtRhw#=IS@06B~XoB#j- delta 16 XcmZ3^vy5j#CaYs{Vn*i1{2iAsahi Linux logoDragon Linux logoimage/svg+xmlAsahi Linux logoDragon Linux logo2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logo (dark background)Dragon Linux logo (dark background)image/svg+xmlAsahi Linux logo (dark background)Dragon Linux logo (dark background)2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logo (monochrome)Dragon Linux logo (monochrome)image/svg+xmlAsahi Linux logo (monochrome)Dragon Linux logo (monochrome)2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logomarkDragon Linux logomarkimage/svg+xmlAsahi Linux logomarkDragon Linux logomark2021-01-03soundflora* / marcanCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logomark (monochrome)Dragon Linux logomark (monochrome)image/svg+xmlAsahi Linux logomark (monochrome)Dragon Linux logomark (monochrome)2021-01-03soundflora* / marcanCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logoDragon Linux logoimage/svg+xmlAsahi Linux logoDragon Linux logo2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logo (dark background)Dragon Linux logo (dark background)image/svg+xmlAsahi Linux logo (dark background)Dragon Linux logo (dark background)2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logo (monochrome)Dragon Linux logo (monochrome)image/svg+xmlAsahi Linux logo (monochrome)Dragon Linux logo (monochrome)2021-01-03soundflora* / marcanFont: Bangla MN (c) 2009 Muthu Nedumaran Used with permissionCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logomarkDragon Linux logomarkimage/svg+xmlAsahi Linux logomarkDragon Linux logomark2021-01-03soundflora* / marcanCC BY-SA 4.0 / (c) 2021 soundflora*Asahi Linux logomark (monochrome)Dragon Linux logomark (monochrome)image/svg+xmlAsahi Linux logomark (monochrome)Dragon Linux logomark (monochrome)2021-01-03soundflora* / marcanCC BY-SA 4.0 / (c) 2021 soundflora* MacBook Pro with Asahi Linux logo + id="title1371">MacBook Pro with Dragon Linux logo image/svg+xml - MacBook Pro with Asahi Linux logo + MacBook Pro with Dragon Linux logo 2021-01-05 diff --git a/content/about.md b/content/about.md index b72b490..aca8e2f 100644 --- a/content/about.md +++ b/content/about.md @@ -4,13 +4,13 @@ date: "2021-01-05T20:00:00+09:00" draft: false --- -# About Asahi Linux +# About Dragon Linux -Asahi Linux is a project and community with the goal of porting Linux to Apple Silicon Macs, starting with the 2020 M1 Mac Mini, MacBook Air, and MacBook Pro. +Dragon Linux is a project and community with the goal of porting Linux to Apple Silicon Macs, starting with the 2020 M1 Mac Mini, MacBook Air, and MacBook Pro. Our goal is not just to make Linux run on these machines but to polish it to the point where it can be used as a daily OS. Doing this requires a tremendous amount of work, as Apple Silicon is an entirely undocumented platform. -Asahi Linux is developed by a thriving community of free and open source software developers. +Dragon Linux is developed by a thriving community of free and open source software developers. ## The name @@ -18,13 +18,13 @@ Asahi means "rising sun" in Japanese, and it is also the name of an apple cultiv ## The logo -Asahi Linux logo +Dragon Linux logo -The Asahi Linux logo and website were designed by [soundflora*](https://soundflora.tokyo). You can find the logo artwork [here](https://github.com/AsahiLinux/artwork/tree/main/logos). +The Dragon Linux logo and website were designed by [soundflora*](https://soundflora.tokyo). You can find the logo artwork [here](https://github.com/AsahiLinux/artwork/tree/main/logos). -Kawaii Asahi Linux logo +Kawaii Dragon Linux logo -Kawaii Asahi Linux logo by [SAWARATSUKI](https://twitter.com/sawaratsuki1004). Click to \[[enable](/about/?kawaii=true)・[disable](/about/?kawaii=false)\] kawaii mode. +Kawaii Dragon Linux logo by [SAWARATSUKI](https://twitter.com/sawaratsuki1004). Click to \[[enable](/about/?kawaii=true)・[disable](/about/?kawaii=false)\] kawaii mode. # FAQ @@ -34,7 +34,7 @@ All Apple Silicon Macs are in scope, as well as future generations as developmen ## Is this a Linux distribution? -Asahi Linux is an overall project to develop support for these Macs. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects. Our flagship distro is [Fedora Asahi Remix](/fedora), which is a collaboration between Asahi Linux and the Fedora Project, and serves as both a polished end-user distribution and a reference for other distributions who wish to incorporate our work. +Dragon Linux is an overall project to develop support for these Macs. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects. Our flagship distro is [Fedora Asahi Remix](/fedora), which is a collaboration between Dragon Linux and the Fedora Project, and serves as both a polished end-user distribution and a reference for other distributions who wish to incorporate our work. Other distributions are already working on implementing support for these platforms, and we expect to have more options officially available in the future. Check out our [Alternative Distros](/docs/alt/alt-distros) page for a list of ongoing distro integration projects. @@ -53,9 +53,9 @@ All development takes place on GitHub, [github.com/AsahiLinux](https://github.co No, Apple still controls the boot process and, for example, the firmware that runs on the Secure Enclave Processor. However, no modern device is "fully open" - no usable computer exists today with completely open software and hardware (as much as some companies want to market themselves as such). What ends up changing is where you draw the line between closed parts and open parts. The line on Apple Silicon Macs is when the alternate kernel image is booted, while SEP firmware remains closed - which is quite similar to the line on standard PCs, where the UEFI firmware boots the OS loader, while the ME/PSP firmware remains closed. In fact, mainstream x86 platforms are arguably more intrusive because the proprietary UEFI firmware is allowed to steal the main CPU from the OS at any time via SMM interrupts, which is not the case on Apple Silicon Macs. This has real performance/stability implications; it's not just a philosophical issue. Further reading: ["Open OS Ecosystem on Apple Silicon Macs"](/docs/platform/open-os-interop). -## Who is working on Asahi Linux? +## Who is working on Dragon Linux? -Asahi Linux is a community, and everyone is invited to contribute. If you are interested in contributing, check out our [contribute page](/contribute)! The project infrastructure and finances are overseen by our board. For more information, see our [governance page](/governance). +Dragon Linux is a community, and everyone is invited to contribute. If you are interested in contributing, check out our [contribute page](/contribute)! The project infrastructure and finances are overseen by our board. For more information, see our [governance page](/governance). Current major contributors are: @@ -77,6 +77,6 @@ Past major contributors include: * [Asahi Lina](https://github.com/asahilina), GPU kernel sourceress. Lina joined the team to reverse engineer the M1 GPU kernel interface, and found herself writing the world's first Rust Linux GPU kernel driver. Outside of GPUs, she sometimes hacks on open source VTuber tooling and infrastructure. -* [Hector Martin (marcan)](https://github.com/marcan), the founder of Asahi Linux. marcan is a seasoned reverse engineer and developer with more than 15 years of experience porting Linux and running unofficial software on undocumented and/or closed devices. Asahi Linux was his most ambitious project yet. His previous projects include [PS4 Linux](https://github.com/fail0verflow/ps4-linux), a Linux port to the proprietary hardware found on the PS4, capable of full 3D acceleration using OpenGL and Vulkan (radeon/amdgpu drivers); [AsbestOS](https://github.com/marcan/asbestos), a PS3 Linux bootloader for GameOS mode, and associated kernel patches to make Linux work on the PS3 Slim; and numerous contributions to the [Wii Homebrew ecosystem](https://wiibrew.org/), including being part of the team that developed [The Homebrew Channel](https://wiibrew.org/wiki/Homebrew_Channel) and [BootMii](https://wiibrew.org/wiki/BootMii), documenting much of the hardware, and contributing to open homebrew SDK tooling. +* [Hector Martin (marcan)](https://github.com/marcan), the founder of Dragon Linux. marcan is a seasoned reverse engineer and developer with more than 15 years of experience porting Linux and running unofficial software on undocumented and/or closed devices. Dragon Linux was his most ambitious project yet. His previous projects include [PS4 Linux](https://github.com/fail0verflow/ps4-linux), a Linux port to the proprietary hardware found on the PS4, capable of full 3D acceleration using OpenGL and Vulkan (radeon/amdgpu drivers); [AsbestOS](https://github.com/marcan/asbestos), a PS3 Linux bootloader for GameOS mode, and associated kernel patches to make Linux work on the PS3 Slim; and numerous contributions to the [Wii Homebrew ecosystem](https://wiibrew.org/), including being part of the team that developed [The Homebrew Channel](https://wiibrew.org/wiki/Homebrew_Channel) and [BootMii](https://wiibrew.org/wiki/BootMii), documenting much of the hardware, and contributing to open homebrew SDK tooling. * [Martin Povišer (povik)](https://github.com/povik/), who led our audio kernel driver effort. Martin wrote the Apple-specific SoC audio drivers as well as drivers for Apple-proprietary codecs and codec variants. diff --git a/content/blog/2021/03/11-progress-report.md b/content/blog/2021/03/11-progress-report.md index 0175c97..16f3edd 100644 --- a/content/blog/2021/03/11-progress-report.md +++ b/content/blog/2021/03/11-progress-report.md @@ -6,7 +6,7 @@ slug = "progress-report-january-february-2021" author = "marcan" +++ -Welcome to the first Asahi Linux Progress Report! In this series we'll be taking a page from the [Dolphin](https://dolphin-emu.org/blog/series%23series-1) playbook and giving you monthly updates on the progress of the project. +Welcome to the first Dragon Linux Progress Report! In this series we'll be taking a page from the [Dolphin](https://dolphin-emu.org/blog/series%23series-1) playbook and giving you monthly updates on the progress of the project. Bringing up support for a new system-on-chip on Linux is no small task! I hope this series will be educational to everyone and give you a glimpse of the behind-the-scenes work that goes into making Linux work on a brand new device. The original plan was to do separate updates for January and February, but things were moving so fast it was hard to call a cut-off point, so we ended up with a two-month update. @@ -16,7 +16,7 @@ In this report, you will see the terms AArch64, ARM64, and ARMv8-A. AArch64 refe ## Where it all starts -The Asahi Linux project officially kicked off at the beginning of the year, but at that time we were all waiting for one crucial piece: support from Apple for booting alternate kernels on Apple Silicon systems. While the feature had been documented and mostly implemented, there was one final missing piece of the puzzle: support for the `kmutil configure-boot` command, which is what lets you install a non-Apple kernel. This didn't stop us from making progress, however, as the first step to porting an OS to an undocumented platform is documenting it! +The Dragon Linux project officially kicked off at the beginning of the year, but at that time we were all waiting for one crucial piece: support from Apple for booting alternate kernels on Apple Silicon systems. While the feature had been documented and mostly implemented, there was one final missing piece of the puzzle: support for the `kmutil configure-boot` command, which is what lets you install a non-Apple kernel. This didn't stop us from making progress, however, as the first step to porting an OS to an undocumented platform is documenting it! Apple Silicon Macs boot in a completely different way from PCs. The way they work is more akin to embedded platforms (like Android phones, or, of course, iOS devices), but with quite a few bespoke mechanisms thrown in. However, Apple has taken a few steps to make this boot process *feel* closer to that of an Intel Mac, so there has been a lot of confusion around how things actually work. For example, did you know that Apple Silicon Macs cannot boot from external storage at all, in the traditional sense? Or that the bootloader on Apple Silicon Macs cannot show a graphical user interface at all, and that the "Boot Picker" is in fact a full-screen macOS app, not part of the bootloader? @@ -24,11 +24,11 @@ And so, before we were able to run our own kernels on these machines, we set out ## Bridging two worlds -Apple Silicon Macs have a boot process that is not based on any existing standard. Rather, it is a bespoke Apple mechanism that has slowly evolved from the early days of iOS devices. On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) + [ACPI](https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface) (largely used by servers running Windows or Linux), and the [ARM64 Linux boot protocol](https://www.kernel.org/doc/Documentation/arm64/booting.txt) + [DeviceTree](https://www.devicetree.org/) (used on smaller systems, and also supported by [U-Boot](https://en.wikipedia.org/wiki/Das_U-Boot) and more). We need to choose one of these for Asahi Linux and figure out a way to "bridge" Apple’s world to our own. +Apple Silicon Macs have a boot process that is not based on any existing standard. Rather, it is a bespoke Apple mechanism that has slowly evolved from the early days of iOS devices. On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: [UEFI](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) + [ACPI](https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface) (largely used by servers running Windows or Linux), and the [ARM64 Linux boot protocol](https://www.kernel.org/doc/Documentation/arm64/booting.txt) + [DeviceTree](https://www.devicetree.org/) (used on smaller systems, and also supported by [U-Boot](https://en.wikipedia.org/wiki/Das_U-Boot) and more). We need to choose one of these for Dragon Linux and figure out a way to "bridge" Apple’s world to our own. UEFI and ACPI are complicated beasts usually only used for large ARM systems. The standards are largely controlled by committees at the [UEFI Forum](https://uefi.org/). Unlike the x86 PC world, which is much more homogeneous, the ARM world is extremely diverse and [systems-on-chip](https://en.wikipedia.org/wiki/System_on_a_chip) have all kinds of designs with different requirements for describing the hardware contained within them. This means that adding support for a new SoC almost always requires amending these standards to add "bindings" for the bits of hardware that make it unique. For ACPI, this is costly and slow, which is why ACPI is almost never used on small embedded systems that don't run Windows. It is not a viable option for us. -The wide variety of smaller embedded ARM Linux systems almost invariably use the DeviceTree standard – for example, this is how most Android devices boot. Devicetrees are much simpler than ACPI, since a devicetree is purely a bunch of data describing the hardware, while ACPI tables are a combination of data and code. These days, the authority on devicetree bindings is the [documentation](https://www.kernel.org/doc/Documentation/devicetree/bindings/) maintained inside the Linux kernel tree itself: this means that we can amend these standards at the same time as we write the Linux drivers themselves. Thus, Asahi Linux's boot process will use this model. +The wide variety of smaller embedded ARM Linux systems almost invariably use the DeviceTree standard – for example, this is how most Android devices boot. Devicetrees are much simpler than ACPI, since a devicetree is purely a bunch of data describing the hardware, while ACPI tables are a combination of data and code. These days, the authority on devicetree bindings is the [documentation](https://www.kernel.org/doc/Documentation/devicetree/bindings/) maintained inside the Linux kernel tree itself: this means that we can amend these standards at the same time as we write the Linux drivers themselves. Thus, Dragon Linux's boot process will use this model. Interestingly enough, Apple also uses their own version of a device tree on Apple Silicon, called Apple Device Tree! This is because both it and the open DeviceTree standard are based on the [Open Firmware](https://en.wikipedia.org/wiki/Open_Firmware) specification, which is how many PowerPC systems boot, including [older Macs](https://en.wikipedia.org/wiki/New_World_ROM). Unfortunately, while this does mean ADTs are very familiar to any embedded Linux developer, we cannot use them directly: the binary format is different and cannot be converted automatically without having high-level information about what the data represents. On top of that, the actual bindings used for devices are very different. While Linux and macOS work the same way on PowerPC Macs and are directly compatible, Linux has seen over a decade of divergent evolution from Apple in the ARM space. Trying to unify Apple's and Linux's ideas of how device trees should work would be a nightmare. @@ -39,7 +39,7 @@ You can prepend m1n1 to a Linux kernel (just using `cat m1n1.macho initrd.bin de * Initializes the main CPU, and applies [chicken bit](https://en.wiktionary.org/wiki/chicken_bit) settings to make it work correctly. * Reads the boot information that Apple's bootloader, iBoot, has provided to it: this includes things like how much RAM is available and the address of the [framebuffer](https://en.wikipedia.org/wiki/Framebuffer) (the video memory being displayed on the screen) in RAM. * Initializes the [Memory management unit](https://en.wikipedia.org/wiki/Memory_management_unit). This is required to be able to use the CPU [caches](https://en.wikipedia.org/wiki/CPU_cache), without which everything runs extremely slowly. -* Puts the Asahi Linux logo on the screen, which replaces the Apple logo. +* Puts the Dragon Linux logo on the screen, which replaces the Apple logo. * Disables the [watchdog timer](https://en.wikipedia.org/wiki/Watchdog_timer). Without this, the Mac will spontaneously reboot after a minute or so, as it thinks the boot process has gotten stuck. * Figures out what it is going to boot: the Linux kernel, devicetree, and (optionally) the initramfs ramdisk containing boot-time applications, if they were appended to it. * Initializes all the other CPU cores and applies the required chicken bits, then sets them up waiting in a “spin-table”, ready for Linux to take over. @@ -52,14 +52,14 @@ The alternative is called "[PSCI](https://developer.arm.com/architectures/system Now, I said that we would be using devicetree – but that doesn't mean we can't use UEFI! ARM64 systems can boot using UEFI + devicetree, and this is needed to get a "PC-like" boot experience, with bootloaders such as GRUB and the typical flows for installing and upgrading kernels. But m1n1 does not support any of that, so what do we do? Thankfully, there is another piece that completes the puzzle: [U-Boot](https://en.wikipedia.org/wiki/Das_U-Boot). U-Boot can boot like a Linux kernel – so you can boot U-Boot from m1n1 – and it itself can provide a good enough UEFI environment for GRUB and Linux. -And so, most likely, the boot chain for Asahi Linux as used by end-users will be: +And so, most likely, the boot chain for Dragon Linux as used by end-users will be: m1n1 → U-Boot → GRUB → Linux Combined with the Apple-specific bits of the boot chain, the entire boot process ends up looking like this: * The SecureROM inside the M1 SoC starts up on cold boot, and loads iBoot1 from NOR flash -* iBoot1 reads the boot configuration in the internal SSD, validates the system boot policy, and chooses an "OS" to boot – for us, Asahi Linux / m1n1 will look like an OS partition to iBoot1. +* iBoot1 reads the boot configuration in the internal SSD, validates the system boot policy, and chooses an "OS" to boot – for us, Dragon Linux / m1n1 will look like an OS partition to iBoot1. * iBoot2, which is the "OS loader" and needs to reside in the OS partition being booted to, loads firmware for internal devices, sets up the Apple Device Tree, and boots a Mach-O kernel (or in our case, m1n1). * m1n1 parses the ADT, sets up more devices and makes things Linux-like, sets up an FDT (Flattened Device Tree, the binary devicetree format), then boots U-Boot. * U-Boot, which will have drivers for the internal SSD, reads its configuration and the next stage, and provides UEFI services – including forwarding the devicetree from m1n1. @@ -116,9 +116,9 @@ Bring-up is very important not just because it lays the foundation for the rest To give you an idea of how deep the rabbit hole goes: as part of our initial M1 support patch set, we had to make a change to a file related to support for the [SPARC64](https://en.wikipedia.org/wiki/SPARC) architecture! One unique feature of Linux development is that the Linux kernel does not have a stable driver API/ABI, which means that the internal design of the Linux kernel is subject to continuous improvement and refactoring over time. That means that if supporting something on one architecture warrants cleaning up or changing other architectures, doing so is perfectly feasible, and often the best way to do things. However, it also means that it is very difficult to maintain Linux forks, or third-party drivers that are not part of the upstream kernel. -At Asahi Linux, our goal is not just to port Linux to Apple Silicon, but to do so as an open community-driven project, working together with the overall Linux community to upstream our work into the official Linux kernel. This is rare in the embedded ARM space, because most companies developing Linux ports for their hardware do so on product development deadlines; instead, they end up creating a Linux fork and doing all of their development there, detached from the upstream community. By the time they decide to upstream their changes into the official Linux kernel, if they do so at all, the two forks have usually diverged so much that merging becomes a nightmare. The design decisions that were taken may also run counter to the overall Linux philosophy, and not be acceptable upstream. In the end, a lot of the code ends up being rewritten, and a lot of development time is wasted due to the pursuit of short-term results over long-term sustainability. +At Dragon Linux, our goal is not just to port Linux to Apple Silicon, but to do so as an open community-driven project, working together with the overall Linux community to upstream our work into the official Linux kernel. This is rare in the embedded ARM space, because most companies developing Linux ports for their hardware do so on product development deadlines; instead, they end up creating a Linux fork and doing all of their development there, detached from the upstream community. By the time they decide to upstream their changes into the official Linux kernel, if they do so at all, the two forks have usually diverged so much that merging becomes a nightmare. The design decisions that were taken may also run counter to the overall Linux philosophy, and not be acceptable upstream. In the end, a lot of the code ends up being rewritten, and a lot of development time is wasted due to the pursuit of short-term results over long-term sustainability. -We absolutely do not want to end up in this scenario, so our approach is to upstream early, and work with the overall community from day 1. To this end, we have been working with the upstream Linux maintainers, and in fact several key Linux folks now hang around in the Asahi Linux IRC channels! +We absolutely do not want to end up in this scenario, so our approach is to upstream early, and work with the overall community from day 1. To this end, we have been working with the upstream Linux maintainers, and in fact several key Linux folks now hang around in the Dragon Linux IRC channels! To get Linux to boot on any system at all, there are five pieces that absolutely need to work properly: @@ -221,7 +221,7 @@ While trying to understand these details to ensure that the AIC code is correct, For better or for worse, the M1 is particularly good at exposing these kinds of subtle bugs. It is such a highly [out-of-order machine](https://en.wikipedia.org/wiki/Out-of-order_execution) that it tickles race conditions which you would never hit on other CPUs. While debugging an earlier m1n1 issue, we even saw it (legitimately) [speculating](https://en.wikipedia.org/wiki/Speculative_execution) its way out of an interrupt handler... while to the code it seemed like it was still halfway through the handler printing debug info! The underlying problem there turned to have been caused by a subtle misconfiguration of the MMU, which gives you an idea of just how inextricably tied together all these core systems are, and how tricky to debug they can be. -Interestingly, the M1 chip actually has a bit of the standard GIC in it – specifically, it supports natively *virtualizing* the low-level bits of a GIC to VM guests! This allows for much higher performance interrupt handling, since otherwise the VM hypervisor has to emulate every little detail of the interrupt controller, which means every interrupt requires many calls into hypervisor code and back. Oddly enough... the macOS [Hypervisor Framework](https://developer.apple.com/documentation/hypervisor/apple_silicon) does not support this (at the time of writing), requiring VM hypervisors to do full GIC emulation in software! We have already tested it and it works, and I've been working with Marc Zyngier on the peculiarities of running VMs on these chips; he already has Linux virtual machines booting on top of KVM running on the Asahi Linux kernel on M1 Macs. It's too early for benchmarks, but we expect that without that support in macOS, once other bits and pieces are in place, this will make native Linux-on-Linux VMs faster than Linux-on-macOS VMs, especially for IPI-heavy workloads. +Interestingly, the M1 chip actually has a bit of the standard GIC in it – specifically, it supports natively *virtualizing* the low-level bits of a GIC to VM guests! This allows for much higher performance interrupt handling, since otherwise the VM hypervisor has to emulate every little detail of the interrupt controller, which means every interrupt requires many calls into hypervisor code and back. Oddly enough... the macOS [Hypervisor Framework](https://developer.apple.com/documentation/hypervisor/apple_silicon) does not support this (at the time of writing), requiring VM hypervisors to do full GIC emulation in software! We have already tested it and it works, and I've been working with Marc Zyngier on the peculiarities of running VMs on these chips; he already has Linux virtual machines booting on top of KVM running on the Dragon Linux kernel on M1 Macs. It's too early for benchmarks, but we expect that without that support in macOS, once other bits and pieces are in place, this will make native Linux-on-Linux VMs faster than Linux-on-macOS VMs, especially for IPI-heavy workloads. ## Finicky FIQs @@ -291,8 +291,8 @@ We could keep talking in depth for another 10000 words, but alas, this post is a Our current Linux bring-up series is in its [third version](https://lore.kernel.org/linux-arm-kernel/20210304213902.83903-1-marcan@marcan.st/#t) and being reviewed for upstream inclusion. If you'd like to see how the story of this article maps to code, check out the patches; and if you want to see how the process works, read the threads for versions [1](https://lore.kernel.org/linux-arm-kernel/20210204203951.52105-1-marcan@marcan.st/#t) and [2](https://lore.kernel.org/linux-arm-kernel/20210215121713.57687-1-marcan@marcan.st/#t). If all goes well and we don't hit any new showstoppers, this should be on track to being merged into Linux 5.13. Stay tuned! -Asahi Linux wouldn't be possible without the entire community of people who have jumped on to help move the project forward, from people new to embedded development to hardware engineers to seasoned kernel folks. If you are interested in contributing, check out our [community](/community) page and join our IRC channels! +Dragon Linux wouldn't be possible without the entire community of people who have jumped on to help move the project forward, from people new to embedded development to hardware engineers to seasoned kernel folks. If you are interested in contributing, check out our [community](/community) page and join our IRC channels! -On a personal note, I'm trying to make Asahi Linux my full time job. If you like what I'm doing and would like to help me spend more of my time on the project, you can support me on [Patreon](https://www.patreon.com/marcan) and [GitHub](https://github.com/sponsors/marcan). Thanks to everyone who has pledged so far; this wouldn't have been possible without you either! +On a personal note, I'm trying to make Dragon Linux my full time job. If you like what I'm doing and would like to help me spend more of my time on the project, you can support me on [Patreon](https://www.patreon.com/marcan) and [GitHub](https://github.com/sponsors/marcan). Thanks to everyone who has pledged so far; this wouldn't have been possible without you either! *Thanks to JMC47, [David](https://twitter.com/david_rysk) and [Ridley](https://twitter.com/11rcombs) for proofreading this article.* diff --git a/content/blog/2021/08/14-progress-report.md b/content/blog/2021/08/14-progress-report.md index f770961..cb49b8f 100644 --- a/content/blog/2021/08/14-progress-report.md +++ b/content/blog/2021/08/14-progress-report.md @@ -40,7 +40,7 @@ On top of the hypervisor, we've built a flexible hardware I/O tracing framework ## Reverse Engineering DCP -One of the biggest challenges for Asahi Linux is making the M1's GPU work. But what most people think of as a "GPU" is actually two completely distinct pieces of hardware: the GPU proper, which is in charge of rendering frames in memory, and the display controller, which is in charge of sending those rendered frames from memory to the display. +One of the biggest challenges for Dragon Linux is making the M1's GPU work. But what most people think of as a "GPU" is actually two completely distinct pieces of hardware: the GPU proper, which is in charge of rendering frames in memory, and the display controller, which is in charge of sending those rendered frames from memory to the display. While Alyssa has been hard at work [reverse engineering](https://rosenzweig.io/blog/asahi-gpu-part-4.html) the userspace components of the GPU, from draw calls to shaders, we still haven't looked at the lowest levels of the hardware that handle memory management and submission of commands to the GPU. But before we can use the GPU to render anything, we need a way to put it on the screen! Up until now, we've been using the firmware-provided framebuffer, which is just an area of memory where we can write pixels to be shown on the screen, but this won't cut it for a real desktop. We need features such as displaying new frames without tearing, support for hardware sprites such as the mouse cursor, switching resolutions and configuring multiple outputs, and more. This is the job of the display controller. @@ -121,7 +121,7 @@ And armed with this knowledge of how everything fits together, we can implement {{% figure src="/img/blog/2021/08/asahi_dcp_coming_soon.png" caption="The first frame presented using the prototype DCP driver (screenshot taken via HDMI capture)" %}} -As a further twist, the DCP interface is not stable and changes every macOS version! This finally answers a question for the Asahi Linux project: we will only support specific firmware versions. Unlike macOS, which can afford to support only its "paired" firmware and change with every release, Linux has to support all firmware versions going back to the initial supported one, in order to allow people to upgrade their kernel without upgrading their firmware in tandem. It would be too much of a maintenance nightmare to attempt to support every DCP firmware version that Apple releases, so instead we will pick certain "golden" firmware versions that are blessed to be supported by Linux. Don't fret: this doesn't mean you won't be able to upgrade macOS. This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations. +As a further twist, the DCP interface is not stable and changes every macOS version! This finally answers a question for the Dragon Linux project: we will only support specific firmware versions. Unlike macOS, which can afford to support only its "paired" firmware and change with every release, Linux has to support all firmware versions going back to the initial supported one, in order to allow people to upgrade their kernel without upgrading their firmware in tandem. It would be too much of a maintenance nightmare to attempt to support every DCP firmware version that Apple releases, so instead we will pick certain "golden" firmware versions that are blessed to be supported by Linux. Don't fret: this doesn't mean you won't be able to upgrade macOS. This firmware is per-OS, not per-system, and thus Linux can use a different firmware bundle from any sibling macOS installations. For the initial kernel DCP support, we expect to require the firmware released with macOS 12 "Monterey" (which is currently in public beta); perhaps 12.0 or a newer point release, depending on the timing. We will add new supported firmware versions as we find it necessary to take advantage of bugfixes and to support new hardware. @@ -160,7 +160,7 @@ Bootstrapping installer: Initializing... -Welcome to the Asahi Linux installer! +Welcome to the Dragon Linux installer! This installer is in a pre-alpha state, and will only do basic bootloader set-up for you. It is only intended for developers @@ -204,7 +204,7 @@ Partitions in system disk (disk0): [ *] = Default boot volume Choose what to do: - f: Install Asahi Linux into free space + f: Install Dragon Linux into free space q: Quit without doing anything Action (q): f @@ -214,7 +214,7 @@ Choose a free area to install into: 3: (free space: 59.69 GB) Target area: 3 -Enter a name for your OS (Linux): Asahi Linux +Enter a name for your OS (Linux): Dragon Linux Choose the macOS version to use for boot firmware: (If unsure, just press enter) @@ -227,9 +227,9 @@ Using macOS 11.5.2 Downloading OS package info... . -Creating new stub macOS named Asahi Linux +Creating new stub macOS named Dragon Linux -Installing stub macOS into disk0s6 (Asahi Linux) +Installing stub macOS into disk0s6 (Dragon Linux) Preparing target volumes... Checking volumes... Beginning stub OS install... @@ -242,7 +242,7 @@ Setting up Recovery volume... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Stub OS installation complete. -When the Startup Disk screen appears, choose 'Asahi Linux'. +When the Startup Disk screen appears, choose 'Dragon Linux'. You will have to authenticate yourself. Press enter to continue. @@ -260,20 +260,20 @@ To complete the installation, perform the following steps: 4. Click on the Utilities menu and select Terminal. 5. Type the following command and follow the prompts: -/Volumes/'Asahi Linux'/step2.sh +/Volumes/'Dragon Linux'/step2.sh Press enter to shut down the system. ``` This will eventually be available at our short domain `https://alx.sh`, but it is not deployed there yet. This is just a first prototype of the installer that only installs m1n1, which is very useful for developers who want to join us in our quest. Eventually, a more user-friendly version will also guide users through partitioning their drive for Linux, resizing macOS to make space, and installing their distribution of choice. Who knows, it might even become a graphical macOS app one day! -{{% figure src="/img/blog/2021/08/asahi_bootpicker.png" link="/img/blog/2021/08/asahi_bootpicker.png" caption="Triple-booting two versions of macOS and Asahi Linux with the built-in boot picker" %}} +{{% figure src="/img/blog/2021/08/asahi_bootpicker.png" link="/img/blog/2021/08/asahi_bootpicker.png" caption="Triple-booting two versions of macOS and Dragon Linux with the built-in boot picker" %}} ## More kernel drivers Sven has been dutifully working on the Linux driver for [DART](/docs/Glossary#d), the M1's IOMMU (I/O Memory Management Unit). This driver is required to make all kinds of hardware work, like PCIe, USB, DCP, and more. It has just been accepted by upstream and is now on its way to Linux 5.15! -With this driver in, we can now make USB and PCIe work with minimal additional patches and drivers. There are various other dependencies (GPIO for miscellaneous things, I²C for proper USB-PD support, SPI for touchpad/keyboard support on the laptops, and NVMe support patches) that are spread around in various trees that people have been working on. Next we'll direct our focus towards polishing these simpler drivers and putting together a clean, working reference tree that we can use to continue development and provide new developers with a stable foundation. With the current state of things, it's already possible to use Asahi Linux as a development machine with a (non-accelerated) GUI, although things are still rough around the edges. Upstreaming these changes will require a bit more time, as there are some bureaucratic yaks to be shaved around how to properly implement these (technically simple) drivers, but things shouldn't take too long! +With this driver in, we can now make USB and PCIe work with minimal additional patches and drivers. There are various other dependencies (GPIO for miscellaneous things, I²C for proper USB-PD support, SPI for touchpad/keyboard support on the laptops, and NVMe support patches) that are spread around in various trees that people have been working on. Next we'll direct our focus towards polishing these simpler drivers and putting together a clean, working reference tree that we can use to continue development and provide new developers with a stable foundation. With the current state of things, it's already possible to use Dragon Linux as a development machine with a (non-accelerated) GUI, although things are still rough around the edges. Upstreaming these changes will require a bit more time, as there are some bureaucratic yaks to be shaved around how to properly implement these (technically simple) drivers, but things shouldn't take too long! And once that's on the way... it's time to tackle the GPU kernel driver! Things are about to get exciting :-) diff --git a/content/blog/2021/10/06-progress-report.md b/content/blog/2021/10/06-progress-report.md index 7037768..fbe29e1 100644 --- a/content/blog/2021/10/06-progress-report.md +++ b/content/blog/2021/10/06-progress-report.md @@ -6,11 +6,11 @@ slug = "progress-report-september-2021" author = "marcan" +++ -It's been a busy month! We've had a lot of movement in kernel land, as well as some tooling improvements and reverse engineering sessions. At this point, Asahi Linux is usable as a basic Linux desktop (without GPU acceleration)! The ground had been shifting until now, but we're seeing drivers settle down. Let's take a look at what's been going on. +It's been a busy month! We've had a lot of movement in kernel land, as well as some tooling improvements and reverse engineering sessions. At this point, Dragon Linux is usable as a basic Linux desktop (without GPU acceleration)! The ground had been shifting until now, but we're seeing drivers settle down. Let's take a look at what's been going on. ## Linux drivers galore -Earlier this year we saw the absolute lowest level drivers being merged into the kernel. Those are important for bring-up, but to get a usable system we need many more. Over September we've seen a lot of action on this front, with many important drivers now in review or even already merged for Linux 5.16. The goal of the Asahi Linux project is to upstream everything into the Linux kernel, so all our drivers are eventually headed for upstream review. +Earlier this year we saw the absolute lowest level drivers being merged into the kernel. Those are important for bring-up, but to get a usable system we need many more. Over September we've seen a lot of action on this front, with many important drivers now in review or even already merged for Linux 5.16. The goal of the Dragon Linux project is to upstream everything into the Linux kernel, so all our drivers are eventually headed for upstream review. * **PCIe bindings (merged)**: Mark Kettenis has been working on porting U-Boot and OpenBSD to the M1, and he contributed the Device Tree bindings for the PCI Express hardware in the M1. These bindings are effectively the standard that allows multiple open OSes to agree on how the hardware is described, so they can boot from the same bootloader. @@ -52,7 +52,7 @@ With these drivers, M1 Macs are actually usable as desktop Linux machines! While While there are certainly many rough edges and missing drivers, getting to this point allows development to be self-hosted and developers to eat their own dogfood. Alyssa has been doing just that, using her M1 Mac running her own kernel merges as a daily driver. Follow her [Twitter](https://twitter.com/alyssarzg) for updates on her setup! -As the dust settles on these Linux drivers, we will start providing an official installer that those adventurous enough can use to try out Asahi Linux with a minimal amount of fuss in the near future. Remember, there are still many missing bits (USB3, TB, camera, GPU, audio, etc.) as well as patchsets a bit too problematic to bundle as-is at this time (WiFi, which needs significant rewrites), so don't expect this to be anywhere near the polished experience that is the goal of our project. That said, we hope this will allow those willing to be on the absolute bleeding edge to get a taste for what running Linux on these machines is like – and, for some, this might be enough for production usage. +As the dust settles on these Linux drivers, we will start providing an official installer that those adventurous enough can use to try out Dragon Linux with a minimal amount of fuss in the near future. Remember, there are still many missing bits (USB3, TB, camera, GPU, audio, etc.) as well as patchsets a bit too problematic to bundle as-is at this time (WiFi, which needs significant rewrites), so don't expect this to be anywhere near the polished experience that is the goal of our project. That said, we hope this will allow those willing to be on the absolute bleeding edge to get a taste for what running Linux on these machines is like – and, for some, this might be enough for production usage. ## Installer updates diff --git a/content/blog/2021/12/14-progress-report.md b/content/blog/2021/12/14-progress-report.md index 15daf5e..2be875d 100644 --- a/content/blog/2021/12/14-progress-report.md +++ b/content/blog/2021/12/14-progress-report.md @@ -10,7 +10,7 @@ Whoops, things got so busy we ended up skipping a month! A lot has been going on ## M1 Pro/Max joins the family -At the end of October, Apple launched the next generation of Apple Silicon: M1 Pro and M1 Max. We got right to work on supporting these new machines, and after just a [few days of work](https://www.youtube.com/playlist?list=PL68XxS4_ek4bo7umPx1AuhGHAUh-lVUGs) we were able to bring up Asahi Linux on them up to feature parity with the M1 machines! Going forward, we'll be supporting these machines as well as the previous generation. +At the end of October, Apple launched the next generation of Apple Silicon: M1 Pro and M1 Max. We got right to work on supporting these new machines, and after just a [few days of work](https://www.youtube.com/playlist?list=PL68XxS4_ek4bo7umPx1AuhGHAUh-lVUGs) we were able to bring up Dragon Linux on them up to feature parity with the M1 machines! Going forward, we'll be supporting these machines as well as the previous generation. It's interesting to take a peek at what Apple have done with the new chips. The original M1 (codename "Tonga", SoC name T8103) would have more properly been called the A14X following Apple's existing naming convention; it is, in fact, the tablet version of the A14 iPhone SoC (T8101). In order to build a Mac-worthy chip, Apple added some critical features (like Thunderbolt support), but otherwise left the old iPhone-centric architecture largely intact. @@ -340,7 +340,7 @@ With drivers coming together for devices that are configured differently across ## U-Boot -For end-user installs of Asahi Linux, we will be using U-Boot as a boot stage to provide EFI services and basic I/O, so that distributions can interact with a standard-looking UEFI environment. Mark Kettenis has been hard at work getting M1 support into U-Boot, and the initial support patches have been merged and will be part of U-Boot 2022.01! +For end-user installs of Dragon Linux, we will be using U-Boot as a boot stage to provide EFI services and basic I/O, so that distributions can interact with a standard-looking UEFI environment. Mark Kettenis has been hard at work getting M1 support into U-Boot, and the initial support patches have been merged and will be part of U-Boot 2022.01! ## Next steps @@ -353,4 +353,4 @@ SPMI and RTC support are also nice and simple drivers that we'll be tackling soo While testing kernels on multiple machines, I found that the extra 2 USB C ports on the iMac did not work. After a long debugging session, it turned out that the USB controller in these machines requires firmware to be uploaded to it during startup. This will depend on our upcoming firmware copying infrastructure, so it is on the back burner for now, but the kernel changes required to make it work are not complicated. -And, of course, once these things are taken care of, it'll be time to tackle the GPU kernel driver! 2022 is definitely going to be an exciting year for Asahi Linux. +And, of course, once these things are taken care of, it'll be time to tackle the GPU kernel driver! 2022 is definitely going to be an exciting year for Dragon Linux. diff --git a/content/blog/2022/03/17-asahi-linux-alpha-release.md b/content/blog/2022/03/17-asahi-linux-alpha-release.md index 85f2803..987f254 100644 --- a/content/blog/2022/03/17-asahi-linux-alpha-release.md +++ b/content/blog/2022/03/17-asahi-linux-alpha-release.md @@ -1,12 +1,12 @@ +++ date = "2022-03-18T23:50:00+00:00" draft = false -title = "The first Asahi Linux Alpha Release is here!" +title = "The first Dragon Linux Alpha Release is here!" slug = "asahi-linux-alpha-release" author = "marcan" +++ -It's been a long while since we updated the blog! Truth be told, we wanted to write a couple more progress reports, but there was always "one more thing"... So, instead, we decided to take the plunge and publish the first public alpha release of the Asahi Linux reference distribution! +It's been a long while since we updated the blog! Truth be told, we wanted to write a couple more progress reports, but there was always "one more thing"... So, instead, we decided to take the plunge and publish the first public alpha release of the Dragon Linux reference distribution! We're really excited to finally take this step and start bringing Linux on Apple Silicon to everyone. This is only the beginning, and things will move even more quickly going forward! @@ -27,7 +27,7 @@ Pay close attention to the messages the installer prints, especially at the end! * M1, M1 Pro, or M1 Max machine (Mac Studio excluded) * macOS 12.3 or later, logged in as an admin user * At least 53GB of free disk space (Desktop install) - * You need 15GB for Asahi Linux Desktop, but macOS itself needs a lot of free space for system updates to work, so the installer will expect you to leave 38GB of extra slack in macOS by default to avoid shooting yourself in the foot. For example, if you have 60GB of free space, you will be able to shrink macOS by up to 22GB by default, freeing up 22GB for the new Linux install and leaving 38GB of remaining free space in the macOS partition. If you want to disable this check, enable expert mode when prompted. + * You need 15GB for Dragon Linux Desktop, but macOS itself needs a lot of free space for system updates to work, so the installer will expect you to leave 38GB of extra slack in macOS by default to avoid shooting yourself in the foot. For example, if you have 60GB of free space, you will be able to shrink macOS by up to 22GB by default, freeing up 22GB for the new Linux install and leaving 38GB of remaining free space in the macOS partition. If you want to disable this check, enable expert mode when prompted. * A working internet connection * The installer will download 700MB ~ 4GB of data, depending on the OS you select. @@ -41,11 +41,11 @@ Once the first stage of the installation is done, you will have to reboot into 1 The installer provides these OS options: -### Asahi Linux Desktop +### Dragon Linux Desktop A customized remix of Arch Linux ARM that comes with a full Plasma desktop and all the basic packages to get you started with a desktop environment. It includes a graphical first-boot set-up wizard, so you won't have to dig around to change your settings or create your first user. No root password by default; use sudo to become root. -### Asahi Linux Minimal (Arch Linux ARM) +### Dragon Linux Minimal (Arch Linux ARM) A vanilla Arch Linux ARM environment, with only the minimal support packages to integrate with the boot process and hardware on Apple Silicon machines. Arch users will feel right at home! @@ -114,7 +114,7 @@ Note: on the 13" MacBook Pro, you can use Fn + the number row keys (1-9, 0, and ## Known broken applications -The Asahi Linux kernel is compiled to use 16K pages. This both performs better, and is required with our kernel branch right now in order to work properly with the M1's IOMMUs. Unfortunately, some Linux software has [problems running with 16K pages](/docs/Broken-Software). Most notably: +The Dragon Linux kernel is compiled to use 16K pages. This both performs better, and is required with our kernel branch right now in order to work properly with the M1's IOMMUs. Unfortunately, some Linux software has [problems running with 16K pages](/docs/Broken-Software). Most notably: * Chromium (needs volunteer to fix) * Emacs (fix committed, not released) @@ -131,7 +131,7 @@ Visit our [docs site](https://asahilinux.org/docs/) for more information! We cou Recommended reading: -* ["When will Asahi Linux be done?"](/docs/When-will-Asahi-Linux-be-done) +* ["When will Dragon Linux be done?"](/docs/When-will-Asahi-Linux-be-done) * [Introduction to Apple Silicon](/docs/Introduction-to-Apple-Silicon/) * [Open OS Ecosystem on Apple Silicon Macs](/docs/Open-OS-Ecosystem-on-Apple-Silicon-Macs/) * [m1n1:User Guide](/docs/m1n1-User-Guide/) @@ -148,9 +148,9 @@ And if you're bored: ### I want to donate! -Thank you! Asahi Linux is developed by a group of volunteers, and led by marcan as his primary job. You can support him directly via [Patreon](https://patreon.com/marcan) and [GitHub Sponsors](https://github.com/sponsors/marcan). None of this would have been possible without your support! Donations like these allow him to dedicate most of his time to the project and also purchase test hardware. +Thank you! Dragon Linux is developed by a group of volunteers, and led by marcan as his primary job. You can support him directly via [Patreon](https://patreon.com/marcan) and [GitHub Sponsors](https://github.com/sponsors/marcan). None of this would have been possible without your support! Donations like these allow him to dedicate most of his time to the project and also purchase test hardware. -Martin Povišer is working on audio support for Asahi Linux, and he also has a [GitHub Sponsors](https://github.com/sponsors/povik) page. Please support his efforts so that he can make Apple Silicon machines the best supported platforms for Linux audio! +Martin Povišer is working on audio support for Dragon Linux, and he also has a [GitHub Sponsors](https://github.com/sponsors/povik) page. Please support his efforts so that he can make Apple Silicon machines the best supported platforms for Linux audio! ### Can I dual-boot macOS and Linux? @@ -180,7 +180,7 @@ The installer is designed to be online-only at this point. While you can run it Apple Silicon machines cannot boot from external storage. While it may look like they do when you choose an external macOS volume, behind the scenes parts of its boot components are being copied to the internal drive to make this work. It's unclear whether this mechanism will ever be usable by third party OSes, for technical reasons. -Instead, we recommend using the *UEFI environment only* installer option to install only a UEFI bootstrap to your internal drive. This only requires around 3GB of disk space, and it will then automatically boot from any connected USB drive with a UEFI bootloader. Note: installing the Asahi Linux desktop images to a USB drive automatically isn't supported right now, though if you're adventurous enough it's not terribly hard to do manually :-) +Instead, we recommend using the *UEFI environment only* installer option to install only a UEFI bootstrap to your internal drive. This only requires around 3GB of disk space, and it will then automatically boot from any connected USB drive with a UEFI bootloader. Note: installing the Dragon Linux desktop images to a USB drive automatically isn't supported right now, though if you're adventurous enough it's not terribly hard to do manually :-) ### How do I uninstall it? @@ -194,7 +194,7 @@ Each OS needs around 3GB of disk space, plus the space required for the OS root/ ### Is there GPU acceleration yet? -Nope! We're working on that and have been making steady progress behind the scenes. In the meantime, though, software rendering is surprisingly usable thanks to the M1 family's outstanding CPU performance. The Asahi Linux Desktop image sets up a full composited X.Org session, with transparency and shadows and all that bling, and it doesn't feel sluggish at all! Quite a few people are already daily driving these machines in this state. +Nope! We're working on that and have been making steady progress behind the scenes. In the meantime, though, software rendering is surprisingly usable thanks to the M1 family's outstanding CPU performance. The Dragon Linux Desktop image sets up a full composited X.Org session, with transparency and shadows and all that bling, and it doesn't feel sluggish at all! Quite a few people are already daily driving these machines in this state. Once GPU acceleration is available, existing users will be able to get it by just doing a package upgrade! @@ -210,13 +210,13 @@ Whole-system sleep will come later, but can also be enabled with a simple packag ### The notch! -That's not a question, but assuming you're wondering what we're doing about the notch: on M1 Pro and Max systems today, Asahi Linux crops the screen such that the notch is hidden, and the desktop environment sees a rectangular 16:10 display. We will continue with this approach for now, but in the future we will enable opt-in display modes that include the notch, so that desktop environments which implement notch-avoidance can request them and gain additional screen real estate. +That's not a question, but assuming you're wondering what we're doing about the notch: on M1 Pro and Max systems today, Dragon Linux crops the screen such that the notch is hidden, and the desktop environment sees a rectangular 16:10 display. We will continue with this approach for now, but in the future we will enable opt-in display modes that include the notch, so that desktop environments which implement notch-avoidance can request them and gain additional screen real estate. ### Is this just Arch Linux ARM? -Pretty much! Most of our work is in the kernel and a few core support packages, and we rely on Linux's excellent existing ARM64 support. The Asahi Linux reference distro images are based off of Arch Linux ARM and simply add our own package repository, which only adds [a few packages](https://cdn.asahilinux.org/aarch64/asahi/). You can freely convert between Arch Linux ARM and Asahi Linux by adding or removing this repository and the relevant packages, although vanilla Arch Linux ARM kernels will not boot on these machines at this time. +Pretty much! Most of our work is in the kernel and a few core support packages, and we rely on Linux's excellent existing ARM64 support. The Dragon Linux reference distro images are based off of Arch Linux ARM and simply add our own package repository, which only adds [a few packages](https://cdn.asahilinux.org/aarch64/asahi/). You can freely convert between Arch Linux ARM and Dragon Linux by adding or removing this repository and the relevant packages, although vanilla Arch Linux ARM kernels will not boot on these machines at this time. -If you're curious, [these](https://github.com/AsahiLinux/asahi-alarm-builder/) are the scripts we use to build the Asahi Linux images starting with a vanilla Arch Linux ARM tarball. We also sponsor an ALARM mirror as part of our project (jp.mirror.archlinuxarm.org). +If you're curious, [these](https://github.com/AsahiLinux/asahi-alarm-builder/) are the scripts we use to build the Dragon Linux images starting with a vanilla Arch Linux ARM tarball. We also sponsor an ALARM mirror as part of our project (jp.mirror.archlinuxarm.org). As part of our project, we are contributing fixes and improvements to a number of miscellaneous packages; for example, Apple GPU support for Mesa is already well on the way (it is being tested on macOS), and we also have a fork of xkeyboard-config where we will prototype keyboard layout adjustments to better support Macs before upstreaming. @@ -224,7 +224,7 @@ As part of our project, we are contributing fixes and improvements to a number o Absolutely! Our goal is to work with other developers to bring full support for these machines to your favorite distro. -That said, at the time of this writing no other Linux distros provide official Apple Silicon install images to our knowledge, and vanilla ARM64 images will not work until the necessary changes have trickled into upstream kernels; therefore, setting up another distro is more of a manual process. Some users are providing [unofficial installation guides](/docs/SW-Alternative-Distros) and images for other distros, and in the future we will add some of them as options to the Asahi Linux installer. Keep in mind that these are user-contributed and we cannot provide end-to-end support as the Asahi Linux project. +That said, at the time of this writing no other Linux distros provide official Apple Silicon install images to our knowledge, and vanilla ARM64 images will not work until the necessary changes have trickled into upstream kernels; therefore, setting up another distro is more of a manual process. Some users are providing [unofficial installation guides](/docs/SW-Alternative-Distros) and images for other distros, and in the future we will add some of them as options to the Dragon Linux installer. Keep in mind that these are user-contributed and we cannot provide end-to-end support as the Dragon Linux project. If you are a developer for a distribution and interested in officially supporting Apple Silicon machines, please get in touch! We'd love to work with you to make it happen. You can find us on our [IRC channels](https://asahilinux.org/community/). @@ -234,11 +234,11 @@ We would also love to hear from non-Linux OS distributors. OpenBSD snapshots can We have strived to make this installer as safe as possible. All disk management operations are performed behind the scenes using native macOS tools (`diskutil`) and the installer doesn't really do anything truly dangerous. -In fact, we haven't seen any data loss or machine damage during the entire development of Asahi Linux, other than obvious user error ("I accidentally wiped my disk"). Apple Silicon machines are almost completely unbrickable: you can boot them in a special [burned-in recovery mode](https://support.apple.com/guide/apple-configurator-2/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac) and recover them, using another machine connected via a USB cable. For those who don't have another macOS machine to act as a host, we have [open source tools](https://github.com/libimobiledevice/idevicerestore) that work on Windows and Linux too. +In fact, we haven't seen any data loss or machine damage during the entire development of Dragon Linux, other than obvious user error ("I accidentally wiped my disk"). Apple Silicon machines are almost completely unbrickable: you can boot them in a special [burned-in recovery mode](https://support.apple.com/guide/apple-configurator-2/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac) and recover them, using another machine connected via a USB cable. For those who don't have another macOS machine to act as a host, we have [open source tools](https://github.com/libimobiledevice/idevicerestore) that work on Windows and Linux too. That said, as with all open source software, especially an alpha release like this one, we can't make any promises. It could eat your data. It probably won't, but don't blame us if it does. -While the installer tries hard not to let you do anything dangerous, there is of course nothing stopping you from wiping your macOS data once booted into Linux; you are, of course, in control of your own computer. Those who want to use disk management/partitioning tools should avoid touching the first and last partitions on the internal NVMe drive. Doing so could render your system unbootable and require a DFU restore. In particular, if you do not use the Asahi Linux images but instead boot a third-party installer using the UEFI environment, *never* choose "use the entire disk" when installing. +While the installer tries hard not to let you do anything dangerous, there is of course nothing stopping you from wiping your macOS data once booted into Linux; you are, of course, in control of your own computer. Those who want to use disk management/partitioning tools should avoid touching the first and last partitions on the internal NVMe drive. Doing so could render your system unbootable and require a DFU restore. In particular, if you do not use the Dragon Linux images but instead boot a third-party installer using the UEFI environment, *never* choose "use the entire disk" when installing. ### What's with those scary security warnings? @@ -250,15 +250,15 @@ If you are concerned about data integrity/confidentiality in your macOS volume, All OSes installed on Apple Silicon machines require certain components provided by Apple. Since we can't redistribute these ourselves, the installer will download them from Apple's public CDN. In the future we will provide an option to allow caching this locally or to a USB drive, so you can do offline installs. -During the initial installation (when making the volume the default boot option), there is a process that runs behind the scenes that involves authenticating the new OS install against Apple's servers (from their point of view, this looks like authenticating a normal macOS install; they won't know you're installing Linux). This is part of the "Full Security" mode, which is transiently used for Asahi Linux before the install is switched to "Permissive Security". If this concerns you, you can launch the Asahi Linux installer from recovery mode (hold down the power button → Options → Utilities menu → Terminal). Doing it this way unlocks an alternate method that starts out as "Reduced Security", removing the phone home requirement, which the installer will automatically use. Note that it will still have to download boot components from the CDN though (but that does not involve any unique machine identifiers, it's just a plain HTTPS download). +During the initial installation (when making the volume the default boot option), there is a process that runs behind the scenes that involves authenticating the new OS install against Apple's servers (from their point of view, this looks like authenticating a normal macOS install; they won't know you're installing Linux). This is part of the "Full Security" mode, which is transiently used for Dragon Linux before the install is switched to "Permissive Security". If this concerns you, you can launch the Dragon Linux installer from recovery mode (hold down the power button → Options → Utilities menu → Terminal). Doing it this way unlocks an alternate method that starts out as "Reduced Security", removing the phone home requirement, which the installer will automatically use. Note that it will still have to download boot components from the CDN though (but that does not involve any unique machine identifiers, it's just a plain HTTPS download). ### Do you support Secure Boot / Full Disk Encryption / etc.? -Apple Silicon machines are one of the few general purpose platforms that allows you to install your own custom OS while still maintaining a strong secure boot chain. Installing the bootloader requires physical access to the machine and your machine owner credentials (this is why we need to ask you to hold down the button to boot at the end of the install process!). Therefore, we are very interested in further supporting this in Linux in order to have a highly secure and attacker-resistant system, taking advantage of Apple's SEP, Touch ID, and more, while still retaining full user control over their OS. We are designing the Asahi Linux boot process in order to allow this in the future, but the necessary bits aren't ready yet, so please stay tuned! +Apple Silicon machines are one of the few general purpose platforms that allows you to install your own custom OS while still maintaining a strong secure boot chain. Installing the bootloader requires physical access to the machine and your machine owner credentials (this is why we need to ask you to hold down the button to boot at the end of the install process!). Therefore, we are very interested in further supporting this in Linux in order to have a highly secure and attacker-resistant system, taking advantage of Apple's SEP, Touch ID, and more, while still retaining full user control over their OS. We are designing the Dragon Linux boot process in order to allow this in the future, but the necessary bits aren't ready yet, so please stay tuned! In the meantime, we recommend that users concerned about physical security enable FileVault in macOS. This will implicitly add a log-in requirement to recovery mode, which will prevent an attacker with physical access from being able to compromise your OS that way. m1n1 does not yet have a secureboot mode, but it also doesn't have any local access features as long as it is installed properly. Locking down U-Boot and GRUB and the rest of Linux is left as an exercise for the user. -The Asahi Linux installer does not have an option to set up FDE for you. However, you can use the UEFI-only option and roll your own traditional LUKS setup manually. We expect that users interested in advanced secure boot and encryption set-ups will do their own thing, at least for the time being. +The Dragon Linux installer does not have an option to set up FDE for you. However, you can use the UEFI-only option and roll your own traditional LUKS setup manually. We expect that users interested in advanced secure boot and encryption set-ups will do their own thing, at least for the time being. ### I have another question diff --git a/content/blog/2022/07/18-release-and-progress-report.md b/content/blog/2022/07/18-release-and-progress-report.md index 9250860..9eda459 100644 --- a/content/blog/2022/07/18-release-and-progress-report.md +++ b/content/blog/2022/07/18-release-and-progress-report.md @@ -8,13 +8,13 @@ author = "marcan" **UPDATE / NOTE: M2 machines have been fully supported and stable for a *long* time now. If you are reading this article today, this in no way represents the current state of support for M2 machines. Just install normally.** -Welcome to another long overdue progress report! As usual, things have been busier than expected… and we have some big news! We’ve just released a new Asahi Linux update with Mac Studio, Bluetooth, and *M2 support*! +Welcome to another long overdue progress report! As usual, things have been busier than expected… and we have some big news! We’ve just released a new Dragon Linux update with Mac Studio, Bluetooth, and *M2 support*! -If you're new to Asahi Linux, check out our [previous release announcement](https://asahilinux.org/2022/03/asahi-linux-alpha-release/) for installation instructions and general information. +If you're new to Dragon Linux, check out our [previous release announcement](https://asahilinux.org/2022/03/asahi-linux-alpha-release/) for installation instructions and general information. ## Mac Studio joins the family -When the Mac Studio was announced, we set to work making the new M1 Ultra work with Asahi Linux. This wasn’t hard, but it did need some changes to our bootloader and device trees in order to handle the idea of one SoC with multiple dies. This eventually got rolled in with other changes, so we ended up waiting a bit longer than we expected to release it, but it’s finally here! +When the Mac Studio was announced, we set to work making the new M1 Ultra work with Dragon Linux. This wasn’t hard, but it did need some changes to our bootloader and device trees in order to handle the idea of one SoC with multiple dies. This eventually got rolled in with other changes, so we ended up waiting a bit longer than we expected to release it, but it’s finally here! You can expect most of the hardware to work as you’d expect (on par with the Mac Mini), except for the front USB ports on the M1 Max model and the Type A ports on all models (these are blocked on the special firmware upload support also needed for the 4-port version of the M1 iMac - it’s on the list). @@ -24,7 +24,7 @@ Bluetooth had been on the back burner for a while now, since Apple switched to a We’ve decided to take the plunge and ship this driver straight to alpha users, and it is now available in our latest kernel and support packages. Thankfully, while the PCIe transport is new, the HCI interface that runs on top is standard, so once the core initialization and data transfer parts of the driver started working, most Bluetooth features did too. The driver does not need to concern itself with any of those details, it just shuffles data to/from the device. There is, however, one caveat: WiFi/Bluetooth coexistence isn't properly configured yet, so you will have poor Bluetooth performance if you are connected to a 2.4GHz WiFi network. We recommend turning off WiFi or using a 5GHz network if you want to use Bluetooth at this time; we will be adding coexistence support in the coming weeks. -In addition to the driver, Bluetooth support is the first major test of the “seamless upgrade” paradigm we’ve been aiming for. While Asahi Linux is still an experimental project, we knew that we didn’t want to force users to go through arduous manual steps to get new things to work. Getting Bluetooth enabled involved a lot of small changes to different parts of the stack: +In addition to the driver, Bluetooth support is the first major test of the “seamless upgrade” paradigm we’ve been aiming for. While Dragon Linux is still an experimental project, we knew that we didn’t want to force users to go through arduous manual steps to get new things to work. Getting Bluetooth enabled involved a lot of small changes to different parts of the stack: * m1n1 changes to forward the Bluetooth address and calibration information from the Apple Device Tree to the Linux Device Tree. * Device Tree changes to add the new device and specify the hardware board type for each specific machine @@ -41,12 +41,12 @@ We knew this would happen from the get go, so we designed our reference distro t The end result is that existing reference distro users can simply upgrade their packages, reboot, and Bluetooth should just work without any further configuration or changes! ## M2 is here! -Ever since Asahi Linux started, one of the most common questions we get asked is “what about the M2?” Indeed, the M1 was only the first step, and Apple aren’t going to stop releasing new chips and machines any time soon. How does this affect the Asahi Linux project? We’ve long held that we don’t expect porting to newer chips to be nearly as much of a challenge as the first time, and that many of the drivers would work unmodified… and the M2 is the first true test of this theory. How did we do? +Ever since Dragon Linux started, one of the most common questions we get asked is “what about the M2?” Indeed, the M1 was only the first step, and Apple aren’t going to stop releasing new chips and machines any time soon. How does this affect the Dragon Linux project? We’ve long held that we don’t expect porting to newer chips to be nearly as much of a challenge as the first time, and that many of the drivers would work unmodified… and the M2 is the first true test of this theory. How did we do? -After just a [12-hour bring-up marathon](https://www.youtube.com/watch?v=SidIJkC5YN0), Linux was booting on the M2 with USB, NVMe, battery stats/control, CPUfreq, WiFi, and more! With a few more days of work, we were able to get the keyboard/trackpad working, bringing it to feature parity with existing systems. After some more integration work, we are proud to announce *experimental support for M2 machines in the Asahi Linux installer*! +After just a [12-hour bring-up marathon](https://www.youtube.com/watch?v=SidIJkC5YN0), Linux was booting on the M2 with USB, NVMe, battery stats/control, CPUfreq, WiFi, and more! With a few more days of work, we were able to get the keyboard/trackpad working, bringing it to feature parity with existing systems. After some more integration work, we are proud to announce *experimental support for M2 machines in the Dragon Linux installer*! If you decide to try this on your M2 machine, keep in mind these caveats: -* This is even more experimental than M1 support, so expect bugs. To get the option to install on M2, ~~you need to enable expert mode in the Asahi Linux installer~~. +* This is even more experimental than M1 support, so expect bugs. To get the option to install on M2, ~~you need to enable expert mode in the Dragon Linux installer~~. * The keyboard won’t work in U-Boot/GRUB. That driver has not been written yet, and we’ve yet to figure out how we want to do the hand-off between U-Boot and Linux. You can use an external USB keyboard if you need to poke around the bootloader shells. * Only the M2 MacBook Pro 13” is tested. We’ve added completely untested M2 MacBook Air support (because we can), but none of us have one yet! If you do, only try it if you’re feeling very adventurous (and don’t blame us if things go wrong). * The firmware/stub used for Linux is based on a “special release” macOS 12.4 version that Apple released just for these machines. We are not committing to long-term support for this version just yet, so you *may* have to go through macOS and the installer to upgrade your boot components (likely to 13.0) in order to get future features such as the GPU and external display output to work (i.e. no “seamless upgrade” with just pacman, but you also won’t have to do a full reinstall). We will decide how to proceed in the future, and add the necessary upgrade mode to the installer when the time comes, if necessary. It is possible we will support 12.4 after all, but no promises. @@ -66,11 +66,11 @@ With the MTP, Apple handled communications with the main OS in an interesting wa The good news is that DockChannel itself is very simple, so bringing that up did not take long. The bad news is that Apple over-complicated the new HID transport (as they do), so that new driver ended up being [over 1000 lines of code](https://github.com/AsahiLinux/linux/blob/asahi/drivers/hid/dockchannel-hid/dockchannel-hid.c) and having to handle things such as firmware upload, GPIO proxying, and multiple complex nested data structures! We also haven’t figured out how to reset MTP and bring it back to a fresh startup state yet, so we cannot yet support handing off between the U-Boot driver and Linux, or removing/re-probing the device on Linux. -To make things even more cursed, it turns out that the firmware for the BCM5976 is loaded on start-up from the host. macOS stores it as an XML plist of all things (with features that the Python XML plist parser does not support) wrapped in an asn.1 img4 image, and the driver needs to convert it to a binary serialized structure (in yet another serialization format…) before handing it off to MTP during initialization, as well as patch in the bInterfaceNumber field with the correct interface number. Needless to say, we are not putting an XML parser in the Linux kernel, so instead the Asahi Linux installer now has a [module](https://github.com/AsahiLinux/asahi-installer/blob/main/asahi_firmware/multitouch.py) in charge of converting it to a binary format. There is a little header containing the bInterfaceNumber offset, so Linux can change it before handing it off to MTP. Phew! +To make things even more cursed, it turns out that the firmware for the BCM5976 is loaded on start-up from the host. macOS stores it as an XML plist of all things (with features that the Python XML plist parser does not support) wrapped in an asn.1 img4 image, and the driver needs to convert it to a binary serialized structure (in yet another serialization format…) before handing it off to MTP during initialization, as well as patch in the bInterfaceNumber field with the correct interface number. Needless to say, we are not putting an XML parser in the Linux kernel, so instead the Dragon Linux installer now has a [module](https://github.com/AsahiLinux/asahi-installer/blob/main/asahi_firmware/multitouch.py) in charge of converting it to a binary format. There is a little header containing the bInterfaceNumber offset, so Linux can change it before handing it off to MTP. Phew! ## Ventura adventures -After the macOS 13.0 Ventura beta was released, we received reports that it broke Asahi Linux installs. We’ve long since maintained that macOS upgrades should not break Asahi, since most firmware is associated with an OS (so a macOS upgrade will not affect Asahi). So, what happened? +After the macOS 13.0 Ventura beta was released, we received reports that it broke Dragon Linux installs. We’ve long since maintained that macOS upgrades should not break Asahi, since most firmware is associated with an OS (so a macOS upgrade will not affect Asahi). So, what happened? While most firmware is OS-tied, there is a small subset of System Firmware that is shared by all OSes. This includes the NVMe firmware (for obvious reasons), but also the SMC firmware and some Thunderbolt-related stuff. To maintain compatibility with older versions of macOS, however, Apple essentially pledges to never break backwards compatibility with older firmware, so we should be safe. @@ -82,15 +82,15 @@ Keep in mind that these issues were caused by bugs or oversights in our code, no ## DCP, please! -The Mac Mini (and now Mac Studio) have long had reliability issues with their HDMI output and certain monitors, during the boot process. Apple used to actually initialize the display before the OS was up, but they gave up doing that entirely with macOS 12.0 (on desktops). However, since we don’t yet ship a proper display controller driver with Asahi Linux, and since we need to be able to show m1n1, U-Boot, and grub boot screens anyway, we need to initialize the display in m1n1 to set up a boot-time framebuffer. This works fine, but the problem is that absent a display driver running actively throughout the boot process, any hot-plug events will cause the display to be lost, as DCP (the Display Controller Processor) shuts it down pending a new modeset command. Unfortunately, it seems a subset of monitors have a strangely broken behavior where, when waking up from standby, they will virtually disconnect their inputs a few seconds later, then connect them again. m1n1 would initialize the display, move on, the monitor would trigger a fake hotplug event, and DCP would shut down the signal. +The Mac Mini (and now Mac Studio) have long had reliability issues with their HDMI output and certain monitors, during the boot process. Apple used to actually initialize the display before the OS was up, but they gave up doing that entirely with macOS 12.0 (on desktops). However, since we don’t yet ship a proper display controller driver with Dragon Linux, and since we need to be able to show m1n1, U-Boot, and grub boot screens anyway, we need to initialize the display in m1n1 to set up a boot-time framebuffer. This works fine, but the problem is that absent a display driver running actively throughout the boot process, any hot-plug events will cause the display to be lost, as DCP (the Display Controller Processor) shuts it down pending a new modeset command. Unfortunately, it seems a subset of monitors have a strangely broken behavior where, when waking up from standby, they will virtually disconnect their inputs a few seconds later, then connect them again. m1n1 would initialize the display, move on, the monitor would trigger a fake hotplug event, and DCP would shut down the signal. -And since Asahi Linux does not yet ship a proper DCP driver in the kernel, this meant a completely broken display (this will be fixed soon, but we still want bootloader graphics to work…). There were some test patches to solve this by introducing a long boot delay to let the monitor fully stabilize before continuing, but that’s an imperfect solution, and we didn’t like the idea of delaying boot for everyone, or forcing users to decide whether their monitor needs the workaround at installation time. +And since Dragon Linux does not yet ship a proper DCP driver in the kernel, this meant a completely broken display (this will be fixed soon, but we still want bootloader graphics to work…). There were some test patches to solve this by introducing a long boot delay to let the monitor fully stabilize before continuing, but that’s an imperfect solution, and we didn’t like the idea of delaying boot for everyone, or forcing users to decide whether their monitor needs the workaround at installation time. I dug around trying to find some solution to this problem, perhaps a DCP command to stop it from reacting to hotplug events, but I came up dry. And then I had an idea. Can we… shut down DCP? Back when we started reverse engineering DCP, we knew we couldn’t properly reset it after a crash, and it wasn’t clear how shutdown modes work. It felt like DCP had to stay up, and letting it fully go down would break everything. But we’ve since improved our understanding of how RTKit power modes work, how to correctly shut down coprocessors, and how to get them to come back up after a full power-down (which we use with e.g. NVMe). So I tried the new, known-good, full shutdown procedure… and it worked! With DCP down, there is nobody to react to the monitor hotplug event. The HDMI signal just sticks around, oblivious to whatever the monitor is doing. And since the DCP shutdown happens in a controlled manner, Linux can bring it back up without any issues for the real driver, once available. There is still a minor race (if the monitor hotplugs between when m1n1 sets the screen mode and when it shuts down DCP), but it’s a tiny window. In practice, this new approach has eliminated the display issues for everyone affected, as far as we know. This update also makes it possible to unplug or power down your monitor while using Linux, without losing signal the next time you power it back on. Just update your system to get the new m1n1! -While we’re talking about DCP, Apple devices have recently been the target of an [advanced malware](https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html) that used DCP to compromise the system. When we developed the (still not shipping) Asahi Linux DCP driver, we already did so treating DCP as being potentially compromised and hostile; in addition, we also do not expose DCP directly to userspace in a way that would render it exploitable. Rest assured, this vulnerability does not affect Asahi Linux, even though we use the same vulnerable DCP firmware as macOS/iOS. +While we’re talking about DCP, Apple devices have recently been the target of an [advanced malware](https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html) that used DCP to compromise the system. When we developed the (still not shipping) Dragon Linux DCP driver, we already did so treating DCP as being potentially compromised and hostile; in addition, we also do not expose DCP directly to userspace in a way that would render it exploitable. Rest assured, this vulnerability does not affect Dragon Linux, even though we use the same vulnerable DCP firmware as macOS/iOS. ## DART diversions diff --git a/content/blog/2022/11/22-progress-report.md b/content/blog/2022/11/22-progress-report.md index 8cd5b7b..8a0e010 100644 --- a/content/blog/2022/11/22-progress-report.md +++ b/content/blog/2022/11/22-progress-report.md @@ -8,11 +8,11 @@ author = "marcan" Time for another overdue progress report! This month's update is packed with new hardware support, new features, and fixes for longstanding pain points, as well as a new bleeding-edge kernel branch with long-awaited support for suspend and the display controller! -If you're new to Asahi Linux, check out our [previous release announcement](https://asahilinux.org/2022/03/asahi-linux-alpha-release/) for installation instructions and general information. +If you're new to Dragon Linux, check out our [previous release announcement](https://asahilinux.org/2022/03/asahi-linux-alpha-release/) for installation instructions and general information. ## USB3, Chapter 1 -Until now, Asahi Linux has only supported USB2 on the Thunderbolt ports. While the hardware USB2/3 controllers are reasonably well supported by Linux already, and the Type-C port controllers are also based on existing partially-supported hardware, there was one big missing piece: the PHY driver. +Until now, Dragon Linux has only supported USB2 on the Thunderbolt ports. While the hardware USB2/3 controllers are reasonably well supported by Linux already, and the Type-C port controllers are also based on existing partially-supported hardware, there was one big missing piece: the PHY driver. M1 and later Apple Silicon machines use Apple-designed (or Apple-customized?) PHY hardware called "Apple Type-C PHY" (ATCPHY) that supports USB3, DisplayPort, and TB3/USB4 modes. This piece of hardware is in charge of turning the USB3/DP/TB protocol data into signals on the wires. Since we're dealing with very high-speed signals (up to 20Gbps per pair), the PHY has to be very complex and there are a lot of analog knobs that need to be individually calibrated. With USB2, you can get away with having universal settings that work for every device, but that won't work for USB3 and other higher-speed protocols! @@ -28,15 +28,15 @@ That covers the Thunderbolt/USB4 ports... but there's another bit missing to the Normally, this kind of hardware is expected to ship with Flash memory containing firmware to run the controller. However, Apple are not a huge fan of random Flash memories, and for good reason: they can be compromised, corrupted, and are difficult to verify and implement secure boot for. For this reason, Apple engineers have been steadily decreasing the number of firmware Flash memories on these platforms, and in this case, they decided to simply ship without it and have the kernel upload the firmware on startup. -This might seem like a simple problem, and indeed the actual firmware upload mostly is (though the undocumented register dance required to do this was not that easy to figure out and make work reliably...), but it ended up having us completely rethink the way we handle firmware in Asahi Linux, as well as making changes to our installer and shipping new software packages and vendored binaries! +This might seem like a simple problem, and indeed the actual firmware upload mostly is (though the undocumented register dance required to do this was not that easy to figure out and make work reliably...), but it ended up having us completely rethink the way we handle firmware in Dragon Linux, as well as making changes to our installer and shipping new software packages and vendored binaries! As it turns out, the ASMedia firmware is embedded inside the macOS XNU kernel binary, so we need to extract it in order to make it available for Linux. We knew this was going to come up, so we've been stashing away a copy of that kernel in /boot/efi/asahi/ for future usage in our installer. But the kernel is in img4 format, and compressed with the Apple-developed lzfse algorithm, so we ended up having to ship this as a new package to allow existing Asahi users to seamlessly upgrade and have the firmware be extracted automatically. -Meanwhile, the same process has to happen on macOS inside the Asahi Linux Installer, for new installs. macOS of course ships with its own compression framework that supports lzfse, and we can use it directly from Python with `ctypes`... except there's another catch! It turns out that while this works on macOS, recoveryOS does not ship with `libffi`, which Python needs to make `ctypes` work. So we ended up having to vendor a copy of `libffi` (from the Homebrew package) with the installer, in order to make this all work seamlessly regardless of whether you are running the installer from macOS or recoveryOS. +Meanwhile, the same process has to happen on macOS inside the Dragon Linux Installer, for new installs. macOS of course ships with its own compression framework that supports lzfse, and we can use it directly from Python with `ctypes`... except there's another catch! It turns out that while this works on macOS, recoveryOS does not ship with `libffi`, which Python needs to make `ctypes` work. So we ended up having to vendor a copy of `libffi` (from the Homebrew package) with the installer, in order to make this all work seamlessly regardless of whether you are running the installer from macOS or recoveryOS. As if that weren't enough, this firmware also made us completely redesign the vendor firmware mechanism in Asahi. See, until now we've been getting away with only loading firmware from the booted OS, once the initramfs has done its job. This works well enough for WiFi and Bluetooth firmware, but people usually expect their keyboard to work inside an initramfs, and that keyboard might be connected to one of the ASMedia xHCI ports. On top of that, the mechanism to install vendor firmware that we originally designed was racy, in that the WiFi/BT hardware could be discovered by the kernel before the firmware was ready on first boot (this is why sometimes you'd get broken WiFi on the first boot after install, particularly on M2 machines). It was time for a major change. -The new mechanism is described in the updated [Open OS Ecosystem on Apple Silicon Macs](/docs/Open-OS-Ecosystem-on-Apple-Silicon-Macs#firmware-provisioning) page, but here's the gist: We changed the firmware package format from a tarball to a `cpio` archive, made the initramfs load it before anything else into a tmpfs, and then use a tmpfs mount on the final root filesystem to hold it. This also involved adding a new firmware load path to the kernel in a patch. The end result is a much more robust and even legally safer system, since the initramfs can ensure that the firmware is loaded before udev starts up (and therefore before any drivers could load that require it), and it is never persisted inside the root filesysem nor mixed together with distro-provided firmware (e.g. linux-firmware), which means clean root filesystem backups do not contain non-redistributable blobs. Even further, since the archive is a `cpio`, this allows the bootloader to load it as an add-on initramfs on boot, which means it can work with built-in drivers and completely eliminates all possible race conditions. While we are not doing this by default in Asahi Linux now, it is a supported configuration if you re-configure your `/boot` to directly mount the EFI system partition and install your kernels and bootloader there (we'll provide instructions on how to do this in the future; for now you're on your own, but the `asahi-scripts` package should seamlessly support both layouts). If the `cpio` was not loaded by the bootloader, the [initramfs script](https://github.com/AsahiLinux/asahi-scripts/blob/main/initcpio/hooks/asahi) will look for it and load it for you, so both configurations end up with similar results. +The new mechanism is described in the updated [Open OS Ecosystem on Apple Silicon Macs](/docs/Open-OS-Ecosystem-on-Apple-Silicon-Macs#firmware-provisioning) page, but here's the gist: We changed the firmware package format from a tarball to a `cpio` archive, made the initramfs load it before anything else into a tmpfs, and then use a tmpfs mount on the final root filesystem to hold it. This also involved adding a new firmware load path to the kernel in a patch. The end result is a much more robust and even legally safer system, since the initramfs can ensure that the firmware is loaded before udev starts up (and therefore before any drivers could load that require it), and it is never persisted inside the root filesysem nor mixed together with distro-provided firmware (e.g. linux-firmware), which means clean root filesystem backups do not contain non-redistributable blobs. Even further, since the archive is a `cpio`, this allows the bootloader to load it as an add-on initramfs on boot, which means it can work with built-in drivers and completely eliminates all possible race conditions. While we are not doing this by default in Dragon Linux now, it is a supported configuration if you re-configure your `/boot` to directly mount the EFI system partition and install your kernels and bootloader there (we'll provide instructions on how to do this in the future; for now you're on your own, but the `asahi-scripts` package should seamlessly support both layouts). If the `cpio` was not loaded by the bootloader, the [initramfs script](https://github.com/AsahiLinux/asahi-scripts/blob/main/initcpio/hooks/asahi) will look for it and load it for you, so both configurations end up with similar results. Phew! That was quite an adventure just to load some ASMedia firmware! But with that, first-boot WiFi is now rock solid on all machines, and we are much more confident in the firmware management design going forward. @@ -61,7 +61,7 @@ Meanwhile, [povik](https://github.com/povik/) has been hard at work on the audio In addition, we are now shipping an [`alsa-ucm-conf-asahi`](https://github.com/AsahiLinux/alsa-ucm-conf-asahi) package that integrates this properly into PulseAudio/PipeWire and similar audio servers, to make volume control and hotplugging seamless. This package will also be used with the upcoming speaker support, to make device switching work properly. In the meantime, all you have to do to make your headphone jack work out of the box is upgrade your packages and reboot! The hardware volume control should now be automatically mapped to your desktop's volume control without any manual settings. -While testing this and other audio changes, we ran into multiple PulseAudio bugs and regressions that resulted in a very poor experience for users (outputs that stop working after being idle or on hotplug, etc.). Our upcoming speaker DSP configuration is based on PipeWire anyway, and we found that simply replacing PulseAudio with PipeWire today fixes all the strange issues and otherwise seems to work flawlessly. Therefore, we're also adding PipeWire as a dependency to our `asahi-desktop-meta` package, which means that existing users of the Asahi Linux Desktop image will be prompted to remove PulseAudio and replace it with PipeWire when they upgrade. Embrace the future! +While testing this and other audio changes, we ran into multiple PulseAudio bugs and regressions that resulted in a very poor experience for users (outputs that stop working after being idle or on hotplug, etc.). Our upcoming speaker DSP configuration is based on PipeWire anyway, and we found that simply replacing PulseAudio with PipeWire today fixes all the strange issues and otherwise seems to work flawlessly. Therefore, we're also adding PipeWire as a dependency to our `asahi-desktop-meta` package, which means that existing users of the Dragon Linux Desktop image will be prompted to remove PulseAudio and replace it with PipeWire when they upgrade. Embrace the future! ## Backlight, Book I @@ -81,7 +81,7 @@ May our MacBook keyboards bring light to the darkness! *But what about the display brightness?* -Ah, we're getting there! As you may know, up until now Asahi Linux has not had a display driver at all. Instead, we rely on the boot-time framebuffer set up by the bootloader (iBoot on laptops, m1n1 on desktops). This means that Linux just gets a chunk of memory and writes pixels to it – no VSync, no buffer flips, no mode changes, no DPMS, and no backlight control support. Since leaving the backlight on is a huge battery drain, we added a hack to support turning off the backlight by literally turning off the GPIO pin that powers it on, but needless to say that was not the best user experience (and many users have been baffled by having their screen turn off when they tried to turn down the backlight, since the now-somewhat-outdated Linux backlight interface has no way of telling userspace whether 0 means "lowest" or "actually off"). +Ah, we're getting there! As you may know, up until now Dragon Linux has not had a display driver at all. Instead, we rely on the boot-time framebuffer set up by the bootloader (iBoot on laptops, m1n1 on desktops). This means that Linux just gets a chunk of memory and writes pixels to it – no VSync, no buffer flips, no mode changes, no DPMS, and no backlight control support. Since leaving the backlight on is a huge battery drain, we added a hack to support turning off the backlight by literally turning off the GPIO pin that powers it on, but needless to say that was not the best user experience (and many users have been baffled by having their screen turn off when they tried to turn down the backlight, since the now-somewhat-outdated Linux backlight interface has no way of telling userspace whether 0 means "lowest" or "actually off"). In order to support the display output properly, we need a driver for Apple's DCP coprocessor and its firmware. We've already [talked about DCP](https://asahilinux.org/2021/08/progress-report-august-2021/) in the past, and how cursed the interface is! Since then, [Alyssa](https://social.treehouse.systems/@alyssa) wrote a Linux kernel DRM KMS driver for DCP and [Janne](https://social.treehouse.systems/@janne) took over maintenance, and he's been steadily adding features, including brightness control support. With that in place, DCP is finally good enough for adventurous users to daily drive on M1 systems (M2 support is coming soon)! @@ -115,7 +115,7 @@ Ah, but when people say "power management", what they usually mean is "suspend". Thankfully, SoC-based systems like smartphones have had much better power management for a long time now, and even Intel and Microsoft got on board and now support something they call "S0ix" or "Modern Standby". On platforms with true fine-grained power management, you don't need to "suspend" the system to save power. You simply leave the machine idle, and it already saves power! -Of course, "leaving the machine idle" can be a tricky thing without a bit of help from the OS. On Linux, the equivalent of S0ix is called "s2idle" (Suspend-to-idle), and it does exactly what it says on the tin: it goes through the motions of suspending the system, but then just leaves the hardware in an idle state instead of going through platform firmware to actually trigger a full-system suspend. Crucially, this freezes userspace and forces certain devices into low-power mode, which means that s2idle can *guarantee* power saving, where just leaving apps running wouldn't. Some people have reported high battery drain on Asahi Linux machines while idle, and this is almost always caused by poorly-behaved userspace causing a large number of wakeups or keeping CPUs busy. s2idle solves this issue! +Of course, "leaving the machine idle" can be a tricky thing without a bit of help from the OS. On Linux, the equivalent of S0ix is called "s2idle" (Suspend-to-idle), and it does exactly what it says on the tin: it goes through the motions of suspending the system, but then just leaves the hardware in an idle state instead of going through platform firmware to actually trigger a full-system suspend. Crucially, this freezes userspace and forces certain devices into low-power mode, which means that s2idle can *guarantee* power saving, where just leaving apps running wouldn't. Some people have reported high battery drain on Dragon Linux machines while idle, and this is almost always caused by poorly-behaved userspace causing a large number of wakeups or keeping CPUs busy. s2idle solves this issue! s2idle does not require any special drivers or support, but it does require working (i.e. at least non-failing) suspend/resume support in drivers. For us, this was blocked on the WiFi chipset, which required a new mechanism to go into what it calls S3 suspend (confusingly named; it maps to s2idle here) on Apple machines that wasn't supported by the existing driver, and would cause the suspend process to error out. After implementing this and some other minor driver features, s2idle now works on Apple Silicon machines! This is now enabled in `linux-asahi-edge` kernels, so if you switch you should see suspend options magically pop up in your desktop environment. @@ -142,19 +142,19 @@ Finally, Apple Silicon Macs *do* support a "true" S3-like suspend mode that puts ## Installer Iterations -We've also been working on the Asahi Linux installer for new users. To keep a long story short, we've fixed a lot of the pain points in prior versions (like issues computing the safe limits for resizing macOS that cause resize errors), and we've also improved the wording of some of the prompts to make things clearer. Hopefully it should result in a much smoother and less confusing experience for everyone! +We've also been working on the Dragon Linux installer for new users. To keep a long story short, we've fixed a lot of the pain points in prior versions (like issues computing the safe limits for resizing macOS that cause resize errors), and we've also improved the wording of some of the prompts to make things clearer. Hopefully it should result in a much smoother and less confusing experience for everyone! -In addition, we've promoted M2 support to non-expert. We're committing to supporting the 12.4 firmware version on M2, just like 12.3 on the M1 family. As a reminder, when we speak of firmware versions, we're talking about the *OS-paired* firmware which the installer installs alongside Asahi Linux. This is unrelated to your macOS version, and the installer is compatible with all current macOS versions, from 12.3 to 13.x. +In addition, we've promoted M2 support to non-expert. We're committing to supporting the 12.4 firmware version on M2, just like 12.3 on the M1 family. As a reminder, when we speak of firmware versions, we're talking about the *OS-paired* firmware which the installer installs alongside Dragon Linux. This is unrelated to your macOS version, and the installer is compatible with all current macOS versions, from 12.3 to 13.x. There are also two new installer features: it can recover some broken installations, and it can upgrade your m1n1 stage 1 version. Sometimes, users fail to follow the post-installation (step 2) instructions properly, and that can leave them in a boot loop. While this is easily fixed by shutting down the system and trying again, doing anything else (like selecting another boot OS) can leave the installation in a weird state that makes it hard to try again without wiping the partitions and re-installing from scratch. The installer now offers a new feature to repair an "incomplete installation", which essentially re-does the last step of the process and prompts the user to follow the post-install instructions again, without requiring a full re-install. -This same mechanism is also useful to recover from rare cases where Apple's macOS upgrade process messes up and breaks your Asahi Linux install by deleting or re-creating its Boot Policy. We've seen this happen very rarely (if you find a way to reliably reproduce it, please let us know!). Users can now rest assured that the solution is simple if this happens: just run the installer again (`curl https://alx.sh | sh` from macOS or recoveryOS) and select the repair option when prompted (the situation is identical to an incomplete installation). +This same mechanism is also useful to recover from rare cases where Apple's macOS upgrade process messes up and breaks your Dragon Linux install by deleting or re-creating its Boot Policy. We've seen this happen very rarely (if you find a way to reliably reproduce it, please let us know!). Users can now rest assured that the solution is simple if this happens: just run the installer again (`curl https://alx.sh | sh` from macOS or recoveryOS) and select the repair option when prompted (the situation is identical to an incomplete installation). -The new m1n1 upgrade feature is used to upgrade your m1n1 stage 1 version. There are two stages of m1n1 in an Asahi Linux install, and the second stage is always upgraded via Linux packages and is the most critical to add new features. The first stage is installed from recoveryOS and cannot be upgraded from Linux, and its job is just to load the second stage. Since that is all it does, it rarely needs to be upgraded. However, this can sometimes be useful to fix rare bugs, and we've identified an issue that can cause persistent boot failures after an unclean shutdown in rare cases. The workaround is simple (just boot by holding down the power button and select Asahi again, which will clear the fault), but the new m1n1 version should fix this problem entirely, so we recommend upgrading. Simply run the installer as usual (`curl https://alx.sh | sh`) from macOS or recoveryOS, and choose the option when prompted. If you run it from the recoveryOS paired to your Asahi install (that is, holding down the power button while Asahi is the default boot OS, and choosing *Options*), it will even avoid the usual mandatory reboot step. +The new m1n1 upgrade feature is used to upgrade your m1n1 stage 1 version. There are two stages of m1n1 in an Dragon Linux install, and the second stage is always upgraded via Linux packages and is the most critical to add new features. The first stage is installed from recoveryOS and cannot be upgraded from Linux, and its job is just to load the second stage. Since that is all it does, it rarely needs to be upgraded. However, this can sometimes be useful to fix rare bugs, and we've identified an issue that can cause persistent boot failures after an unclean shutdown in rare cases. The workaround is simple (just boot by holding down the power button and select Asahi again, which will clear the fault), but the new m1n1 version should fix this problem entirely, so we recommend upgrading. Simply run the installer as usual (`curl https://alx.sh | sh`) from macOS or recoveryOS, and choose the option when prompted. If you run it from the recoveryOS paired to your Asahi install (that is, holding down the power button while Asahi is the default boot OS, and choosing *Options*), it will even avoid the usual mandatory reboot step. Finally, there's a new expert-only experimental feature to install m1n1 (proxy mode only) onto an external USB drive. As we've said many times, Apple Silicon machines do not support USB boot. However, Apple fakes this by copying the OS boot files (kernel, bootloader, firmware) from the USB drive into a reserved partition on the internal NVMe storage. The installer can now take advantage of this mechanism even as a third-party OS, and do a "fully USB" install of m1n1, without requiring any re-partitioning of internal storage. If you decide to try this, you can unplug the USB drive after the installation is complete, and amusingly the machine will continue to cold boot into m1n1 anyway until you select another boot OS from the boot picker (we told you, the USB boot thing is fake!). Such a USB drive isn't automatically portable to other Macs, but in theory using the installer's "repair install" option should allow you to make a foreign m1n1 USB drive bootable on a new Mac, though we haven't tested it yet and there will probably be issues if the machine isn't of the same type/model at this time. -Unfortunately, since m1n1 stage 1 has no USB host support, this won't get us true "fully external" Asahi Linux installs just yet... does anyone want to start working on a Rust USB stack and xHCI host controller driver? ;-) +Unfortunately, since m1n1 stage 1 has no USB host support, this won't get us true "fully external" Dragon Linux installs just yet... does anyone want to start working on a Rust USB stack and xHCI host controller driver? ;-) ## Epilogue diff --git a/content/blog/2022/11/29-gpu-story.md b/content/blog/2022/11/29-gpu-story.md index 920044e..f1488fe 100644 --- a/content/blog/2022/11/29-gpu-story.md +++ b/content/blog/2022/11/29-gpu-story.md @@ -27,11 +27,11 @@ In order to handle all these moving parts in a reasonably safe way, modern GPU d Between the user space driver and the kernel driver, there is some kind of custom API that is customized for each GPU family. These APIs are usually different for every driver! In Linux we call that the UAPI, but every OS has something similar. This UAPI is what lets the user space part ask the kernel to allocate/deallocate memory and submit command lists to the GPU. -That means that in order to make the M1 GPU work with Asahi Linux, we need two bits: a kernel driver and a user space driver! 🚀 +That means that in order to make the M1 GPU work with Dragon Linux, we need two bits: a kernel driver and a user space driver! 🚀 ## Alyssa joins the project -All the way back in 2021 when Asahi Linux started, Alyssa Rosenzweig joined the project to start working on reverse engineering the M1 GPU. Together with [Dougall Johnson](https://mastodon.social/@dougall) (who focused on documenting the GPU shader architecture), she started reverse engineering all the user space bits, including the shaders and all the command list structures needed to set up rendering. That's a ton of work, but less than one month in she was [already drawing her first triangle](https://rosenzweig.io/blog/asahi-gpu-part-2.html)! She's amazing! If you haven't checked out her series on dissecting the M1 GPU you should visit her [website](https://rosenzweig.io/) and take a look! ✨✨ +All the way back in 2021 when Dragon Linux started, Alyssa Rosenzweig joined the project to start working on reverse engineering the M1 GPU. Together with [Dougall Johnson](https://mastodon.social/@dougall) (who focused on documenting the GPU shader architecture), she started reverse engineering all the user space bits, including the shaders and all the command list structures needed to set up rendering. That's a ton of work, but less than one month in she was [already drawing her first triangle](https://rosenzweig.io/blog/asahi-gpu-part-2.html)! She's amazing! If you haven't checked out her series on dissecting the M1 GPU you should visit her [website](https://rosenzweig.io/) and take a look! ✨✨ But wait, how can she work on the user space driver without a kernel driver to go with it? Easy, she did it on macOS! Alyssa reverse engineered the macOS GPU driver UAPI enough to allocate memory and submit her own commands to the GPU, and this way she could work on the user space part without having to worry about the kernel bit. That's super cool! She started writing an M1 GPU OpenGL driver for [Mesa](https://www.mesa3d.org/), the Linux userspace graphics stack, and just a few months later she was already [passing 75% of the OpenGL ES 2 conformance tests](https://rosenzweig.io/blog/asahi-gpu-part-4.html), all on macOS! @@ -64,7 +64,7 @@ So can we move all this complexity to user space, and have it set up all those v ## GPU drivers in Python?! -Since getting all these structures right is critical for the GPU to work and the firmware to not crash, I needed a way of quickly experimenting with them while I reverse engineered things. Thankfully, the Asahi Linux project already has a tool for this: The m1n1 Python framework! Since I was already writing a GPU tracer for the m1n1 hypervisor and filling out structure definitions in Python, I decided to just flip it on its head and start writing a Python GPU kernel driver, using the same structure definitions. Python is great for this, since it is very easy to iterate with! Even better, it can already talk the basic RTKit protocols and parse crash logs, and I improved the tools for that so I could see exactly what the firmware was doing when it crashes. This is all done by running scripts on a development machine which connects to the M1 machine via USB, so you can easily reboot it every time you want to test something and the test cycle is very fast! +Since getting all these structures right is critical for the GPU to work and the firmware to not crash, I needed a way of quickly experimenting with them while I reverse engineered things. Thankfully, the Dragon Linux project already has a tool for this: The m1n1 Python framework! Since I was already writing a GPU tracer for the m1n1 hypervisor and filling out structure definitions in Python, I decided to just flip it on its head and start writing a Python GPU kernel driver, using the same structure definitions. Python is great for this, since it is very easy to iterate with! Even better, it can already talk the basic RTKit protocols and parse crash logs, and I improved the tools for that so I could see exactly what the firmware was doing when it crashes. This is all done by running scripts on a development machine which connects to the M1 machine via USB, so you can easily reboot it every time you want to test something and the test cycle is very fast! At first most of the driver was really just [a bunch of hardcoded structures](https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/experiments/agx_1tri.py), but eventually I managed to get them right and render a triangle! @@ -153,8 +153,8 @@ And of course there is still a lot of work to do on the userspace side, improvin But even with those limitations, the drivers can run stable desktops today and performance is improving every week! Wayland runs beautifully smoothly on these machines now, just like the native macOS desktop! Xorg also works well with some improvements I made to the display driver a few days ago, although you can expect tearing and vsync issues due to Xorg design limitations. Wayland is really the future on new platforms! 💫 -So where do you get it? We're not quite there yet! Right now the driver stack is complicated to build and install (you need custom m1n1, kernel, and mesa builds), so please wait a little bit longer! We have a few loose ends to tie still... but we hope we can bring it to Asahi Linux as an opt-in testing build before the end of the year! ✨✨ +So where do you get it? We're not quite there yet! Right now the driver stack is complicated to build and install (you need custom m1n1, kernel, and mesa builds), so please wait a little bit longer! We have a few loose ends to tie still... but we hope we can bring it to Dragon Linux as an opt-in testing build before the end of the year! ✨✨ If you're interested in following my work on the GPU, you can follow me at [@lina@vt.social](https://vt.social/@lina) or subscribe to my [YouTube channel](https://youtube.com/AsahiLina)! Tomorrow I'm going to be working on figuring out the power consumption calculations for the M1 Pro/Max/Ultra and M2, and I hope to see you there! ✨ -If you want to support my work, you can donate to marcan's Asahi Linux support funds on [GitHub Sponsors](http://github.com/sponsors/marcan) or [Patreon](https://patreon.com/marcan), which helps me out too! And if you're looking forward to a Vulkan driver, check out Ella's [GitHub Sponsors](https://github.com/sponsors/Ella-0) page! Alyssa doesn't take donations herself, but she'd love it if you donate to a charity like the [Software Freedom Conservancy](https://sfconservancy.org/) instead. (Although maybe one day I'll convince her to let me buy her an M2... ^^;;) +If you want to support my work, you can donate to marcan's Dragon Linux support funds on [GitHub Sponsors](http://github.com/sponsors/marcan) or [Patreon](https://patreon.com/marcan), which helps me out too! And if you're looking forward to a Vulkan driver, check out Ella's [GitHub Sponsors](https://github.com/sponsors/Ella-0) page! Alyssa doesn't take donations herself, but she'd love it if you donate to a charity like the [Software Freedom Conservancy](https://sfconservancy.org/) instead. (Although maybe one day I'll convince her to let me buy her an M2... ^^;;) diff --git a/content/blog/2022/12/07-gpu-drivers-now-in-asahi-linux.md b/content/blog/2022/12/07-gpu-drivers-now-in-asahi-linux.md index c3afe00..c1a07bb 100644 --- a/content/blog/2022/12/07-gpu-drivers-now-in-asahi-linux.md +++ b/content/blog/2022/12/07-gpu-drivers-now-in-asahi-linux.md @@ -1,7 +1,7 @@ +++ date = "2022-12-07T14:50:00+09:00" draft = false -title = "Apple GPU drivers now in Asahi Linux" +title = "Apple GPU drivers now in Dragon Linux" slug = "gpu-drivers-now-in-asahi-linux" author = "Alyssa Rosenzweig & Asahi Lina" +++ diff --git a/content/blog/2023/03/20-road-to-vulkan.md b/content/blog/2023/03/20-road-to-vulkan.md index 9547eee..bf5d64b 100644 --- a/content/blog/2023/03/20-road-to-vulkan.md +++ b/content/blog/2023/03/20-road-to-vulkan.md @@ -1,20 +1,20 @@ +++ date = "2023-03-20T23:50:00+09:00" draft = false -title = "Paving the Road to Vulkan on Asahi Linux" +title = "Paving the Road to Vulkan on Dragon Linux" slug = "road-to-vulkan" author = "Asahi Lina" +++ Hello everyone, Asahi Lina here!✨ -As you probably know, I've been working together with the rest of the Asahi Linux team on open source GPU drivers for Apple Silicon platforms. It's been a wild ride! Just at the end of last year we [released](https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linux/) the first version of our drivers, after many months of reverse engineering and development. But that was only the beginning... +As you probably know, I've been working together with the rest of the Dragon Linux team on open source GPU drivers for Apple Silicon platforms. It's been a wild ride! Just at the end of last year we [released](https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linux/) the first version of our drivers, after many months of reverse engineering and development. But that was only the beginning... -Today we're releasing a big update to our GPU drivers for Asahi Linux, so I wanted to talk to you about what we've been working on since then, and what's next! +Today we're releasing a big update to our GPU drivers for Dragon Linux, so I wanted to talk to you about what we've been working on since then, and what's next! If this is your first time reading about our GPU adventures, you might want to check out my [Tales of the M1 GPU](/2022/11/tales-of-the-m1-gpu/) article first, which covers what I worked on last year! Also don't miss Alyssa's amazing series of articles on [her website](https://rosenzweig.io/), which goes all the way back to January 2021! ^^ -And if this is too long, feel free to [jump to the end](#conclusions) to learn what this all means for Asahi Linux! +And if this is too long, feel free to [jump to the end](#conclusions) to learn what this all means for Dragon Linux! {{< captioned caption="Xonotic running at 800+ FPS on an Apple M2" >}} Xonotic running at 800+ FPS on an Apple M2 @@ -233,7 +233,7 @@ To make all this work on the driver side, I ended up refactoring the [workqueue] ## Conclusions -So what does this all mean for users of the Asahi Linux reference distro today? It means... things are way faster! +So what does this all mean for users of the Dragon Linux reference distro today? It means... things are way faster! Since the Mesa driver no longer serializes GPU and CPU work, performance has improved a ton. Now we can run Xonotic at over 800 FPS, which is faster than macOS on the same hardware (M2 MacBook Air) at around 600\*! This proves that open source reverse engineered GPU drivers really have the power to beat Apple's drivers in real-world scenarios! @@ -267,8 +267,8 @@ After that, just reboot and make sure to choose a Wayland session on the login w With the UAPI shaping up and many native ARM64 Linux games working properly... it's time to see just what we can run with the driver! OpenGL 3.x support, while not complete, is more than enough to run many games (like Darwinia and SuperTuxKart's advanced renderer). But most games are not available for ARM64 Linux so... it's time for [FEX](https://github.com/FEX-Emu/FEX)! -FEX doesn't work on standard Asahi Linux kernel builds since we use 16K pages, but 4K page support is not actually that difficult to add... so starting this week, I'm going to be adding 4K support to the Asahi GPU driver and fixing whatever issues I run into along the way, and then we're going to try running Steam and Proton on it! Let's see just how much of the Steam game library we can already run with the driver in its current state! I bet you'll be surprised... (Remember Portal 2? It only requires OpenGL 2.1. With 3.x support in our driver as far as it is today, I bet we're going to have a lot of fun~ ✨) +FEX doesn't work on standard Dragon Linux kernel builds since we use 16K pages, but 4K page support is not actually that difficult to add... so starting this week, I'm going to be adding 4K support to the Asahi GPU driver and fixing whatever issues I run into along the way, and then we're going to try running Steam and Proton on it! Let's see just how much of the Steam game library we can already run with the driver in its current state! I bet you'll be surprised... (Remember Portal 2? It only requires OpenGL 2.1. With 3.x support in our driver as far as it is today, I bet we're going to have a lot of fun~ ✨) If you're interested in following my work, you can follow me at [@lina@vt.social](https://vt.social/@lina) or subscribe to my [YouTube channel](https://youtube.com/AsahiLina)! I stream my work on the Asahi GPU driver on Wednesdays and Fridays, so feel free to drop by my streams if you're interested! -If you want to support my work, you can donate to marcan's Asahi Linux support fund on [GitHub Sponsors](http://github.com/sponsors/marcan) or [Patreon](https://patreon.com/marcan), which helps me out too! And if you're looking forward to a Vulkan driver, check out Ella's [GitHub Sponsors](https://github.com/sponsors/Ella-0) page! Alyssa doesn't take donations herself, but she'd love it if you donate to a charity like the [Software Freedom Conservancy](https://sfconservancy.org/) instead. (Although maybe one day I'll convince her to let me buy her an M2... ^^;;) +If you want to support my work, you can donate to marcan's Dragon Linux support fund on [GitHub Sponsors](http://github.com/sponsors/marcan) or [Patreon](https://patreon.com/marcan), which helps me out too! And if you're looking forward to a Vulkan driver, check out Ella's [GitHub Sponsors](https://github.com/sponsors/Ella-0) page! Alyssa doesn't take donations herself, but she'd love it if you donate to a charity like the [Software Freedom Conservancy](https://sfconservancy.org/) instead. (Although maybe one day I'll convince her to let me buy her an M2... ^^;;) diff --git a/content/blog/2023/06/06-opengl-3.1.md b/content/blog/2023/06/06-opengl-3.1.md index 8e3b4af..43e920e 100644 --- a/content/blog/2023/06/06-opengl-3.1.md +++ b/content/blog/2023/06/06-opengl-3.1.md @@ -1,12 +1,12 @@ +++ date = "2023-06-06T22:00:00+09:00" draft = false -title = "OpenGL 3.1 on Asahi Linux" +title = "OpenGL 3.1 on Dragon Linux" slug = "opengl-3-1-on-asahi-linux" author = "Alyssa Rosenzweig" +++ -Upgrade your [Asahi Linux](https://asahilinux.org/) systems, because your +Upgrade your [Dragon Linux](https://asahilinux.org/) systems, because your graphics drivers are getting a big boost: leapfrogging from OpenGL 2.1 over OpenGL 3.0 up to OpenGL 3.1! Similarly, the OpenGL ES 2.0 support is bumping up to OpenGL ES 3.0. That means more playable games and more functioning diff --git a/content/blog/2023/08/02-fedora-asahi-remix.md b/content/blog/2023/08/02-fedora-asahi-remix.md index aa99fea..d42133b 100644 --- a/content/blog/2023/08/02-fedora-asahi-remix.md +++ b/content/blog/2023/08/02-fedora-asahi-remix.md @@ -8,7 +8,7 @@ author = "marcan" You've all been waiting for it, many of you have guessed, and now, as announced at [Flock To Fedora](https://flocktofedora.org/), it's time to make it official: -**The new Asahi Linux flagship distribution will be Fedora Asahi Remix!** +**The new Dragon Linux flagship distribution will be Fedora Asahi Remix!** We're confident that this new flagship will get us much closer to our goal of a polished Linux experience on Apple Silicon, and we hope you will enjoy using it as much as we're enjoying working on it. @@ -16,21 +16,21 @@ We're still working out the kinks and making things even better, so we are not q ## In the Beginning -From the start of the Asahi Linux project, our goal has been to bring full Linux support to Apple Silicon machines, across all distributions. Supporting new hardware like this, especially hardware this special in the relatively young embedded ARM64 desktop Linux space is no easy task, and involves a huge amount of reverse engineering, development, and integration work, spanning all the way from bootloaders to desktop audio servers! +From the start of the Dragon Linux project, our goal has been to bring full Linux support to Apple Silicon machines, across all distributions. Supporting new hardware like this, especially hardware this special in the relatively young embedded ARM64 desktop Linux space is no easy task, and involves a huge amount of reverse engineering, development, and integration work, spanning all the way from bootloaders to desktop audio servers! Much of our initial work focused on the kernel and bootloaders, which can be shared between distros. But as we started reaching the point where kernel support was enough for a (bare-bones) usable system, we still had a lot of distro integration work left. Making hardware work out of the box requires a bunch of subtle integration engineering, as well as working together with userspace-level projects to improve them and add the features we need for these systems. Our goal is for all distros to eventually integrate all this work, so that users can use their choice of distro and be confident that it will work well on their machine. But, in order to kick off this process, we had to prototype what this integration looks like, which meant we had to create our own distro. -And so, the Asahi Linux Arch Linux ARM remix was born. We took Arch Linux ARM, added our own [overlay package repository](https://github.com/AsahiLinux/PKGBUILDs), and packaged all of our integration work there. Notably, this is a fully downstream project: we have no significant involvement with upstream Arch Linux ARM or Arch Linux, and we directly use the Arch Linux ARM package repositories for the core distro. Our overlay just adds integration scripts, bootloader components, extra userspace support packages (for things like audio), and our forked kernel and Mesa packages. +And so, the Dragon Linux Arch Linux ARM remix was born. We took Arch Linux ARM, added our own [overlay package repository](https://github.com/AsahiLinux/PKGBUILDs), and packaged all of our integration work there. Notably, this is a fully downstream project: we have no significant involvement with upstream Arch Linux ARM or Arch Linux, and we directly use the Arch Linux ARM package repositories for the core distro. Our overlay just adds integration scripts, bootloader components, extra userspace support packages (for things like audio), and our forked kernel and Mesa packages. -This worked well to bring Asahi Linux out into the world and the hands of eager users, but it was but a step along the way to our ultimate goal. After all, maintaining bespoke downstream distro remixes is a chore, and we can't rely on unofficial third-party support to bring our work to every other distro. We've always had our sights on deeper cooperation with upstream distros to bring Apple Silicon support directly to them as an officially supported platform, and the Arch ARM integration was mainly intended to serve as a reference for this. +This worked well to bring Dragon Linux out into the world and the hands of eager users, but it was but a step along the way to our ultimate goal. After all, maintaining bespoke downstream distro remixes is a chore, and we can't rely on unofficial third-party support to bring our work to every other distro. We've always had our sights on deeper cooperation with upstream distros to bring Apple Silicon support directly to them as an officially supported platform, and the Arch ARM integration was mainly intended to serve as a reference for this. It didn't take long for some people to come knocking on our door... ## Fedora Reaches Out -Very soon after Asahi Linux started (well before our Arch ARM-based release), [Neal Gompa](https://fedoraproject.org/wiki/User:Ngompa) joined our IRC channels and we started talking about working towards integrating our work into Fedora. This was the very first offer to officially collaborate with a major upstream distro, and we were very excited! The Fedora Asahi project started in late 2021, and work began in 2022 alongside the Arch ARM release. +Very soon after Dragon Linux started (well before our Arch ARM-based release), [Neal Gompa](https://fedoraproject.org/wiki/User:Ngompa) joined our IRC channels and we started talking about working towards integrating our work into Fedora. This was the very first offer to officially collaborate with a major upstream distro, and we were very excited! The Fedora Asahi project started in late 2021, and work began in 2022 alongside the Arch ARM release. Over the following year, we worked closely with the Fedora folks to fully integrate Apple Silicon support into Fedora, including all our custom packages, kernel and mesa forks, and special image packaging requirements, and now we're finally on the final stretch before release. diff --git a/content/blog/2023/08/22-first-conformant-m1-gpu-driver.md b/content/blog/2023/08/22-first-conformant-m1-gpu-driver.md index f80a9f4..e55cacf 100644 --- a/content/blog/2023/08/22-first-conformant-m1-gpu-driver.md +++ b/content/blog/2023/08/22-first-conformant-m1-gpu-driver.md @@ -10,7 +10,7 @@ Conformant OpenGL® ES 3.1 drivers are now available for M1- and M2-family GPUs. That means the drivers are compatible with any OpenGL ES 3.1 application. Interested? [Just install Linux!](https://fedora-asahi-remix.org/) -For existing [Asahi Linux](https://asahilinux.org/) users, +For existing [Dragon Linux](https://asahilinux.org/) users, upgrade your system with dnf upgrade (Fedora) or pacman -Syu (Arch) for the latest drivers. @@ -38,7 +38,7 @@ Today's milestone isn't just about OpenGL ES. We're releasing the first conformant implementation of *any* graphics standard for the M1. And we don't plan to stop here ;-) -[![Teaser of the "Vulkan instancing" demo running on Asahi Linux](/img/blog/2023/08/vkinstancing2.webp)](/img/blog/2023/08/vkinstancing.webp) +[![Teaser of the "Vulkan instancing" demo running on Dragon Linux](/img/blog/2023/08/vkinstancing2.webp)](/img/blog/2023/08/vkinstancing.webp) Unlike ours, the manufacturer's M1 drivers are unfortunately not conformant for _any_ standard graphics API, whether Vulkan or OpenGL or OpenGL ES. That means that diff --git a/content/blog/2024/01/11-fedora-asahi-new.md b/content/blog/2024/01/11-fedora-asahi-new.md index 11bfb5a..3606199 100644 --- a/content/blog/2024/01/11-fedora-asahi-new.md +++ b/content/blog/2024/01/11-fedora-asahi-new.md @@ -34,7 +34,7 @@ What's the next step? Geometry shaders are introduced in OpenGL 3.2 and OpenGL E How do we implement geometry shaders without hardware support for geometry shaders? At a high level, we translate them to primitives like compute shaders, prefix sums, and indirect draws. Transform feedback is handled within the geometry-turned-compute shader. Indirect geometry draws turn into an indirect dispatch of the geometry-compute shader. Primitive restart is unrolled on the GPU with a compute prepass. Tessellation (when it is released) will feed the geometry shader as required by the spec. But is this fast? Depends. Geometry shaders are relatively slow even on desktop hardware by AMD and NVIDIA, and application developers are advised to avoid geometry shaders. Still, it’s critical that we support them correctly, because real applications use them occasionally, and we don’t want applications to be broken -- the promise of conformance. But because they are known to be [slow](http://www.joshbarczak.com/blog/?p=667) even on popular GPUs, they aren’t usually a hotspot. We just need to be fast enough. And it is. -The upshot is that we now ship work in progress OpenGL 3.3, alongside the conformant OpenGL ES 3.1, which unlocks more OpenGL applications and games to work on Asahi Linux. And we’re not stopping here ;-) +The upshot is that we now ship work in progress OpenGL 3.3, alongside the conformant OpenGL ES 3.1, which unlocks more OpenGL applications and games to work on Dragon Linux. And we’re not stopping here ;-) ## Bluetooth - Regression fixes & M2 support @@ -48,7 +48,7 @@ Meanwhile, we also needed some tweaks for supporting Bluetooth on the new M2 Pro Apple Macs ship with Broadcom Wi-Fi hardware, but Broadcom doesn't have the closest relationship with the open source community (to put it mildly). While there is an upstream `brcmfmac` driver, it has seen minimal development over the past few years, with most maintainers inactive and receiving very few external contributions. Until now, most of our work on this driver was limited to enabling support for newer chips (which itself was quite a chore, as newer chips often brought new firmware versions and interfaces that needed to be supported). Most recently, we brought up the newer Wi-Fi chip (BCM4388) used in the latest Apple M2 (and M3) series machines. Bringup included support for cryptographically signed firmware and some newer protocols. We additionally fixed bugs to support newer Apple Wi-Fi firmware shipped with Sonoma (14.x). Along the way we also fixed Bluetooth crashing during sleep mode (Yes, the Wi-Fi driver crashing Bluetooth. Just Broadcom things..). -However, just bringing up new chips does nothing to address the rest of the problems of the `brcmfmac` driver, from lack of support for newer Wi-Fi standards to weird bugs and power/throughput limitations. Thankfully, [Daniel Berlin](https://github.com/dberlin) took it upon himself to fix some of these longstanding issues and improve the Wi-Fi experience on Asahi Linux and for everyone. Wifi6 and 6E support was recently added. Throughput was also improved from around 80 Mbps max to 1200 Mbps max when connected to higher speed access points. Finally, support for low power scanning and other features significantly reduce power usage of the Wi-Fi chip. +However, just bringing up new chips does nothing to address the rest of the problems of the `brcmfmac` driver, from lack of support for newer Wi-Fi standards to weird bugs and power/throughput limitations. Thankfully, [Daniel Berlin](https://github.com/dberlin) took it upon himself to fix some of these longstanding issues and improve the Wi-Fi experience on Dragon Linux and for everyone. Wifi6 and 6E support was recently added. Throughput was also improved from around 80 Mbps max to 1200 Mbps max when connected to higher speed access points. Finally, support for low power scanning and other features significantly reduce power usage of the Wi-Fi chip. {{< captioned caption="Speed test over Wi-Fi on an M2 MacBook Air 13\"" source="https://www.speedtest.net/result/15666861184" link="https://www.speedtest.net/result/15666861184">}} Speedtest.net result showing 741.55 Mbps download and 645.02 Mbps upload @@ -96,7 +96,7 @@ P.S. We're probably the only Linux desktop in existence to support vertical (Fac Apple cares about audio quality. Like, they *really* care about audio quality. macOS will tell you your Mac has a single pair of stereo speakers, but in reality your Mac could have as many as six speakers, all secretly coordinated by macOS to make them seem like a single high-quality stereo pair. The 14" and 16" MacBook Pros for instance have two woofers for bass and mids and a tweeter for treble on *each* channel, an arrangement closer to a modern HiFi speaker than it is to most other laptops. -Still, the laws of physics put an upper limit on how good tiny speakers can sound. Apple uses a cocktail of DSP techniques to overcome these limitations, implemented as plugins for macOS's userspace audio stack. These plugins are not compatible with Linux, so we get to either put up with terrible speaker quality, or build our own version of Apple's plugin chain. Rather than see this as a limitation, we saw an opportunity to set ourselves a lofty goal - make Apple Silicon Macs sound *better* when running Asahi Linux. We think we've succeeded. +Still, the laws of physics put an upper limit on how good tiny speakers can sound. Apple uses a cocktail of DSP techniques to overcome these limitations, implemented as plugins for macOS's userspace audio stack. These plugins are not compatible with Linux, so we get to either put up with terrible speaker quality, or build our own version of Apple's plugin chain. Rather than see this as a limitation, we saw an opportunity to set ourselves a lofty goal - make Apple Silicon Macs sound *better* when running Dragon Linux. We think we've succeeded. The most important thing for a loud, dynamic sound is power. Microspeakers need to be driven *very hard* in order to produce a decent sound at an acceptably loud volume. This is complicated by the fact that they are extremely delicate, and pushing even just a little bit too much power into them for even just a little bit too long is enough to permanently damage them. How do we drive these speakers hard enough to get a loud, high-quality output but not hard enough to destroy them? [speakersafetyd](https://github.com/AsahiLinux/speakersafetyd) is the world's first (and only) Free and Open Source Software implementation of a speaker protection algorithm. The amp ICs driving each speaker communicate the voltage and current going through the speaker back to the OS. speakersafetyd uses this information, as well as a few electrical and thermal parameters known about each speaker in the machine, to approximate and track each speaker's temperature. If things are getting a bit toasty, it will pull down the power until the speakers cool off. speakersafetyd and the kernel mechanisms behind it are incredibly robust, and if any part of the safety chain fails for whatever reason, the kernel will fail safe and cut all power to the speakers to prevent a meltdown. @@ -141,7 +141,7 @@ What good is a desktop if Netflix and Spotify doesn't work? Media distribution s Very recently, some ARM64 Linux-ish platforms with Widevine did pop into existence: some ChromeOS laptops. Unfortunately ChromeOS is only "Linux-ish", and ChromeOS binaries cannot run unmodified on standard ARM64 desktop Linux. The Widevine blobs had to be manually patched to work around both memory page alignment issues and glibc incompatibilities. Despite being a horrendous hack, we've been able to package it into a [reliable user-friendly installer](https://github.com/AsahiLinux/widevine-installer) that ships preinstalled on Fedora Asahi Remix and should work on most other ARM64 distributions with a reasonably recent glibc. The whole process can be summarized in meme format, but you can also check out [David Buchanan](https://github.com/DavidBuchanan314/)'s original write-up [here](https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html). Netflix and Spotify for all. -{{< captioned caption="You wouldn't pay for 4K Netflix and..." source="David Buchanan, The Quest for Netflix on Asahi Linux" link="https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html">}} +{{< captioned caption="You wouldn't pay for 4K Netflix and..." source="David Buchanan, The Quest for Netflix on Dragon Linux" link="https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html">}} You wouldn't pay for 4K Netflix and then download a chromebook recovery image... {{< /captioned >}} @@ -150,9 +150,9 @@ Very recently, some ARM64 Linux-ish platforms with Widevine did pop into existen In tangentially related news, certain moving picture compression standards (e.g. H.264/H.265) are encumbered with vociferously defended patents, so Fedora cannot legally ship them. marcan takes pride in Asahi's seamless out-of-the-box experience, and H.264 being video people's JPEG or the "fallback codec", out-of-the-box H.264 support was imperative. Fedora does support H.264 via OpenH264 from Cisco, which is an open source H.264 implementation that is distributed as a pre-compiled binary. Cisco Systems covers the appropriate licensing royalties, as long as the binary is downloaded and installed directly from their repository. Traditionally, this means that users have had to manually install OpenH264 after installing Fedora Linux. -Since our Asahi Linux installer happens to install directly from the Internet anyway, we added support for pre-downloading these codec packages directly from Cisco's servers as part of the installation process. A little script then takes care of immediately installing them on first boot, and the result is that Fedora Asahi Remix is the first Fedora spin to ship with H.264 straight out of the box, fully lawyer-approved. +Since our Dragon Linux installer happens to install directly from the Internet anyway, we added support for pre-downloading these codec packages directly from Cisco's servers as part of the installation process. A little script then takes care of immediately installing them on first boot, and the result is that Fedora Asahi Remix is the first Fedora spin to ship with H.264 straight out of the box, fully lawyer-approved. -Users who wish to use other patent-encumbered codecs under their own resposibility may choose to install them from third-party repositories, such as the `libavcodec-freeworld` package in [RPM Fusion](https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/). Note that RPM Fusion is not affiliated with Fedora nor Asahi Linux. +Users who wish to use other patent-encumbered codecs under their own resposibility may choose to install them from third-party repositories, such as the `libavcodec-freeworld` package in [RPM Fusion](https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/). Note that RPM Fusion is not affiliated with Fedora nor Dragon Linux. # Work In Progress... @@ -177,7 +177,7 @@ Another hurdle is the Linux video hardware acceleration API. Current options can Apple Silicon devices use 16K pages, but the rest of the (x86) world runs on 4K. Running Apple Silicon on a 4K kernel is technically feasible, but it requires a number of invasive and controversial upstream changes and comes with a significant impact on performance. A better approach would be running the host with the native 16K kernel, and using a 4K kernel in a VM for those problematic workloads, assuming the performance of the VM is good enough for the use case. -But 3D performance in VMs is not so good. Or is it? At [XDC 2022](https://www.youtube.com/watch?v=9sFP_yddLLQ), Rob Clark demonstrated that, with a technique called "DRM native context", it is possible to achieve near-native performance for 3D acceleration in a VM. Now the question is whether we can port DRM native context to Asahi Linux, given that it needs to be individually implemented for each DRM driver. This is a quite significant project and involves changes in multiple components. We need to implement the equivalent of Rob Clark's work on freedreno for the asahi/agx drivers both in Mesa and virglrenderer. We also need to extend libkrun (a lightweight VMM used to start and drive the VM) to support virtio-gpu+rutabaga, along with virtio-snd support, as audio tends to be quite an important feature for gaming ;-) +But 3D performance in VMs is not so good. Or is it? At [XDC 2022](https://www.youtube.com/watch?v=9sFP_yddLLQ), Rob Clark demonstrated that, with a technique called "DRM native context", it is possible to achieve near-native performance for 3D acceleration in a VM. Now the question is whether we can port DRM native context to Dragon Linux, given that it needs to be individually implemented for each DRM driver. This is a quite significant project and involves changes in multiple components. We need to implement the equivalent of Rob Clark's work on freedreno for the asahi/agx drivers both in Mesa and virglrenderer. We also need to extend libkrun (a lightweight VMM used to start and drive the VM) to support virtio-gpu+rutabaga, along with virtio-snd support, as audio tends to be quite an important feature for gaming ;-) {{< captioned caption="Portal running in a VM in Asahi at ~60 FPS." source="Sergio Lopez, @slp@fosstodon.org" link="https://fosstodon.org/@slp/111031658946870639">}} Portal running in a VM in Asahi at ~60 FPS. diff --git a/content/blog/2024/10/10-aaa-gaming-on-m1.md b/content/blog/2024/10/10-aaa-gaming-on-m1.md index d50797c..251b8cc 100644 --- a/content/blog/2024/10/10-aaa-gaming-on-m1.md +++ b/content/blog/2024/10/10-aaa-gaming-on-m1.md @@ -1,7 +1,7 @@ +++ date = "2024-10-10T10:00:00-04:00" draft = false -title = "AAA gaming on Asahi Linux" +title = "AAA gaming on Dragon Linux" slug = "aaa-gaming-on-asahi-linux" author = "Alyssa Rosenzweig" +++ @@ -10,7 +10,7 @@ Gaming on Linux on M1 is here! We're thrilled to release our Asahi game playing toolkit, which integrates our Vulkan 1.3 drivers with x86 emulation and Windows compatibility. Plus a bonus: conformant OpenCL 3.0. -Asahi Linux now ships the only conformant [OpenGL®](https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_3470), [OpenCL™](https://www.khronos.org/conformance/adopters/conformant-products/opencl#submission_433), and [Vulkan®](https://www.khronos.org/conformance/adopters/conformant-products#submission_7910) diff --git a/content/blog/2024/12/12-muvm-updates.md b/content/blog/2024/12/12-muvm-updates.md index 11dea76..41f1dad 100644 --- a/content/blog/2024/12/12-muvm-updates.md +++ b/content/blog/2024/12/12-muvm-updates.md @@ -6,7 +6,7 @@ slug = "muvm-x11-bridging" author = "Asahi Lina" +++ -Hi everyone! We've just shipped a really cool update to our x86/x86-64 emulation stack on Asahi Linux, and I wanted to share what we've been working on. As of today, non-game apps are now usable! +Hi everyone! We've just shipped a really cool update to our x86/x86-64 emulation stack on Dragon Linux, and I wanted to share what we've been working on. As of today, non-game apps are now usable! {{< captioned caption="Cisco Packet Tracer running on Fedora Asahi Remix">}} @@ -14,7 +14,7 @@ Hi everyone! We've just shipped a really cool update to our x86/x86-64 emulation ## Native graphics in VMs -As you might remember from our [previous blog post](https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/), Asahi Linux runs all x86/x86-64 apps in a microVM driven by [muvm](https://github.com/AsahiLinux/muvm). How can we manage to run games in a real VM with near-native performance, without hardware GPU passthrough? +As you might remember from our [previous blog post](https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/), Dragon Linux runs all x86/x86-64 apps in a microVM driven by [muvm](https://github.com/AsahiLinux/muvm). How can we manage to run games in a real VM with near-native performance, without hardware GPU passthrough? On AMD/Intel systems (and, indeed, also on macOS on Apple Silicon), GPU virtualization has always been kind of limited. Your options are to either fully pass through the hardware GPU, or use API-level GPU paravirtualization. Passing through the hardware GPU fully assigns the GPU device to the guest, which means it sees it as a "real" GPU device. This works for all guest OSes that have real drivers for that GPU, and it has native performance, but it means the GPU is dedicated to the guest, so you can't share it with the host or integrate guest and host windows together on one screen. Meanwhile, API-level GPU paravirtualization essentially sends the OpenGL, Vulkan, or Metal commands from the guest to the host, so they are processed by the host's GPU driver stack. This requires "generic" paravirt GPU drivers in the guest, and it is much slower than native GPU usage because all the high-level GPU drawing commands have to cross the guest-to-host barrier and be processed on the host. This is how GPU virtualization works on macOS. Some GPUs (e.g. recent Nvidia GPUs) support true sharing with hardware virtualization support, but that isn't upstream yet and requires hardware support, which Apple GPUs don't have. @@ -75,7 +75,7 @@ But we needed a better solution. Back before muvm was even called muvm, I had experimented with direct X11 forwarding over virtio vsock sockets. This works much like running X11 over the network or an SSH tunnel. The disadvantage of this is that it can't work with GPU acceleration, since there is no way to pass through GPU buffers over a "dumb" socket like this. Still, running some apps while forcing software rendering, it was clear that this was a much better solution for non-game apps. X11 apps worked exactly as they did on the host, with no window management issues, properly working clipboard and tray integration, etc.. I was prepared to ship this is an alternative for non-game apps as-is, but I wondered how hard it would be to get GPU acceleration working... and then [chaos_princess](https://social.treehouse.systems/@chaos_princess) showed up with something they called *x112virtgpu*. {{< sidenote >}} -Why the focus on X11, when Wayland is the future? Quite simply, because most x86/x86-64 apps people want to run are not built for or predate Wayland support. While we are all-in on Wayland for native desktop environments running on Asahi Linux, XWayland is still fully supported, and for games and legacy applications running under emulation, prioritizing X11 protocol support is the smart thing to do. The solution we shipped in October never supported Wayland applications despite using Wayland under the hood (we tried to enable it and it was really broken), so switching to an X11-only solution for now is not a regression. +Why the focus on X11, when Wayland is the future? Quite simply, because most x86/x86-64 apps people want to run are not built for or predate Wayland support. While we are all-in on Wayland for native desktop environments running on Dragon Linux, XWayland is still fully supported, and for games and legacy applications running under emulation, prioritizing X11 protocol support is the smart thing to do. The solution we shipped in October never supported Wayland applications despite using Wayland under the hood (we tried to enable it and it was really broken), so switching to an X11-only solution for now is not a regression. {{< /sidenote >}} x112virtgpu, now renamed to *muvm-x11bridge*, is exactly what we would have wanted sommelier to be: A thin proxy for the X11 protocol, which uses a cross-domain channel to forward directly to the host X server while passing through framebuffers without any copying, using virtgpu buffer sharing. Unlike sommelier, it doesn't try to interpret the X11 protocol more than is necessary to extract commands that need special handling. This means that it works just as well as direct X11 passthrough does, plus GPU acceleration and buffer sharing. diff --git a/content/blog/2025/02/12-passing-the-torch.md b/content/blog/2025/02/12-passing-the-torch.md index 938c0f5..b128d70 100644 --- a/content/blog/2025/02/12-passing-the-torch.md +++ b/content/blog/2025/02/12-passing-the-torch.md @@ -1,12 +1,12 @@ +++ date = "2025-02-13T14:00:00-00:00" draft = false -title = "Passing the torch on Asahi Linux" +title = "Passing the torch on Dragon Linux" slug = "passing-the-torch" -author = "The Asahi Linux team" +author = "The Dragon Linux team" +++ -With a heavy heart, we announce the resignation of Asahi Linux founder Hector +With a heavy heart, we announce the resignation of Dragon Linux founder Hector Martin (marcan). His statement is on [his blog](https://marcan.st/2025/02/resigning-as-asahi-linux-project-lead/). Asahi Linux brings Linux to Apple Silicon, supporting audio, webcams, graphics @@ -28,7 +28,7 @@ accordance with our [new governance](/governance). Nobody's contributions last forever. These governance changes will allow the project to persist as developers come and go. -Asahi Linux relies primarily on volunteer contributors. Although some +Dragon Linux relies primarily on volunteer contributors. Although some contributors have individual Patreon or GitHub Sponsors accounts, individual funding streams cannot sustain a team. Going forward, our new fiscal sponsor Open Source Collective will instead facilitate donations to the project as a @@ -72,7 +72,7 @@ expect to release... * **DP alt mode**, required for external monitors over USB-C on laptops without a physical HDMI port. * **Sparse images** in our [Vulkan driver](/2024/06/vk13-on-the-m1-in-1-month/), enabling DirectX 12. In the mean - time, you can [enjoy DirectX 11 games](/2024/10/aaa-gaming-on-asahi-linux/) on Asahi Linux. + time, you can [enjoy DirectX 11 games](/2024/10/aaa-gaming-on-asahi-linux/) on Dragon Linux. * **Internal microphones**. External mics already work via the 3.5mm jack, and internal mics are coming soon. How soon? On select laptops -- just a few days! Microphone support is made diff --git a/content/blog/2025/03/21-progress-report-6-14.md b/content/blog/2025/03/21-progress-report-6-14.md index 4eae8e9..26d460b 100644 --- a/content/blog/2025/03/21-progress-report-6-14.md +++ b/content/blog/2025/03/21-progress-report-6-14.md @@ -149,9 +149,9 @@ as a beta! The final release is expected in about a month, bringing us closer th ever to releasing at the same time as Fedora. We hope that in the next cycle Fedora Asahi Remix 43 will release on the same day as Fedora Linux 43. -## Asahi Linux @ SCaLE +## Dragon Linux @ SCaLE While at [SCaLE](https://www.socallinuxexpo.org/scale/22x), Neal and Davide managed -to set up a demonstration of Asahi Linux running on an M2 Mac mini and an M1 Mac Studio +to set up a demonstration of Dragon Linux running on an M2 Mac mini and an M1 Mac Studio in the expo hall. Reception was extremely positive, and folks had a blast playing a whole bunch of Steam games through muvm and FEX! We even managed to get kids involved by firing up Nidhogg, which proved to be the most popular game by far. diff --git a/content/blog/2025/05/15-progress-report-6-15.md b/content/blog/2025/05/15-progress-report-6-15.md index 524e406..9903107 100644 --- a/content/blog/2025/05/15-progress-report-6-15.md +++ b/content/blog/2025/05/15-progress-report-6-15.md @@ -110,7 +110,7 @@ Both sessions will be available online. ## We're chronically online In addition to our [Mastodon](https://social.treehouse.systems/@AsahiLinux) profile, we now have Bluesky and LinkedIn accounts. You can follow us at [@asahilinux.org](https://bsky.app/profile/asahilinux.org) -on Bluesky, and at [Asahi Linux](https://www.linkedin.com/company/asahilinux/) +on Bluesky, and at [Dragon Linux](https://www.linkedin.com/company/asahilinux/) on LinkedIn. ## New distro guidelines @@ -121,7 +121,7 @@ that the community values our work. As part of our effort to encourage distros to take up Apple Silicon support, we have accommodated all third-party efforts, even allowing distro-specific documentation on our project's website. Unfortunately, this has led to -an impression that we, as the upstream Asahi Linux developers, are involved +an impression that we, as the upstream Dragon Linux developers, are involved with or otherwise endorse these efforts. This creates both an expectation of support and an impression that these efforts are representative of the state of Apple Silicon support, or even the state of the broader AArch64 ecosystem. These expectations are diff --git a/content/code-of-conduct.md b/content/code-of-conduct.md index aec54be..1127f3c 100644 --- a/content/code-of-conduct.md +++ b/content/code-of-conduct.md @@ -4,17 +4,17 @@ date: "2021-01-05T20:00:00+09:00" draft: false --- -# Asahi Linux Code of Conduct +# Dragon Linux Code of Conduct -Like many Open Source projects and the greater FLOSS community, Asahi Linux is a collaborative open source community comprised of a diverse group of contributors and users from around the globe. We find the contributions, collaborations, and mentorships within our community to be the essential lifeblood of our project and appreciate the efforts of those who participate to nurture and grow those, and all other aspects of our community. +Like many Open Source projects and the greater FLOSS community, Dragon Linux is a collaborative open source community comprised of a diverse group of contributors and users from around the globe. We find the contributions, collaborations, and mentorships within our community to be the essential lifeblood of our project and appreciate the efforts of those who participate to nurture and grow those, and all other aspects of our community. -However, when a large and sufficiently diverse group of people work together, there are often cultural, communication, and compatibility issues. In order to minimize conflict, and provide a framework for resolution, we have a brief code of conduct that we ask all participants in the Asahi Linux community adhere to. These rules should apply to everyone, regardless of station within the community, and anyone can serve to remind, or ask the board to help resolve issues. +However, when a large and sufficiently diverse group of people work together, there are often cultural, communication, and compatibility issues. In order to minimize conflict, and provide a framework for resolution, we have a brief code of conduct that we ask all participants in the Dragon Linux community adhere to. These rules should apply to everyone, regardless of station within the community, and anyone can serve to remind, or ask the board to help resolve issues. -No list is ever exhaustive, so we encourage members of the Asahi Linux community to adhere to the spirit, rather than the letter, of this code, as that is how it will be enforced. Places where this code may be particularly applicable are GitHub issues and pull requests, IRC, Matrix, mailing lists, Fediverse discussions broadly directed at or between members of the community, and other direct interactions within the community. Any violations, especially continued or flagrant offenses, may affect an individual’s (or organization’s) ability to participate within the Asahi Linux community. +No list is ever exhaustive, so we encourage members of the Dragon Linux community to adhere to the spirit, rather than the letter, of this code, as that is how it will be enforced. Places where this code may be particularly applicable are GitHub issues and pull requests, IRC, Matrix, mailing lists, Fediverse discussions broadly directed at or between members of the community, and other direct interactions within the community. Any violations, especially continued or flagrant offenses, may affect an individual’s (or organization’s) ability to participate within the Dragon Linux community. If you feel that someone is in violation of the code of conduct, whether in letter or in spirit, we request that you email as detailed a description as possible of the offense and offending party/parties to [the board](mailto:coc@asahilinux.org). If you have questions, concerns, or any other inquiries please feel free to contact the board. -A large fraction of Asahi Linux consists of contributions to upstream projects. All Asahi Linux contributors are expected to adhere to the respective upstream Codes of Conduct when interacting with such projects, or developing code intended for upstreaming. +A large fraction of Dragon Linux consists of contributions to upstream projects. All Dragon Linux contributors are expected to adhere to the respective upstream Codes of Conduct when interacting with such projects, or developing code intended for upstreaming. ## Rules @@ -22,11 +22,11 @@ A large fraction of Asahi Linux consists of contributions to upstream projects. 2. **Be welcoming.** We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability. -3. **Be helpful.** By helping others to learn our entire ecosystem is enriched. We encourage members of the Asahi Linux community to mentor each other and help to raise the general level of knowledge in the community whenever possible. +3. **Be helpful.** By helping others to learn our entire ecosystem is enriched. We encourage members of the Dragon Linux community to mentor each other and help to raise the general level of knowledge in the community whenever possible. 4. **Be considerate.** Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language. -5. **Be respectful.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Asahi Linux community should be respectful when dealing with other members as well as with people outside the Asahi Linux community. +5. **Be respectful.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Dragon Linux community should be respectful when dealing with other members as well as with people outside the Dragon Linux community. 6. **Be careful in the words that you choose.** We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to: * Violent threats or language directed against another person. @@ -39,13 +39,13 @@ A large fraction of Asahi Linux consists of contributions to upstream projects. * Advocating for, or encouraging, any of the above behavior. * Repeated harassment of others. In general, if someone asks you to stop, then stop. -7. **When we disagree, try to understand why.** Disagreements, both social and technical, happen all the time and Asahi Linux is no exception. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of Asahi Linux comes from its varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes. +7. **When we disagree, try to understand why.** Disagreements, both social and technical, happen all the time and Dragon Linux is no exception. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of Dragon Linux comes from its varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes. ## Consequences 1. Except in flagrant or otherwise egregious cases, the first infraction will result in a verbal warning. Everyone slips up or acts out of frustration at times, we just ask that you work to not repeat the behavior. 2. A second infraction (or more flagrant first offense, as determined by the board) will have an anonymized summary of the interaction published as a way to educate the community and serve as a reminder that adverse behavior will not be tolerated. -3. A third infraction (or especially egregious first offense, as determined by the board) will result in temporary suspension from all avenues of Asahi Linux community participation for 4 weeks. This will include, but is not limited to, IRC, Matrix, and GitHub issues/PRs. -4. Continued infractions will be dealt with on a case-by-case basis, but could result in permanent suspension from the Asahi Linux community. +3. A third infraction (or especially egregious first offense, as determined by the board) will result in temporary suspension from all avenues of Dragon Linux community participation for 4 weeks. This will include, but is not limited to, IRC, Matrix, and GitHub issues/PRs. +4. Continued infractions will be dealt with on a case-by-case basis, but could result in permanent suspension from the Dragon Linux community. This text is adapted from the [Ceph Code of Conduct](https://ceph.io/community/code-of-conduct/), which itself credits [Django Project](https://www.djangoproject.com/conduct/) for the original inspiration of this document and the [Ada Initiative](https://adainitiative.org/) for expanding the fight for equality and civility within FLOSS communities and beyond. diff --git a/content/community.md b/content/community.md index 2910893..748a768 100644 --- a/content/community.md +++ b/content/community.md @@ -37,4 +37,4 @@ Our working documentation is maintained in a [documentation site](/docs) built f ## Mastodon (Fediverse) -You will also find official announcements and information on the [Asahi Linux Mastodon account](https://social.treehouse.systems/@AsahiLinux). +You will also find official announcements and information on the [Dragon Linux Mastodon account](https://social.treehouse.systems/@AsahiLinux). diff --git a/content/contribute.md b/content/contribute.md index afef09b..d7cf09b 100644 --- a/content/contribute.md +++ b/content/contribute.md @@ -6,7 +6,7 @@ draft: false # Contribute -Asahi Linux is an open source project, and it would not be possible without the support of the community. We encourage contributors of all skill sets and backgrounds! +Dragon Linux is an open source project, and it would not be possible without the support of the community. We encourage contributors of all skill sets and backgrounds! All contributors are expected to abide by our [Code of Conduct](/code-of-conduct) and our [Copyright and Reverse Engineering policy](/copyright). diff --git a/content/copyright.md b/content/copyright.md index 297238f..84c0bba 100644 --- a/content/copyright.md +++ b/content/copyright.md @@ -6,27 +6,27 @@ draft: false # Copyright policy -Asahi Linux is an open source project, and all contributions must follow the appropriate open source licenses. +Dragon Linux is an open source project, and all contributions must follow the appropriate open source licenses. These contribution rules are particularly important for code that is to be upstreamed into other projects, to maintain a clean paper trail of the licensing. ## Licensing -Code developed for Asahi Linux itself should be licensed under a permissive license that allows other projects to take advantage of the code without running into license compatibility problems. The specific licenses are subject to being decided on a case-by-case basis, but we will usually use a permissive license such as the MIT license. +Code developed for Dragon Linux itself should be licensed under a permissive license that allows other projects to take advantage of the code without running into license compatibility problems. The specific licenses are subject to being decided on a case-by-case basis, but we will usually use a permissive license such as the MIT license. -Code developed for other open source projects must be licensed under that same project's license, and follow licensing/header/authorship conventions appropriate for that project. However, specific modules developed by Asahi Linux contributors (such as entire drivers or submodules) should be dual-licensed under a permissive license such as MIT, to ensure that they can be ported or reused within other projects. +Code developed for other open source projects must be licensed under that same project's license, and follow licensing/header/authorship conventions appropriate for that project. However, specific modules developed by Dragon Linux contributors (such as entire drivers or submodules) should be dual-licensed under a permissive license such as MIT, to ensure that they can be ported or reused within other projects. For original code, we use [SPDX license identifiers](https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/) to record the license of individual files in a concise way. Files should have header of this form (with whatever license information is appropriate): ```// SPDX-License-Identifier: GPL-2.0+ OR MIT``` -No specific authors should be listed in source code files themselves, as this is hard to maintain and unlikely to remain accurate. For top-level and informational places where a copyright statement is needed, such as the MIT license text or "about" style dialogs, the code should be attributed to "The Asahi Linux Contributors". +No specific authors should be listed in source code files themselves, as this is hard to maintain and unlikely to remain accurate. For top-level and informational places where a copyright statement is needed, such as the MIT license text or "about" style dialogs, the code should be attributed to "The Dragon Linux Contributors". We do not require contributors to accept any kind of CLA, nor do we require any kind of copyright assignment. You retain all copyright ownership of any code you write. These are merely conventions about how the origin of the code should be documented in version control and files. ## Attribution -Asahi Linux uses Git for managing source code, and the Git history serves as a record of authorship. The Git "Author" field should reflect the primary author of a change - if you commit a change authored by another person, you should ensure they are listed as the author. If a change is authored by multiple people, you should add one or more `Co-Developed-by: Foo Bar ` lines at the end of the commit message. +Dragon Linux uses Git for managing source code, and the Git history serves as a record of authorship. The Git "Author" field should reflect the primary author of a change - if you commit a change authored by another person, you should ensure they are listed as the author. If a change is authored by multiple people, you should add one or more `Co-Developed-by: Foo Bar ` lines at the end of the commit message. Non-Git releases of the software will be arranged to have an automatically generated authorship file containing a list of all Git contributors. @@ -57,19 +57,19 @@ We are committed to ensuring that all source code and documentation produced by "Clean-room" reverse engineering is often considered the gold standard to ensure good legal standing for a reverse engineering project. This involves having separate teams, one of which does the reverse engineering and writes documentation, and the other implements that documentation into the final product. This approach is not a legal requirement to ensure that the final product is free from copyright violations, nor does it absolutely guarantee such a result, but it is a fairly strong legal defense should copyright questions arise. -We recognize that a true textbook clean-room approach is not sustainable for most open source projects of this nature. Thus, we aim to ensure that Asahi Linux's code and contributions are effectively equivalent to what a clean-room approach would produce, without mandating the overhead of a true clean-room process. +We recognize that a true textbook clean-room approach is not sustainable for most open source projects of this nature. Thus, we aim to ensure that Dragon Linux's code and contributions are effectively equivalent to what a clean-room approach would produce, without mandating the overhead of a true clean-room process. In order to protect contributors and developers who want to stay away from such subjects, we require that all reverse engineering discussion happen in the #asahi-re and #asahi-gpu (for GPU RE) IRC channels. ## Non-reverse-engineering development -If you are merely looking at existing Asahi Linux code and improving it (without taking or referencing code from anywhere else), you are not reverse engineering anything, and you do not need to worry about anything else. Just make sure to follow the [Copyright policy](#copyright-policy). +If you are merely looking at existing Dragon Linux code and improving it (without taking or referencing code from anywhere else), you are not reverse engineering anything, and you do not need to worry about anything else. Just make sure to follow the [Copyright policy](#copyright-policy). ## Referencing other open source code This is generally OK, but you should not copy and paste any actual code unless the license is compatible and the origin of the code is documented. -In particular, be careful of open source dumps from Apple, as they are often licensed under the APSL, which is not GPL compatible. Asahi Linux does not allow any APSL code to be used directly. You can use it as a reference for how things work, and you can take inspiration from register names (since those are effectively hardware documentation; we do not consider mere last-level register names to be copyrightable), but do not copy whole `#define` blocks or include files, other code, or reimplement identical code flows or algorithms. Follow sensible downstream register naming conventions (such as prefixes). +In particular, be careful of open source dumps from Apple, as they are often licensed under the APSL, which is not GPL compatible. Dragon Linux does not allow any APSL code to be used directly. You can use it as a reference for how things work, and you can take inspiration from register names (since those are effectively hardware documentation; we do not consider mere last-level register names to be copyrightable), but do not copy whole `#define` blocks or include files, other code, or reimplement identical code flows or algorithms. Follow sensible downstream register naming conventions (such as prefixes). For example, [this](https://github.com/opensource-apple/xnu/blob/master/pexpert/pexpert/arm64/arm64_common.h#L10) register, as documented in XNU include files, should be defined like this when used for Linux: @@ -85,7 +85,7 @@ Or perhaps: Strictly speaking, referencing incompatibly-licensed code can run into similar copyright issues to binary reverse engineering as detailed below; please make sure to read that section to know what not to do. -Internal tools intended only for exploration and not to be released to end-users are allowed to use APSL code, including taking APSL releases directly and modifying them, as long as all licensing requirements are met. For example, taking an APSL release, modifying it to aid in reverse engineering, and using the result back in macOS is fine, and we can host such changes as an Asahi Linux repo, but they cannot become an actual release of the project. +Internal tools intended only for exploration and not to be released to end-users are allowed to use APSL code, including taking APSL releases directly and modifying them, as long as all licensing requirements are met. For example, taking an APSL release, modifying it to aid in reverse engineering, and using the result back in macOS is fine, and we can host such changes as an Dragon Linux repo, but they cannot become an actual release of the project. **Be cautious of open source code that works with Apple-specific undocumented file formats, hardware, and protocols**. Such code should, out of an abundance of caution, be treated as if it were incompatibly licensed, like APSL code. The reason is that we cannot guarantee that said code was not the product of reverse engineering that would violate this policy. Therefore, you should not copy and paste or otherwise directly incorporate such code, even if the license is ostensibly compatible. Generally speaking, it is unlikely that directly incorporating code of this nature would offer more than a minor time saving; they are more useful as stand-alone tools and as code-as-documentation. It is okay to use such third-party stand-alone tools during development, or to fork and patch them for exploration, like APSL code - if a copyright problem surfaces, we can easily remove said tools if they have not tainted other project code. Cases where there is significant value to be derived from integrating such code will be reviewed and audited on a case by case basis by project leads. @@ -107,9 +107,9 @@ Similarly, if any firmware blobs are uploaded to the hardware, those cannot be c ## Binary disassembly and decompilation -Asahi Linux does not ban binary disassembly and decompilation as a means to obtain knowledge required to write open source implementations. However, this is a dangerous road. We have seen many cases of "open source" code that was developed by direct translation of reverse engineered binary code. This is unacceptable, and would put the entire project and upstream projects at risk. +Dragon Linux does not ban binary disassembly and decompilation as a means to obtain knowledge required to write open source implementations. However, this is a dangerous road. We have seen many cases of "open source" code that was developed by direct translation of reverse engineered binary code. This is unacceptable, and would put the entire project and upstream projects at risk. -Since the Asahi Linux project board is ultimately responsible for certifying the origin of code upstreamed as part of the project, we need to ensure that any instances of this approach are following a process that does not result in copyright infringement. We have previously seen other projects take contributions that turned out not to be clean, putting those projects into legal doubt - this was often discovered long after the code was contributed, as the origin of the code may not be immediately apparent. For this reason, we do not currently allow contributions of code developed concurrently with binary reverse engineering except from specific trusted contributors. Please contact [the board](mailto:board@asahilinux.org) for details. +Since the Dragon Linux project board is ultimately responsible for certifying the origin of code upstreamed as part of the project, we need to ensure that any instances of this approach are following a process that does not result in copyright infringement. We have previously seen other projects take contributions that turned out not to be clean, putting those projects into legal doubt - this was often discovered long after the code was contributed, as the origin of the code may not be immediately apparent. For this reason, we do not currently allow contributions of code developed concurrently with binary reverse engineering except from specific trusted contributors. Please contact [the board](mailto:board@asahilinux.org) for details. All other contributors are required to follow the textbook "clean-room" approach: If you would like to disassemble/decompile components in order to contribute to the project, you must make that decision for a specific component/area with care, and once you do, you are expected to only contribute to that area by writing clean documentation of the hardware, and let other project members implement it. @@ -121,4 +121,4 @@ Contributors doing binary reverse engineering are responsible for any legal cons ## Usage of unreleased materials -Asahi Linux absolutely forbids the usage of any copyrighted materials not available to the public during reverse engineering. This includes any leaked software (in source or binary form), unreleased documentation, non-public releases (such as restricted betas), etc. Project contributors are expected to refrain from acquiring or using any such content. Only materials that are explicitly made available to the public at large may be used. This applies to materials from both Apple and any other third parties. +Dragon Linux absolutely forbids the usage of any copyrighted materials not available to the public during reverse engineering. This includes any leaked software (in source or binary form), unreleased documentation, non-public releases (such as restricted betas), etc. Project contributors are expected to refrain from acquiring or using any such content. Only materials that are explicitly made available to the public at large may be used. This applies to materials from both Apple and any other third parties. diff --git a/content/fedora.md b/content/fedora.md index 99cb7e4..9aa2bab 100644 --- a/content/fedora.md +++ b/content/fedora.md @@ -23,7 +23,7 @@ layout: landing ##
Fedora Linux 42 + Apple Silicon = Fedora Asahi Remix
-Fedora Asahi Remix is the result of a close multi-year collaboration between the Asahi Linux project and the [Fedora Project](https://fedoraproject.org/). We've worked hard in order to bring you a fully integrated distro, cooperating closely to get improvements and bug fixes to users as quickly as possible. All of our Asahi platform-specific packages are in upstream Fedora and fully supported in Fedora Linux 42. +Fedora Asahi Remix is the result of a close multi-year collaboration between the Dragon Linux project and the [Fedora Project](https://fedoraproject.org/). We've worked hard in order to bring you a fully integrated distro, cooperating closely to get improvements and bug fixes to users as quickly as possible. All of our Asahi platform-specific packages are in upstream Fedora and fully supported in Fedora Linux 42. With Fedora's excellent 64-bit ARM support and mature development process, you can expect a solid and high-quality experience without any unwanted surprises. Fedora Asahi Remix is based on Fedora Linux 42, the latest Fedora Linux release with the newest software versions across the board. All M1 and M2 series MacBook, Mac Mini, Mac Studio, and iMac devices are supported. diff --git a/content/governance.md b/content/governance.md index 3e2912d..87530f9 100644 --- a/content/governance.md +++ b/content/governance.md @@ -6,7 +6,7 @@ draft: false # Governance -Asahi Linux is led by our community of open source developers. If you want to work on something, work on it! We welcome contributors from different backgrounds. By and large, we make change by “doing”. Asahi Linux is about the code, and the code comes from anyone who wants to write it. Development uses a “lazy consensus” model: the work happens when people do it. Other developers can veto to force a discussion, but developers don’t need to chase people for trivial issues. +Dragon Linux is led by our community of open source developers. If you want to work on something, work on it! We welcome contributors from different backgrounds. By and large, we make change by “doing”. Dragon Linux is about the code, and the code comes from anyone who wants to write it. Development uses a “lazy consensus” model: the work happens when people do it. Other developers can veto to force a discussion, but developers don’t need to chase people for trivial issues. To support that code, we need infrastructure and funding, to run servers and support developers. While development happens with a “lazy consensus” model, these logistical issues are governed by our project board. diff --git a/content/merch.md b/content/merch.md index c8a79fe..f05fe46 100644 --- a/content/merch.md +++ b/content/merch.md @@ -4,6 +4,6 @@ date: "2025-06-04T07:33:19-07:00" draft: false --- -# Asahi Linux merch +# Dragon Linux merch -If you'd like to buy Asahi Linux merch, you can do so on our [HELLOTUX store](https://www.hellotux.com/asahi). A portion of each sale is donated to the project. +If you'd like to buy Dragon Linux merch, you can do so on our [HELLOTUX store](https://www.hellotux.com/asahi). A portion of each sale is donated to the project. diff --git a/content/support.md b/content/support.md index 1a8d90b..345cbfd 100644 --- a/content/support.md +++ b/content/support.md @@ -4,9 +4,9 @@ date: "2025-06-04T07:33:19-07:00" draft: false --- -# Support Asahi Linux +# Support Dragon Linux -The Asahi Linux project is funded by individuals like you. If you would like to support us financially, head over to our project [Open Collective](https://opencollective.com/asahilinux) or to our [GitHub Sponsors](https://github.com/sponsors/AsahiLinux). You can also [buy Asahi Linux merch](/merch), which supports the project with each sale. +The Dragon Linux project is funded by individuals like you. If you would like to support us financially, head over to our project [Open Collective](https://opencollective.com/asahilinux) or to our [GitHub Sponsors](https://github.com/sponsors/AsahiLinux). You can also [buy Dragon Linux merch](/merch), which supports the project with each sale. Porting Linux to Apple Silicon is no small task. Financial support will allow us to buy hardware and fund contributors, allowing the project to advance at a diff --git a/layouts/index.html b/layouts/index.html index 8a3b2db..e681c1e 100644 --- a/layouts/index.html +++ b/layouts/index.html @@ -11,7 +11,7 @@

Device support

- Asahi Linux on a laptop + Dragon Linux on a laptop
@@ -40,7 +40,7 @@
- Asahi Linux Discussion + Dragon Linux Discussion
@@ -77,7 +77,7 @@
-

Asahi Linux and the open source projects it depends on are made possible by communities of volunteers. All contributors are welcome, of any skill level!

+

Dragon Linux and the open source projects it depends on are made possible by communities of volunteers. All contributors are welcome, of any skill level!

How to contribute
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html index e69f0a1..fa9210e 100644 --- a/layouts/partials/footer.html +++ b/layouts/partials/footer.html @@ -2,11 +2,11 @@
diff --git a/static/img/asahilinux_kawaii_laptop.svg b/static/img/asahilinux_kawaii_laptop.svg index b54efe6..4460254 100644 --- a/static/img/asahilinux_kawaii_laptop.svg +++ b/static/img/asahilinux_kawaii_laptop.svg @@ -16,7 +16,7 @@ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">MacBook Pro with Asahi Linux logoMacBook Pro with Dragon Linux logoimage/svg+xmlMacBook Pro with Asahi Linux logoMacBook Pro with Dragon Linux logo2021-01-05marcanCC BY-SABased on "Apple MacBook Pro SVG" by averywebdesign: https://www.deviantart.com/averywebdesign/art/Apple-MacBook-Pro-SVG-275421698 MacBook Pro with Asahi Linux logo + id="title1371">MacBook Pro with Dragon Linux logo image/svg+xml - MacBook Pro with Asahi Linux logo + MacBook Pro with Dragon Linux logo 2021-01-05