Skip to content

MacBook Neo developer builds and preview catalog - #48

Draft
scottjones wants to merge 11 commits into
mainfrom
mac/neo-j700
Draft

scottjones wants to merge 11 commits into
mainfrom
mac/neo-j700

Conversation

@scottjones

Copy link
Copy Markdown
Collaborator

Adds MacBook Neo (apple,j700) support to developer builds only, plus the catalog tooling for a developer preview that installs on every M1, M2 and M3 Mac and the Neo. Public builds and channel catalogs still refuse the Neo.

What's in it

  • Engine .29 and .30:
    • installs on macOS 26 firmware, reading the restore bundle and firmware from the running macOS when the recovery image is AEA-encrypted;
    • on a j700ap, replaces Asahi's Stage 1 with Aurora's J700 Stage 1 from the image's esp/aurora/stage1-j700.bin;
    • collects the Neo's C1FE trackpad firmware, its MT7932 Wi-Fi and Bluetooth inputs (.29) and its Touch ID calibration (.30) from macOS.
  • Removal recognises a Neo install's 6 GB stub and its J700 Stage 1.
  • Developer build (OMARCHY_DEVELOPER_BUILD=1): its own workspace, no channel menu, and only a sealed catalog, so a catalog that admits Macs the public ones don't can never reach it over the network.
  • Catalog developer mode (make-unsigned-catalog.py --developer): developer_models groups give boards from supported-models.json's new developer section their own payload and metadata. The main group still covers exactly every M1, M2 and M3 Mac, refused boards stay refused, and check-catalog still rejects apple,j700.

Preview

The downloads are on the pre-release neo-preview-dev4-20261007:

  • an M1–M3 image with Aurora 12.0 and m1n1-aurora aurora12;
  • a Neo image (dev4) with the J700 boot chain and the same 12.0 kernel;
  • engine .30.

The developer app is to be built from this branch's head by the holder of the Developer ID, notarized, and attached there.

Before merging

Validation

  • ./test/all passes on macOS with Bash 5.3 and Python 3.13, including 6 new catalog tests (29 in test_make_unsigned_catalog.py).
  • The macOS Swift build and tests for the developer build profile need a macOS run on the final commit; the catalog change touches no Swift.

🤖 Generated with Claude Code

scottjones and others added 11 commits October 4, 2026 20:09
The MacBook Neo (J700, T8140) can only use macOS 26 boot firmware, which
asahi-installer v0.9.2 was not written for. The engine now:

- knows T8140, j700ap and a macOS 26.6 (25G72) OS-firmware entry;
- names the restore bundle "./Restore" when macOS 26's bootcaches.plist
  no longer does;
- replaces the restore image's encrypted (AEA) recoveryOS and ExclaveOS
  images with the running macOS's decrypted copies of the same build,
  which the stub's recoveryOS kernel can mount, and collects firmware the
  same way;
- gives a stub on macOS 26 firmware 6 GB instead of 2.5 GB, room for the
  decrypted recoveryOS and two sets of personalized boot objects.

The Python overlay repack now pins the patch the omarchy.14 base was built
with (patches/base), so a base still has to reproduce exactly what it
shipped while the new upstream file takes the current patch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OMARCHY_DEVELOPER_BUILD=1 marks the app with OmarchyDeveloperBuild: its
own workspace, no channel menu, and only a sealed catalog in the bundle,
so a developer catalog that admits Macs the public ones do not can never
reach it over the network. Name the MacBook Neo, and stop the bundling step
from overwriting the inspection engine when the catalog's engine is the
same file.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Removal took a stub outside 2.3-2.7 GB for another macOS installation and
refused it. A stub on macOS 26 firmware is 5,999,951,872 bytes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Public builds keep unqualified boards such as apple,j614s fail-closed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
iBoot panics on stock asahi m1n1 as the J700's custom boot object. On a
j700ap the engine now replaces asahi's Stage 1 with Aurora's J700 Stage 1
from the image's esp/aurora/stage1-j700.bin, filled in place (a port of
aurora-silicon/m1n1 tools/fill_stage1_config.py) to chainload the new ESP's
m1n1/boot.bin. A Neo image without that file is refused; other Macs keep
asahi's Stage 1.

Firmware collection also counts C1FE multitouch keys as trackpads: the
J700_Multitouch.im4p keys its trackpad C1FE0,0, which asahi_firmware
skipped, leaving no apple/tpmtfw-j700.bin and a dead trackpad.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a j700ap the engine now adds the MT7932's Wi-Fi and Bluetooth inputs
to the vendor firmware package: the IZUBA patch, RAM and power-table
files, the factory OCA2, WCAL and BCAL calibrations from BWC2, the J7CF
records from IZUBA_wifi.cfg, the Bluetooth firmware and its .ptx, and
the Bluetooth address from /chosen. Each input is validated. The radios
are experimental, so a failed collection is logged and the install goes
on without them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
installer-v0.9.2-omarchy.29.tar.gz, 17,851,067 bytes, SHA-256
14323c78..., reproduced twice with macOS /usr/bin/python3 3.9.6 from a
fresh v0.9.2 checkout that also reproduces .28. Compared with .28 it adds
omarchy_mt7932.py and changes main.py, omarchy_asahi.py and version.tag.
The bundled inspection pin, the packager and both release templates
select it, so the release scripts publish the engine the catalog names.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Removal links a startup container to its EFI partition through the
ESP its m1n1 boot object names. Aurora's J700 Stage 1, which the Neo
boots and engine .29 installs, keeps that in a versioned, CRC-checked
config block and ends at STACKBOT, so removal found no ESP and refused
the Neo's own installation. Exactly one valid version-1 block now names
the ESP; asahi's m1n1 variables remain the fallback.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Neo keeps its Mesa calibration in the iBoot System Container as one
standalone signed IMG4 of type FSC2, which aurora-touchid's extractor
did not find. On a j700ap the engine now reads the raw container
read-only, takes the one FSC2 image with a CALB payload and an IM4M
manifest, and adds it to the vendor firmware as apple/mesacal-j700.bin,
the name the Neo's device tree gives the driver. Like the radios, a
failure is logged and the install goes on.

installer-v0.9.2-omarchy.30.tar.gz, 17,852,406 bytes, SHA-256
2d5a14c3..., reproduced twice with macOS /usr/bin/python3 3.9.6; it adds
omarchy_mesa.py and changes omarchy_asahi.py and version.tag. The
bundled pin, packager and both release templates select it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
make-unsigned-catalog.py --developer accepts developer_models: groups of
boards from supported-models.json's new developer section, each with its own
payload (split or whole) and metadata, alongside the main group, which still
covers exactly every M1, M2 and M3 Mac. Refused boards stay refused, a group
may not repeat a Mac or a file name, and check-catalog still rejects
apple,j700, so a developer catalog can never reach a channel. Each group's
digests are computed once instead of once per Mac.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mrobs11

mrobs11 commented Oct 9, 2026

Copy link
Copy Markdown

M3 MacBook Air 13" (J613): dev4 preview installed and booted

I installed the developer preview from neo-preview-dev4-20261007 on a 13-inch M3 MacBook Air, and it booted into Omarchy.

  • Mac: MacBook Air 13" M3, Mac15,12 / J613, 24 GB, 2 TB
  • macOS: 27.0 (26A428), FileVault off
  • Installer: Omarchy-Installer-Developer-2.1.0.zip from this pre-release
  • Catalog: developer catalog sequence 1791382094, payload digest sha256:e4588ecc…6a61
  • Image and engine: developer-preview-20261007-aurora12 with engine v0.9.2-omarchy.30. The app staged the M1–M3 installer_data.json, not installer_data-m3air.json.
  • Result: the install and the Recovery step completed, and the Mac boots into Omarchy. The macOS 27 "system firmware is too old" failure from System Firmware too old when installing omarchy on M3 Pro with MacOS 27 omarchy-mac#440 didn't happen here, although this staged installer_data.json lists supported_fw only up to 26.6.
  • Disk layout after install: EFI 524 MB, Boot 2.1 GB, Root 566.7 GB, stub APFS container 2.5 GB

I haven't checked individual hardware yet (Wi-Fi, Bluetooth, audio, backlight and brightness keys, sleep, USB-C, external display, camera). I'll add those results here.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants