meta-apple-silicon

A Yocto/OpenEmbedded BSP for Apple Silicon Macs.

I couldn't find an active Yocto BSP targeting M series Macs. Every other OS on this hardware (Fedora Asahi Remix, the Asahi reference image) is a binary distribution built from the Asahi project's packages. If you want to build a custom, source built OS for an Apple Silicon Mac with bitbake, this layer is a starting point.

Note: neither machine has been booted from this layer yet. The VM machine's full task graph resolves and its kernel recipe is proven in the parent project. Bare metal is scaffolding. Read docs/status.md before you plan around any of this. It separates what was verified here from what is proven upstream from what is untested.

The two machines

Machine	State	What it is
apple-silicon-vm	Resolves, not yet built	A virtio guest on an Apple Silicon host (UTM, QEMU, Apple Virtualization). UEFI, then systemd-boot, then the kernel. The full core-image-base task graph resolves (6,125 tasks, 0 errors) and the kernel fetches, but no image has been compiled or booted from this layer. See docs/status.md. The same kernel tree, SRCREV and config do boot in the parent project.
apple-silicon	Not yet	Bare metal M1/M2 via the Asahi boot chain (iBoot2, m1n1, U-Boot, systemd-boot, kernel). Recipes and layout are scaffolded. See the porting guide.

Why the VM machine matters even if you want bare metal

Most of an Apple Silicon BSP can be built and proven without a Mac in the loop: the kernel fork, the config machinery, the image assembly, even the boot chain recipes as compile gates. The VM machine lets you iterate in seconds instead of installer round trips. Bare metal comes last, once everything around it is known good. See docs/porting.md.

Traps this layer already solved

These cost real days to find. They are baked into the configs here so you don't repeat them.

1. 4K vs 16K pages. Apple's cores require the 16K translation granule. The emulated CPUs in UTM and QEMU do not implement it, so a 16K guest kernel silently fails to boot on them. The VM machine is 4K and bare metal is 16K. Mixing these up is the most common failure.
2. ACPI, not just device tree. Under UEFI, which is the real boot path, firmware describes the machine via ACPI. A kernel config with CONFIG_ACPI unset (the stock qemuarm64 default, because it assumes -kernel direct boot) boots fine from -kernel and then hangs before printing one character under real firmware. The VM fragment forces the full ACPI set.
3. Test the UEFI path, not -kernel. Because of trap 2, a -kernel smoke test proves nothing about the boot you actually ship. docs/testing.md shows the edk2 pflash and systemd-boot path.

Quick start (VM machine)

Full setup is in examples/README.md. In short, add this layer to a stock openembedded-core build, then:

MACHINE=apple-silicon-vm bitbake core-image-base   # roughly 5 to 8h first build

Boot the resulting wic.qcow2 under UTM with "Use Apple Virtualization" unchecked, since the emulated path is the one with the working CPU granule. Or use QEMU with an edk2 pflash firmware. See docs/testing.md for a scripted headless boot.

What's here

meta-apple-silicon/
  conf/machine/apple-silicon-vm.conf     VM machine (task graph verified)
  conf/machine/apple-silicon.conf        bare metal machine (work in progress)
  recipes-kernel/linux/linux-asahi_git.bb  Asahi kernel, config built from scratch
  recipes-kernel/linux/files/apple-silicon-vm.cfg  the 4K, ACPI and virtio fragment
  recipes-bsp/{m1n1,u-boot}/             boot chain recipes (stubs, see porting)
  files/wic/apple-silicon-efi.wks        UEFI GPT layout. It lives in files/wic/
                                         rather than wic/ because
                                         WKS_SEARCH_PATH does not scan the latter
examples/
  README.md      minimal standalone build plus the fast checks that skip building
docs/
  status.md      what works and what doesn't, precisely
  porting.md     the bare metal bring up sequence
  testing.md     how to boot test the real UEFI path headlessly

Licence

Layer metadata is MIT (see LICENSE). The software it builds (the Asahi kernel, m1n1, U-Boot) carries its own upstream licences such as GPL-2.0.

Credit

The hardware enablement is entirely the work of the Asahi Linux project. This layer only packages it for OpenEmbedded. If this is useful to you, support them.