Skip to content

Releases: Kb2uka/Omarchy-M4-Native

15-inch M4 Air tester build (v0.1.0-alpha.1-j715-test.1)

Choose a tag to compare

@Kb2uka Kb2uka released this 22 Oct 22:18
6c6d2e4

Tester build for the 15-inch M4 MacBook Air (2025), Mac16,13 / J715 only. It isn't for the 13-inch Air, the Mac mini or any other Mac. Discussion and reports: #142.

This exact build has not been booted yet. An earlier revision of the same kit (#155) installed on one J715. On that Mac, setup, the desktop with GPU acceleration, the keyboard and trackpad, Wi-Fi, both USB-C ports, restart and shut down all worked, and Bluetooth started. This build is the 13-inch Air's installer update 4 with these changes for the 15-inch Air:

  • the J715 devicetree (#147);
  • a kernel that also accepts the J715's built-in keyboard and trackpad;
  • the installer's j715ap profile, which collects the J715's Wi-Fi and Bluetooth firmware from Apple's 26.5.1 recovery image;
  • a GPU module that admits the J715;
  • the 13-inch Air's speaker, video and update services turned off.

The installer changes partitions and boot policy. macOS stays installed and selectable at startup. Back up first.

What to expect

  • Works on the tested J715: the built-in display with GPU acceleration, the keyboard and trackpad, both USB-C ports, Wi-Fi and Bluetooth.
  • Don't suspend. On the tested J715 the panel stayed black after resume. Closing the lid does not suspend.
  • Off in this build:
    • speakers, headphones, and Bluetooth and USB audio;
    • video decoding and protected movies;
    • brightness keys, the camera and CPU idle;
    • M4 updates: omarchy-m4-update refuses this board, so a fix means a new tester build.

Download and install (macOS Terminal)

curl -fLO https://github.com/Kb2uka/Omarchy-M4-Native/releases/download/v0.1.0-alpha.1-j715-test.1/download-j713.command
bash download-j713.command
cd "$HOME/Downloads/Omarchy-M4-v0.1.0-alpha.1-j715-test.1/installer"
bash Install.command --install --tester

For the full steps and what to report, read START-HERE.md in that folder.

Pins

  • download-manifest.tsv SHA-256 1b016a0370d0b86b360f00b1b90c220c6cbc98d479f0e09c2af3902b6a3d4cd7
  • download-j713.command SHA-256 146687ffcf01a155cc3c3fbbad4f729576b749d52ad44dbf68179606031e5882
  • KIT.json SHA-256 408743b8ea157c5e48a95ef2ab1422ea12437400619eb4939da3b344790b0840

How it was built

The assets were built by tools/derive-j715-test-kit.py at 6c6d2e4dd48b6306416c28686b5212b6bc4f77dc, from installer update 4 (KIT.json 9f216fd0…). The three changed binaries were rebuilt from public sources by the maintainers:

  • the kernel 291c4b95…, with tools/build-j715-kernel.sh;
  • the GPU module 55831cf4…, with gpu/j713/build-test-module.sh, which first reproduced alpha.1's 80cf3669…;
  • the devicetree 84a19aba…, with tools/build-j715-dtb.py.

Both binaries are recorded under kit_binaries in packaging/channel-source-joins.json. Their sources are in the kit's source/ and source/j715/ directories. The download assets keep the J713 transport names.

Thanks to @kazuhidet for the kit (#155).

M4 Mac mini tester build (v0.1.0-alpha.1-j773g-test.1)

Choose a tag to compare

Tester build for the plain M4 Mac mini (2024), Mac16,10 / J773g only. It is not for the MacBook Air, the M4 Pro mini or any other Mac. Discussion and reports: #136.

Nobody has booted this build on a Mac mini yet. It is the 13-inch Air's installer update 4 with three changes for the mini:

  • the Mac mini devicetree (#139);
  • the macOS 26.6.2 firmware the mini's installer profile uses;
  • the desktop drawn in software on the HDMI screen, with the Air-only services turned off (#141).

It changes partitions and boot policy. macOS stays installed and selectable at startup. Back up first.

What to expect

  • Display: HDMI only. Connect the monitor before powering on. No USB-C or Thunderbolt monitors.
  • Graphics: drawn in software, no GPU acceleration.
  • USB: the two rear USB-C ports nearest HDMI. The third rear port and the front ports are off.
  • Network: wired Ethernet is expected to work. Wi-Fi and Bluetooth are untested.
  • Not included: the speaker, video decoding, protected movies and M4 updates.

Download and install (macOS Terminal)

curl -fLO https://github.com/Kb2uka/Omarchy-M4-Native/releases/download/v0.1.0-alpha.1-j773g-test.1/download-j713.command
bash download-j713.command
cd "$HOME/Downloads/Omarchy-M4-v0.1.0-alpha.1-j773g-test.1/installer"
bash Install.command --install --tester

Then read START-HERE.md in that folder for the full steps and what to report.

Pins

  • download-manifest.tsv SHA-256 4f6427e95b37d63a412f913081dbb3aa194a5692f602b0c9a7f57a5d5c55b2ac
  • download-j713.command SHA-256 fe091a7bf705e17c057fb49c0a450e9a5b5b0f9351738ca762022ddd5582bf8a
  • KIT.json SHA-256 9b6a5d0e60dd94341a2496bb33cde63ea2e7e46082a90ee87d25f8bde1513ad9

The assets were built by tools/derive-j773g-test-kit.py at df692997e5764efbcd0c44f7f92595bbe3783e1b from installer update 4 (KIT.json 9f216fd0…). The download assets keep the J713 transport names. Corresponding source is in the kit's source/ directory, unchanged from update 4.

v0.1.0-alpha.1 installer update 4: GPU on every M4 Air, including the eight-core

Choose a tag to compare

@Kb2uka Kb2uka released this 17 Oct 16:23
2110d2b

EXPERIMENTAL — installer update 4 for v0.1.0-alpha.1

For new installs. Update 4 is a new system image whose GPU starts on every 13-inch M4 MacBook Air, including the base model's eight-core GPU (#118, thanks Jeff Hollis) and Airs whose GPU power limit is below 24800 mW (#57). A fresh install now reaches the desktop on its first boot, with no detour through the text login. No fresh installation from this exact kit has been done yet, so please report how yours goes. Update 3 remains available.

Already installed?

You need nothing from this page. Run omarchy-m4-update and restart once. It brings the same GPU module as omarchy-m4-gpu 1-3, so an eight-core Air that only reached the text login gets its desktop. If your Air stops on the m1n1 logo, follow the 1TR kmutil steps in j713-m1n1-issue82-ans-reset.md; that loader can't arrive through omarchy-m4-update.

Install

Download download-j713.command from Assets below and run it in macOS Terminal:

bash "$HOME/Downloads/download-j713.command"

The kit lands in ~/Downloads/Omarchy-M4-v0.1.0-alpha.1-update.4/installer/. Then follow the installation guide. Connecting to M4 updates happens on its own after first login, once the Air is online.

What changed from update 3

  • GPU module in the image (#57, #118, #133): /opt/m4-gpu/asahi_m4.ko is de0337a7… in place of alpha.1's 80cf3669…, and its pin in /opt/m4-gpu/runtime.sha256 matches. It accepts each Air's own GPU power limit up to 24800 mW and any eight-core GPU mask, and it is the module omarchy-m4-gpu 1-3 ships. Alpha.1's module and pin are kept in /var/lib/omarchy-m4/gpu-module/, so m4-gpu-module reports fixed and sudo m4-gpu-module --rollback still restores alpha.1.
  • Unchanged from update 3: the speaker filters in the image, m1n1 stage 1 8c5a1573… (#82), first-boot auto-connect, kernel c3704cfd…, devicetree e54c77a7…, initramfs and the stage 2 loader.
  • Source: assembled by tools/prepare-j713-release.py at 2110d2b (#133), packaged by tools/package-j713-download.py at 55f6cb0 (#134). The GPU module's source is gpu/j713 at 3eb265b with kernel-controller.tar.gz and the GPU source packet. It was rebuilt byte for byte twice in m4-gravity-builder:20261008, each time after first reproducing alpha.1's 80cf3669…. Every GPL binary outside packages is rebuilt-identical. The 14 MIT userspace binaries (Mesa, the VA-API driver, the speaker daemon) are alpha.1's and are listed as not yet rebuild-verified in IMAGE.json. Unlike update 3, the kit is exactly what the assembler produced, with no notes added afterwards; UPDATES.md in the kit describes this update.

Verification

  • Image read-back:
    • the GPU module (0644), its pin (0664) and alpha.1's rollback files (0600, directory 0755) are as described above, and every other runtime pin is unchanged;
    • the four filters, the channel connect timer and script, m4-gpu.service and m4-video-start match the tree at 2110d2b byte for byte;
    • first boot has not run;
    • the zip's kernel, devicetree, initramfs, loader and root image match IMAGE.json, and every file matches SHA256SUMS.
  • On hardware: the same module booted a ten-core Air (0x3ff, 24800 mW) and an eight-core Air (0x3bd, 24155 mW) through the update channel. Desktops came up with GPU rendering and no GPU faults; the GPU benchmark gave 112.1 and 89.7 fps (0.80, eight of ten cores).
  • macOS 26.5.2 (Mac Studio): the downloader rebuilt the kit from these assets offline, and Install.command --verify-only passed every file (exit 0).
  • Hosted CI passed on #133 and #134.
  • Not verified: a fresh installation from this kit, a first boot of this image, and macOS 27.

Checksums

  • Download manifest SHA-256: c305724ee8e473fc2191f0560da15d04b6e16d665efb8e84f947a94f84eb0d00 (embedded in download-j713.command)
  • KIT.json SHA-256: 9f216fd08695049b3c2affdabe459477795c4a0a765526d7d2dcfe706a2ff345
  • SHA256SUMS SHA-256: 454569f6092e8413e15b438ded17c99e9a4e7b20f87787ebb8193badd95b6428
  • Root image SHA-256: 995b5c2a3a331007056a529e51bf8e805c6c3827abf624efb8e6b8f16788665a
  • GPU module SHA-256: de0337a773930c7862a99706112dd71eaaecf2021707da248fd3d07feefdc824
  • Kernel SHA-256: c3704cfd2afb7760e73f0b9939a68864a30bd916fcd478bd960e538373123dc9
  • Assets: see DOWNLOAD-SHA256SUMS.

Release target: 2110d2b553ebd3dafb16578f0d27c3156229cda7 (develop, with #133).

Independent experimental project. Not endorsed by Omarchy, Asahi Linux, Arch Linux, Apple or the upstream projects. Use at your own risk.

v0.1.0-alpha.1 installer update 3: static speaker filters, #82 stage 1

Choose a tag to compare

@Kb2uka Kb2uka released this 17 Oct 00:55
11c17c9

EXPERIMENTAL PRE-RELEASE — installer update 3 for v0.1.0-alpha.1

For new installs. Update 3 is a new system image. It ships the speaker filters in the image (no more macOS AudioDSP check before partitioning), it carries the m1n1 stage 1 fix for Airs that stop on the m1n1 logo at every boot (#82), and a new install connects to M4 updates by itself. No fresh installation from this exact kit has been done yet, so please report how yours goes. Update 2 remains available.

Already installed?

You need nothing from this page. Run omarchy-m4-update. It now brings:

  • omarchy-m4-boot 1-12: the front USB-C port works like the hinge-side one (#112), plus the opt-in full-panel desktop around the camera notch, sudo m4-notch --show (#107).
  • omarchy-m4-gpu 1-2: a failed GPU start is now written to the journal (#108).

Restart once afterwards. The #82 stage 1 fix is the one part an installed Air can't get through omarchy-m4-update. If your Air stops on the m1n1 logo, follow the 1TR kmutil steps in j713-m1n1-issue82-ans-reset.md.

Install

Download download-j713.command from Assets below and run it in macOS Terminal:

bash "$HOME/Downloads/download-j713.command"

The kit lands in ~/Downloads/Omarchy-M4-v0.1.0-alpha.1-update.3/installer/. Then follow the installation guide, using update.3 in place of update.2 in its paths. Connecting to M4 updates happens on its own after first login, once the Air is online.

What changed from update 2

  • Speaker filters in the image (#111, thanks sheetsync). The four approved J713 filters (cddb9a1c…, c398560b…, c02bbed3… twice, the same ones every installed Air runs) are written into the root image. Install.command no longer generates them from the Mac's AudioDSP, so owner-audio/ and the NumPy source are gone from the kit. The firmware, recovery and other installer steps are still unqualified on macOS 27.
  • m1n1 stage 1 (#110): the installer's boot/m1n1.bin is 8c5a1573… in place of alpha.1's 18cc4cd1…. It leaves an M4's ANS stopped without a PMGR reset, which froze two Airs on firmware mBoot-18000.161.10. It booted on the owner's Air, and its in-place equivalent fixed one of the freezing Airs.
  • First boot (#74, #108): the image enables m4-channel-connect.timer, and m4-gpu.service logs to the journal.
  • Devicetree: update 1's shutdown devicetree (e54c77a7…), which installed Airs already have.
  • Unchanged: kernel c3704cfd…, initramfs, the stage 2 loader 3a3f7a64…, and every other installed payload, including alpha.1's GPU module (omarchy-m4-gpu from the channel replaces it once the Air connects).
  • Source: adds source/j713-audio-kernel-ee98743a.tar.gz (the audio module source at the alpha.1 tag), the GPU source packet and source/UPDATE-3.md. Assembled by tools/prepare-j713-release.py at 11c17c9 (#115, #116). Every GPL binary outside packages is rebuilt-identical. The 14 MIT userspace binaries (Mesa, the VA-API driver, the speaker daemon) are alpha.1's and are listed as not yet rebuild-verified in IMAGE.json.

Verification

  • Image read-back: the four filters, the owner-options service, the channel connect timer and service, m4-gpu.service and m4-video-start in the image match the tree at 11c17c9 byte for byte. The preset Widevine choices are absent, and first boot has not run. The zip's kernel, devicetree, initramfs and loader match IMAGE.json. Compared with the alpha.1 installer, only boot/m1n1.bin and j713_owner_assets.py differ.
  • Stage 1 rebuild: patches-m1n1/build-test-loaders.sh in m4-gravity-builder:20261008 rebuilt alpha.1's stage 1 (18cc4cd1…), then 8c5a1573…, exactly.
  • macOS 26.5.2 (Mac Studio): the downloader rebuilt the kit from these assets, and Install.command --verify-only passed every file (37 OK).
  • Public download (Mac mini, macOS 26.5.2): after publishing, download-j713.command from this page rebuilt the kit over unauthenticated HTTPS, and Install.command --verify-only passed every file (37 OK).
  • Hosted CI passed on #115 and #116.
  • Not verified: a fresh installation from this kit, a first boot of this image, and macOS 27.

Checksums

  • Download manifest SHA-256: 6af067a22f1c6df624a30383a5b1374899edcd6c4d4ca004fe15a4bc7d477a64 (embedded in download-j713.command)
  • KIT.json SHA-256: 55ac4fefa89a1090d6917799d4036d539cda05132f07d174c349c665431b9bac
  • SHA256SUMS SHA-256: 21cfcc90738e6638ea65c26ae827b8a7fc89c1efe280f1157446860dc5844c74
  • Root image SHA-256: 58b3514e2b4d2e2702f257d89acb649a66c335d01b006fb735dee8512d6c0637
  • Kernel SHA-256: c3704cfd2afb7760e73f0b9939a68864a30bd916fcd478bd960e538373123dc9
  • Assets: see DOWNLOAD-SHA256SUMS.

Release target: 11c17c9909caf2b297e1d6b14c342ba257580e16 (develop, with #115 and #116).

Independent experimental project. Not endorsed by Omarchy, Asahi Linux, Arch Linux, Apple or the upstream projects. Use at your own risk.

TEST ONLY: eight-core Air GPU for #118 (test 1)

Choose a tag to compare

@Kb2uka Kb2uka released this 17 Oct 13:54
cc3130d

Test build for #118 (GPU and desktop on the eight-core Air). Not a release; not in the M4 update channel.

omarchy-m4-gpu 1-3 from #118 (commit ae1b04e), unsigned, for 13-inch M4 MacBook Airs (Mac16,12) on v0.1.0-alpha.1.

  • Applies GPU module de0337a7… at the next boot. It is #57's module (per-chip power limit) with an Air gate that also accepts the eight-core GPU: any core mask with two of the ten positions fused off. Every other check is unchanged.
  • Moves an Air from 1-1 or 1-2 (#57's module, 3cf47fa7…) to the new module the same way the update channel will.
  • Checked on a ten-core Air: four clean boots, desktop up, no GPU faults, and the same CPU and GPU benchmark results as before.

Files:

  • omarchy-m4-gpu-1-3-aarch64.pkg.tar.zst: SHA-256 9bc3c58d85d39b8596943b3bf47589534e08740e53210f5195a2d87ea53b3957
  • pr118-bench.sh, pr118-gpubench.py: a quick CPU and offscreen GPU benchmark, for comparing with a ten-core Air
  • SHA256SUMS

Install

Download and check the files:

mkdir -p ~/pr118 && cd ~/pr118
for f in omarchy-m4-gpu-1-3-aarch64.pkg.tar.zst pr118-bench.sh pr118-gpubench.py SHA256SUMS; do
  curl -fLO https://github.com/Kb2uka/Omarchy-M4-Native/releases/download/test-pr118-gpu-eight-core-1/$f
done
sha256sum -c SHA256SUMS

If you installed your own build of the module, put 1-2's module back first, so the package takes the same path the channel will. m4-gpu-module reports "state": "unknown" when your own build is installed. Check that the staged copy is 1-2's (3cf47fa7…), then restore it and its pin:

m4-gpu-module | grep '"state"'
sha256sum /usr/lib/omarchy-m4/gpu/asahi_m4.ko    # must start with 3cf47fa7
sudo install -m 644 /usr/lib/omarchy-m4/gpu/asahi_m4.ko /opt/m4-gpu/asahi_m4.ko
sudo sed -i 's|^[0-9a-f]\{64\}  /opt/m4-gpu/asahi_m4.ko$|3cf47fa706630ddc5fc55a3bce00ab31e8a4c5ee48e1ba563e26a0406da196f8  /opt/m4-gpu/asahi_m4.ko|' /opt/m4-gpu/runtime.sha256
m4-gpu-module | grep '"state"'                   # now "fixed"

Then install the test package and restart:

sudo pacman -U ./omarchy-m4-gpu-1-3-aarch64.pkg.tar.zst
m4-gpu-module | grep -E '"state"|"status"'       # "previous", "newer fix staged; applies at the next boot"
sudo systemctl reboot

After the restart

Please post on #118:

m4-gpu-module
sudo journalctl -b -k --no-pager | grep -E 'G16: (Air|firmware|barrier)|G16.*(fault|timeout|error)'
cd ~/pr118 && bash pr118-bench.sh    # from a terminal on the desktop

and whether the desktop came up and stays up with GPU rendering. For comparison, a ten-core Air gives about 112 fps for the GPU, 1,342 MB/s for one P core and 17,798 MB/s for ten cores. An eight-core GPU should give about eight tenths of that GPU figure at the same clock, and the same CPU figures.

Roll back

sudo m4-gpu-module --rollback, then restart. That restores alpha.1's module, which refuses the eight-core GPU like 1-2 does. To go back to 1-2 instead, run sudo pacman -U /var/cache/pacman/pkg/omarchy-m4-gpu-1-2-aarch64.pkg.tar.zst, then repeat the two restore commands above.

Source: the module is built from gpu/j713/asahi/g16.rs (GPL-2.0-only) on the v0.1.0-alpha.1 kernel tree, and the package recipe and tool are in #118; see gpu/j713/README.md.

Use only if asked on #118.

TEST ONLY: GPU start fix and journal logging for #82 (test 1)

Choose a tag to compare

@Kb2uka Kb2uka released this 15 Oct 15:29

Test build for #82 (desktop could not start after a fresh install). Not a release; not in the M4 update channel.

omarchy-m4-gpu 1-2 from #108 (commit 9da9d14), unsigned, for 13-inch M4 MacBook Airs (Mac16,12) on v0.1.0-alpha.1. It needs only python, so it installs on a fresh installation that has not connected to M4 updates.

  • Applies the fixed GPU module (#57, 3cf47fa7…) at the next boot. It accepts each Air's own GPU power limit up to 24800 mW, where alpha.1's module needs exactly 24800 mW, and logs why it refuses a GPU.
  • Sends m4-gpu.service output to the journal, so sudo journalctl -b -u m4-gpu.service shows the start script.
  • Each boot's report names the GPU values the module checks: core mask, power limit, firmware build.

Files:

  • omarchy-m4-gpu-1-2-aarch64.pkg.tar.zst: SHA-256 1e4eefe9be854e121397ce230ed0e19aa1798fa0341b526ed21772efb6af88ef
  • SHA256SUMS

Install from the recovery login (Ctrl+Option+F2), after joining Wi-Fi with nmtui:

curl -fLO https://github.com/Kb2uka/Omarchy-M4-Native/releases/download/test-issue82-gpu-journal-1/omarchy-m4-gpu-1-2-aarch64.pkg.tar.zst
curl -fLO https://github.com/Kb2uka/Omarchy-M4-Native/releases/download/test-issue82-gpu-journal-1/SHA256SUMS
sha256sum -c SHA256SUMS
sudo pacman -U ./omarchy-m4-gpu-1-2-aarch64.pkg.tar.zst
sudo systemctl reboot

Roll back the module: sudo m4-gpu-module --rollback, then restart. Connecting to M4 updates later keeps 1-2 (the channel has 1-1 until #108 is published).

Source: the package recipe and tool are in #108. The module is built from gpu/j713/asahi/g16.rs on the v0.1.0-alpha.1 kernel tree (GPL-2.0-only); see gpu/j713/README.md.

Use only if asked on #82.

v0.1.0-alpha.1 installer update 2: macOS 26.6.2

Choose a tag to compare

@Kb2uka Kb2uka released this 14 Oct 20:36
d311b66

EXPERIMENTAL PRE-RELEASE — installer update 2 for v0.1.0-alpha.1

New installs on macOS 26.6.2 now work. The v0.1.0-alpha.1 kit stops at its speaker-filter step on macOS 26.6.2 (25G83), before any partition change, because that release ships an AudioDSP build (b8711ac5…, 17,311,312 bytes) the kit did not list. This kit qualifies it (#83, thanks luth-v). It installs the same alpha.1 system, byte for byte.

Already installed? You need nothing from this page. Keep using omarchy-m4-update.

Install

Download download-j713.command from Assets below and run it in macOS Terminal:

bash "$HOME/Downloads/download-j713.command"

The kit lands in ~/Downloads/Omarchy-M4-v0.1.0-alpha.1-update.2/installer/. Then follow the installation guide, including its last step: connect to M4 updates. That step brings the shutdown fix and every later M4 update.

Qualified macOS builds for the speaker filters: 26.5.1 (25F80), 26.5.2 (25F84) and 26.6.2 (25G83). Other builds may be refused before any partition change.

What changed from v0.1.0-alpha.1

  • Updated (5 files): owner-audio/bundle/manifest.json (AudioDSP now lists the 26.5.x and 26.6.2 builds; the four output filter hashes are unchanged), owner-audio/bundle/README.md, owner-audio/bundle/src/run-memory.py, owner-audio/bundle/src/run-transfer.py and owner-audio/m4-j713-fir-owner.py, from commit 109877b.
  • Refreshed docs: START-HERE.md, KNOWN-LIMITATIONS.md and UPDATES.md, from commit d311b66.
  • Added source: source/owner-fir-update-2.tar.gz (the speaker-filter source at 109877b), source/omarchy-j713-v0.1.0-alpha.1-gpu-air-source.tar.gz (the GPU module source packet, previously attached only to the release page) and source/UPDATE-2.md.
  • Metadata: IMAGE.json, KIT.json and SHA256SUMS name this release.
  • Unchanged, byte for byte: the system image os/omarchy-j713-0.1.0-alpha.1.zip (76b41cbd…), Install.command, installer-macos.tar.gz, the native speaker-filter helpers and NumPy wheel, and every other file in source/. The three OS parts below have the same SHA-256 as v0.1.0-alpha.1's.

Verification

  • The five updated files match the pins in the new manifest, as do the unchanged helpers and NumPy wheel.
  • macOS 26.5.2 (Mac Studio): the kit's speaker-filter generator, run exactly as Install.command runs it, produced the four pinned filters (cddb9a1c…, c398560b…, c02bbed3… twice). The new downloader rebuilt the kit from these assets, and Install.command --verify-only passed every file.
  • macOS 26.6.2: verified by luth-v on a second 13-inch M4 Air in #83. The same pipeline produced the same four filters, and an Air installed from a kit with this pin passed --verify-only and the speaker-filter step, with speakersafetyd-j713 active.
  • Hosted CI passed on #83, on its promotion (#94) and on the docs change (#96).
  • Not newly verified: a fresh installation from this exact kit.

Checksums

  • Download manifest SHA-256: 561dfd6c2ebc44fe138b5ae70f80715a6568f4104764bbad99ef776553cafaa1 (embedded in download-j713.command)
  • KIT.json SHA-256: 08c29791f47feb36a65e7cec7b8877327f5cef9d624aa68d71a8e68e20a0eab8
  • SHA256SUMS SHA-256: 0bd1cdb8bd4c2cd70361f46e9eaead1941fec4e7fe916c150dba942abdd8cf28
  • Kernel SHA-256: c3704cfd2afb7760e73f0b9939a68864a30bd916fcd478bd960e538373123dc9
  • Assets: see DOWNLOAD-SHA256SUMS.

Release target: d311b66d58a45ffd887e4a0b71b3dc8615c85b7e (develop, with #83 and #96).

Independent experimental project. Not endorsed by Omarchy, Asahi Linux, Arch Linux, Apple or the upstream projects. Use at your own risk.

TEST ONLY: m1n1 dockchannel console fix for #82 (test 1)

Choose a tag to compare

@Kb2uka Kb2uka released this 14 Oct 13:08

Test build for #82. Not a release; not in the M4 update channel.

Test m1n1 loaders for 13-inch M4 MacBook Airs (Mac16,12) on v0.1.0-alpha.1 that stop on the m1n1 logo. m1n1 no longer waits forever for room in the dockchannel debug console: it waits 100 ms (2 s once something has been seen draining it), then drops that console's output until it has room again. The screen console is unchanged. Source and details: #86.

Each loader is alpha.1's, rebuilt byte-identically in alpha.1's builder, plus only this patch and the version tag -dctx1.

  • m1n1-stage1-issue82-test1.bin: stage 1, SHA-256 54807eb5aa8a2dae7aa64eac735d12168e42bc275d2dd24d328dcadcf7e526dd. Install from macOS recoveryOS (1TR) the way installer step 2 does: kmutil configure-boot -c m1n1-stage1-issue82-test1.bin --raw --entry-point 2048 --lowest-virtual-address 0 -v <Omarchy stub system volume>.
  • m1n1-stage2-issue82-test1.bin: stage 2, SHA-256 7bc78b9138ae449eeab08d0a713c96f25e0d7477b7a48f2804da2c17509a9609.
  • m4-m1n1-test-stage2.py: replaces stage 2 inside /boot/efi/omarchy/boot.bin from Linux, keeping the old one for rollback. It accepts alpha.1's stage 2 or the #82 reporter's 8-byte build.
  • dockchannel-tx-bound.patch: the source change, against the m1n1-stage1-source.tar.gz / m1n1-stage2-source.tar.gz trees in the alpha.1 companion. Rebuild with patches-m1n1/build-test-loaders.sh in #86.

Stage 2:

sha256sum -c SHA256SUMS
sudo python3 m4-m1n1-test-stage2.py install m1n1-stage2-issue82-test1.bin 7bc78b9138ae449eeab08d0a713c96f25e0d7477b7a48f2804da2c17509a9609
sudo reboot
sudo python3 m4-m1n1-test-stage2.py status

status shows the running loaders. A test loader's tag ends in -dctx1.

Verified so far: the owner's Air (iBoot1 mBoot-18000.120.36) boots stage 2 -dctx1 to the desktop with no new kernel errors. The owner's Air never hung, so this shows no regression, not the fix. Stage 1 has not been booted on any Air yet.

Use only if asked on #82.

Test: #82 ANS reset experiments (stage 1 v1–v3)

Choose a tag to compare

@Kb2uka Kb2uka released this 15 Oct 00:37

Test build for #82. Not a release; not in the M4 update channel.

Three experiment stage 1 loaders for the 13-inch M4 Air in #82, whose stage 1 freezes inside the first pmgr_reset(die, "ANS") in nvme_shutdown(). Each is test 1's stage 1 (54807eb5…, from test-issue82-dockchannel-1) edited in place. A few instructions become NOPs, and the version tag changes from -dctx1 to -i82v1/-i82v2/-i82v3 at the same length, so no instruction moves. A rebuild from source changes the layout and hides the freeze, which is why these are in-place edits.

Loader Change (offsets in test 1) SHA-256
m1n1-stage1-issue82-v2.bin pmgr_reset_device(): the four PMGR stores (set/clear DEV_DISABLE and RESET, 0x26964/74/88/98) become NOPs; the console print is kept d75486df569a3be4b84603aa8c3fd24ebab703572d636c1b7a28afdd13000969
m1n1-stage1-issue82-v1.bin nvme_shutdown(): both bl pmgr_reset (0x23e90, 0x23ea0) become NOPs. ANS is still put to sleep and stopped; Linux resets it later ac8e2c4aff14c4abce68a1a01c5ec401d7cdb7354602d5cac6dfb9c76219c798
m1n1-stage1-issue82-v3.bin pmgr_reset_device(): the bl debug_printf (0x26954) becomes a NOP; the reset is kept e263faedcadb53fc8c817b864e4815baa7ba053b9091c4c37a8a9e6596aa9be1
  • issue82-variants.py regenerates all three from test 1's stage 1 and refuses any other input. It checks every site holds the expected instruction and that each removed call reaches the expected function.
  • Install from macOS recoveryOS (1TR), as test 1 was, with the installer's 64 KiB vars block appended: kmutil configure-boot -c <loader> --raw --entry-point 2048 --lowest-virtual-address 0 -v <Omarchy stub system volume>.
  • Stage 2: leave it as the 8-byte dockchannel-off build.
  • Pass: stage 2 starts and /proc/device-tree/chosen/asahi,m1n1-stage1-version ends in the loader's tag.

Background and the expected outcome of each: docs/j713-m1n1-issue82-ans-reset.md in #86.

Not booted on any Air yet. The owner's Air never froze, so it cannot test these.

Use only if asked on #82.

TEST ONLY: GPU power limit for #57 (test 1)

Choose a tag to compare

@Kb2uka Kb2uka released this 14 Oct 01:17

Test build for #57. Not a release; not in the M4 update channel.

A test GPU module for 13-inch M4 MacBook Airs (Mac16,12) on v0.1.0-alpha.1 whose GPU probe fails with -22. It accepts each Air's own GPU power limit up to 24800 mW instead of exactly 24800. Every other check is unchanged, and it logs a reason whenever it rejects a machine. Source and details: #80.

  • asahi_m4-issue57-test1.ko: SHA-256 3cf47fa706630ddc5fc55a3bce00ab31e8a4c5ee48e1ba563e26a0406da196f8, built for kernel 7.1.9-m4-gpu-backport-20261008.
  • m4-gpu-test-module: installs it with a backup, and rolls back to alpha.1.
  • g16-issue57-test1.rs: the changed source file (GPL-2.0-only). Replace drivers/gpu/drm/asahi/g16.rs in the v0.1.0-alpha.1 GPU source packet with it to rebuild; see gpu/j713/README.md in #80.

Use only if asked on #57.