Tool
m1n1
Asahi Linux's bootloader and hardware-research environment for Apple Silicon Macs. It bridges Apple's boot chain to Linux by loading appended device trees, initramfs and kernels; in proxy mode a USB link lets a Python client probe hardware live and run macOS or Linux under m1n1's hypervisor while tracing its hardware accesses.
Requirements & limits
- Under active development: the reviewed main commit (2026-10-19) is 53 commits past the v2.0.0 tag (2026-10-02), whose message calls it the first GPL release, otherwise identical to v1.9.9. The latest GitHub release, v1.9.9, ships a stage-2 m1n1.bin and a UEFI-only package holding just an m1n1 boot.bin.
- Runs only on Apple Silicon Macs. Builds need an aarch64-linux-gnu-gcc cross toolchain (or a native ARM64 one), LLVM and lld on macOS, or the bundled compose setup, plus Rust's aarch64-unknown-none-softfloat target for chainloading builds. The Python proxy client (pyserial, construct, asn1) talks to m1n1 over USB from another host.
- Apple's kmutil installs m1n1 as a custom boot object from macOS recovery, normally via the Asahi Linux installer. run_guest.py takes a Mach-O guest such as an XNU kernelcache from the user's own macOS install; the repository ships no Apple firmware, kernels or macOS components. proxyclient/hv holds 27 tracers for blocks such as AGX, DCP, NVMe and SMC.
- CI builds main, checks C and Rust formatting and runs the proxy client's pytest suite on Ubuntu and macOS 14 and 15; those tests cover its assembler, object loading and toolchain handling, not behavior on Mac hardware.
- Code through v1.9.9 stays MIT; from v2.0.0 m1n1 is GPL-2.0-or-later, and embedded third-party code such as libfdt, Arm Trusted Firmware portions and dlmalloc, and vendored Rust crates keep their own licenses. Asahi Linux's LLM policy broadly forbids generative AI for material contributions, citing its clean-room reverse-engineering rules; AGENTS.md, CLAUDE.md and GEMINI.md say the maintainers forbid any AI or LLM use for legal reasons.
About this entry
- Type
- Tool
- Category
- Firmware tools
- Relationship
- Foundation tool
- Targets
- Firmware
Sources reviewed
The description was reviewed against primary sources. This does not establish runtime testing, security auditing or verified compatibility.
Primary sources
- README.md GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- docs/sw/m1n1-user-guide.md GitHub · AsahiLinux/docs · Revision 0d1f891
- proxyclient/tools/run_guest.py GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- proxyclient/hv GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- requirements.txt GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- .github/workflows/test.yml GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- .github/workflows/build.yml GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- LICENSE GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- LICENSE.MIT GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- AGENTS.md GitHub · AsahiLinux/m1n1 · Revision 7cde7d1
- https://asahilinux.org/llm-policy/
- https://github.com/AsahiLinux/m1n1/releases/tag/v1.9.9
- https://github.com/AsahiLinux/m1n1/releases/tag/v2.0.0
More in Firmware and hardware
- SVD-Loader for Ghidra · Tool
- ThinkPad IMX471: recovering camera tuning for Linux · Case study
- flipper-telink: replacement firmware for Tuya Zigbee remotes · Case study
- Supermodel: initial Real3D Pro-1000 image-generator emulation · Case study
- OpenDMCUFirm: a reimplemented Wii U DMCU display firmware · Case study
- reflecticon-224: running Lexicon 224 reverb firmware on emulated hardware · Case study