Boot architecture
How the experimental chain is put together, which stages have executed on the M3 test machine, and which stages are still only a design.
The chain
BootCampARM is aiming at a Boot Camp-like path: Apple's firmware starts an alternative environment, and that environment eventually starts Windows 11 ARM64 without macOS remaining as the host operating system. The chain under test is:
- Apple iBoot
- m1n1
- U-Boot, providing UEFI
- The BootCampARM shim
- Windows Boot Manager
- The Windows loader
- Windows 11 ARM64
m1n1 stage 1 is wrapped as a Mach-O boot object so kmutil configure-boot can install it into a stub volume. Its chainload variable names a file on the EFI system partition. That file is stage 2: m1n1 with device trees and U-Boot. U-Boot's bootefi starts the shim. The shim rebuilds a device path and calls LoadImage on \EFI\BOOT\BOOTAA64.EFI.
The evidence boundary
On the primary test machine, a MacBook Pro 14-inch with M3 (2023), execution has been recorded through the shim. The shim has loaded an ARM64 Microsoft EFI image, hooked its entry, and traced UEFI boot and runtime services.
The boundary is the next stage. Windows Boot Manager initialization is not verified. Windows PE has not run. Windows Setup has not completed. Nothing on this site should be read as a Windows desktop.
STARTING WINDOWS in the diagnostic trace is a string the shim prints before StartImage. It is not evidence that Windows finished starting.
Why the design includes an EL2 layer
Apple Silicon does not present the firmware interfaces a stock Windows 11 ARM64 kernel expects. The interrupt controller is Apple's, not a GICv3. CPU bring-up uses Apple mailboxes rather than PSCI. The boot path is iBoot and a Mach-O image, not a PC UEFI firmware with ACPI tables.
The engineering tree's firmware notes describe an m1n1 hypervisor path that emulates a virtual GIC and PSCI at EL2, then a UEFI stage. That is a hardware-virtualization compatibility layer. It is not an unvirtualized bare-metal port of Windows, and this project has not demonstrated either a finished hypervisor product or a finished Windows boot.
Whether a later design can shrink that layer is an open research question. The public claim stays with the stages that have actually executed.
Component roles
Apple iBoot starts the machine. BootCampARM does not replace it.
m1n1 is derived from the Asahi Linux bootloader. Stage 1 is what iBoot loads. Stage 2, on the EFI system partition, carries device trees and U-Boot. m1n1 does not read a hypervisor.cfg file; the chainload variable is the configuration that matters.
U-Boot provides the UEFI implementation used in the current experiments, including bootefi.
The BootCampARM shim is an AArch64 EFI application. The current build announces itself as SHIM ENTRY 7. It loads the Microsoft image from the same volume, can hook the PE entry, and can log GetVariable, HandleProtocol, AllocatePages, and related services. A second, smaller image (diag.efi) only prints its entry, the current exception level, and architectural counters. That probe exists because Windows Boot Manager reads PMCCNTR_EL0 early. If the counter read does not return, the probe stops. That is a firmware experiment, not a Windows log.
Windows Boot Manager, the Windows loader, and Windows 11 are Microsoft components and the goal of the chain. They are past the evidence boundary.
Intended volume layout
BootCampKit's planner describes four volumes after the macOS container. These are design constants, not a procedure:
| Volume | Role | Planner constant |
|---|---|---|
| Stub APFS | Holds a minimal boot object so iBoot can load m1n1 | about 2.5 GB |
| EFI system partition | FAT32, stage 2, and EFI binaries | 500 MB |
| BCINSTALL | FAT32, intended for Windows setup files | 12 GB |
| BOOTCAMP | Microsoft Basic Data, left for Windows Setup to format | at least 64 GB |
Creating those volumes rewrites the partition map of an internal SSD and can change boot policy on the stub. This documentation does not contain commands for doing that. See the installation notes.
What has not been demonstrated
- A completed Windows Boot Manager initialization
- Windows PE
- Windows Setup, or any installed Windows system
- Storage, display, keyboard, or trackpad drivers for Windows
- A Secure Boot design, bypass, or policy
- The same boot environment on any machine other than the primary M3 test Mac
- Support for M1, M2, M4, or other M3 models
Related work
BootCampARM uses and studies other people's boot software. It is not those projects, and their hardware results are not results of this project.
- m1n1 (opens in a new tab), from the Asahi Linux project, is the bootloader family used for stage 1 and stage 2.
- U-Boot provides the UEFI environment in the current experiments.
- Community firmware discussed in the engineering notes includes m1n1_windows (opens in a new tab) and apple_silicon_platforms_mu (opens in a new tab). Those repositories are independent. This site does not treat their status as BootCampARM compatibility.
Apple and Microsoft are not involved. Boot Camp, macOS, Windows, and the related product names are their trademarks.