Skip to content

Add omarchy-ane-dkms, the Apple Neural Engine driver - #745

Merged
maralcbr merged 14 commits into
omacom:masterfrom
joshuaswarren:add-omarchy-ane-dkms
Oct 4, 2026
Merged

maralcbr merged 14 commits into
omacom:masterfrom
joshuaswarren:add-omarchy-ane-dkms

Conversation

@joshuaswarren

@joshuaswarren joshuaswarren commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Summary

This adds omarchy-ane-dkms, the Apple Neural Engine (ANE) driver for Apple Silicon Macs. The source is the published v0.4.5 release of joshuaswarren/omarchy-ane (commit d882f48). The package is aarch64 only, publishes to edge only, and carries the omarchy-platform-apple-silicon group.

When the package is installed, the ANE is on by default on the chips that ran it on real hardware: T8103 (M1), T6001 (M1 Max) and T6021 (M2 Max). The other M1 and M2 chips are opt-in and untested. omarchy-ane 0.4.5 itself turns T6000 (M1 Pro) and T6020 (M2 Pro) on, from one community row each that ran the kernel's own driver; this package keeps both opt-in (see prepare() below) until a row from this package passes on each.

Contents

  • /usr/src/omarchy-ane-$pkgver: dkms.conf (with @PKGVER@ replaced), ane/Makefile, ane/ane_stats_show.c, ane/include/, ane/src/, ane/t6021/. DKMS builds ane.ko (M1 family) and ane_t6021.ko (M2 family) for each kernel that has headers. Both modules report the package version. Both give the busy time and the job count in sysfs (ane_stats) and the last 256 submissions in debugfs (ane_timeline); the module parameter stats=0 turns both off. dkms.conf sets BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE": DKMS skips a kernel that ships its own ANE driver (exit 77) and builds on every other kernel.
  • /usr/bin: omarchy-ane-check, omarchy-ane-dt, omarchy-ane-firmware-fetch, omarchy-ane-smoke, omarchy-ane-run, omarchy-ane-probe.
  • omarchy-ane-smoke runs an add program 20 times through omarchy-ane-run and checks each output bit for bit. The M1 family (T8103, T6000, T6001, T6002) runs /usr/share/omarchy-ane/fixtures/h13-anec/add/program-0.anec; the M2 family (T6020, T6021, T6022, T8112) runs /usr/share/omarchy-ane/fixtures/h14-anec/add/program-0.anec. It prints one JSON line. Exit 0: 20 of 20 bit-exact. Exit 1: a call failed or was not exact. Exit 2: no smoke on this Mac. build() makes omarchy-ane-run (tools/ane-run) with libane linked statically. At run time it needs only libc and libm.
  • omarchy-ane-probe prints a read-only JSON report of the ANE state, with no root and no network. It compares the device tree with the chip's table in /usr/share/omarchy-ane/soc.
  • /usr/share/omarchy-ane/soc/SOC.json: cited ANE data for twelve chips after the M2 that no driver binds (T8122, T6030, T6031, T6034, T8132, T6040, T6041, T8140, T8142, T6050, T8150, T8152). packaging/build-dtbo installs them. It compiles the eight data-only overlays as a check and installs none of them.
  • /usr/lib/omarchy-mac-boot/dtb-overlays/PREFIX/omarchy-NAME.dtbo, from packaging/build-dtbo. omarchy-mac-boot 20261004-2 (omacom/omarchy-mac-pkgs 2a3ed89) ships this directory and applies the overlays in it when it builds m1n1 stage 2. Without omarchy-mac-boot (Arch Linux ARM), this package creates the directory, and omarchy-ane-dt applies the overlays from the pacman hooks.
    • Enabled: t8103, t6001, t6021.
    • Opt-in (untested; the key is one line in /etc/omarchy-mac-boot/dtb-overlays.opt-in): t6000 (ane-t6000), t6002 (ane-t6002), t6020 (ane-t6020), t6022 (ane-t6022), t8112 (ane-t8112), and the T6021 U-Boot input overlay (uboot-serial-stdin-t6021). omarchy-ane-check prints UNTESTED SoC on these chips. Lines in the retired /etc/omarchy-platform/dtb-overlays.opt-in have no effect; the owner moves them.
  • /usr/lib/omarchy-ane/update-m1n1-dtbs and the pacman hooks 90-omarchy-ane-dt.hook and 90-omarchy-ane-dt-remove.hook. The second Target of 90-omarchy-ane-dt.hook is usr/lib/omarchy-mac-boot/dtb-overlays/*/*.dtbo, the Target of omarchy-mac-boot's 95-omarchy-mac-dtb-overlays.hook.
  • 90-omarchy-ane-firmware.hook: after each install and upgrade it runs omarchy-ane-firmware-fetch --hook. The package cannot ship Apple firmware, and Linux must start the T6021 ANE firmware. The hook fetches the pinned image from the macOS 13.5 IPSW on T6021 only. When the pinned file is there, it downloads nothing. When the fetch fails, it prints a note and exits 0. The ANE then stays off until sudo omarchy-ane-firmware-fetch succeeds and the Mac reboots. M1 chips need no fetch: iBoot loads their firmware.
  • conflicts=('omarchy-mac-boot<20261004-2'): an older omarchy-mac-boot does not read /usr/lib/omarchy-mac-boot/dtb-overlays, and its boot check fails on a DKMS module. pacman refuses this package next to it; with --noconfirm and on an empty answer the default is No. A system without omarchy-mac-boot is not affected.
  • depends=(dkms 'dtc>=1:1.7.1' python). dtc 1.7.1 is the first release that keeps a labelled node's phandle when it applies an overlay. Arch's dtc has epoch 1, so the bound carries it. makedepends=(dtc libdrm): libane includes drm.h from libdrm.
  • optdepends: linux-aurora-headers, linux-asahi-headers.
  • provides=(omarchy-ane-abi=1): ANE_ABI_MAJOR of ane.ko. The ioctl interface does not change in 0.4.5.
  • prepare() runs the release's own tools/promote_chip.py --chip t6000 --to opt-in --apply and the same for t6020. That sets both rows of packaging/dt/overlays to opt-in, puts the omarchy,opt-in key back in both overlays, lists both chips as untested in omarchy-ane-check, and leaves DEFAULT_ON of the firmware hook at apple,t6021.
  • check() runs the seven tool tests, then asserts that T6000 and T6020 stay opt-in: the built t6000 and t6020 overlays carry ane-t6000 and ane-t6020, DEFAULT_ON does not name apple,t6020, and omarchy-ane-check prints UNTESTED SoC on both chips. Then it runs dkms build in a private DKMS tree. After a build it lists ane.ko and ane_t6021.ko. On a kernel with CONFIG_DRM_ACCEL_ANE (the in-tree driver), dkms exits 77 and builds nothing; check() prints that and passes. Any other dkms failure fails check().
  • post_remove deletes the firmware files that omarchy-ane-firmware-fetch wrote (T602x and T8112). pacman does not own them. The remove hook takes out the update-m1n1 line and the overlaid device-tree copies.

Tested chips

From the v0.4.2 release notes. Each on-by-default chip is tested on one machine. These gates built the modules from source (13c684a on T8103 and T6001, 5a457a3 on T6021). The module sources have not changed since: the DKMS build of v0.4.5 gives the same srcversions (B4AE691E569A2BBD37E18E3, 59494CBC56F28ED8D1122C6). libane changed in 0.4.3 (#111: an M1-family program loads straight into the buffer object); the v0.4.4 release notes give its T8103 and T6001 runs. No hardware ran 0.4.5, which moves paths only.

  • T8103 (M1), one M1 laptop: smoke 20/20 bit-exact, 40 encoder blocks bit-exact, 10-minute stress with no error, 0 dmesg findings.
  • T6001 (M1 Max), one M1 Max laptop: smoke 20/20 bit-exact, 10-minute stress with no error, 0 dmesg findings. One timing bar (encoder within 1 % between the two arms) failed at 2.748 % because the new arm is faster; outputs were bit-exact in both arms.
  • T6021 (M2 Max), one M2 Max laptop, passed at the default parameters: boot and bind, smoke 20/20, nine gate ops, the whole Parakeet encoder bit-exact. In v0.4.0, one boot of that laptop with the packaged boot.bin (stock m1n1 1.6.1) passed 16 gates with the encoder bit-exact; that laptop needs the opt-in uboot-serial-stdin-t6021 overlay.

The package on an M1

One M1 laptop (T8103, kernel 7.1.12-2-7-ARCH, an omarchy-mac-boot with the #677 overlay hook), from the PR branch: makepkg -s --noconfirm -f with check(), then pacman -U over 0.4.0-1.

  • 0.4.2 (7980d7b): makepkg exit 0: 7 check() tests ok, dkms build done. pacman -U exit 0: DKMS removed 0.4.0 and installed 0.4.2; the UKI and m1n1 were rebuilt. ane 0.4.2, srcversion B4AE691E569A2BBD37E18E3. omarchy-ane-check --smoke: 20/20 bit-exact, ready.
  • 0.4.1 (80d5711): makepkg exit 0, pacman -U exit 0, the same steps.

The log lines are in the PR comments. No M1 Max or M2 Max has run the package.

Merge order

This PR waits until omarchy-mac-boot 20261004-2 (omarchy-pkgs #789, the port of omacom/omarchy-mac#677 in omacom/omarchy-mac-pkgs 2a3ed89) is published: on an older omarchy-mac-boot, a DKMS module fails the omarchy update boot check. conflicts=('omarchy-mac-boot<20261004-2') refuses an older omarchy-mac-boot and allows a system without one (Arch Linux ARM).

Upgrade from the 0.3.0 recipe

The 0.3.0 recipe had omarchy-ane-m2-enable and the gate /etc/modprobe.d/ane_t6021.conf in backup=(). On upgrade, pacman deletes an unchanged gate file. A changed gate file becomes ane_t6021.conf.pacsave, and modprobe reads only *.conf files. A line ane-t6021 in the opt-in file has no effect now.

Upstream watch

github: joshuaswarren/omarchy-ane, pattern v<version>, min_release_age: 24h. No auto_merge, so every bump is a reviewed PR. A release that changes the DKMS source list or the packaged files needs more than a pkgver and sha256sums bump (0.4.1 did). Since 0.4.3, omarchy-ane turns T6000 and T6020 on by default on one in-tree-driver row each; the prepare() flip keeps both opt-in here until a row from this package exists on each chip or the maintainer accepts the in-tree rows. Then the two promote_chip.py lines and their check() assertions go.

Source

The v0.4.5 release is published (not a draft or a prerelease). sha256sums is the checksum of the downloaded GitHub archive archive/refs/tags/v0.4.5.tar.gz: f19216e36e552b15c856a1d26b91f296fdebbf9d4322b0e29deadb6dd4029f3b (two equal downloads). The archive's tree equals git archive d882f48.

Verification

  • CI on 76e9aea: build, aarch64: success. makepkg 0.4.5-1 with linux-aurora-headers 7.1.12.aurora2-11 and dkms 3.4.3-2: both promote_chip.py lines ran, the seven check() tests ok, check: T6000 and T6020 are opt-in, Building module(s).... done., ane.ko and ane_t6021.ko listed; build-dtbo: t6000 (opt-in) and t6020 (opt-in) under /usr/lib/omarchy-mac-boot/dtb-overlays/.
  • The M1 runs above (0.4.2 and 0.4.1).
  • makepkg -A -d -f -C with dkms 3.4.3-2 in an Arch Linux x86_64 chroot, on the v0.4.5 archive, with the prepare() and check() above; both promote_chip.py lines ran and check() printed check: T6000 and T6020 are opt-in. The DKMS step is cross-compiled for arm64 against a module tree from the linux-aurora 7.1.12.aurora2-11 source and config. Option unset: exit 0, ane.ko and ane_t6021.ko version 0.4.5. CONFIG_DRM_ACCEL_ANE=y or =m: exit 0, check() prints that no DKMS build ran. A kernel whose module build fails: exit 4 in check().
  • Without the prepare() flip, check() fails (the firmware hook still fetches on T6020), and by hand on that tree the t6000/t6020 overlays have no omarchy,opt-in key and omarchy-ane-check prints no UNTESTED line for them.
  • The package has 58 files, the 0.4.2 list with the overlay directory moved, equal to a list derived from the release tree. All nine .dtbo match the Targets of both hooks; nothing is under an omarchy-platform directory. No data-only overlay is installed.
  • omarchy-mac-boot's own lib/dtb-overlays.sh (omarchy-mac-pkgs 2a3ed89), with a fake root that holds only this package's overlay directory, on linux-aurora 7.1.12 stock board device trees: with no opt-in file, the ANE node goes into t8103-j293, t6001-j316c and t6021-j414c only. With ane-t6000 and ane-t6020 in /etc/omarchy-mac-boot/dtb-overlays.opt-in, t6000-j314s and t6020-j414s get it too. The same lines in the retired /etc/omarchy-platform/dtb-overlays.opt-in change nothing.
  • The built package with dummy omarchy-mac-boot packages (pacman 7.1.0): none installed, it installs; 20260927-1 and 20261004-1, refused (are in conflict (omarchy-mac-boot<20261004-2)); 20261004-2, it installs.

Build approval

CI runs with the build-approved label.

The package builds ane.ko and ane_t6021.ko with DKMS from a
joshuaswarren/omarchy-ane release. It installs the device-tree
overlays, the readiness check, the M2 opt-in tools and their pacman
hooks. aarch64 and edge only.

ane_t6021 stays blocked by /etc/modprobe.d/ane_t6021.conf until the
user opts in. Removal takes out the firmware and the opt-in line that
omarchy-ane-m2-enable wrote.

The watch follows published GitHub releases after 24 hours, on the
reviewed lane.
@kwilczynski
kwilczynski self-requested a review October 1, 2026 16:43
omarchy-ane removed omarchy-ane-m2-enable and the modprobe gate
packaging/modprobe/ane_t6021.conf, and added 90-omarchy-ane-firmware.hook,
which fetches the T6021 firmware after each install and upgrade
(omarchy-ane receipts/2026-10-01-t6021-default-on).

- package(): install the firmware hook; drop omarchy-ane-m2-enable, the gate
  file and its backup=() entry. On upgrade pacman deletes an unchanged gate
  file; a changed one becomes ane_t6021.conf.pacsave, which modprobe does not
  read (it reads only *.conf).
- post_remove: remove both firmware files that omarchy-ane-firmware-fetch
  writes (T602x and T8112). Drop the ane-t6021 opt-in edit: no overlay reads
  that key now.
- The overlay comment names /usr/share/omarchy-platform/dtb-overlays.
omarchy-ane-smoke (joshuaswarren/omarchy-ane#50) runs the add program 20
times on the ANE and checks each output against the exact fp16 sum. It
runs omarchy-ane-run from its own directory with the program in
/usr/share/omarchy-ane/fixtures.

- build(): make tools/ane-run. It links libane statically and needs only
  libc and libm at run time. libdrm is a makedepend for drm.h.
- check(): add tools/test_ane_smoke.py (stub runner, fake root, no device).
- package(): install omarchy-ane-smoke, tools/ane-run as omarchy-ane-run,
  and fixtures/h14-anec/add/program-0.anec.
The source is the published v0.4.0 release of joshuaswarren/omarchy-ane
(commit 16d13ef). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.0.tar.gz.
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

The recipe now packages omarchy-ane v0.4.0 (16d13ef). In this release the ANE is on by default on T6021 (joshuaswarren/omarchy-ane#44).

  • pkgver=0.4.0. sha256sums is the checksum of archive/refs/tags/v0.4.0.tar.gz: 4061ae5c8531299c01519c03deeada4b1146c62a0809de1572534ca6c6ee562d.
  • package() installs 90-omarchy-ane-firmware.hook. After each install and upgrade it runs omarchy-ane-firmware-fetch --hook. The hook fetches only on T6021. When the pinned file is there, it downloads nothing. When the fetch fails, it prints a note and exits 0, and the ANE stays off.
  • Removed: omarchy-ane-m2-enable, /etc/modprobe.d/ane_t6021.conf and its backup=() entry. On upgrade, pacman deletes an unchanged gate file. A changed gate file becomes ane_t6021.conf.pacsave, and modprobe reads only *.conf files.
  • post_remove removes the two firmware files that omarchy-ane-firmware-fetch writes (T602x and T8112). The ane-t6021 opt-in edit is gone: no overlay reads that key now.
  • The overlays install to /usr/share/omarchy-platform/dtb-overlays, the Apply package-owned device tree overlays to m1n1 stage 2 omarchy-mac#677 directory. Enabled: t8103, t6001, t6021. Opt-in: t6000, t6002, t6020, t6022, t8112, and the T6021 U-Boot input overlay.
  • New (omarchy-ane-smoke: packaged add-fixture smoke; promotion golden and regression rule joshuaswarren/omarchy-ane#50): omarchy-ane-smoke runs the shipped add program 20 times through omarchy-ane-run and checks each output bit for bit. build() makes omarchy-ane-run (tools/ane-run, libane static; at run time it needs only libc and libm). makedepends adds libdrm (drm.h). check() adds tools/test_ane_smoke.py. package() installs both tools and /usr/share/omarchy-ane/fixtures/h14-anec/add/program-0.anec.
  • dkms.conf did not change.
  • T6021: on the M2 Max laptop, with the packaged stock m1n1 1.6.1 boot.bin (no reserved memory), the driver loads the firmware from its own memory. It passes the 16-op gate set, and the whole Parakeet encoder is bit-exact. This is one laptop, and that laptop needs the opt-in uboot-serial-stdin-t6021 overlay.

Verification, on a host without makepkg: bash -n on both files. The recipe's prepare(), build(), the four check() tests and package() ran in bash on the downloaded archive: all ok. The dkms.conf build lines, cross-compiled against an arm64 7.1.13 kernel build tree: ane.ko and ane_t6021.ko, both version 0.4.0. omarchy-ane-run cross-built for aarch64: NEEDED libm.so.6, libc.so.6. The package file list (42 files) equals the list from the release tree. Not run: makepkg, dkms build, pacman -U or -R. The PR description is rewritten for this release.

The source is the published v0.4.1 release of joshuaswarren/omarchy-ane
(commit 4f01bb3). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.1.tar.gz.

- prepare(): both modules now compile ane/ane_stats_show.c and include
  ane/include/, so the DKMS tree copies them. Without them the DKMS build
  fails on the missing ane_stats.h.
- package(): install tools/omarchy-ane-probe and the H13 add program that
  omarchy-ane-smoke runs on the M1 family. packaging/build-dtbo also installs
  the twelve data/ane-soc tables to /usr/share/omarchy-ane/soc and installs
  none of the data-only overlays.
- check(): add test_ane_probe, test_validate_ane_soc and
  test_promotion_check. test_promote_chip and test_promote_from_verdict need
  a git checkout and stay out.
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

The recipe now packages omarchy-ane v0.4.1 (4f01bb3).

  • pkgver=0.4.1. sha256sums is the checksum of archive/refs/tags/v0.4.1.tar.gz: c11bfe8eedb58d6284ef07cd7f3e46dfa513224cbe8bebf34477417574a3a343.
  • prepare() also copies ane/ane_stats_show.c and ane/include/ into the DKMS tree. Both modules need them in 0.4.1; with the 0.4.0 copy list the DKMS build fails on ane_stats.h. So a bump of pkgver and sha256sums alone does not build this release.
  • package() installs omarchy-ane-probe and the H13 add program that omarchy-ane-smoke runs on the M1 family. packaging/build-dtbo also installs the twelve SoC tables to /usr/share/omarchy-ane/soc and installs no data-only overlay.
  • check() adds test_ane_probe, test_validate_ane_soc and test_promotion_check. test_promote_chip and test_promote_from_verdict need a git checkout, so they stay out.

Verification, on a host without makepkg, on the downloaded archive: prepare(), build(), the seven check() tests and package(): all ok. The dkms.conf build lines, cross-compiled against an arm64 7.1.13 module tree: both modules version 0.4.1, with the srcversions that the release notes give for the hardware gates. The package has 58 files (0.4.0: 42), equal to the list derived from the release tree. Not run: makepkg, dkms build, pacman -U or -R. The PR description is updated for this release.

@maralcbr maralcbr added the build-approved Maintainer approved this PR to build on the self-hosted pool label Oct 2, 2026
@maralcbr

maralcbr commented Oct 2, 2026

Copy link
Copy Markdown
Collaborator

Started CI (build-approved). Could you paste your M1 makepkg and pacman -U log for 0.4.1 here? The body still says those weren't run for this version.

Merge order: this lands after #677 is merged in omarchy-mac and the omarchy-mac-boot bump that carries it is published. Any DKMS module on today's omarchy-mac-boot makes the omarchy update boot check fail on modules.* size/checksum mismatches, and #677 is the fix.

Please add a guard that refuses an older omarchy-mac-boot but still allows none (Arch Linux ARM): for example a pre_install/pre_upgrade check in omarchy-ane-dkms.install that stops when pacman -Q omarchy-mac-boot is older than the bump. I'll post the version once the bump is out.

The source is the published v0.4.2 release of joshuaswarren/omarchy-ane
(commit 545d059). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.2.tar.gz.

No other recipe line changes: the DKMS build files, the packaged files and
the check() tests are those of 0.4.1. dkms.conf now sets
BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE", so DKMS skips a kernel that
ships its own ANE driver and builds on every other kernel.
@maralcbr

maralcbr commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

0.4.2 is green on aarch64: all seven check() tests pass and DKMS builds both modules (not excluded) against linux-aurora-headers. I checked that the archive sha256 matches the published v0.4.2 release.

Still open from my earlier comment:

  • The guard against an older omarchy-mac-boot (still allowing none, for Arch Linux ARM).
  • Your M1 makepkg and pacman -U log.

Merge order is unchanged: after #677 (the disabled-node fix) and the omarchy-mac-boot bump that publishes it.

@joshuaswarren

Copy link
Copy Markdown
Contributor Author

The recipe now packages omarchy-ane v0.4.2 (545d059); head 7980d7b.

  • pkgver=0.4.2. sha256sums is the checksum of archive/refs/tags/v0.4.2.tar.gz (two equal downloads): c26179882e1e78b446c8062a9826acca1776130f452ae970fd1fc9ca150a9566.
  • No other recipe line changes. The DKMS source list, the 58 packaged files and the check() tests are those of 0.4.1.
  • dkms.conf now sets BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE". DKMS skips a kernel that ships its own ANE driver (exit 77) and builds on every other kernel. The linux-aurora config on master has no CONFIG_DRM_ACCEL_ANE, so DKMS builds there.

Checks

  • CI on 7980d7b (build): success. makepkg 0.4.2-1 ran check() (7 tests ok) and dkms build against linux-aurora-headers 7.1.12.aurora2-11: Building module(s).... done.
  • dkms 3.4.3 (the CI's version) with tools/test_dkms_exclusive.py: CONFIG_DRM_ACCEL_ANE=m exit 77, =y exit 77, unset: builds.

M1 makepkg and pacman -U logs

One M1 laptop (T8103), kernel 7.1.12-2-7-ARCH, 0.4.0-1 installed before each run. makepkg -s --noconfirm -f (no --nocheck) from the PR branch, then pacman -U.

0.4.2 (7980d7b): makepkg exit 0; pacman -U exit 0.

==> Making package: omarchy-ane-dkms 0.4.2-1 (Sat Oct  3 05:29:04 2026)
    omarchy-ane-0.4.2.tar.gz ... Passed
==> Starting check()...
test_ane_dt: ok
test_ane_firmware_fetch: ok
test_ane_m2: ok
test_ane_smoke: ok
test_ane_probe: ok
test_validate_ane_soc: ok
test_promotion_check: ok
Building module(s).... done.
==> Finished making: omarchy-ane-dkms 0.4.2-1 (Sat Oct  3 05:29:39 2026)
(3/3) Remove DKMS modules
==> dkms remove --no-depmod omarchy-ane/0.4.0 -k 7.1.12-2-7-ARCH
upgrading omarchy-ane-dkms...
(2/7) Install DKMS modules
==> dkms install --no-depmod omarchy-ane/0.4.2 -k 7.1.12-2-7-ARCH
UKI stored in /boot/efi/EFI/Linux/omarchy_linux-aurora.efi
(7/7) Updating m1n1 image for device tree overlays...
m1n1 updated at /run/.system-efi/m1n1/boot.bin

After the upgrade: ane 0.4.2, srcversion B4AE691E569A2BBD37E18E3 (the srcversion of the release's T8103 gate); omarchy-ane-check --smoke: smoke: add-fixture on t8103: 20/20 calls bit-exact, omarchy-ane-check: ready; dmesg has no ANE error, DART fault or Unbalanced pm_runtime line.

0.4.1 (80d5711): makepkg exit 0 (same check() lines, Building module(s).... done.). pacman.log of the pacman -U:

[ALPM-SCRIPTLET] ==> dkms remove --no-depmod omarchy-ane/0.4.0 -k 7.1.12-2-7-ARCH
[ALPM] upgraded omarchy-ane-dkms (0.4.0-1 -> 0.4.1-1)
[ALPM-SCRIPTLET] ==> dkms install --no-depmod omarchy-ane/0.4.1 -k 7.1.12-2-7-ARCH
[ALPM] running '95-omarchy-mac-dtb-overlays.hook'...
[ALPM-SCRIPTLET] m1n1 updated at /run/.system-efi/m1n1/boot.bin

That laptop runs an omarchy-mac-boot with the #677 hook (95-omarchy-mac-dtb-overlays.hook), not a published one.

Merge order

Understood: #745 waits until omarchy-mac#677 is merged and the omarchy-mac-boot bump that carries it is published.

Guard against an older omarchy-mac-boot

A pre_install/pre_upgrade check cannot stop the install: pacman ignores its exit status. In pacman v7.0.0, add.c:467-474 discards the return value of _alpm_runscriptlet. With pacman 7.1.0, a dummy package whose pre_install returns 1 printed error: command failed to execute correctly, and pacman -U returned 0 and installed it.

A versioned conflict does stop it. conflict.c:186 checks the version (_alpm_depcmp). callback.c:462-468 asks Remove omarchy-mac-boot? [y/N], and with --noconfirm the default (No) applies (util.c question()). Dummy packages on pacman 7.1.0 (x86_64 chroot), with conflicts=('omarchy-mac-boot<2.0-1'):

omarchy-mac-boot Result
not installed installs
1.9-1, --noconfirm refused: unresolvable package conflicts detected; 1.9-1 stays
2.0-1 or 2.1-1 installs
1.9-1, upgraded to 2.0-1 in the same transaction installs
1.9-1, empty answer to the prompt refused

An answer of y to the prompt removes omarchy-mac-boot.

So I propose conflicts=('omarchy-mac-boot<VERSION') in place of a scriptlet check. Please post VERSION; the line follows in a separate commit.

@maralcbr

maralcbr commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

Thanks, the logs settle it, and the 95-omarchy-mac-dtb-overlays.hook run is useful evidence for #677 too.

You're right about the scriptlet: pacman ignores the pre_install exit status. Go with conflicts=('omarchy-mac-boot<VERSION'). One caveat for the record: nothing requires omarchy-mac-boot on our Macs (Required By: None), so an explicit y at that prompt really removes it. The default No covers --noconfirm and a bare Enter, and that's what Omarchy's own installs use, so I accept that.

VERSION will be the pkgver of the omarchy-mac-boot bump that pins #677 with the disabled-node fix. I'll post it here once that bump is published.

dkms.conf sets BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE", so on a kernel
that ships the in-tree driver "dkms build" exits 77 and builds nothing.
check() treated that as a failure, and makepkg stopped in check().

check() now takes exit 77 as "no DKMS build" when the kernel's config sets
CONFIG_DRM_ACCEL_ANE, and prints it. After a build it lists ane.ko and
ane_t6021.ko from the DKMS tree. Every other dkms exit status still fails
check().
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

check() failed on a kernel that ships the in-tree ANE driver. A tester on an M2 Pro with such a kernel (CONFIG_DRM_ACCEL_ANE set) had to build with --nocheck. Fixed in 5ef9ebd; pkgver stays 0.4.2.

Cause

dkms.conf sets BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE", so on that kernel dkms build builds nothing and exits 77 (dkms 3.4.3: diewarn 77 in do_build, "77: skipped due to BUILD_EXCLUSIVE"). check() ran dkms build as a plain command, so makepkg stopped. The seven tool tests do not depend on the kernel; all of them passed first. The two dkms lines of check(), by hand, on a kernel tree with CONFIG_DRM_ACCEL_ANE=y:

dkms add exit 0
Warning: The .../dkms/omarchy-ane/0.4.2/7.1.12-2-11-ARCH/x86_64/dkms.conf
for module omarchy-ane/0.4.2 includes BUILD_EXCLUSIVE directives
which do not match this kernel/arch/config for any modules.
This indicates that it should not be built.
dkms build exit 77

Fix

check() keeps the status of dkms build:

  • 0: it lists ane.ko* and ane_t6021.ko* in the DKMS tree; a missing module fails check().
  • 77: it requires CONFIG_DRM_ACCEL_ANE=y or =m in the kernel's include/config/auto.conf or .config (the files dkms reads), then prints check: no DKMS build: KVER ships the in-tree ANE driver (CONFIG_DRM_ACCEL_ANE).
  • Any other status fails check(), as before.

Runs

Real makepkg -A -d -f -C and dkms 3.4.3-2 in an Arch Linux x86_64 chroot. The DKMS step is cross-compiled for arm64 (KBUILD_MODPOST_WARN=1: the tree has no Module.symvers) against an O= tree from the linux-aurora 7.1.12.aurora2-11 source and config, /usr/lib/modules/7.1.12-2-11-ARCH/build. For the in-tree cases, CONFIG_DRM_ACCEL_ANE=y or =m is added to that tree's .config and include/config/auto.conf, the two files a headers package ships. "Broken" is a kernel dir whose make modules fails.

Kernel 7980d7b 5ef9ebd
option unset exit 0 exit 0; ane.ko, ane_t6021.ko listed (version 0.4.2)
CONFIG_DRM_ACCEL_ANE=y exit 4: A failure occurred in check() exit 0; skip line printed
CONFIG_DRM_ACCEL_ANE=m exit 4: A failure occurred in check() exit 0; skip line printed
broken not run exit 4: Bad return status for module build, A failure occurred in check()

5ef9ebd, CONFIG_DRM_ACCEL_ANE=y:

test_promotion_check: ok
Warning: The .../dkms/omarchy-ane/0.4.2/7.1.12-2-11-ARCH/x86_64/dkms.conf
for module omarchy-ane/0.4.2 includes BUILD_EXCLUSIVE directives
which do not match this kernel/arch/config for any modules.
This indicates that it should not be built.
check: no DKMS build: 7.1.12-2-11-ARCH ships the in-tree ANE driver (CONFIG_DRM_ACCEL_ANE)
==> Starting package()...

5ef9ebd, option unset:

Building module(s)..... done.
.../dkms/omarchy-ane/0.4.2/7.1.12-2-11-ARCH/x86_64/module/ane.ko
.../dkms/omarchy-ane/0.4.2/7.1.12-2-11-ARCH/x86_64/module/ane_t6021.ko
==> Starting package()...

CI on 5ef9ebd (build, aarch64, linux-aurora-headers 7.1.12.aurora2-11): success; check() printed .../7.1.12-2-11-ARCH/aarch64/module/ane.ko and .../ane_t6021.ko.

Not run: a makepkg on a real in-tree-driver kernel.

At install time, the Arch dkms hook (hook.sh, dkms 3.4.3-2) runs dkms install and on a nonzero status prints ==> WARNING: `dkms install ...' exited 77 and goes on; I read this in the source and did not run it.

The source is the published v0.4.3 release of joshuaswarren/omarchy-ane
(commit 0477f72). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.3.tar.gz.

No other recipe line changes: the DKMS build files and the 58 packaged paths
are those of 0.4.2. In 0.4.3 the T6000 and T6020 overlays are enabled, and
the firmware hook also fetches on T6020.
@maralcbr

maralcbr commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

0.4.3 checksum matches the published release. Unlike 0.4.2, this one is a policy change, so I'd like to hold the T6000/T6020 flip out of this first edge package:

  • Evidence. The CHANGELOG (still under ## Unreleased in the v0.4.3 tag) cites one promotion row per chip. In tools/fixtures/promote_from_verdict/pr113-block.json, T6020 has 1 passing row out of 42, and it is driver_source: intree: the kernel's driver, not this package's DKMS ane_t6021.ko. I can't find the T6000 row (6eb94f49985b) in the release tree. This PR's "Tested chips" section still lists only T8103, T6001 and T6021.
  • Stale comments. packaging/dt/t6000-ane.dts still says "UNTESTED, OPT-IN … No M1 Pro has run ane.ko", and t6020-ane.dts says "OPT-IN, UNTESTED", but the omarchy,opt-in properties are gone.
  • T6020 risk. It now fetches firmware on install and starts ane_t6021, which can't be unloaded until reboot.

Options: package 0.4.2 here and flip T6000/T6020 in a later bump once each has a passing DKMS row from this package, or keep 0.4.3 with those two overlays opt-in via the recipe. On T6000 I can help: our lab M1 Pro (MacBookPro18,3) can run the gate once the #677 boot bump is out.

Also: libane's ANEC load changed to the direct path by default. The CHANGELOG says "Not merged before hardware" with the A/B still pending, but it's in the tag and omarchy-ane-run links it. Has the M1 smoke run on 0.4.3? And tools/__pycache__/ is committed (not packaged, just noise).

@joshuaswarren

Copy link
Copy Markdown
Contributor Author

The recipe now packages omarchy-ane v0.4.3 (0477f72); head 3e2be18.

  • pkgver=0.4.3. sha256sums is the checksum of archive/refs/tags/v0.4.3.tar.gz (two equal downloads): dcd5442ea202a71c0423b608ff95fed282f4d8e36aad297936d065d4f531712d.
  • No other recipe line changes. The DKMS source list and the 58 packaged paths are those of 0.4.2. The check() change from 5ef9ebd (dkms exit 77 on a kernel with the in-tree driver) is unchanged.

What changes in the package

  • T6000 (M1 Pro) and T6020 (M2 Pro) are on by default: their overlays are enabled and carry no omarchy,opt-in key. The omarchy-ane promotion workflow turned each on from one passing community row (rows 6eb94f49985b, 3c9389040f51).
  • 90-omarchy-ane-firmware.hook now fetches the firmware on T6020 as well as T6021 (DEFAULT_ON).
  • omarchy-ane-check no longer prints UNTESTED SoC on T6000 and T6020.
  • omarchy-ane-run (libane) loads an M1-family program straight into the buffer object; ANE_LOAD_STAGED=1 keeps the old path (omarchy-ane chore: sync AUR packages #111).
  • ane.ko and ane_t6021.ko sources do not change: the DKMS build gives the 0.4.2 srcversions (B4AE691E569A2BBD37E18E3, 59494CBC56F28ED8D1122C6).

Checks

  • CI on 3e2be18 build, aarch64: success. makepkg 0.4.3-1 with linux-aurora-headers 7.1.12.aurora2-11 and dkms 3.4.3-2: the seven check() tests ok, Building module(s).... done., then check() listed ane.ko and ane_t6021.ko.
  • makepkg -A -d -f -C with dkms 3.4.3-2 in an Arch Linux x86_64 chroot, on the v0.4.3 archive. The DKMS step is cross-compiled for arm64 against a module tree from the linux-aurora 7.1.12.aurora2-11 source and config:
Kernel makepkg
option unset exit 0; ane.ko, ane_t6021.ko version 0.4.3
CONFIG_DRM_ACCEL_ANE=y exit 0; check: no DKMS build: 7.1.12-2-11-ARCH ships the in-tree ANE driver (CONFIG_DRM_ACCEL_ANE)
CONFIG_DRM_ACCEL_ANE=m exit 0; the same line
module build fails exit 4: A failure occurred in check()
  • The package file list (58 files) equals a list derived from the v0.4.3 tree and has the same paths as 0.4.2.
  • On fake device-tree roots: the packaged omarchy-ane-firmware-fetch --hook tries the fetch on T6020, prints the ANE is not on by default here on T6022, and Nothing to fetch on T6000. The packaged omarchy-ane-smoke picks the H14 program on T6020 and the H13 program on T6000.

Not run for 0.4.3: makepkg and pacman -U on a Mac, and any T6000 or T6020 run of this package.

0.4.3 turns T6000 and T6020 on by default. Each flip rests on one community
row from a kernel with the in-tree ANE driver, not from this package, so
this first edge package keeps them opt-in and stays at 0.4.2. The check()
change for kernels with the in-tree driver stays.

pkgver and sha256sums are those of 7980d7b.
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

0.4.2 again in 48018d1 (pkgver and sha256sums as in 7980d7b). The check() change from 5ef9ebd stays. T6000 and T6020 stay opt-in; T6021 stays on by default. My 0.4.3 comment above crossed yours.

  • Evidence. Confirmed. In the public dataset (tools/promotion_check.py --remote at v0.4.3), T6000 has 11 rows and T6020 42. Each chip has one judged row, and it passed: 6eb94f49985b (T6000) and 3c9389040f51 (T6020), both driver_source: intree. The promotion rule counts in-tree and DKMS rows alike, so neither chip has a passing row from this package.
  • Stale comments. Confirmed. In v0.4.3, t6000-ane.dts and t6020-ane.dts still say OPT-IN/UNTESTED, and their omarchy,opt-in property is gone.
  • T6020 risk. Confirmed. With 0.4.3, T6020 would fetch the firmware at install and load ane_t6021, which only a reboot unloads. With 0.4.2 it stays opt-in.
  • libane. Confirmed. The v0.4.3 CHANGELOG says "Not merged before hardware", but chore: sync AUR packages #111 is in the tag and omarchy-ane-run links it. No M1 smoke has run on 0.4.3.
  • tools/__pycache__/. Confirmed: aurora_dt.cpython-312.pyc is committed in v0.4.3. It is not packaged.

omarchy-ane will cut a cleanup release, 0.4.4, with these fixes and a T8103 smoke on the new libane. The recipe moves to it after that.

Thanks for the M1 Pro offer. A T6000 run of this package there, after the #677 bump, would be that chip's first DKMS row.

CI on 48018d1: success. The recipe directory has the same tree as 5ef9ebd, so CI reused that green aarch64 build (job).

The source is the published v0.4.4 release of joshuaswarren/omarchy-ane
(commit df902f5). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.4.tar.gz.

0.4.4 is a cleanup release of 0.4.3: no driver, libane or dkms.conf change,
and the same 58 packaged paths. It keeps T6000 and T6020 on by default.
The check() change for kernels with the in-tree driver stays.
@maralcbr

maralcbr commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

0.4.4's checksum matches the release, and the cleanup is good (CHANGELOG section, no __pycache__, consistent dts headers). But it still ships T6000 and T6020 on by default: your commit message says so, t6000-ane.dts/t6020-ane.dts say "Overlay state: on by default" with no omarchy,opt-in, and DEFAULT_ON in omarchy-ane-firmware-fetch still has apple,t6020. The 0.4.4 "Known limits" itself says that on these chips "the overlay and the DKMS modules of this package have not run".

That's the case we agreed to keep out of this first edge package ("T6000 and T6020 stay opt-in"). Either:

  • go back to 0.4.2 here, or
  • keep 0.4.4 and make the two chips opt-in in the recipe: in prepare(), add omarchy,opt-in = "ane-t6000" / "ane-t6020" to those two dts roots before build-dtbo, and drop apple,t6020 from DEFAULT_ON, with a check() assertion that both stay opt-in.

Once a T6000 DKMS row exists (our M1 Pro, after the #677 bump), a follow-up bump can flip T6000.

0.4.4 keeps T6000 and T6020 on by default. Both flips rest on community rows
from kernels with the in-tree ANE driver, and this first edge package keeps
those two chips opt-in, so the recipe stays at 0.4.2 until a row from this
package exists on each.

The recipe directory is the same as at 48018d1.
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

Back to 0.4.2 in 80adc10. The recipe directory is the same as at 48018d1: pkgver=0.4.2, sha256sums c26179882e1e78b446c8062a9826acca1776130f452ae970fd1fc9ca150a9566, and the check() change from 5ef9ebd. CI on 80adc10 is green; it reused the green aarch64 build of that tree (job).

You are right: we agreed that T6000 and T6020 stay opt-in in this package, and 0.4.4 still turns both on. Thanks for confirming the 0.4.4 cleanup (CHANGELOG section, no __pycache__, consistent dts headers).

@maralcbr

maralcbr commented Oct 4, 2026

Copy link
Copy Markdown
Collaborator

omacom/omarchy-mac#677 is merged (a76179cd). The omarchy-mac-boot bump that pins it is in progress; I'll post the published VERSION here for your conflicts= line. #764 is merged too, and #791 can go once this PR and #764 are published.

@maralcbr

maralcbr commented Oct 4, 2026

Copy link
Copy Markdown
Collaborator

The overlay paths changed when #677 moved to the new Mac packages repo. omarchy-mac-boot is now built from omacom/omarchy-mac-pkgs, and its port of #677 merged there as 2a3ed89 with a new layout (the owner wants /usr/share/omarchy-platform to belong to omarchy-mac alone):

Before (#677) Now (omarchy-mac-pkgs 2a3ed89)
Overlays /usr/share/omarchy-platform/dtb-overlays/PREFIX/NAME.dtbo /usr/lib/omarchy-mac-boot/dtb-overlays/PREFIX/NAME.dtbo (omarchy-mac-boot ships the dir empty)
Opt-in list /etc/omarchy-platform/dtb-overlays.opt-in /etc/omarchy-mac-boot/dtb-overlays.opt-in (same format)
Hook target usr/share/omarchy-platform/dtb-overlays/* usr/lib/omarchy-mac-boot/dtb-overlays/*/*.dtbo
Library /usr/lib/omarchy-mac/boot/dtb-overlays.sh unchanged, so omarchy_mac() detection still works

Also new: if the admin sets DTBS= in /etc/default/update-m1n1, update-m1n1 and the boot check both leave overlays out, with a warning only. That closes the .pacnew/DTBS= follow-up for the explicit-DTBS case.

So 0.4.2 as packaged would install its overlays where nothing reads them. Needed: OVERLAY_DIR and OPT_IN in omarchy-ane-dt (and the old-dir refusal, which now has two old locations), the build-dtbo install path that reads it, the second Target of 90-omarchy-ane-dt.hook, the opt-in path in omarchy-ane-check and the docs, and the PR body. That means a new omarchy-ane release. Since 0.4.3+ turn T6000/T6020 on, either cut it from the 0.4.2 line, or keep those two opt-in in the recipe as discussed.

The boot package carrying this layout ships through #789 as omarchy-mac-boot 20261004-2 (expected; I'll confirm once it's on edge), so the guard would be conflicts=('omarchy-mac-boot<20261004-2').

The source is the published v0.4.5 release of joshuaswarren/omarchy-ane
(commit d882f48). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.5.tar.gz.

0.4.5 moves the overlays to /usr/lib/omarchy-mac-boot/dtb-overlays and the
opt-in file to /etc/omarchy-mac-boot/dtb-overlays.opt-in, the layout of
omarchy-mac-boot 20261004-2 (omacom/omarchy-mac-pkgs 2a3ed89).

- conflicts=('omarchy-mac-boot<20261004-2'): an older omarchy-mac-boot does
  not read the new overlay directory, and its boot check fails on a DKMS
  module. A system without omarchy-mac-boot is not affected.
- prepare() keeps T6000 and T6020 opt-in with the release's own
  tools/promote_chip.py, until a row from this package passes on each.
- check() asserts that both stay opt-in: the overlay key, DEFAULT_ON of the
  firmware hook, and the UNTESTED line of omarchy-ane-check.
@joshuaswarren

Copy link
Copy Markdown
Contributor Author

The recipe now packages omarchy-ane v0.4.5 (d882f48); head 76e9aea. sha256sums is the checksum of archive/refs/tags/v0.4.5.tar.gz (two equal downloads): f19216e36e552b15c856a1d26b91f296fdebbf9d4322b0e29deadb6dd4029f3b.

Your list against 0.4.5:

T6000 and T6020: one release line. 0.4.5 turns both on, so prepare() runs the release's own tools/promote_chip.py --chip t6000 --to opt-in --apply, and the same for t6020. check() asserts that both stay opt-in: the built overlays carry ane-t6000/ane-t6020, DEFAULT_ON does not name apple,t6020, and omarchy-ane-check prints UNTESTED SoC for both. Without the flip, check() fails. The two lines go when a row from this package passes on each chip, or when you say in-tree rows are enough.

Checks:

  • CI on 76e9aea (build, aarch64): success. promote_chip: t6000 -> opt-in, promote_chip: t6020 -> opt-in, the seven check() tests ok, check: T6000 and T6020 are opt-in, Building module(s).... done., build-dtbo: t6000 (opt-in): /usr/lib/omarchy-mac-boot/dtb-overlays/t6000/omarchy-ane.dtbo.
  • makepkg -A -d -f -C with dkms 3.4.3-2 in an Arch Linux x86_64 chroot, on the v0.4.5 archive, DKMS cross-compiled for arm64 against the linux-aurora 7.1.12.aurora2-11 tree: option unset exit 0 (both modules version 0.4.5); CONFIG_DRM_ACCEL_ANE=y and =m exit 0 with the "no DKMS build" line; a failing module build exit 4 in check().
  • Your lib/dtb-overlays.sh from 2a3ed89, with a fake root that holds only this package's overlay directory, on linux-aurora 7.1.12 stock board DTBs: with no opt-in file, the ANE node goes into t8103-j293, t6001-j316c and t6021-j414c only. With ane-t6000 and ane-t6020 in /etc/omarchy-mac-boot/dtb-overlays.opt-in, t6000-j314s and t6020-j414s get it too. The same lines in /etc/omarchy-platform/dtb-overlays.opt-in change nothing.
  • The built package with dummy omarchy-mac-boot packages (pacman 7.1.0): none installed, it installs; 20260927-1 and 20261004-1, refused with are in conflict (omarchy-mac-boot<20261004-2); 20261004-2, it installs.

The opt-in file is not migrated, by design: lines in the retired /etc/omarchy-platform/dtb-overlays.opt-in stop counting, and the owner re-adds them in the new file (the v0.4.5 release notes, "Breaking changes"). This package is not published yet, so no installed system has such lines from it. Not run for 0.4.5: makepkg and pacman -U on a Mac.

@maralcbr

maralcbr commented Oct 4, 2026

Copy link
Copy Markdown
Collaborator

Reviewed 0.4.5: I verified the paths, the T6000/T6020 opt-in flip (I ran your prepare() step on the release tarball, no git needed) and the green CI, and the DKMS sources equal 0.4.2's. Looks good. I'll merge once omarchy-mac-boot 20261004-2 is on edge (omarchy-pkgs#789). Before that, every Mac would get the conflict prompt, and a 'y' there removes the boot package.

@maralcbr maralcbr left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

omarchy-mac-boot 20261004-2 (overlay layout, depmod-map boot check) is live on edge. 0.4.5 matches it, keeps T6000/T6020 opt-in, CI green, M1 install evidence on the same module sources; second review agrees. Merging.

@maralcbr
maralcbr merged commit 96f90c9 into omacom:master Oct 4, 2026
6 checks passed
@github-actions

github-actions Bot commented Oct 4, 2026

Copy link
Copy Markdown
Contributor

Publish succeeded → live

Packages: omarchy-ane-dkms (aarch64, PR artifact)

  • edge/aarch64: omarchy-ane-dkms-0.4.5-1-aarch64

Commit 96f90c9 · run

maralcbr pushed a commit that referenced this pull request Oct 4, 2026
Pulls omarchy-mlx, omarchy-mlx-vulkan, omarchy-ane-dkms and
mil-hwx-compiler: MLX on the GPU and Core ML models on the Neural
Engine. Opt-in only; installs through the Install > AI row.

Depends on #745 (omarchy-ane-dkms) and #764 (omarchy-mlx) publishing
first: CI resolves each package against published edge.
@maralcbr

maralcbr commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator

First T6000 run of this package: PASS on our lab MacBook Pro 14" M1 Pro (MacBookPro18,3, apple,j314s). I installed the edge packages: omarchy-ane-dkms 0.4.5-1, omarchy-mac-boot 20261004-2, linux-aurora 7.1.12.aurora2-12. The only local change was ane-t6000 in /etc/omarchy-mac-boot/dtb-overlays.opt-in.

Before the reboot:

  • pacman -Syu omarchy-mac omarchy-mac-boot omarchy-ane-dkms: DKMS built ane 0.4.5, srcversion B4AE691E569A2BBD37E18E3, and 95-omarchy-mac-dtb-overlays.hook ran update-m1n1.
  • /run/omarchy-dtb-overlays/t6000-j314s.dtb and t6000-j316s.dtb carry apple,t6000-ane.
  • omarchy-apple-silicon-boot-check: "installed boot files match".

After the reboot (2026-10-06 08:18 AEST):

  • Running tree: /soc/ane@284000000 apple,t6000-ane, status okay, from the overlay (dtbs_source=overlay).
  • ane loaded, DART containment armed: 0, [drm] Initialized ane 1.0.0 for 285c04000.ane, /dev/accel/accel0.
  • omarchy-ane-check: ready (node, module built, loaded, bound, accel node all ok).
  • omarchy-ane-smoke: add-fixture on t6000: 20/20 calls bit-exact, min 0.037 ms, median 0.039 ms, golden 5ad7eccd…0dd6.
  • dmesg has no DART fault, Unbalanced pm_runtime, BUG or Oops. The boot check still matches after the reboot.
  • omarchy-ane-probe shows the overlay's ane, three DARTs and the six ane pmgr domains, all enabled.

The machine stays opted in for now. I haven't submitted a collector row (collect_deep.py --submit) from it yet; that's for the owner to decide.

@maralcbr

maralcbr commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator

T6000 now has a passing DKMS row from this package: aa82b34d6d02 (driver_source=dkms, submitted from the lab M1 Pro after the run above). promotion_check.py --remote: t6000 has 2 judged rows, both pass, so ON. Per your condition, a follow-up recipe PR can drop the T6000 promote_chip --to opt-in line and its check() assertion. T6020 stays opt-in until it has a DKMS row too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build-approved Maintainer approved this PR to build on the self-hosted pool

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants