⬅️ 返回

Windows on ARM (ARM 指的是剑桥词典中的定义，不是 剑桥的公司)

上次更新: 2025年3月31日 - 晚上10:57 UTC+2 编辑于2025年4月1日 - 晚上10:20 UTC+2: 这件事是/曾经是认真的，不是玩笑。这是在 Pixel Watch 3 上运行 UEFI，能够启动 Windows 和 Linux。如果你对让这一切“滴答”作响 (双关语) 的代码感兴趣，请查看 mu_seluna_platforms。 TL;DR: WOA-Project GitHub 组织上的 Pixel Watch 指南 文章底部还有一个部分概述了我将在本周末发布的其他内容。如果你不在意时间，请向下滚动 😉 多年来，我花费（或者说浪费）了大量时间，试图让 Windows on ARM 在非计算机设备上运行，我开始感到无聊。

下一个项目会是什么呢？多年来我一直在思考，甚至跑去做 折叠屏设备，但我仍然无法摆脱脑海中的一个想法，那就是还能做些什么，更明显、更愚蠢（抱歉）、更有用的事情。一些我还没有弄清楚的事情。在网上漫无目的地浏览了数千小时，包括与 老年人 交流，但我仍然无法找到答案……

……然后它突然出现在我的脑海中。 答案一直就在我的眼前。是的！让 Windows 在 ARM 上 运行！更准确地说，是在智能手表上运行！

我以前怎么就没想到呢！

你也可以做到！是的，真的可以，请参阅 WOA-Project GitHub 组织上的 Pixel Watch 指南

在 2025 年，智能手表有什么理由不让人喜欢呢？毕竟，它们即使没有比你拥有的一些设备更强大，也至少一样强大。以下是我们正在处理的设备的简要描述：

让 Windows 在你的 ARM 上运行

现在故事已经讲完了（见上文），让我们找一个受害者（抱歉）、测试对象（为了作者的神智，我们将假装这一切并非仅仅因为 Windows on ARM 的双关语而开始）

选择的是 Google Pixel Watch 3 (大型 LTE 型号)，它于去年年底发布，主要原因是我手头有它，而且它还拥有我 2000 美元的手机所拥有的所有功能，但价格只有四分之一（我之前告诉你了我们为什么要纠结于昂贵的手机）

这款手表运行的是 Android 15（最初是 Android 14，稍后会详细介绍），具有可解锁的引导加载程序，但不幸的是，它具有 Google 每年都在重新发明如何引导 Linux 的概念（稍后也会详细介绍） 我新买的手表在拥有的第一天，正在做每个普通用户都会做的事情，摆弄它 这款手表使用 Snapdragon W5 Gen 1（零件号 SW5100），结合了 2GB DDR4X RAM 和 32GB eMMC 存储

这对于智能手表来说已经足够了，让我们面对现实，但也足够我们使用。它使用 Qualcomm 芯片组意味着我可以轻松地重用我以前使用 Qualcomm 芯片组的硬件的经验，并利用容易访问的开源代码仓库（包括 Google 自己的）

作为一个现代的 Qualcomm 平台，大致基于 Kona 时代的固件（Kona 是 Snapdragon 865），对于固件方面来说，这也是熟悉的领域。 图片来源: Qualcomm Technologies, Inc. SoC 还使用了 _古老但可靠的 _ Cortex-A53 内核，确切地说是 4 个。这有点过时（Cortex A53 是在 2011 年设计的），并且无法运行需要原子操作的现代操作系统，但这对于我们在这里进行的有趣实验来说已经足够了。

现代 Qualcomm 固件意味着我们已经在 XBL (Qualcomm 自己的 eXtensible Boot Loader) 中处理 UEFI。因此，凭借着手表和所有这些知识，第一步是使用 root 过的启动镜像备份手表，并进行检查。 这不好玩 然后执行相同的步骤，即痛苦地从原厂 UEFI 中取回所有 EFI 文件，并使它们适应在我自己的 UEFI 环境中运行。我们突然进入了 UEFI 的世界。 经过数小时的修补和弄清楚正确的加载顺序（先验地说是完全错误的），我们进入了一个 shell! 并对 UEFI 代码进行了一些仔细的调整，因为事实证明，如此低的分辨率超出了 UEFI 规范（谁知道呢）。 然后，通过获取 8250 的已知 ACPI 表，并根据本机设备树文件中找到的正确计时器/GIC 信息进行修补，进行了几个小时的 ACPI 表编辑： 这并不难，一旦你知道在哪里查找，就基本上是复制粘贴，针对几个表。 ...以及一个只有 4 个 CPU 的虚拟测试 DSDT ACPI 表： 我们只支持 CPU，是的，今天我们不会走得更远…… ...我们终于进入了一个操作系统！ 是的，这只是 Windows PE，非常基本，我甚至懒得等它完全加载。但它可以工作。 但是，事情并非如此简单，从来都不是。

这工作正常，但我错过了一些细节，并且没有阐述上周末发生的趣事。因为那是我几个月前所在的地方。这一次，我做了准备。

第一个显而易见的未知数是我到底是如何将 Windows PE 放在这里的，它有 32GB 的存储空间，而且手表上的所有东西肯定都已经达到最大容量了，对吧？

是的，但也请看一下分区布局： 这是一个现代的 Google 产品，因此它使用了 super 分区，两个插槽（a 和 b），以及更多前沿格式（例如启动镜像标头 v4）

我并不完全想摆弄我的手表（毕竟，比起胡闹，我更喜欢把它当作手表）

使用 Windows PE 是显而易见的选择 (ramdisk 中的 Windows) (之后也是 Linux，因为我想尝试，是的，如果你愿意，它也可以工作)

但我仍然需要一个地方来放置所有文件，并且它不会放在我容量有限的 uefi 镜像中。

由于这是一个双插槽设备，我滥用了未使用的当前插槽（对我来说是 a）来覆盖我能找到的最大插槽分区 (modem_a)，并放置我自己的启动文件。这需要对 Windows PE 进行一些修剪，因为它的最大尺寸只有 150MB，但它可以工作。

这解决了演示问题。但请记住我之前说过关于 Google 的话吗？

几天前，准备发布这场灾难时，我（再次）从嘴里溜出了错误的话，这场技术奇迹，我想把它建立在手表上可用的最新固件的基础上。 事实证明，Google 刚刚向手表发布了 Android 15（之前使用的是 Android 14）。让我们更新，毕竟不会有什么问题…… 旁白: 所有的事情都出了问题 简而言之，Google 网络刷机实用程序在我身上死了两次，不得不重新启动它。每次都花费了 4 个多小时 (这太慢了)。一旦完成（在星期六晚上 10 点），我以为我会尝试我上次已知良好的 UEFI，但它不起作用了……

事实证明，在我的旧实验和现在之间，他们的 ABL 代码更新了，现在它声称我的 uefi（它的日志的内核）太小了……？ 什么？ 在尝试了各种方法数小时后，包括修改设备中的普通内核镜像，我最终发现不知何故这只接受非常原始的内核镜像标头，这对我很不利，因为它包含跳转指令。在不想为此花费更多的时间之后，我只是拿走了该内核标头，剥离了它的所有代码，将其填充到正确的数量，以便其未修改的跳转指令到达该文件的末尾，然后将我的 uefi 附加到其中。我们又恢复了正常

奖励

在星期天，我以为我会完成我的一些实现，比如让 USB 工作，简短的故事是它有点工作，但只适用于大容量存储。但至少现在你可以使用我编写的利用 Windows Phone 的 developermenu 的指南来备份和摆弄存储，在此之前你必须 root wearOS 和所有东西，这不是那么直接。USB 只需要几个简单的 IOMMU 域附加补丁，因为它们已经从之前的固件中附加了。至于为什么它仍然会因其他用例（例如我自己的 linuxloader 或 ufp）而崩溃，我不知道。 手表上的大容量存储，以及我见过的最好的文本对齐。

结论

是的，这是一个愚人节项目，就像我个人做的每个愚人节项目一样，它是真实的，而且很傻，也没有完成。你现在可以尝试它。但老实说，你真的不应该这样做，哈哈。

对我来说，从事这项工作非常有趣，这篇博文也是以同样有趣和愚蠢的方式在最后一刻完成的。这也不是为了成为写作书籍的畅销书。我希望对于这个星球上的某个人来说，这个实验是有用的。对于其他人，我希望你有一个美好的一天。

PS: 我将在本周晚些时候发布一些针对 Surface Duo 的新更新，此外，这是 4 月初计划发布的所有内容的摘要，除了 Windows on ARM 之外 😉:

以及一些已经完成的工作，无需特殊发布

我要感谢 Rafael Rivera 允许我使用他的 "Windows on ARM" 艺术品作为这个 Meme 启动徽标。