Linux在M4上越过休眠障碍，启动Shell还不是完整支持
据 Yuka 工程记录，M4 上的 Linux 启动问题涉及 WFI 等待指令造成的状态丢失，相关规避机制已进入上游项目。
作者：林岚｜OC 开发者生态编辑
据 Yuka 工程记录，M4 上的 Linux 启动问题涉及 WFI 等待指令造成的状态丢失，相关规避机制已进入上游项目。
一句话结论：解决基础启动与多核问题是重要进展，图形和外设支持仍需继续开发。
OC 此前报道过 Asahi 的 M3/M4 支持进展。这次新增的是开发者对 M4 启动障碍的具体排查，以及 WFI/WFIT 规避机制进入 Linux 与 m1n1 的进展。
WFI 的作用是让处理器等待中断，通常用于空闲状态。作者发现，在相关配置下，M4 的行为会导致寄存器状态丢失。内核原先假定这类状态得以保存，实际硬件行为与假设之间的差异使启动失败。
早期实验通过跳过指令让多核启动，但普遍替换并不是合适的上游方案。虚拟机可能由宿主拦截等待指令，用于安排不同客户系统；错误地触发规避逻辑，会影响另一类运行环境。
最终方向是内核提供空闲方式的启动配置，再由引导层按已知裸机条件选择。它把平台检测和通用内核机制分开，避免为了单一硬件把所有环境都当作同一种情况处理。
作者报告已能进入 shell 并使用所有核心，相关方法也在其他新芯片上验证。但 GPU、显示控制器和摄像头等复杂外设仍有逆向工作。普通用户评估能否替换 macOS 时，应看完整支持清单，不能只依据启动成功。
关键事实
- 进展：WFI/WFIT 规避机制进入 Linux 与 m1n1。
- 成果：作者报告 M4 可进入 shell，并使用多核。
- 边界：完整外设与桌面支持不是此次已完成的结果。
OC 判断
这类工作展现了兼容性工程的真正难点：硬件状态、固件和内核必须协同。上游机制的价值大于一段仅在本机奏效的补丁。
为什么重要
- 对开发者：按裸机和虚拟化环境分别验证。
- 对企业：评估完整外设能力与维护成本。
- 对用户：能启动不等于适合日常桌面使用。
评论
围绕这篇文章补充信息、提出问题或分享观察。