Developers just dropped the first patches to boot Apple’s latest M4 chip under Linux. The code arrives months after warnings that this generation would test the patience of even the most dedicated reverse engineers. And the patches confirm it. Basic booting works in theory. Real hardware support remains distant.
Early Steps Meet Hardware Barriers
Open-source contributor Yureka Lilian submitted the initial Device Tree files and bindings for the Apple M4 SoC this week. The series targets the Linux kernel and mirrors the straightforward approach taken for the M3. Yet functionality stays minimal. Phoronix reported that the patches allow booting to a simple console at best. No desktop environment. No full peripheral set. Stability issues linger too.
Lilian noted in the submission that several changes complicate the process. SMP support depends on the idle=nop parameter for now. The patches sit in the Asahi Linux mailing list for review. Interested parties can examine them directly at lore.kernel.org. They lay groundwork. Nothing more.
This development follows a rocky path. Linux 7.2 merged initial M3 support. That code boots the chip but offers little value to typical users. The M4 effort builds on similar foundations. It also inherits the same constraints. Asahi Linux documentation lists nearly every M4 feature as TBA or work in progress. GPU acceleration. NVMe storage. USB controllers. All sit in limbo. Asahi Linux confirms the Mac mini 2024, MacBook Pro models from late 2024, and 2025 MacBook Air variants lack an installer. Devicetrees exist in draft form. Practical use does not.
But the real story started earlier. In April 2025 Asahi Linux developers discovered Apple altered the boot process on M4 silicon. Sven Peter, a key contributor, described the shift on Mastodon. “Looks like M4 support for Asahi Linux is going be rather painful,” he wrote. The changes affect how the m1n1 bootloader interacts with the hardware at Exception Level 2.
When configuring a Mach-O boot object, the system drops into an environment where Apple’s APTM runs in GL2. Linux must then communicate from EL2 with the MMU already enabled to set up pagetables. That configuration fails for both Linux and the hypervisor used to reverse-engineer XNU. Switch to a raw boot object and the environment changes again. EL2 loads with GL2 active and most Apple-specific extensions disabled. Linux accepts this state. The hypervisor cannot run XNU inside it. Reverse engineering grinds to a halt. Phoronix covered the warning in detail. The project continued upstreaming M1 and M2 support while others experimented with M4. Progress slowed.
AppleInsider echoed the concern weeks later. The outlet noted that m1n1 simply refused to boot properly on M4 hardware for some testers. Apple had changed something fundamental. The same GL2 and pagetable issues surfaced. No timetable emerged. Developers hoped exception handlers or pagetable hijacking might offer a path forward. AppleInsider reported the project remained focused on earlier chips. M4 sat on the back burner.
By late 2025 the picture had not improved much. Phoronix reported in December that Asahi Linux carried experimental DisplayPort code. M3, M4, and even M5 bring-up continued in the background. Changes in the M4 and M5 generations had already broken existing reverse-engineering tools. M4/M5 modifications broke parts of the toolchain. DOOM ran on M3 hardware in testing. That counted as a win. Full M4 desktop use stayed far off. The year-end update made clear that graceful support would take time. Downstream Asahi kernels would see partial functionality first. Upstream kernel integration would follow later. Possibly much later.
So here we stand in mid-2026. The new patches mark tangible forward motion. They do not promise quick results. Community discussion on X reflects cautious optimism mixed with frustration. One recent post highlighted that M3 support still lags. M4 will likely follow the same extended timeline. Another noted the hardware itself impresses under macOS. Linux users wait for parity.
The Asahi Linux team has delivered remarkable results on M1 and M2 Macs. GPU drivers reached conformance. Daily use became realistic. That success came after years of patient work. M4 demands the same dedication. Perhaps more. Apple tightened security and altered low-level interfaces. Each generation adds complexity. The open-source effort must match it.
Performance comparisons already show what the hardware can do. Phoronix benchmarked an M4 Mac mini against Intel and AMD systems running Ubuntu. The Apple chip often led in efficiency. Power consumption stayed low while delivering strong results in compilation, video encoding, and certain rendering tasks. Those tests ran on macOS. Linux cannot yet tap the same potential. Until drivers mature, the silicon’s advantages stay locked behind proprietary code.
Developers continue laying foundations. The Device Tree patches represent one piece. Future submissions will address CPU frequency scaling, interrupt controllers, and graphics. Each step requires verification against real hardware. Each step risks uncovering new Apple modifications. The process feels painstaking. It also feels necessary.
Users who bought M4 systems for Linux experimentation now hold powerful but limited machines. Some dual-boot. Others run virtual machines. Native support would change the equation. It would let developers, researchers, and enthusiasts tap unified memory, efficient cores, and high-end GPUs without compromise. That day has not arrived.
The patches sit under review. Comments will shape the next revision. Lilian’s work gives the community a concrete starting point. From here the effort branches into drivers, power management, and peripherals. Success depends on sustained contributions. It also depends on Apple’s willingness to leave enough surface area exposed.
Progress on M3 offers a preview. That chip reached basic booting in 7.2. Alpha-quality support appeared later. M4 follows a similar trajectory but starts from a harder position. The painful boot changes documented last year still echo. Yet the community persists. New code appears. Discussions continue on mailing lists and forums.
Industry watchers note the broader pattern. Apple ships sophisticated silicon. Open-source projects race to catch up. Sometimes they succeed brilliantly. Sometimes the gap widens. For now the M4 on Linux represents the widening phase. Basic boot patches exist. Everything else demands time, ingenuity, and persistence.
Check the Asahi feature matrix for the latest status. Watch the kernel lists for follow-up patches. The story unfolds in small commits and occasional breakthroughs. Expect no miracles. Prepare for steady, hard-won advancement. The M4 hardware deserves a first-class Linux port. Delivering it will test the entire Asahi ecosystem once again.
WebProNews is an iEntry Publication