[PATCH 0/7] Add some Asahi Linux packages

Hi Guix,

this patch series adds some packages to run Guix on Apple silicon. They are

loosely based on the offical PKGBUILDs [1] of the Asahi Linux project and the

nixos-apple-silicon [2] packages.

u-boot-apple-m1 is a modified version of u-boot from the Asahi Linux team,

which is unlikely to be upstreamed from what I heard in the internet.

m1n1 is the bootloader of the Asahi Linux project, which is placed on the EFI

system partition under /boot/efi/m1n1/boot.bin by the Asahi Linux

installer. For now this is only the package, but I think we also need a proper

Guix bootloader for this. The final /boot/efi/m1n1/boot.bin should be

concatenation of the m1n1.bin binary, the u-boot-apple-m1 binary and the Linux

device trees. I'm not very familiar with how bootloaders work in Guix, but I

believe on a system reconfigure 2 bootloaders should be installed on the EFI

system partition, m1n1 itself and GRUB (I haven't tried extlinux yet).

asahi-fwextract is a tool that extracts a manifest.txt file and 2 archives,

firmware.cpio and firmware.tar from an archive which the Asahi Linux installer

places under /boot/efi/asahi/all_firmware.tar.gz. The all_firmware.tar.gz file

itself is extracted from the rescue partition of the MacOS installation when

installing. This tool can be used by a user to create an installation or

system image that includes the required firmware.

asahi-mesa is the mesa package that includes the GPU driver and is not

upstreamed yet. asahi-mesa-utils and asahi-mesa-headers are variants that use

asahi-mesa.

The next step would be to support building a Linux with Rust modules. I'm

waiting for some patches from the Rust team to do this.

Could you please review those patches?

Thanks, Roman.

[1] https://github.com/AsahiLinux/PKGBUILDs

[2] https://github.com/tpwrules/nixos-apple-silicon

Roman Scherer (7):

gnu: Add asahi-fwextract.

gnu: libdrm: Update to 2.4.114.

gnu: Add asahi-mesa.

gnu: Add asahi-mesa-headers.

gnu: Add asahi-mesa-utils.

gnu: Add m1n1.

gnu: Add u-boot-apple-m1.

gnu/packages/bootloaders.scm | 54 ++++++++++++++++++++++++

gnu/packages/firmware.scm | 35 ++++++++++++++++

gnu/packages/gl.scm | 79 ++++++++++++++++++++++++++++++++++++

gnu/packages/xdisorg.scm | 12 +++---

4 files changed, 174 insertions(+), 6 deletions(-)

--

2.39.1

---

gnu/packages/bootloaders.scm | 32 ++++++++++++++++++++++++++++++++

1 file changed, 32 insertions(+)

---

gnu/packages/bootloaders.scm | 22 ++++++++++++++++++++++

1 file changed, 22 insertions(+)

---

gnu/packages/gl.scm | 51 +++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 51 insertions(+)

---

gnu/packages/firmware.scm | 35 +++++++++++++++++++++++++++++++++++

1 file changed, 35 insertions(+)

---

gnu/packages/xdisorg.scm | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)

---

gnu/packages/gl.scm | 13 +++++++++++++

1 file changed, 13 insertions(+)

---

gnu/packages/gl.scm | 15 +++++++++++++++

1 file changed, 15 insertions(+)

Thank you for the patches.

Here a couple of comments:

"https://github.com/AsahiLinux/m1n1/archive/v….tar.gz". These are

automatically generated and have changed in the past, leading to

different hashes. In the interest of reproducibility please use

“git-fetch” with plain commit hashes instead.

outputs "out"). Instead of this:

Please do this:

This also applies to “asahi-fwextract”.

lists of package variables. If you want to modify an inherited list

of inputs such as in “asahi-mesa” please use “modify-inputs”.

source snippet instead.

pyproject-build-system is going to be the default in the future, and

it would be good to use it already to address any incompatibilities

early.

Could you please send a new version of this patch set? Thanks again!

--

Ricardo

Hi Roman,

Thanks for the patches! I was going to work on getting Guix System running on Apple silicon machines at some point, glad more people are interested.

Can you explain more what you mean by this?

Is this updated version required by asahi-mesa? If so, it may be best to order it before adding asahi-mesa. (Also, I'm sure someone can correct me if this is a bad suggestion, but maybe mention changing the 'true's to 'enabled' in the configure flags in the change log, plus maybe why (e.g. is it deprecated in this release?))

I believe this also applies to GitLab's too, so please make sure you change it for 'asahi-mesa' and 'asahi-mesa-headers' as well.

(Speaking of, is there a reason you use 'package/inherit' for 'u-boot-apple-m1' and 'asahi-mesa', but not 'asahi-mesa-headers' and 'asahi-mesa-utils'? I understand the difference between them (mostly), but not why you'd want to only do it for those packages.)

Thanks,

Winter

---

gnu/packages/bootloaders.scm | 24 ++++++++++++++++++++++++

1 file changed, 24 insertions(+)

---

gnu/packages/bootloaders.scm | 36 ++++++++++++++++++++++++++++++++++++

1 file changed, 36 insertions(+)

---

gnu/packages/xdisorg.scm | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)

---

gnu/packages/firmware.scm | 42 +++++++++++++++++++++++++++++++++++++++

1 file changed, 42 insertions(+)

---

gnu/packages/gl.scm | 50 +++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 50 insertions(+)

---

gnu/packages/gl.scm | 6 ++++++

1 file changed, 6 insertions(+)

---

gnu/packages/gl.scm | 15 +++++++++++++++

1 file changed, 15 insertions(+)

Hi Ricardo,

I updated the patch series and sent v2 of it.

Thanks for your review!

Roman

Ricardo Wurmus <rekado@elephly.net> writes:

Hi Ricardo & Winter,

I didn't receive Winter's email and just saw it in the web interface

after I sent v2 of the patch series. Should I be subscribed to the whole

guix-patches mailing list as well to receive them? I'm new to the email

based workflow and sometimes still a bit lost.

I will address the feedback I got from Winter and send a v3.

@Winter, I will address your comments. You are right about the order of

libdrm, it should come before mesa-asahi.

About this next step. The Asahi Linux team has a version of the Linux

kernel that contains a GPU kernel module written in Rust. To build this

module I used customize-linux and added the rust and the

rust-bindgen-cli packages to its native inputs.

This is what I currently did:

```

(define (make-asahi-linux name config)

(let* ((version "6.2-rc3-6")

(base (customize-linux

#:linux linux-libre-arm64-generic

#:name name

#:source (origin

(method url-fetch)

(uri (string-append "https://github.com/AsahiLinux/linux/archive/"

"asahi-" version ".tar.gz"))

(sha256

(base32 "0bk4grzcizk48hhalyyaa4alk5069z102vx5ddw12jfqzsrdfccn"))))))

(package

(inherit base)

(version version)

(arguments

(substitute-keyword-arguments (package-arguments base)

((#:phases phases '%standard-phases)

#~(modify-phases #$phases

(add-before 'configure 'configure-rust

(lambda* (#:key inputs #:allow-other-keys)

(setenv "LIBCLANG_PATH"

(string-append (assoc-ref inputs "clang") "/lib"))

(setenv "RUST_LIB_SRC"

(string-append (assoc-ref inputs "rust-src")

"/lib/rustlib/src/rust/library"))))

(replace 'configure

(lambda* (#:key inputs #:allow-other-keys)

(copy-file #$config ".config")

(chmod ".config" #o644)))))))

(native-inputs

`(("clang" ,clang)

("llvm" ,llvm)

("python" ,python)

("rust" ,(replace-jemalloc (@@ (gnu packages rust) rust-1.62)))

("rust-bindgen-cli" ,(replace-jemalloc rust-bindgen-cli))

("rust-src" ,rust-src-1.62)

("zstd" ,zstd)

,@(package-native-inputs base)))

(home-page "https://asahilinux.org")

(synopsis "Linux on Apple Silicon")

(description "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."))))

(define-public asahi-linux

(make-asahi-linux "asahi-linux" (local-file "kernel.config")))

(define-public asahi-linux-edge

(make-asahi-linux "asahi-linux-edge" (local-file "kernel.edge.config")))

```

However, rust-bindgen-cli isn't yet packaged, and the version I used

previously (0.59.2) somehow disappeared from crates.io. They now only

have versions > 0.61.0 available, which I plan to package.

The rust team is updating many packages at the moment, so my plan was to

wait until those made it into the main branch.

I think the differences of package/inherit vs (inherit) aren't very

clear to me. I'm guess I should use package/inherit to be able to use

input transformations. Is that correct?

Roman

Roman Scherer <roman.scherer@burningswell.com> writes:

Hi Ricardo & Winter,

here's a 3rd version of the patch series:

- I changed the commit message of libdrm to mention the renamed options

- I'm using now Git and a pinned commit to fetch the sources from Github and Gitlab

- I'm now using package/inherit in all packages

I'm not sure about the ordering of libdrm. I saw the mails are not ordered by

patch number on the web interface. But looking at my Git history, and the

patch number in the subject line, libdrm ([PATCH 4/7] gnu: libdrm: Update to

2.4.114) is updated before adding asahi-mesa ([PATCH 5/7] gnu: Add

asahi-mesa). So, aren't they in the correct order?

Roman

Roman Scherer (7):

gnu: Add m1n1.

gnu: Add u-boot-apple-m1.

gnu: libdrm: Update to 2.4.114 and adjust renamed options.

gnu: Add asahi-fwextract.

gnu: Add asahi-mesa.

gnu: Add asahi-mesa-headers.

gnu: Add asahi-mesa-utils.

gnu/packages/bootloaders.scm | 59 ++++++++++++++++++++++++++++++

gnu/packages/firmware.scm | 42 ++++++++++++++++++++++

gnu/packages/gl.scm | 70 ++++++++++++++++++++++++++++++++++++

gnu/packages/xdisorg.scm | 12 +++----

4 files changed, 177 insertions(+), 6 deletions(-)

--

2.39.1

---

gnu/packages/bootloaders.scm | 36 ++++++++++++++++++++++++++++++++++++

1 file changed, 36 insertions(+)

---

gnu/packages/bootloaders.scm | 23 +++++++++++++++++++++++

1 file changed, 23 insertions(+)

---

gnu/packages/xdisorg.scm | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)

---

gnu/packages/firmware.scm | 42 +++++++++++++++++++++++++++++++++++++++

1 file changed, 42 insertions(+)

---

gnu/packages/gl.scm | 49 +++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 49 insertions(+)

---

gnu/packages/gl.scm | 6 ++++++

1 file changed, 6 insertions(+)

---

gnu/packages/gl.scm | 15 +++++++++++++++

1 file changed, 15 insertions(+)

Hi,

As I understand, some GPU drivers are written in rust.

Though the GPU driver and the display controller are separate hardware

blocks, so one could use ARM Apple computers without 3D acceleration

but with working displays and desktop environments.

The 3D acceleration is also experimental anyway, so as I understand

Asahi Linux users need to opt-in and install a specific package to be

able to use that.

What I wonder more generally here is also how to best deal with forks

and upstreaming.

As I understand Ashai is working with various upstream projects to

upstream code. So there are several possible approaches that aren't

necessarily mutually exclusive.

The project status[1] has information on what works with upstream code.

So for instance one way could be to add support though upstream

projects. Here it means that the laptops touchpads currently won't work

for instance, but almost all the important features for the Mac Mini

from 2020 would work.

That would still need a special kernel package built with 16K pages

(that is needed for some hardware features related to the IOMMU), but

it could probably be derived from the main kernel packages.

And the benefit here is that the maintenance could be done for free if

the new Linux packages are inherited from existing package and

automatically use the same version.

For the m1n1 package, Asahi Linux is the upstream, so there is probably

nothing special there.

Do you have pointers and references for that?

Another way would be to (also) package all Asahi Linux forks whenever

possible and use that. Though in that case I wonder what is the plan

for updating the packages. For instance does Asahi Linux makes some

releases? If not how to decide on the frequency of updates?

And will there be any plans for migrating to upstream projects when

forks are no longer necessary?

PS: Note that I'm just a random Guix user, I'm not a maintainer.

References:

-----------

[1]https://github.com/AsahiLinux/docs/wiki/Feature-Support

Denis.

Hi all,

Hopefully everyone can see this properly (e.g. in their email clients).

I mistakenly thought that Debbugs would forward my message to the participants, but it turns out you have to manually CC everyone if you don't have the existing conversation in your mailbox (e.g. through subscribing to the list). Maybe there's a better way to join the conversation I'm not aware of, but for now, I've just CC'd everyone manually.

Ah! Yes, you're right, I didn't realize they were out of order in the web interface... strange!

Yup, that looks good to me! Though, I do have to ask: is there a reason you swapped the additions of asahi-fwextract and asahi-mesa in v3? It's technically okay (that is, libdrm is bumped before asahi-mesa is added), but it may make more sense to group the two related changes together? Maybe I'm nit-picking too much ;)

bindgen and bindgen-cli split into two crates with v0.61.0, see https://github.com/rust-lang/rust-bindgen/blob/a8c8638d28f135823e913dab69b8a0d4fa4bbf15/CHANGELOG.md#changed-4.I suspect if you check your previous code, you were pulling bindgen pre-split.

Got it, thanks for the clarification. I was just asking because it did seem like building it was as simple as adding a few packages to inputs, so I was wondering if there was something I was missing.

Per my understanding, it has to to do with grafting, so maybe it only makes sense when a package is/can be grafted? I'm sure someone else can chime in with more concrete advice though, since both forms are used throughout the tree.

Moving on to Denis' comments:

Correct, it comprises of a kernel built with a different config, and their Mesa fork.

This is just a single configuration flag, AFAIK.

In general, I'm unsure if upstreaming these packages are the right thing to do at this point in time, due to how fast the project is moving. The Asahi team is going to eventually upstream ~all of their patches, so in the meantime, it may make the most sense to put everything Asahi-related in a channel? Of course, once things have stabilized and things are upstreamed, the channel will get smaller and smaller, but I think it may be the best option here.

(If any of you are interested in working on this, I'd be happy to help! Please reach out.)

WDYT?

Thanks,

Winter

Hi Guix,

here is another updated version of the patch series. It's the same as v3,

except that I moved asahi-fwextract to be the last patch.

The updated libdrm is needed for the asahi-mesa packages. asahi-fwextract is

not related to the mesa patches, so I moved it to the bottom.

Roman Scherer (7):

gnu: Add m1n1.

gnu: Add u-boot-apple-m1.

gnu: libdrm: Update to 2.4.114 and adjust renamed options.

gnu: Add asahi-mesa.

gnu: Add asahi-mesa-headers.

gnu: Add asahi-mesa-utils.

gnu: Add asahi-fwextract.

gnu/packages/bootloaders.scm | 59 ++++++++++++++++++++++++++++++

gnu/packages/firmware.scm | 42 ++++++++++++++++++++++

gnu/packages/gl.scm | 70 ++++++++++++++++++++++++++++++++++++

gnu/packages/xdisorg.scm | 12 +++----

4 files changed, 177 insertions(+), 6 deletions(-)

base-commit: 203578eef286f3b44cd82fd2eb965a828e21fbe7

--

2.39.1

---

gnu/packages/bootloaders.scm | 36 ++++++++++++++++++++++++++++++++++++

1 file changed, 36 insertions(+)

---

gnu/packages/bootloaders.scm | 23 +++++++++++++++++++++++

1 file changed, 23 insertions(+)

---

gnu/packages/xdisorg.scm | 12 ++++++------

1 file changed, 6 insertions(+), 6 deletions(-)

---

gnu/packages/gl.scm | 49 +++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 49 insertions(+)

---

gnu/packages/gl.scm | 6 ++++++

1 file changed, 6 insertions(+)

---

gnu/packages/firmware.scm | 42 +++++++++++++++++++++++++++++++++++++++

1 file changed, 42 insertions(+)

---

gnu/packages/gl.scm | 15 +++++++++++++++

1 file changed, 15 insertions(+)

Hello everyone,

I just sent v4 of the patch series, addressing a concern from Winter

about the order of the patches.

Winter <winter@winter.cafe> writes:

Yeah, I think that happend to me as well :)

I hope I addressed this in v4 of the patch series.

Aha, interesting. However, I still have the impression that some code

disappeared from the crates repository. This was my original package

definition that does not build anymore (it did a month ago). I will look

into it.

```

(define-public rust-bindgen-cli

(package

(name "rust-bindgen-cli")

(version "0.59.2")

(source

(origin

(method url-fetch)

(uri (crate-uri "bindgen-cli" version))

(file-name (string-append name "-" version ".tar.gz"))

(sha256

(base32 "1f4fpycxmbrqk8r2x9brhfgjh86mzc6bngn4a9631x78b2jaklib"))))

(build-system cargo-build-system)

(arguments

`(#:cargo-inputs

(("rust-bindgen" ,rust-bindgen-0.59))

#:phases

(modify-phases %standard-phases

(add-before 'check 'disable-commandline-multiple-headers-test

(lambda* (#:key outputs #:allow-other-keys)

(substitute* "src/main.rs"

(("fn commandline_multiple_headers")

"#[ignore]\n fn commandline_multiple_headers")))))))

(inputs (list clang))

(home-page "https://rust-lang.github.io/rust-bindgen/")

(synopsis "Generate Rust FFI bindings to C and C++ libraries")

(description "This package is the CLI to rust-bindgen and can be used to

automatically generate Rust FFI bindings to C and C++ libraries.")

(license license:bsd-3)))

```

Yes, I think so as well. The only missing thing to build this kernel is

the Rust support (if you want the GPU driver) for building kernel

modules.

@Winter I actually have a Guix channel where these patches are coming

from [1]. I asked a while ago on the guix-devel [2] mailing list if

there is interest in adding some of those patches to Guix itself. At

least Tobias showed interest, that's why I'm sending those patches.

[1] https://github.com/r0man/asahi-guix

[2] https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00348.html

I'm interested in collaborating on this, be it here or in my

channel. I'm especially interested in help writing a Guix bootloader for

m1n1. I'm not too familiar with how multiple bootloaders work in Guix,

and how updating m1n1 on a Guix reconfigure should work with regards to

rolling back in case something went wrong.

I think the m1n1 Guix bootloader should do something similar on system

reconfigure, as this script here does:

Replying to some of Denis questions:

I can't find it anymore. :/ I might have read it somewhere on Reddit, the

Fediverse or in one of Hector Martins presentation. I'll let you know

when I find it again.

I think they do rolling releases, since they are based on Arch

Linux. You get support for the GPU by installing their linux-asahi-edge

and mesa-asahi-edge packages.

In my channel I track their https://github.com/AsahiLinux/PKGBUILDs

repository and usually update packages whenever there is a change on

their side.

My plan was to update the Asahi package variants as long as they are

needed, and fade them out eventually when everything is upstreamed on

their side.

Roman