Skip to content
BootCampARM
Ko-fi (opens in a new tab)

Development

Where the engineering code lives, which commands exist, and which claims a change is not allowed to invent.

Two trees

The site you are reading is a Next.js application. It does not contain the installer, the shim, or firmware binaries.

The engineering tree is a Swift package named BootCampARM, with an Xcode app target beside it. As of this record it is local development source. Until NEXT_PUBLIC_GITHUB_URL points at a real repository, this site will not link to one.

Engineering tree

The package (Package.swift, Swift tools 5.10, macOS 13 and later) builds:

  • BootCampKit, the framework: system probe, compatibility check, device database, disk inventory and planner, stub installer, firmware payloads, Windows media helpers, and the install orchestrator
  • BootCampXPC and BootCampHelper, a privileged helper boundary
  • bootcamp-cli, the command-line front end

The Mac app lives under App/BootCampARM and is described by project.yml / BootCampARM.xcodeproj. The app copy in that tree is older marketing language in places. The website, not the app's intro screen, is the public description of what has actually been demonstrated.

Firmware experiments are under firmware/diag-efi. A vendored m1n1 tree may be present under build/m1n1. That upstream project remains Asahi Linux's.

Command line

bootcamp-cli accepts probe, disks, plan, install, uninstall, and stage-payload.

probe and disks read the machine. plan calculates a layout. install is able to modify the disk, boot objects, and security policy of a stub volume. Developers who already have the tree should treat install as destructive and prefer --dry-run when they only want to see the plan. --iso, --size, --payload, and --disk select inputs. The default payload id in the source is ntasp-mu.

None of these commands are distributed from this website.

Tests

The package defines BootCampKitTests, covering the Mach-O boot-object wrapper, the m1n1 variable block, the step-2 generator, the disk planner, and byte-size arithmetic. The command in that tree is swift test. This website does not publish a test run from that package. A passing planner test would still not mean Windows boots.

Diagnostic EFI

firmware/diag-efi/build.sh builds three PE32+ EFI applications with LLVM clang (aarch64-unknown-windows) and lld-link:

  • diag.efi from entry.c, a handoff probe
  • shim.efi from shim.c and shim_hook.S, the instrumented loader
  • plain.efi, the same shim compiled without the entry hook

The script expects clang and lld-link, with Homebrew LLVM paths as the default. Building it does not install it, and installing it is the risky part this site does not turn into a guide.

The shim's console strings are the source of the sanitized trace on the homepage. When you change those strings, change the trace data in this website in the same change, and do not add lines that the shim does not print.

Boundaries

Changes to either tree should keep these distinctions intact:

  • Verified means it ran on the named test machine.
  • Observed means the instrumentation saw it, and it is still being checked.
  • Not achieved means there is no such result.
  • A device-database entry is not compatibility.
  • Do not describe the EL2 compatibility layer as unvirtualized bare metal.
  • Do not add a download that is not a real release artifact.
  • Do not put serial numbers, unique chip ids from a personal machine, signing keys, or raw personal logs into the website.