Wii U 架构

Rodrigo Copetti 的实用分析

译者：晓晓的锋 和 总比没有强, 我在, 合二为一, BLACKFEATHER, 东风 以及其他群友

如果您使用无障碍阅读工具、电子书或旧版浏览器，切换到“经典”版。

电子书版本
Image

This article is also published on many digital book stores for the benefit of eBook readers. The new edition is DRM-free and can be read whilst offline. Furthermore, it's updated at the same pace as the website.

You can find the eBook at Amazon Kindle, Apple Books, Kobo and other stores. The profits contribute towards the improvement of current articles and the development of future ones.

For more information, please take a look at here.

相关影像

型号

Image
Wii U
于2012年11月18日在美国发售, 于2012年11月30日在欧洲发售, 还于2012年12月8日在日本发售.

主板

Image
主板
有趣的是这里有许多空余的空间, 我猜是为了容下光驱和散热器才设计得那么宽的.
Image
带有重要部件标签的主板

图示

Image
主架构图

一个简短的介绍

在 Wii 取得如此巨大成功之下, 任天堂新主机面临的问题是难以复制前代主机的成功, 任天堂新的产品也需要从平价的智能手机和平板电脑的诱惑中_挽救_它宝贵的用户. 这一切的结果是任天堂最终推出了一个有着激进创新和高昂成本的主机. 在 Wii U 上, 用户获得了前所未有的全新体验, 而开发者们则不得不面对主机内相对老旧的硬件架构.

关于主机的架构的新问题即将来到. 这次一次, 我们来看看任天堂与 IBM 和 AMD _最后一次_合作的项目.

对其前辈和竞争对手的介绍

你可能会有点惊讶, Wii U 与和它不同的主机有着相同的 DNA: Wii 和 Xbox 360 (而这些技术又从 GameCube 和 PlayStation 3 中继承!). 正因如此, 我强烈建议你先阅读有关这些主机的相关文章，因为这里介绍的许多技术都与它们的前辈有关.

此外，与Wii的向后兼容性是本文的一个反复出现的话题. 和 Xbox 360 上的软件模拟与 PlayStation 3 上的临时 PS2 硬件相比，Wii U将其提升到一个更高的境界. 不过，这确实是有代价的，你最终也会看到. 即便如此，本文的主要目标是分析Wii U. 所以，与Wii有关的功能将与主要功能分开讨论.

新一代的手柄

说到任天堂，手柄控制器往往是一个吸引人的讨论话题. 这里也不例外，所以我发现在我们深入研究主体之前，从这个部件开始分析会更好. 这里也不例外，所以我发现在我们深入研究主体之前，从这个部件开始分析会更好.

Image
GamePad (黑色版本).

Wii U 附带一个无线的 ‘手柄’ (之前从来没有过的). 它差不多有传统手柄的两倍大, 但同时它的功能也多了许多. 它的正式名字叫 Display Remote Controller (DRC) 但我们更习惯称它为 GamePad. 在它上面, 我们可以找到一块触控屏, 一组按键, 一个收纳好的触控笔以及许多的传感器. 总得来说, 它是一个有趣的_主机_.

由于它有完整的硬件，你可以认为它本身就是一台独立的计算机. 然而，由于其软件的原因，GamePad 最终看起来像是一个连接到主机的终端，其功能包括:

因为有了上面的功能，除了作为一个手柄，GamePad在营销时还提到了两个功能：“第二块屏幕”和“屏幕镜像”. 其中一种情况下，控制台可以在不占用电视画面的情况下在 GamePad 上显示独占信息. 另一方面，用户可以在不需要电视的情况下使用主机.

Image
塞尔达传说: 黄昏公主 HD (2016).
GamePad 的显示器充当了一个方便的辅助屏幕来显示地图和背包库存.
Image
超级马里奥制造 (2015).
游戏主要在 GamePad 上游玩，而电视就像一个“投影仪”.

然而，在实际情况中，并没有任何标准的做法. 因此，这两种风格的采用完全取决于游戏的编程方式.

架构

现在让我们看看 GamePad 是由什么组成的，这本身就是一项棘手的任务，因为 GamePad 的内部没有任何文档记录. 幸运的是，一个名为“Memahaxx”的黑客组织做出了行动，并对该设备进行了彻底的逆向工程. 不止如此，他们还向公众公布了他们的成果.

Image
GamePad 的内部结构.

设备主要搭载了三个芯片 [1] 或者更准确的说, 是三个完全独立的计算机:

首先, 我们有 DRC-WUP 它是一个系统级芯片 (SoC) 藏着另一个协处理器 ARM926EJ-S (与 Wii 上的一样, 它到底还有多少库存?) 搭配有 4 MB 内存 以及一个特殊的 H.264 加速芯片 用于 H.264 串流的解码与编码. 这是也是控制外围设备的主要芯片. 它可以访问屏幕、音频和 NFC 功能.

继续来看 SoC, 你会找到 Broadcom BCM4319, 另一个迷你电脑搭载 ARM Cortex-M3 架构并且提供 802.11 a/b/g/n 连接能力的射频基础硬件 [2]. 值得强调的是，考虑到使用 Cortex-M3，博通对 CPU 的选择的确比任天堂更“现代” (与它的第二代 Thumb) 是为2010年代的嵌入式系统设计的. 公平地说，众所周知，任天堂的选择并不总是基于“削减成本”，而是基于成本和供应. 在任何情况下，BCM4319 都将使用 5GHz 频段提供 Wi-Fi 连接.

最后, UIC-WUP 是另一个任天堂标志的组件，我们可以在其中找到 意法半导体 STM8, 2 KB 和 28 KB 的 EEPROM. STM8 是一种用于小量但重复性高的任务的现代8位微控制器. 也就是说，UIC-WUP 被用于处理剩余的I/O工作.

GamePad 的固件 (或固件们) 存储在一个单独的Flash芯片中. 这提供了通过SPI总线访问的 32 MB 的空间. 奇怪的是，固件代码 并没有加密 (这有助于Memahaxx的工作).

GamePad 主板的其余部分全都是I/O端口和不同寻常的传感器. 因此，我将在本文的“I/O”部分对它们进行介绍.

来聊聊主板

Wii U的主板包括一个名为 DRH 的微型芯片，该芯片依靠 Wi-Fi 协议与 GamePad 进行通信，并依靠 USB 协议与主板的其他部分通信. 这包括GPU, 它将帧缓冲区直接流式传输到 DRH，以便在 GamePad 上显示.

Image
GamePad 与 Wii U 连接的概览图.

DRH 运行实时操作系统 (RTOS)，遵循 µITRON 4.0 规范. 它非常复杂，提供协作多任务处理和任务间通信. 最后，值得注意的是，Wii U 与 GamePad 通过Wi-Fi进行的通信并没有与 Wii U 的互联网功能混合，后者由单独的芯片 (和天线) 处理.

背后的相关功能

除了网络堆栈的定制化实现 (稍后将对此进行解释)，GamePad在背后进行了大量处理.

一旦GamePad启动并运行，该设备就能够通过实时解码来显示 H.264 视频流. 屏幕分辨率为 854x480像素，刷新率为 60 Hz，这并不是全高清的，但它保持了16:9的比例.

奇怪地使用标准

与 Wii Remote 魔改蓝牙协议以避免第三方使用类似相比，GamePad 魔改了两个 Wi-Fi 标准，即 WPS 和 WPA2-PSK，因此它们只能与 Wii U [3] 一起使用.

总之，Wii U 和 GamePad 使用 有 5 GHz 带宽的 802.11n 协议相互通信. 控制台充当接入点 (AP)，GamePad 充当其唯一客户端. 尽管如此，Memahaxx还报告称，游戏机的操作系统实现了同时使用两个 GamePad 的能力，尽管最终没有使用.

Image
将 GamePad 与 Wii U 配对的过程需要用户输入由扑克符号组成的密码。

要首次建立通信信道，必须先对两个设备进行 “配对” (就像Windows笔记本电脑通过选择网络名称并提供密码与Wi-Fi路由器配对一样). 这是使用 Wi-Fi保护设置 (WPS) 协议完成的，然而，这并不像按下 SYNC 按钮并等待两个设备配对那么容易. 该过程还包括用户按照电视上的指示 (由主机输出) 选择 GamePad 上显示的特定扑克符号. 在后台，用户正在输入部分密码，然后 GamePad 在密码末尾添加一个硬编码的 5678，并将其发送到控制台. 如果该过程成功完成，GamePad将接收控制台的 SSID、BSSID 和 PSK 值，以便从现在起自动连接.

从那时起，后续连接依赖于 WPA2-PSK 协议，并且两个设备都使用TCP/IP数据包传输信息.

奇怪的是，GamePad利用 时间戳 来保持音频和视频流的同步. 时间戳是“信标帧”上的一个属性，由 AP 来广播有很多原因, 其中之一是同步范围内设备的内部时钟.

中央处理器 (CPU)

我希望你还有一些时间，因为我们仍然需要从_中央芯片_开始深入 Wii U 的内部结构.

起源与猜想

自从 Wii U 发布以来 (以 Project Cafe 被熟知), 关于新的中央处理器将由什么组成，有很多猜测. 在某个时候，大家都猜测任天堂将采用IBM的 POWER 系列 [4] 的现代版本. 我想玩家都期待着一款突破性的 CPU，就像六年前 Cell 和 Xenon 所展示的那样. 此外，随着 PowerPC 的衰落 (最明显的是苹果在2006年改用英特尔核心)，认为IBM的任何新 CPU 都将作为 POWER 架构的升级版的想法并不太牵强.

诚然，之前的逻辑有一个错误，那就是任天堂不喜欢新兴技术. 相反，他们的方案侧重于抓住现有技术，寻找创新和巧妙的用途. 这不一定是一个坏特性，因为任天堂的工程师们非常聪明地展示了技术被认为“过时”的最先进的应用程序. 看看 Game Boy 的 Z80 hybrid，或者任天堂ds上的降频ARM9，甚至是名为 “Wii” 的部分升级的游戏机. 如果说所有这些都有共同点的话，那就是它们都打破了销售记录. 现在，Wii U 会加入这个队伍吗？ 答案我想我们都应该知道了.

第8代架构

在上一个世代主机中，索尼和微软在降低成本的当代技术上下了很大的赌注 (有些比其他人风险更大). 对于 Wii U，任天堂的方向略有不同，专注于低成本、低功耗和向后兼容性 [5]. 后者将对这款主机的最终设计产生重大影响. 因此，新的CPU没有提供任何激进的组件，而是试图赶上行业的最新进步 (多核处理、GHz级别速度等).

话虽如此，任天堂与 IBM 合作推出了他们的新 CPU. 它叫做 Espresso，运行频率为 1.24 GHz [6].

现在，让我们深入谈谈 Espresso:

Image
Espresso 的概览图

……和这个系列中的任何其他文章一样，我会解释它是如何工作的。

熟悉的面孔

在我们开始进行真正的分析之前，让我回过头来看一下上一个图表。 正如你在那里看到的，Espresso 是一个对称的多核系统，就像 Xenon 一样. 但这还不是全部，因为 Espresso 的每一个内核似乎都是 IBM 的 Broadway 的复制品，与 Wii 使用的内核完全相同 (或者换种说法，它是 GameCube 中的 Gekko 的调整版本).

对于 Espresso 的研究

我们现在来看看 Espresso 是如何构造的. 正如我已经解释过的 Broadway 和 Gekko 如何工作 我将侧重于Espresso的新颖之处，即它的多核心布局、缓存系统和内存.

在这一点上，可以公平地说，任天堂和 IBM 都没有公开记录 Espresso 的内部工作原理 (与 Xenon 和 Cell 不同，这两者有许多 IBM 工程师在 IBM 现已关闭的 developerWorks 门户网站上发表了关于它们文章). 我想这两个公司都没有计划在 Wii U 之外将 Espresso 商业化. 即便如此，这一部分之所以成为可能，是因为 fail0verflow (又名 Team Twiizers) 等黑客组织花费了无数小时，他们不仅成功地对这个系统进行了逆向工程，还花时间发布了有关它的文档 (如果你喜欢这个话题，别忘了看引用的文档). 在这项研究中，我将第三方研究与 IBM (与 Broadway 有关) 和 Freescale 的公开信息相结合，结果如下.

‘多核心’ 的 Broadway

Image
四个 512 MB DDR3 芯片旁边的大型 SoC (包括了 Espresso 和其他的一些芯片)

Espresso 拥有三个基于 PowerPC 750CXe 架构的CPU 核心. 这些设计的日期可追溯到2001年， 意味着数据路径和指令组的状态与10年前大致相同. 为了做出区别， PowerPC 处理单元 (Xenon和Cell的主要核心) 选择了 POWER4 的设计，并为了相应主机的要求重新设计了它.

让我们继续，Espresso实现了 对称多核心布局… 但如何使用这些旧核心？ 好吧，IBM在一个常见问题的门户网站 (现已关闭) 中解释说，750已经支持多核运算[7]， 它只需要额外的程序来维护缓存的完整性 (在不同的L1、L2和TLB之间)。 然而，通过软件来做到这一点会抵消多核处理器设计的优势，所以这种想法从未被采纳…… 也就是说，任天堂需要再次与IBM合作.

最后，IBM使用了三个Broadway CPU，将时钟提升至1.24 GHz 并包装了额外的 L2 缓存和必要电路，用来处理总线竞争与缓存一致性问题(因此不必用软件来完成). 这就是Espresso.

灵活的总线

Image
Espresso 内部核心的结构

连接CPU核心和外部组件的外部总线有一个有趣的历史。 可以追溯至1993年 摩托罗拉88110的发布. 在 AIM 联盟形成后，IBM 和摩托罗拉各自基于他们的最强技术创造了一款联合CPU. IBM贡献了他们的POWER架构，摩托罗拉贡献了88110 CPU的总线设计. 在1993年，PowerPC 601问世.

PowerPC 601采用了名为 60x bus 的总线协议。 这在当时是相当先进和灵活的，支持64位操作、更快的时钟速度、以及缓存一致性和多处理器配置(因此IBM表示750 CPU可以进行多核运算) [8]。 所有的一切都让我想起了日立的SUPER H技术（Super H处理器核心家族由日立在90年代早期开发，Super H指以32位元存取的精简指令集架构，SH4曾被用在世嘉DC）

回到Wii U, IBM再次使用60x bus连接Espresso的三个核心。 此外，他们还实现了一种总线的变体，将Espresso(作为芯片) 与主板的其他部分连接起来.

如果你想知道目前60x bus的采用情况，恐怕它早已被摩托罗拉为PowerPC 74xx系列(也称为“G4”) 实现的一种名为“MPX”的改进协议所取代. MPX总线通过使用“数据流”来减少等待状态，解决了60x bus的不足，如数据吞吐量慢 [9]. 另一方面，IBM展示了他们的“弹性接口”总线，包括PowerPC 970系列(G5) 和POWER4 [10].

更多缓存

对于Wii(和GameCube)，Broadway/Gekko只处理了256 KB的二级缓存和64 KB的一级缓存. 在Wii U上，Espresso的每个核心的L1缓存保持不变，但其中两个现在拥有512 KB的L2缓存，第三个核心则拥有惊人的2MB的L2. 实际上，这并不意味着有2.5MB的 “可用”缓存，因为不同的内核可能需要从RAM中缓存相同的部分，如果缓存是共享的，这种情况就不会发生 (但那样的话，会出现其他问题！).

Espresso 中的所有L2缓存都是 4路关联。 与Xenon和Cell中的8路关联（8-way associations）相比，在Xenon中，这是为了减少3个核心对1MB的共享L2缓存竞争. 在Espresso中，遍历关联缓存将花费更少的时间，但缓存未命中的频率会更高.

为了处理三个独立的 L2 缓存之间的缓存一致性，Espresso 的内部总线接口遵守 MERSI 协议 (与 Cell/Xenon 相同). 作为参考，Broadway (单核系统) 使用了 MEI 协议.

附带说明一下，Espresso 中的 L2 属于 eDRAM 类型，而不是 SRAM. 此外，L1的的block(关键词：cache的结构)仍然提供locked（译注：锁内存总线，CPU或DMA访问内存的动作是原子化的，即完成一个动作后解除锁定其他设备才能访问）和RAM-to-L1(内存到L1)直接存储器存储的指引。

改进空间

正如 fail0verflow 强调的那样，Wii U 作为一个系统实际上缓存是不一致的. 外部I/O可以在Espresso不知道的情况下改变内存，因此缓存在这些情况下不会被自动刷新。 相比之下，Xbox 360的南桥在外围设备DMA到主RAM之后会通知缓存。

此外，PowerPC针对多核心环境下的两条指令。 lwarx (Load Word和Reserve Indexed) 和stwcx (tore Word Condition Indexed), 不再能够正常工作. 正如fail0verflow所指出的[11]，这些现在需要手动刷新缓存才能按预期工作。 至少它不是第一个带有损坏指令的 PowerPC 变体(参见 Xbox 360 的 xdcbt).

幸运的是，这并不全是坏消息. 至少Espresso继承了Gekko的乱序执行，而这一点不得不从 Xenon 和 Cell 中删除.

可用内存

本节既简单又复杂. 综上所述，有三个地方可以存储易失性数据：

造成这种差异的原因是，你可能记得Wii 和 GameCube时代的MEM1和MEM0. 它们在Wii U上得到了延续，尽管MEM1略有增加.

Image
通用内存的内存布局（在“Wii U”模式下）.

不管怎样，从开发者的角度来看，只有MEM2和MEM1(两个较大的内存) 可以访问。 2GB的DDR3内存可以保存任何类型的数据(同时包括CPU和GPU)，而其他两个的功能则更为有限. MEM1 用于图形数据(“图形”部分有更多详细信息), 操作系统使用 MEM0(“操作系统”部分有更多详细信息).

在某些方面，该系统遵循统一内存架构(UMA)。 尽管MEM1和MEM2处于中间层，但我不能说这个系统完全符合UMA模式(不同于某些竞争者)。

GDDR3 或 DDR3 ？

旧Wii 使用 GDDR3 内存，用于图形操作的速度特别快。 Wii U的选择不仅更大，而且还具有一个新类型，叫做 DDR3 (命名开头没有“G”). 这是否意味着Wii U已被降级？ 令人困惑的是，没有。

GDDR3 内存是 DDR2 的改进版本，用于图形相关功能. 几年后，DDR3到来，它同时继承了DDR2和GDDR3. 你是否感到了困惑？ 好吧，让人更加困惑的是，后续的GDDR4和GDDR5是在DDR3基础上的增强，而不是其他。

这种命名方式具有不必要的欺骗性. 但我们不要失去重点，Wii U采用了DDR3，这意味着与Wii的GDDR3相比，带宽更高。

成为一个Wii

我很想说，虽然新硬件在某些方面看起来不尽如人意，但对Wii的向后兼容性达到了与Nintendo DS或Game Boy Advance一样的水准.

使用的方法也与这两种机型相同. Wii U不再采用软件模拟或临时硬件， 而是作为Wii的超集. 因此，可以通过隐藏其现代功能轻松复制 Wii 的硬件。

所以，每当Wii U决定 “变成Wii”时，Espresso就会停用两个核心 (保留一个Broadway 核心) ，MEM2会隐藏1984MB的内存 (保留64MB的内存). 一旦进入“虚拟 Wii”(vWii) 模式，旧的 Wii 游戏就可以安全地认为它在真实的 Wii 上运行。

这种兼容模式背后还有更多细节，包括_模糊_I/O(在适当的时候解释)，所以如果你对这个过程感到好奇，请继续阅读！

PowerPC的最后一次冒险

当我们即将结束CPU部分时，这似乎是我最后一次分析基于PowerPC的系统 (至少按时间顺序排列，我还没有谈到苹果Pippin).

PowerPC有一段有趣的发展历程，起起落落. 虽然它没有成功地推翻x86，但它确实征服了三代游戏机。

无论如何， 我们热爱的 Espresso 实质上是对一个完全过时的平台进行的现代化改进。 IBM和摩托罗拉都已经放弃了 750CL 系列，分别转而支持 7400 和 970 系列. 然而，IBM如何挖掘他们的旧设计来生产一款能够在2010年进行竞争的游戏主机，这很令人好奇。 但我猜测，Espresso没有消费者版本的现象，证明了IBM对进一步推广Espresso并不感兴趣.

但是，就像Xenon或Cell一样，这都是进化的一部分。 我不相信这类技术会被遗忘或放弃，它们的设计和专业知识最终会融合到其他项目中。

图形

虽然CPU可以被认为是对传统技术的_致敬_，但让我告诉你，GPU则是_正式_的下一代。

Image
超级马里奥 3D 世界 (2013).
Image
塞尔达无双 (2014).
Image
皮克敏3 (2013).
Image
喷射战士 (2015).
Image
塞尔达传说: 风之杖 (2016). 以极高的1920x1080像素进行渲染！
从电视上看到的 Wii U 游戏示例。 除了《风之杖》以外，所有游戏都是以最大分辨率(1280x720像素) 呈现。

图形处理器位于Espresso旁边的一个大型硅芯片中，它叫做 Latte， 以 550MHz 运行[12]，长话短说，它是广泛和复杂的。 Latte 拥有除图形处理外的更多基础功能，不要担心，这会在将在本文的下一节中进行解释。 现在，只需要记住图形处理位于Latte中。

Image
又一张 SoC 的照片. 所以您在了解 Latte 之后就可以来思考这些了.

顺便说一下，对于意大利读者来说，你可能知道，Wii U的代号是由与咖啡有关的术语组成的，‘Latte’也不例外，因为这是非意大利人所说的’Latte macchiato’:’ )

面临新挑战的旧伙伴关系

与任天堂和IBM的良好关系类似，这家公司也保持着一种独特的合作关系，他们从Nintendo 64开始.

ArtX是以设计Reality Coprocessor (当时是Silicon Graphics的一部分) 而闻名的团队，该团队后来研发了Flipper，GameCube的独特SoC，内置了其标志性图形处理器。 几年后，在被 “ATI”收购后，他们为Wii提供了Hollywood，从中我们发现了Flipper的GPU的加速版本. 但最重要的是，大约在同一时间，ATI一直在为微软研发一项尖端技术。 结果是 Xenos 及其面向大众的新着色器模型.

在Xbox 360发布多年后，ATI被一家名为 “AMD”的芯片公司收购，这使得我们要解释一下AMD的历史。

泰坦降临

AMD最初被称为英特尔的伙伴，曾经是英特尔 CPU(即 8086 和 80286)的第二个供应商，这种关系在 AMD 开始销售未经授权和改进的80386 CPU[13]后破裂 。 英特尔对此十分不开心，很快，两家公司就成为了正面竞争者。

竞争如此激烈，以至于在上世纪90年代末，英特尔(Intel) 计划用他们的新系列“Itanium”cpu来占领64位市场，但很快就被AMD的更简单的替代方案挫败了: x86扩展“amd64”(也被称为“x86-64”). 因此，英特尔被迫采用AMD的标准。 作为参考，amd64仍然作为当前x86 CPU的ISA (截至2022年)。

然而，AMD从来都不是一帆风顺的。 由于与英特尔竞争的压力也带来了一些失败(即被放弃的“3DNow！”扩展，Fusion 的推迟发布等)，现在，随着 2006 年收购 ATI，AMD 发现自己面临两条战线: 英特尔在 CPU 市场，英伟达在显卡市场。

下一代Radeon

我们已经分析了AMD，再让我们分析一下ATI的Radeon产品线状况。

在Xenos及其基于“统一渲染架构”的新架构推出后，ATI仍然忙于微软的项目，因此他们无法分配足够的资源在短期内将Xenos推向PC市场。 因此，剩下的团队专注于维护他们经典的x1000/R500系列，这为英伟达在ATI之前发布他们名为GeForce 8(具有Tesla架构) 的显卡留下了足够的空间。 最后，在 2007 年(Xenos 两年后) ，ATI 推出了 Radeon 2000 系列(代号为 R600) 和 它的 TeraScale 架构。 新设计现在不受微软的预算和许可控制，为那些愿意支付高价的用户带来了Xenos的所有优点，以及可选的额外功能。

现在，对于 Wii U，ATI 为任天堂准备了一张基于 Terascale 的显卡，但从未正式确认他们基于哪种型号。 Fail0verflow 将它与 Radeon HD 4000 系列 (代号 R700) [14] 联系起来。 作为参考，基于R700的显卡于2008年推出，是R670和R600系列的增量更新。 最明显的变化是包含了更快的视频解码硬件和对OpenCL的支持，尽管只有前者(在某种程度上) 可以在Wii U上使用。

无论如何，Wii U的GPU有两个名字， 任天堂在提及硬件时称其为 GPU7，在提及 API 时称其为 GX2。 对于这篇文章，我将使用’GPU7’这个称呼，因为我将把重点放在硬件上。

GPU7的架构

TeraScale架构是Xenos/Crayola移植到PC 市场的具体化……而GPU7则是将TeraScale重新带回到主机. 它最明显的特征是使用统一着色器模型，将顶点和像素单元集中到一个单元中， 现在称为 SIMD 单元。

值得强调的是，虽然采用了Xenos，但是API模型仍然是基于segregated shader model(被隔离的着色器渲染模型)，这样的话Xenos的库并没有提供更多的功能，导致现在仍然使用一个统一的计算单位。 好吧，多亏了后续更新(Direct3D 10 和 OpenGL 3.3)，情况已不再如此。 回到Wii U，GX2是唯一可用的API，它是基于OpenGL 3.3。

硬件组织

大部分与图形有关的数据都存储在上述2GB的DDR3 RAM中，被称为MEM2，它由CPU和GPU共享。 这意味着GPU必须把数据存放在那里，但是MEM2相对较慢，并且没有为CPU和GPU并发工作所导致的竞争做优化。 因此，任天堂设计了与Xbox 360类似的东西，那就是加入了一个专用的、接近32MB的EDRAM(称为MEM1)，用于快速操作(即渲染目标和其他高要求的缓冲区). 因此，不仅可以渲染更大的帧，而且还有额外的空间来执行具有可接受性能的后处理 (即抗锯齿)。

Image
数据如何在可用内存中进行编排的例子.

反过来，Wii U的EDRAM 大于Xbox 360(意味着 tiling（tiling指的是一种将渲染区分割为小单元的技术，同样的可以在DC的图形板块看见）的需求更小了)。 然而，EDRAM不包括用于后处理的专用电路。

构造画面（frame）

这是《游戏机架构》系列的标志性部分，我试图解释将几何图形 (来自 CPU) 转换为像素 (用户最终在电视上看到的像素) 的过程。 然而，在这篇文章中，解释将有点不同，因为TeraScale的基本原理已经在Xbox 360的文章中解释过了。

自Xenos以来最重要的变化是几何着色器和计算着色器的实现(或者更好地说，标准化)，两者都利用了统一渲染架构的新功能。 这并不意味着GPU7为了使用这两种新技术而被重新设计，事实上这只是在不修改硬件的情况下扩展了API来开启新的应用

作为一款为任天堂游戏机构建的AMD/ATI芯片，GX2支持两个着色器api， OpenGL’s GLSL 3.3和OpenGL ESSL。 SDK还带有一些扩展功能，提供只有在GPU7上才有的功能，但它不支持OpenCL，当然也不支持Direct3D。

Image
GPU7 的图形管道概览.

尽管如此，GPU7还是继承了Radeon R700系列的设计，所以GPU7的管线(pipeline) 在一定程度上与Direct3D 10.1和OpenGL 3.3标准保持一致。 虽然，他们各自的着色器语言并不为GPU7所理解 (他们需要随官方SDK提供的专有编译器)。

附带说明一下，PC 市场的典型 Radeon 卡使用 AGP 或 PCI-e 总线接口。 好吧，Wii U 硬件仍然使用将 I/O 寄存器公开为内存位置的老式做法 [15]。 我猜任天堂和 AMD 都不担心，因为这都是定制设计的一部分。

现在让我们一步一步地检查管线。 由于该设计与Xbox 360的Xenos GPU非常相似，我将尽量专注于GPU7的新颖之处，以避免重复信息。

指令

Image
命令阶段概述.

对于大多数显卡，尤其是 ATI/AMD 显卡，起点始终是 指令处理器 [16] 正如我们之前多次看到的，这是GPU和外部世界 (即CPU)之间的门。

对于 GPU7，指令处理器读取存储在 RAM 中的指令并激活芯片内必要的引擎。 最值得注意的是，GPU7具有一个专用的直接内存访问(DMA) 控制器，可以在MEM1和MEM2之间操作数据，而无需CPU的干预。

此外，DMA可能会异步工作 (与其他电路不同步)，因此GPU7提供了一些命令来刷新其缓存并与DMA同步 (以信号的形式) 以维持秩序。

Vertex

Image
顶点 (vertex) 阶段概述. 你很快会发现，这个阶段和像素阶段也没有 那样地 不同.

乍一看，这个阶段与Xenos/Crayola基本一致，只是有些区块被扩大了 (增加了缓存)，而有些区块则被收缩了(减少了ALU单元的数量，内存输出路径更短). 然而，这并不一定意味着性能下降，因为我们不要忘记GPU7比Xenos领先7年。

首先，让我们看看ALU（arithmetic-logic unit 算术逻辑单元是中央处理单元的一部分，它对计算机指令字中的操作数进行算术和逻辑运算。）。 Xenos依靠三根着色器管道(16个AUL区块)来执行vertex shaders(一种图形处理功能，用于通过对物体的顶点数据执行数学运算来为3D 环境中的物体添加特殊效果)。 GPU7仅捆绑两个16ALU的区块，但每个区块现在都被包围在一个更大的硬件叫做 SIMD 处理器， 我认为这一部分更大的附加电路(指 L1 缓存中的8KB和额外的接口和控制单元）是为了保持更多的并行流量。 此外，每个ALU都是由四个“子ALU”组成的，允许前者一次性计算由四个标量组成的向量。 ATI/AMD把这些子ALU叫做stream processors(流处理器),这是一个通用的营销术语。

现在，序列发生器（Sequencer）不会立刻发送计算结果，当计算结果到来时，他们首先会被合并成更大的一组64个顶点(vertices)以及一些元数据来控制操作[17]， 这叫做 “波前”或”波导面”（Wavefront） 合并的Vertex组接着被发送到两个SIMD。考虑到在GPU7中只有32个ALU的事实。 这会花费 四个周期 来计算。

我认为这种新设计使制造商能够设计不同性能范围的显卡，通过 昂贵的设备包括更多的SIMD单元（如此只需要更少的时钟周期就能完成计算）。 作为一个不靠使用高端硬件而出名的游戏主机（他们通过能效来弥补），wiiu完成Wavefront的计算需要四个时钟周期

Geometry

Image
几何 (geometry) 阶段概述.

几何着色渲染器是在两个著名API（Direct3D和OpenGL）将同一规范的构造器纳入其规格之后出现的图形管道的新阶段。 这个新阶段的目的是使开发人员能够操纵基本元素(点、线或三角形)，而不是单个顶点[18]。 这对从现有几何图形程序化生成 新的几何图形很有帮助(即设计阴影、毛皮（fur）等等)。 GPU7像Radeon R700一样，继承了对 OpenGL 3.3 的遵守，因此支持这种新的着色器类型。

然而，在场景背后，几何阶段只是顶点阶段（vertex stage）的另一个“模式”。 为了让这一过程更加快速，如果几何着色器被激活，则顶点阶段（vertex stage）不会马上向前转发数据以进行光栅化。 相反，输出数据被保存在MEM2专用缓冲区中，顶点阶段（vertex stage）将会重新开始，但数据是从几何缓存区获取的。 然后波前（Wavefront）被组装用来收集多达64个”基元”或”图元”数据(primitive) 的索引，同时表示几何着色器的元数据将被执行。 随后，序列发生器（Sequencer）读取新的波前，解析原始数据并将其发送给两个SIMD以供计算。 这一过程将一直重复直到所有原始材料都得到处理为止。

最后，着色器管道进入光栅化阶段。

光栅器

Image
光栅阶段概述.

光栅化阶段往往比其他的阶段简单得多 主要原因是将顶点转换为像素的行为大多是系统性的，不需要额外的编程能力(除了一些可供调整的参数)。 因此，这个阶段与Crayola/Xenos是相同的。

虽然如此，Z缓冲区和模板缓冲区不再分配在专用内存上。 相反，新的渲染后端块(执行Z和模板测试，并支持分层测试) 必须访问RAM才能工作(EDRAM或主RAM)。

光栅化器可以使用128位像素格式[19] 合成高达8192 x 8192像素的帧。 这将允许具有HDR色彩质量的大帧数。 然而，出于显而易见的原因，开发者并不需要_那么_大的帧数(1280 x 720对于这个控制台已经足够了)，除了HDR将被广泛使用。

像素

Image
像素和分散阴影阶段概述.

像素着色器阶段采用与顶点着色器（vertex shader）相同的方法，除了现在已经被打乱的像素。 在经过了对Xenos像素功能和GPU7新的顶点管线的介绍之后，我担心这里没有太多可以解释的了。

现在负责将纹理提取到SIMD单元的块被称为纹理管道，并且有两个这样的管道。 每个纹理管道都包含8 KB的L1缓存，在访问RAM时它们共享32 KB的L2缓存。 此外，它们可以立即执行高达16倍的各向异性过滤，并且还可以获取立方体贴图(用于环境映射/反射)。

我想值得指出的是，着色器模型(OpenGL GLSL 3.3)为操作纹理添加了大量新例程(例如新类型的纹理混合，按位运算符，纹理调整)并消除了许多限制(例如每个着色器允许的指令数量)。 所有这些都使开发人员的工作变得更加容易。

像素操作

Image
可用的像素操作概述.

一旦帧被渲染出来，开发人员可以应用更多的Z测试(如果在之前的阶段没有激活)，颜色混合，并最终将像素导出到帧缓冲区以进行显示。 这都是由渲染后端(有两个) 执行的操作，它们位于像素着色器阶段的末尾。

最后，尽管Wii U没有像Xbox 360那样在EDRAM模块中捆绑复杂的电路，但GPU7仍然提供了许多有趣的功能。 这些功能包括 高达16次的自动多样本抗锯齿(MSAA 16x)，用于软化边缘，令人惊讶的是，它不需要平铺渲染，因为Wii U拥有更大的32 MB EDRAM(MEM1)，足以支持这些操作(当然，MSAA 16x可能会消耗过多的MEM1，不过MSAA 8x仍然可以接受)。

除此之外，我们还需要考虑程序员可能决定实现的自定义算法。 这要归功于API的灵活性和大量可用的着色器操作，包括Compute Shaders(将CPU计算卸载到GPU)。

交互式比较

我在交互式查看器上添加了新的 3D 模型，因此您可以自己检查之前(Hollywood GPU) 和之后(Latte GPU/GPU7) 的“效果”：

线框表面纹理
3D model
Wii 平台的超级马里奥银河 (2007) .
4,877个多边形.
线框表面纹理
3D model
Wii U 平台的超级马里奥 3D 世界 (2013) .
9,304 个多边形.

虽然马里奥的纹理在Wii U上似乎没有提供很多额外的东西，但GPU7的改进在于额外的表面和骨骼，特别是手和脸，这使得模型对环境效果和动画的反应更加真实。 这样一来，在整个游戏过程中，场景看起来更加自然。

视频解码

除了GPU7的3D渲染能力之外，还有一个额外的功能是加入了H.264解码电路，将H.264压缩数据流转换为GPU可以理解的原始帧(并随后在屏幕上渲染). 主要优点是带宽效率没有性能损失。

因此，H.264单元可以以开发人员喜欢的任何方式 (即在游戏中或以电影的形式)用于在游戏中显示.

视频输出

现在是时候让任天堂放弃他们专有的模拟电路，拥抱(至少一个！) 视频标准了。 看，HDMI 1.4插孔终于被安装在了机器背面，同时还有传统的AV Multi Out作为 “备用”。

Image
主机的后视图，有两个视频接口（HDMI 和 Multi-AV）.

现在，尽管输出分辨率可最高达到 1080p， 但大多数游戏都使用 720p 来保证游戏表现和抗锯齿以及更高的分辨率之间的平衡。 使用 720p 还有助于开发人员在不改变游戏逻辑的情况下保持对 480i 和 576i 的支持(因为视频编码器负责自动缩小帧). 这种操作方式与PlayStation 3和Xbox 360的操作方式一致。

辅助GPU

话说回来，这台主机为什么还能玩Wii游戏？ 是否有某种GPU7到 Hollywood的模拟器在幕后运行？ 嗯，简短的回答是不。 你可能会感到惊讶，任天堂直接在 Latte 中添加了Hollywood的旧GPU电路(我们称之为“Wii GPU”) [20]。 这个单元只在Wii游戏运行时起作用。 虽然，Wii GPU 装有旧的 3 MB 的 1T-SRAM，也就是我们现在所知的 MEM0。 因此，至少新硬件使用了额外的内存。

此外，任天堂还安装了一个名为DMCU的额外芯片，以复制旧的视频接口。 根据 fail0verflow的信息，DMCU 只是一个摩托罗拉 68HC11 控制器，它被编程为像前身一样工作。 它的唯一目的是接收来自Wii游戏的指令，并将帧转发给GPU7，以便后者能够将其在电视上播放。 由于Wii游戏是为PAL/NTSC显示制作的，GPU7的视频编码器必须使其升频(根据我的经验，它并不擅长这样做……)。

如果你想知道，Wii U游戏有没有’Wii GPU和GPU7’协同处理的功能。 尽管我们知道其中一方会给另一方造成瓶颈，但它将会是十分有趣的事情……

音频

起初，我以为Wii U通过软件实现其音频功能(就像其竞争对手开始做的那样).。 但随之而来的是其他问题：Wii 复杂的 DSP 是如何模拟的？ Espresso足够强大吗？

嗯，这还不是全部。 与Wii不同，Wii U的音频管道必须服务于三个终端： - 电视，预计最多6个声道(通常只有2/立体声). - GamePad 最多有 4 个声道(也称为环绕声). - 最多四个 Wii 遥控器(每个都有一个低质量声道).

瞧，Latte还容纳了一个定制的DSP，用于音频合成。 它通过任天堂的库运行，尽管开发者可以通过软件扩展音频通道(以CPU周期为代价)，如果这对他们来说还不够的话。

Image
音频管道概述. 在这个例子中，游戏是通过光驱加载的.

DSP会帮助完成混音和排序任务，其余的(即过滤、效果等)由软件完成(Espresso的工作). 此外，任天堂的库负责工作负荷管理，音频任务首先被分配给DSP，在负荷满载的情况下，这些任务会被发送到Espresso。

工作负载量和由此产生的性能将取决于许多因素，包括流式传输的编码类型(如 ADPCM比PCM占用更多资源). 程序员必须首先使用提供的音频分析工具测试他们的代码，以得出有效的实施方案。

I/O

在I/O和交互方式上，任天堂仍然打破了现状。 从硬件的角度来看，这些组件的选择和内部组织往往会达到强迫性水平的成本效益。 这可能是因为这一领域完全由任天堂的工程师指导，他们努力使主机保持在一个可承受的价格。

熟悉的ARM芯片

还记得旧的 ARM926EJ-S 吗？它 完全控制 Wii 的硬件？ 是的，Wii U 中也有相同的 CPU. 然而，主要的区别在于，Starlet现在有着更大的内存 (96KB 的 SRAM)，并对于安全相关任务有着更好的算法.

顺便说一句，在 Wii U 中没有这个 ARM9 CPU 的官方名称的情况下 (毕竟，任天堂认为，你不应该知道这个芯片…)，fail0verflow想出了他们的标识代号：Starbuck.

Image
主机结构的主图. 注意 Starbuck 是如何被放置于 Latte 的重要区域的.

话虽如此，Starbuck 的编程相关能力已经大大加强了. 我在“操作系统”和“反盗版和自制”部分进行了详细介绍. 现在，请记住 Starbuck 相当于 Southbridge.

外部接口

Image
前面板打开时主机的前视图.

从外面看这台主机，Wii U 提供了以下接口:

内部接口

如前面所述，Starbuck 连接到大多数 (可能不是全部的) I/O 外围设备. 考虑到它与Wii的强大向后兼容性，以及包含相同的 ARM9 内核用于I/O处理，我认为 Starbuck 仍然依赖 AMBA 总线 与外围设备通信，特别是 AHB 版本 (因为新接口需要更高的带宽).

因此，Starbuck 连接到以下接口:

补充接口

对于另一个部分，让我们来看看 Wii U 包含的一些不同寻常的功能，起初没有人知道它们会被用来做什么.

Image
一个用于任天堂大乱斗的马里奥 amiibo 手办 [22].

当用户拿到 Wii U 的时候，他们很快注意到 GamePad 有一个 近场通信 (NFC) 读取器. 起初，任天堂并没有分享这些功能会用在哪里，一些媒体甚至猜测它最终会启用NFC支付 [23]. 到2014年，任天堂才最终公布了他们对NFC技术的意图：手办，他们称之为 amiibos. 它们嵌入了一个独特的NFC标签[24]，支持它们的游戏允许用户 “扫描” 他们的 amiibo (将它们放在 GamePad 的 NFC 读取区域顶部). 然后，游戏将检测放置了哪种类型的手办，并做出相应的反应 (即解锁额外内容、获得特殊皮肤等). 标签内置了可以用来存储用户数据的小型存储 (只有512字节 [25]).

总的来说，这些手办不仅为任天堂打开了另一个市场，而且很快就变成了罕见的收藏品 (供黄牛们获利). 尽管这些雕像的市场并不完全是“新兴的”，因为动视和迪士尼等其他公司已经在将这类产品商业化.

操作系统

如果我告诉你机器内一共有 四种操作系统, 你敢相信吗? 其中两个跑在 ‘Wii U’ 模式, 而另外两个仅仅用于向后兼容.

由于这个话题可能会让人非常困惑，让我们从机器的 Wii U-only 系统开始.

随着年龄的推移，智慧也在逐渐显现。

就像最初在 Wii 中一样，Wii U同时运行两个操作系统，一个在 CPU (Espresso) 中，另一个在I/O处理器 (Starbuck) 中. 然而，两者都是用更大量的抽象层和更复杂的安全模型设计的. 因此，Wii U游戏其实不是直接裸机运行的.

Starbuck 改进版操作系统

首先，Starbuck 的操作系统现在被称为 IOSU (fail0verflow 给出的另一个名称，意思是 IOS + Wii U)，你只能找到它的一个变体. 这意味着没有更多的 升级槽位，尽管有一种被称为 “IOSU255” 的替代版本 IOSU，它只在安装系统更新时加载.

IOSU 仍然由 多线程微内核 组成，该内核现在可以分配多达180个线程 (以前是100个)，以及 驱动程序 和 模块，以负责I/O访问和安全.

一个有趣的方面是，Starbuck 使用了两个安全的内存块来加载其内核：其内部 96 KB 的 SRAM 和 3 MB 的 1T-SRAM (称为“MEM0”) 来自 Wii GPU 部分. 这是出于性能和安全原因，因为它可以防止 Starbuck 被篡改并减少拥塞.

Espresso 的新操作系统

首先，Espresso 现在运行的是一个真正的操作系统. 而 Wii 游戏是在裸机上运行的，这是最明显的变化. 这被称为 Cafe OS，它由多个组件组成，不一定存储在同一介质中 [26]:

接下来，内核以 监管模式 运行，并使用 Wii 所依赖的相同 进程间通信 (IPC) 信道与 Starbuck 通信. 该组件可以在内存中加载多个程序 (进程)，但它可以同时运行的进程数量非常有限 (尤其是在需要前台功能的情况下)，我稍后会详细介绍.

Image
Wii U 中两种操作系统组合后的特权级别概览.

Cafe OS 使用名为 “RPL” 的专有二进制格式加载系统和用户应用程序，该结构用于可执行文件和库. 此外，主要可执行文件被称为“RPX”. Cafe OS 的一个应用程序 Loader 负责将它们加载到内存中 (与 IOSU 合作) 并执行它们. 此外 Loader 还执行 动态链接，将程序中 Cafe OS 的引用与控制台中安装的物理 Cafe OS 连接起来. 最后，应用程序以 “通道” 的形式安装，这些通道稍后会显示在 “系统菜单” (交互式界面) 中.

由于内核组织内存布局的方式，用户只能同时运行 最多两种类型的程序. 一个是可用内存最多的 “前台” 程序 (即游戏)，另一个是分配内存明显较少的 “后台” 应用程序 (即网络浏览器). 用户可以在两者之间切换，而无需关闭任何一个，但一次只能显示一个，而且只能加载一个“前台”和一个“后台”应用程序. 否则，要么被关闭，要么被解除内存分配.

巨大的代价

是时候解决一些听起来有点离谱的问题了：Cafe OS的运行消耗了1GB，这是本该应用于游戏的 MEM2 的一半. 这意味着，Wii U拥有2 GB的DDR3，只向用户关心的最重要的应用程序授予1 GB.

虽然我的看法可能_不太专业_，但这真的很令人失望，尤其是考虑到像 Mac OS X 10.4 “Tiger” 这样的操作系统，它也运行在类似的 PowerPC CPU 上，提供了一组更复杂的功能，并且只要求最低256MB的 RAM. 即便如此，游戏机制造商倾向于在设计操作系统时尽可能减少占用空间，而任天堂这次似乎无法满足这一要求. 令人好奇的是，甚至有报道称，任天堂计划推出新版本的SDK和软件更新，以减少操作系统方面的内存消耗. 然而，新机来了，它的继任者已经在商店里了，而且看不到 Wii Us 的进一步进展. 那好吧！

尽管如此，还是有一个小小的妥协：“强制前台”应用程序可能会额外占用40 MB，只要它们正在显示 (也就是显示在前台). 然而，一旦用户切换到后台应用程序，该内存块就会自动解除分配. 这并不是一个“简单”的功能，而是由开发人员来找到好的用途.

保持传统

当玩Wii游戏时，一切都会改变，因为Wii U进入了一种被称为 ‘Virtual Wii’ (vWii) 的状态. 这并不是模拟器，而是重新调整了硬件，使Wii游戏认为它们是在原始平台上运行的.

要进入 vWii 模式，Starbuck 执行一个名为 cafe2wii 的程序，该程序负责将主机转换为 Wii (也就是取消激活所有现代功能) [28]. 现在，有不同的二进制文件集可供使用 (每个二进制文件都有cafe2wii的特别版本)，特别是OSv0 和 OSv1. 选择取决于所需的vWii模式的类型. 总结起来就是：

幸运的是，并不是所有 vWii 模式下的现代硬件都被浪费了，因为 GamePad 也可以变成一个带控制器的镜像屏幕. 如果这还不够的话，GamePad的正面包含红外线灯，可以充当传感器条，所以 Wii 遥控器手柄根本不需要电视.

就像任何具有向后兼容性的任天堂游戏机一样，一旦进入 Wii 模式，唯一的方法就是重新启动游戏机.

存储介质

Wii 毫不避讳地提供了以多媒体为中心的存储选项 (SD 卡是一个不错的补充). 因此，Wii U就是以此为基础的.

话虽如此，现在还是让我们看看这个控制台中有哪些存储选项:

引导 ROMs

Image
在这个复杂的封装中，有两个隐藏的只读存储器（ROM），以普通形式储存启动代码。

第六代产品巩固了视频游戏机中操作系统的概念. 然而，该设备仍然暴露在将现成组件与内部组件相结合所导致的漏洞中. 由于主机制造商无法定制第三方芯片的设计，定制的安全组件必须位于主板内的不同位置，从而面临篡改和逆向工程的风险.

在第7代产品中，IBM推出了一系列新的 PowerPC CPU，在硅中嵌入了一个隐藏的掩模 ROM. 这使得 PlayStation 3 和 Xbox 360 能够以简单的形式存储敏感代码 (因为CPU只能理解未加密的代码)，而不用担心被黑客读取. 话虽如此，现在轮到 Wii U 了，所以IBM也为此做好了准备：在 Espresso 内部，有一个隐藏的 16KB ROM 连接到其中一个核心. 这被用作 Espresso 的第一个启动阶段，一旦执行，它将确保后续的二进制文件得到任天堂的批准.

再加上 Starbuck 自己的 4 KB 引导 ROM (继承自以前的Wii型号)，你就有两个CPU在启动时强制执行任天堂的安全代码.

机密 ROMs

任天堂还添加了其他 ROM 散布在 Latte 周围，其中包含 非常敏感 的信息.

第一个是 1 KB 的一次性可编程 (OTP) 存储器，其中存储了许多加密密钥。 这种内存也可以在 Wii 上找到，但尺寸较小 (128字节). OTP 存储用于加密/解密数据和验证现有数据完整性的信息[29]. 它还存储用于启用/禁用主板的低级别功能的标志 (比如 JTAG 调试). 此外，OTP 在 Espresso 的 bank 和Starbuck的 bank [30] 之间是分开的，因为两者都需要读取不同的密钥，然后在不同的时间点锁定 OTP 访问.

第二个是 512 字节的 SPI EEPROM（SEEPROM），它是可写的 (尽管不是所有的都经过编辑)，并包含许多配置标志和其他元数据 [31]. SEEPROM 中的一些数据是用 OTP 存储器中的密钥加密的.

分散的 NAND

Image
NAND 芯片提供 1 GB 存储.
Image
eMMC 芯片提供 8 GB 存储（在这张图中）.

在讨论了系统的底层部分之后，让我们现在来看一下“可见”部分的存储位置. 主板上有两个存储空间:

首先, 我们有 1 GB of NAND 被分成两个 banks:

  • 第一个 512MB 存储 Wii U 的操作系统（后期的引导程序和 Cafe OS）.
  • 第二个512 MB包含构成 Wii 操作系统（系统菜单、IOS 插槽和通道）的软件，但 原始引导程序 除外.

其次，8 GB 或 32 GB 的 eMMC（取决于购买的型号）仅可用于用户数据（下载的游戏、DLC和游戏更新）. 请记住，这可能还包括从虚拟控制台 (Virtual Console) 商店下载的Wii游戏（只能从Wii U的系统菜单启动）.

存储扩展

Image
为了可以在 Wii U 上工作, 一般将外置硬盘连接到 USB Y 型电缆.

对于那些空间很快用完的用户，Wii U提供了开箱即用的 外部USB存储 支持. 然而，唯一的限制是，介质必须使用 Wii U 的专有文件系统进行格式化，并且只能存储用户数据. 顺便说一句，Wii U 的 USB 端口只能输出高达 500mA 的电流 [32]，具有讽刺意味的是，这对于一般的 USB 硬盘（约900mA）来说是不够的. 因此，用户不得不使用 USB Y 电缆来组合两个 USB 端口的电流.

接下来，还有一个 SD卡插槽，但这只能被某些存储多媒体文件（如图像）的程序和游戏所利用. 幸运的是，它支持 FAT32，因此不需要格式化.

启动流程

有两个独立的 CPU 可能很难初始化. 尽管如此，任天堂对这种做法并不陌生. 那么，Wii U是如何协调 Espresso 和 Starbuck 的，从而使控制台最终在安全的环境上运行交互式界面的呢？ 让我们看看.

多核混沌 (Multicore chaos)

在我们开始之前，我想解决其他对称架构（如xbox 360）上存在的 相同的问题：对称内核必须协调，这样每个内核就不会同时接管系统. 好吧，Espresso采用了与x86类似的做法，在x86中，只有一个内核在打开CPU时被激活. 然后，由主内核中的程序加载来唤醒另外两个 [33].

尽管如此，所有内核都包含相同的重置向量 (vector). 因此，程序负责询问自己从哪种类型运行，然后根据答案继续运行. 这种操作方式类似于 ARMv7.

启动流程

是时候来看启动程序了，我先告诉你，它并不是特别简单. 毕竟，它是两块有独特安全模型并且完全独立的处理器，正在以一种有序的方式启动，这就需要进行许多协调. 为了你们能听得懂，我的总结会尽量简化，以避免向你们提供大量信息. 所以，如果你想要了解更多，请不要忘记查看引用的文章.

另一方面，你不需要完全理解这个问题才能看文章的其余部分. 如果不是您感兴趣的领域，请随时可以跳过！

好吧，让我们开始吧。 一旦用户按电源按钮，将发生以下事件[34]：

  1. Starbuck 被唤醒并进行到…
    1. 执行在其重置矢量 (vector) 中找到的代码(0xFFFF0000) [35], 它指向它的掩码 ROM (其中第一个启动阶段是， boot0). 第一个例行 (routine) 让 Starbuck 将 boot0 复制到Starbuck的SRAM, 所以它运行得更快.
    2. boot0 然后通过读取 OTP 内存和 SEEPROM 上的标志（flags）来初始化部分 I/O 和附近的区块。 然后从 NAND 中获取下一个引导步骤 (boot1)。
    3. boot1 已经被加密和签名，因此 Starbuck 首先检查其签名 (RSA 类型) 以及内容的完整性(比较 SHA-1 哈希校验值) 然后开始解密它 (使用 AES)。 所有需要的密钥和证书都是从 OTP 内存中提取的。
    4. 更多I/O 的初始化完成后。 然后，SEEPROM 和部分 OTP 将被锁定无法再次访问。 最后， boot1 部分的初始化就暂告一个段落。
    5. boot1 初始化更多 I/O 并准备使用 MEM2 和 MEM0 [36]。 然后从 NAND 读取 IOSU 固件 到MEM1 并执行相同的验证 & 解密过程。 如果一切顺利，Starbuck 会禁用使用过的 OTP 内存，并完全清除敏感数据。 最后，它将转到 IOSU 固件。
    6. IOSU 固件 是一堆程序的集合。 首次启动的是 IOSU Loader，它加载了剩下的其他固件(像是 IOSU）到特定的内存位置(SRAM 和 MEM0)。 然后它从MEM1中清除自己，跳到了在 IOSU 内核 等待的 SRAM。
    7. IOSU 内核 首先快速进行 MEM1 检查 [37]， 一旦完成后， Starbuck 会运行在 IOSU。 为了能正常执行功能，IOSU 的相关模块可以在 MEM0 上找到。
    8. Espresso 是下一个，所以IOSU 将 Cafe OS (加密形式) 复制到 MEM2 并启动 Espresso。
  2. Espresso 的第一个核心启动后…
    1. 重置矢量（vector）处于地址 0x00000100, 此处被 Boot ROM 占用, 所以它开始在那里执行.
    2. MMU, L1/L2 缓存和注册表被清除。 然后，Espresso 切换到“翻译模式”(激活 虚拟内存)。
    3. 通过篡改锁定的 L1 缓存和空内存写入，BootROM 被复制到 L1（为了更快地运行），而不会到达外部 RAM。
    4. 重置向量（reset vector）变成一个无限循环(以阻止试图重置 的 CPU)。
    5. OTP 的 AES 密钥已复制到 L1。 然后，OTP 被禁用。
    6. Cafe OS 内核的 header 已复制到L1，其签名使用存储的密钥进行验证。
    7. Cafe OS 内核的数据通过使用 DMA 将数据散列和解密，以区块的方式来回发送到 L1 缓存。
    8. 现在未加密的 Cafe OS 内核在 RAM 中映射完毕并准备执行。 L1 和 L2 已被刷新；启动 ROM 已被禁用。 最后，跳转执行 Cafe OS 内核。
    9. Espresso，正在运行 Cafe OS 内核，检查用于指引它启动 系统菜单 应用程序的配置文件。
    10. 系统菜单 是从 NAND 到 MEM2 并像其他加密的程序一样处理的。 如果一切正常， 系统菜单 将被启动。
  3. 用户现在将可以控制主机了！

vWii 启动流程

一旦 Wii 图标启动，系统将进入一个 “额外” 加载阶段，将 Wii U 变成一个 Wii。 这个过程开始于 Starbuck 执行 cafe2wii, 然后到 [38]：

  1. 重启 Espresso.
  2. 将 Espresso 降频并禁用两个额外的核心。
  3. 上传用于 DMCU 视频编码器的固件。
  4. 将 旧字体 上传到 MEM1 的区域 它们可以从 EXI 接口访问(为了创建 旧的 EXI 路由)。
  5. 启用 AHCI 接口上的兼容模式(即连接到SATA 光盘驱动器的接口)，以便可以使用旧的 光盘接口 (DI) 协议来命令它。
  6. 将 OTP 内存中的密钥复制到其内置的 SRAM，因为 vWii 会认为内部的 SRAM 是 传统的 SEEPROM。
  7. 禁用 Wii U-exclusive I/O，但 GamePad 除外 (除非它被用户或游戏停用)。
  8. 启动 IOS。 IOS 槽 的选择取决于使用哪种 vWii 模式，如果在 HAI 模式中，则取决于游戏。
    • 为vWii设计的 IOS 软件包已经略有改动，增加了一些模块。 这包括 DI2SD 来模拟光盘驱动器和 OHCI1 将来自GamePad 的输入转换成蓝牙命令 (以此来使用 Wii 手柄）[39]。
  9. 上传 Wii 系统菜单 或 NAND 启动程序 (运行Wii 图标的二进制文件) 到 MEM2, 选择取决于使用的 vWii 模式。
    • 由于 Espresso 将从 启动ROM 起就启动，它只能使用 Wii U 的安全模型接收二进制。 因此，Wii 的相关程序都进行了修改以进行兼容。
  10. 启动 Espresso，让它处理并运行指定的二进制文件。
  11. 用户现在将又可以控制主机了！

交互界面

Wii U的图形用户界面叫做 系统菜单 (或’Wii U Menu’) 正如你以前看到的那样，它是一个在 Cafe OS 完成加载后立即启动的应用程序。

Wii U提供的大多数服务（例如： 光盘游戏启动器、设置、在线商店等等）以前台应用程序的形式出现，用户可以从系统菜单中选择其中任何一个。 在另一边， 一组小的功能 (如 网页浏览器) 已作为后台应用程序实现，并且只能从“主页”菜单中启动。

Image
从GamePad上看到的系统菜单，显示了安装的传统网格’频道’(应用程序) 。
Image
主菜单可以在两个屏幕同时显示. 当用户在 GamePad 上按下 ‘Home’ 按钮后显示.

系统菜单界面是针对触摸屏设计的。 尽管它的主要控制器是 GamePad， 它还支持指向交互屏幕（如Wii 那样）。

Image
设置应用程序(GamePad 视角) 提供了相应选项.
Image
设置应用程序(电视视角)是一个关于选项的指南.

在其他新闻上，Miis (任天堂的 签名头像) 也被移植到 Wii U。 看起来并没有很多游戏，但是有许多系统应用程序使用Miis (主要用于装饰目的)。

Image
新的 Mii 编辑器(GamePad 视角).
Image
虽然看起来不像，但这是从电视上看到的Web浏览器应用程序(实际浏览发生在GamePad上)。

在任天堂所有家庭游戏机中，GUI 第一次是多用户的。 因此要求用户在首次启动时设置一个 系统帐户 (类似于 索尼 和 微软 的主机)。

Image
系统菜单也在电视上显示信息. 展示了一个住满 Mii 小人的小镇, 他们还会对你说一些随机的小提示. 最初，Miiverse 服务还在运行时，该屏幕也展示来自 Miiverse的用户界面的消息.

在亲身体验过 GUI 后，我惊讶于它缓慢的运行速度。 总体来说不是缓慢的，但在应用程序之间切换 (必要且经常发生) 需要相当长的时间。 这可能是由于安全模式到位缓慢(请回忆 Espresso 和 Starbuck binaries 的引导过程)，因为 每一次 都需要运行。 此外，Espresso似乎对已执行的算法并不特别快（将在“反盗版/自制软件”部分解释安全模型）。

传统的 shell

系统菜单有一个叫做 Wii 模式 的特定应用程序。 这是启动 旧的系统菜单 来游玩 Wii 游戏的程序。 在背后，这个应用会启动之前说到的 cafe2wii 程序，并且我们已经知道了这种方法是如何运作的。

Image
在进入 vWii 模式之前，系统会询问用户是否要保持 GamePad 为使用状态(作为输入设备和镜像屏幕).

一旦进入了 vWii 模式，它的 主菜单 将也能更改主机的相关设置（如 Wii 手柄的配对信息和其他设置）。 因此，为了避免与 Wii U 本地配置发生冲突，IOSU 的内核模块负责事先同步两个设置 [40]。

Image
vWii 模式中的 Wii 系统菜单. 除了已安装的三个新频道（与Wii U有关）和其他已移除的频道之外，差别不大. 请看视频编码器产生的细小黑边，它试图将原始的480p图像适配到720p/1080p信号中。

vWii 模式不一定需要电视。 如果用户选择激活 GamePad 显示，GamePad 将会变为一个显示器， 传感器条和 “经典控制器” (Wii 时期的可选配件)。 然而，最后一个功能仅适用于从eShop购买的 Wii 游戏(虚拟控制台的一部分)。

Image
启用GamePad的vWii模式后，请注意我的相机捕捉到GamePad发出的两个红外线灯。

任天堂还在 vWii 中加入了新的 Wii U 相关频道，以使用户的体验更加舒适。

Image
新的“Wii系统传输”频道可以通过网络将旧Wii的用户数据(包括Wii Shop购买记录和点数) 导入到Wii U上，但同时也会将旧Wii恢复到出厂设置状态。(令人担忧)
Image
新的“返回Wii U”频道，顾名思义，通过重置控制台将其恢复为Wii U模式。

最后，系统菜单上的设置按钮只允许管理保存数据 (出于实际原因，已移除“Wii 系统设置”屏幕)。

可更新性

这两个操作系统都有很强的“可更新” 性，由任天堂在线发布软件更新或者通过游戏光盘。 在这样做时，除了改进软件或修补系统的漏洞外，还可以支持新的附件。

Image
控制台安装系统更新的屏幕界面。

当更新器启动时，Starlet 会加载一个叫做“IOSU255”的特别 IOSU，然后从那里安装更新 [41]。 更新包可以同时包含 Wii U 和 vWii 模式的更新。

游戏

在这一章，我们深挖由任天堂提供的 Wii U游戏的开发，发行和在线服务。

开发生态

游戏工作室将会获得两套开发 Wii U 游戏的产品，一套是精选的硬件单元，另一套是定制的软件包。

硬件套装

类似于Wii，任天堂把套件分为了三种 [42]：

  • Cafe Tool for Development (CAT-DEV) 是用于开发、调试和配置的旗舰开发工具包。 它有着大量的内存和增强的I/O，以帮助进行原型设计。 CAT-DEV 通过 TCP/IP向 PC 传送信息。
  • 一旦开发进入测试阶段，测试人员就可以使用 Cafe Tool Reader（CAT-R）用于测试版构建，而无需购买更昂贵的CAT-DEV。 CAT-R的形状就像零售版的 Wii U，唯一的变化是在其软件中。 它的 CD 驱动器只能读取 CAT-R 盘 ，这些盘片与零售盘相同，但刻录了为开发单位制作的替代签名（signatures）。 同样的 GamePad 配件也分别发运和购买。

软件套件

官方软件开发工具包(SDK) 叫做 Cafe SDK 并捆绑了：

  • 一组用于与Cafe OS 和 主机交互的软件库。
  • Green Hill的 MULTI编译器和集成开发环境（IDE），CodeWarrior 现在已经过时。
  • 各种 实用工具 来连接到 CAT-DEV 设备。
  • GLSL shader 编译器 和一个 HL 到 GLSL shader 翻译器. 这就是 GPU7 据说与 GLSL（OpenGL的着色器）甚至 HLSL（Direct3D的着色器）兼容的原因。 但是，如果不先将 GLSL 或 HLSL 着色器编译成本地 GPU7 代码，程序员就无法在 GPU7 上使用它们。
  • 专有链接器 用于打包Wii U 可执行文件/库(形式为 RPX 和 RPL 文件)。

这些工具被设计运行于已经安装了Cygwin 的 64位版本的 Windows 7。

最后，值得提醒的是，由于游戏现在运行在Cafe OS之上，库不再是静态链接(也就是二进制文件中同时包含库文件). 所有 Cafe OS 引用都是动态链接的，操作系统现在负责运行时链接。

存储介质

这一部分与第七代游戏机非常吻合。 总之，有两种游戏分发类型：零售 和在线。

Image
一款零售游戏的例子。

零售店出售的Wii U光盘，是松下公司设计的专有光盘介质，试图复制Blu-ray光盘的许多功能…… 而不使用蓝光光盘。 它可以容纳约 24 GB 的数据，但只有 ~20 GB 可用于实际游戏数据，其余用于存储软件更新文件、元数据和其他Cafe OS需要的信息。

光驱还能够读取Wii光盘，而Wii光盘又与标准DVD格式类似。 然而，光驱不支持DVD或蓝光的播放功能。

除了光盘，用户还可以选择使用eShop渠道购买Wii U游戏和游戏扩展(又称DLC)。 该渠道还包括VC虚拟主机游戏。

Image
eShop商店的主界面。

令人惊讶的是，VC已经扩展到Wii， Nintendo DS和Game Boy Advance。 就NDS和GBA而言，VC游戏的结构与其前身(Wii的VC游戏) 相同，模拟器和游戏都被打包为一个单独游戏。 换句话说，与 PlayStation 3 不同，没有共享的模拟器。

最后，将 eShop 购买的产品安装到 eMMC 存储或外置 USB 设备中，这取决于用户的喜好。

游戏更新

游戏可使用 “Update files”进行更新。 如果存在更新，在游戏启动之前，系统菜单会提供这些更新进行下载。

在幕后，更新文件像eShop游戏或DLC一样被安装在用户存储空间。 Cafe OS 支持两种类型的更新：替换文件和增量补丁.

网络服务

WiiConnect24一直很有趣，但任天堂后来用一套新的服务取代了它，这套服务归入Nintendo Network品牌。

第一个明显的区别是，为了访问在线服务(包括eShop和多人游戏)，用户必须首先注册一个任天堂网络账户。 然后，这个账户将与之前创建的系统账户配对。

从开发者的角度来看，官方SDK捆绑了与任天堂的认证服务器互动的库。 然后开发商使用认证数据与他们自己的服务器进行互动，并提供他们所提供的任何在线功能。

附带说明一下，任天堂还通过捆绑 Miiverse 等新型应用程序涉足社交媒体服务。 与 Facebook walls类似，Miiverse允许用户发布笔记并评论他们最喜欢的游戏。 为了活跃气氛，这些信息后来会随机出现在系统菜单或支持游戏中。

尽管如此，Miiverse的寿命并不长，它在2017年底关闭了(在我最终设法得到Wii U之后的几个月……).

反盗版和自制游戏

欢迎来到本文的最后一节(并感谢你走到这一步！). 在这里，我们将分析Wii U对黑客的抵御能力如何。 公平地说，没有一款游戏机(在这篇文章系列中) 曾经达到100%的成功率。 然而，游戏机保持 “不可破解”的时间和所需的努力将在某种程度上影响游戏工作室是否会投资于该平台。

说了这么多，让我们继续分析吧!

主要目标

任天堂不得不用各种手段来保证下面三个部件不被破解:

实施保护

首先是：光盘驱动器。

…… 嗯，到目前为止，光驱还没有被破解。

考虑到蓝光驱动器在整个Wii U的生命周期中的低采用率，我推测没有足够的热情来破解驱动器 和/或 深入研究其新的保护方法。 对于好奇的人来说，Wii U的主板现在以类似于Xbox 360驱动器的方式与驱动器进行身份验证，并且从那里开始，所有的通信都是加密的。

这让我们剩下两个目标(IOSU和Cafe OS)，而且，这一次，我们做了大量的研究。

专用硬件

一般来说，IBM 和任天堂采用了许多方法来高效、经济地保护这款游戏机。

首先是关注点分离模型，用于限制 Espresso 和Starbucks之间的硬件访问。 这确保了如果主CPU(Espresso) 被劫持，I/O仍然受到某种保护。 此外，两个CPU都包含一个内存管理单元，可以根据需要伪装物理内存映射.

其次，正如我之前提到的，Espresso和Starbuck都捆绑了自己隐藏的Boot ROMs(分别有16KB和4KB)，所以它们在伸向容易被篡改的外部区域之前，总是准备好一定程度的保护(RSA和AES加密)。 这样一来，所有后续处理的代码都必须加密，而且只能由任天堂编写。

第三，Starbuck在 Latte 中分配了大量内存 以启动其操作系统 (IOSU)，而无需使用外部内存。 这又增加了一层防篡改的保护。

接下来，Starbucks 在其硬件上嵌入了SHA-1和AES-128运算器，能够在不影响性能的情况下对数据进行散列、加密和解密。

让我们继续，虽然Starbuck在技术上是一个过时的ARM9 CPU，但任天堂用一个定制的eXecute Never(XN) 控制器对它进行了增强，该控制器限制了Starbuck 可以在哪些内存位置执行代码[43]。 XN单元履行了NX bit的作用。

最后，加密密钥和证书存储在 Latte 内部的OTP 内存 中，Espresso 和 Starbuck 都可以在完成每个条目后立即密封访问。

信任链

与任何涉及签名和加密的软件一样，签名必须有可靠的等级。

从Espresso方面来看，主核心总是在空白状态下启动，但只要它执行完Boot ROM，它就只运行Ancast images(fail0overflow的命名法) 形式的二进制文件。 Ancast images包含一个由任天堂使用RSA-2048私钥(只有任天堂知道) 签名的头，其有效载荷 (实际程序) 是用AES-128密钥签名。 OTP单元为Espresso提供了解密Cafe OS内核的AES密钥(Espresso在Wii U模式下的起点). 之后，由 Cafe OS 执行安全模型。

另一方面，Starbuck在Boot ROM之后的引导程序阶段使用Ancast image格式。 在IOSU加载并运行后，它的一个名为IOS-MCP的内核模块负责验证和解密AES密钥。 之后，加密的Ancast image和AES密钥被上传到MEM2，以便Espresso完成解密，最后执行有效载荷。

Wii 模式下的应用程序具有相同的性质，Espresso 提供了一个单独的密钥来解密Wii 系统菜单 或NAND 启动程序 [44]，从而使 Espresso 能够在不降低其安全性的情况下执行 Wii 应用程序。 Starbuck还在OTP中提供了两个额外的密钥，分别用于解密cafe2wii(Ancast格式) 和Wii系统更新(作为Wii U更新的一部分安装)

操作系统保护

为了进一步补充信任链，每个操作系统都在其基础上增加了额外的层次。

首先，Cafe OS实现了进程隔离，因此Espresso下的程序不能篡改其它进程的内存空间。

此外，对Cafe OS应用程序的操作是一个复杂的过程，涉及两个CPU和不同的安全机制。 长话短说，为了安装 和/或 启动应用程序，IOS-MCP内核模块负责所有必要的工作[45]。 在安装之前，应用程序的签名(在其头中找到) 与存储在OTP中的相应证书进行核对，从而确保该应用程序已被任天堂批准 (因为他们是证书私钥的唯一拥有者). 之后，应用程序的 title key 使用 OTP 存储的 Wii Common key 解密，这允许 Espresso 稍后执行二进制文件(因为实际程序代码仍然是加密的). 最后，只要应用程序在任何时候被启动，Cafe OS的加载器就会被用来准备执行和链接二进制文件。 尽管如此，IOSU在将签名转移到Espresso之前会再次检查签名。

最后，IOSU知道Espresso的应用程序，并且只根据应用程序的权限授予某些I/O权限。 这意味着像网络浏览器这样的特定应用程序将永远无法访问SD卡。

缺陷

乍一看，Wii U的安全模式看起来更加灵活，并且解决了其前身的许多不足之处。 然而，它并非没有明显的缺陷：

但当然，其中大部分并不是立即发现的 (尤其是在发布当天). 因此，我们现在就来看看不同的安全研究人员和自制软件开发者是如何破解这台主机的。

攻破

攻破Wii U的安全模式是一个缓慢的过程。 然而，它最终成功了，从而为许多类型的自制应用打开了大门。 这场征途充满了长时间的静默, 超级重大的发现, 专注盗版的开发, 不必要的闹剧以及_黄金年代_.

让我们从头开始。

提取密钥

只要设备采用了像AES这样的对称加密模式，黑客设法提取密钥就是一个时间问题。 如果wii出现了这种情况，看，Wii U也跟着发生了。 请记住，一旦你有了密钥，你就可以像任天堂那样对内容进行加密，这样就取消了一层保护。

Image
fail0overflow(Sven，Marcan和Comex) 在第30届混沌通信大会(2013年) 上展示他们的发现。[46]

2013年，在第30届混沌通信大会(Chaos Communication Congress) 期间，fail0overflow发表了大量的发现[47]，不久之后，为其他研究人员和开发人员启动了一个连锁反应。 为了给出一个概述，fail0verflow 指出：

  1. Wii时代的老Broadway和Starlet漏洞仍然在vWii模式下工作。 这使研究人员获得了对 Starbuck的控制权，然后可以利用它来篡改内存 和/或 攻击Espresso。 换句话说，内部存在一个glitcher与snooper。
  2. 一旦Boot ROM完成了对Ancast image的解密，没有任何东西可以验证未加密的数据是否被第三方更改。 因此，通过改变解密的内存(在vWii模式下使用被劫持的Starbuck)，Espresso最终将执行任意代码。 但只是提取了Boot ROM便到此为止了…………
    • 这是fail0verflow的一个起点，它使该小组能够提取系统代码 (目前只在vWii模式下) 用于研究目的。 但这为新发现铺平了道路。 虽然，这并不包括Boot ROM和OTP密钥，因为在任意代码执行之前，访问是被禁用的。
  3. 在 Starbuck 的控制下，在 Espresso 执行其 Boot ROM 时锁定 SREST（软重置）行会导致它陷入无限循环（因为 Boot ROM 在 Espresso 的重置向量中添加了陷阱）。 然而，如果Espresso在Boot ROM执行的最后阶段被软复位 (特别是在刷新缓存之后)，复位向量会指向MEM2中的一个可写位置。 因此，这使得在 Boot ROM 仍然可见的情况下允许执行任意代码。
    • 因此，Boot ROM最终被提取出来(并随后进行研究)。
  4. 仍然和Starbuck有关，如果在比预期更短的脉冲宽度下锁定HREST(硬重置) ，可能会导致Espresso处于不稳定/不可预测的状态，但这可能对黑客有利，因为 Espresso可能会忽略隐藏OTP存储器的指令(其中密钥驻留) 。 此外，在自定义代码的帮助下，这可以转储加密密钥。
    • 有了这个，fail0overflow 设法提取了 Espresso 用来解密二进制文件的 AES 密钥。
  5. Starbuck的Boot ROM (boot0) 在CPU更新寄存器后被隐藏。 但寄存器仍然可以在vWii模式下重新启用。
    • …这允许 fail0verflow 轻松提取Starbuck的Boot ROM。
  6. Wii U 网络浏览器的源代码是公开的(根据 WebKit 的 LGPL 许可)。 那么，项目的提交历史暴露了历史漏洞。 其中一个能够产生堆溢出，导致任意代码执行。
    • 复现这一漏洞使该小组能够在Wii U模式下执行代码，并随后提取Cafe OS用于研究。 此外，这个漏洞环境也与IOSU互动，这导致了下一个发现……
  7. 该团队最终发现了IOSU的一个漏洞，这导致在Wii U模式下以Starbuck的内核权限执行代码。
    • …… 导致Starbuck的加密密钥被提取。

新的可能性

考虑到这是关于Wii U的第一次安全相关演示，所展示的巨大工作量和成就令人惊讶。 有了这个，自制软件开发者现在可以开始尝试对vWii的入口点进行调试。

尽管如此，仍存有一些难点有待解决。 由于Wii U的可执行文件仍然需要有效的RSA签名，因此原生自制仍然是不可能的。 另外，还有系统代码 (即boot2) 有待提取和解密。

无论如何，fail0verflow并没有立即发布他们对Wii U的攻击，因为他们担心这会在自制软件或Linux支持之前导致盗版开发[48]。 然而，他们确实发布了一份编写Wii U代码的指南(包括引入Linux的可能性)。 尽管它提供了在Espresso上重新启用多核的说明，他们的平台仍然依赖vWii，无法访问Cafe OS或整个MEM2[49]。

征服Cafe OS

在fail0verflow的发现之后，全球Wii U黑客领域开始慢慢出现进展，首先是网络浏览器上的漏洞，导致在Cafe OS下以用户权限 (当前) 执行任意代码。

Image
Relys展示他的新Pong游戏在Cafe OS上运行的情况 [50]。

2015年3月 (差不多两年后)，用户Relys发布了第一个在Wii U模式下运行的原生Homebrew应用程序[51]，pong乒乓球游戏的复刻版。 它从一个网络浏览器漏洞启动，接管了UI线程并获得对帧缓冲区的控制。 这个游戏的实现还成功地调用了本地系统例程来绘制屏幕。

反应到总部后，任天堂也开始频繁地进行系统更新，以修补用户的漏洞，使用现在著名的“进一步提高整体系统稳定性”的更新目标。 猫鼠游戏开始了。

Image
以下是一个专门设计用于在Wii U上触发漏洞链的网站示例。该链可能会捆绑一个有效负载以执行一些有用的操作。

此后不久，网页浏览器漏洞下的homebrew开发成了事实上的标准。 在同一个月里，为了便于开发，一个新的开发小组发布了 libwiiu [52], 一个专为网络浏览器漏洞的工具包。 libwiiu 依靠devKitPro 编译套件并提供额外的 CafeOS 头文件来访问系统功能(只有那些在网页浏览器的用户界面下可用的系统功能)。 最后，他们的工具链自动嵌入了一个带有必要漏洞的有效载荷，并将所有东西打包成随时可以托管的HTML文件。

2015年8月达到了一个新的里程碑：libwiiu团队发布了一个内核漏洞[53]。 这个新发现利用了多线程的竞争条件，在内核锁定一个名为OSDriver的结构之前改变其内容[54]。 这允许相邻的核心能够用数据填满它，并最终上传到内核的内存。 因此，可以在无需强制执行权限的情况下将任意内核调用添加到读取和写入内存。

尽管有了这一切，任天堂却已经在系统版本5.5.0中修补了 OSDriver的漏洞(仅在该内核漏洞公开发表的两天前发布)。 此外，IOSU仍然无法控制(意味着没有任意I/O可使用)。

欺骗 IOSU

对于那些没有更新过5.3.2版本的人(因为5.4.0版本修补了最后一个用户区网络漏洞，5.5.0版本则修复了内核漏洞)，仍有更多的功能需要解锁。 尽管IOSU仍然未被攻克，但三核处理器Espresso现在已经处于用户的控制之下。 因此，通过一些变通的方式，可以让IOSU认为自己正在执行一个应用程序，从而授予更高的权限。

Image
Golden45展示了他的新自制应用程序，使用户能够从SD卡中启动游戏备份 [55]。

在2015年10月，开发者Golden45和Dimok发布了Loadiine [56]。 该应用程序依赖于Espresso内核漏洞，可以从SD卡中运行盗版Wii U游戏。 为了运行Loadiine，它需要从Web浏览器中启动，并使用内核特权来启动官方应用程序。 紧接着，Loadiine 就会进行实时内存篡改，以将程序执行重定向到存储在 SD 卡上的游戏。 最初，只有《任天堂明星大乱斗》可以使用这个方法，之后 Mii 制作也可使用。 无论如何，所有这些内存操作都是为了让 IOSU 认为它仍在运行相同的官方程序，从而授予足够的特权使得盗版游戏可以正常运行。 这种方法不能完全依赖于网络浏览器，因为 IOSU 未赋予其对SD 卡的访问权利。

你现在可能认为，在Loadiine带来与盗版有关的进展后，对自制程序的进一步渴望完全黯然失色了。 然而，在2016年2月，Dimok发布了Homebrew Launcher [57]，这是另一个网页浏览器负载，这一次可以从SD卡启动ELF二进制文件。 在向 Team Twiizers/fail0verflow 的经典自制软件频道致敬的同时，Homebrew Launcher 列出了存储在SD卡上的ELF应用程序，并允许用户按照自己的意愿启动任何应用程序。 这是一个离开了嵌入程序到 HTML 文件的做法，类似于 Loadiine，Homebrew Launcher 通过劫持 Mii Maker来实现。

Image
Homebrew Launcher正在运行中。

现在，对于那些更新到 5.5.0的人，将有一些好消息（在最后）:

总之，5.5.0上的用户现在能够享受最新的自制程序。 事实上，这些漏洞到今天还没有修复。

达到半固化

一旦 homebrew 达到一定的成熟度，总有一个人问……有没有一种方法可以让这一切变得更加简单易懂？ 换句话说，我们能否摆脱对网络浏览器的需求？

嗯，这是一个具有挑战性的任务，因为IOSU仍然在系统菜单上运行任何应用程序之前强制执行代码签名（因此，需要使用网络浏览器和劫持 Mii Maker）。 总而言之，如果没有一个安装非签名频道并能够启动它们的方法，就会回到鸡生蛋 蛋生鸡的问题。

让我们来到2016年， 这对于独立的安全研究是 ”有趣的“ 一年 （以及不必要的戏剧性 [61]…）:

总之，这两个发现直到那年年底才公开发布。 主要原因是大多数作者计划一旦他们制定了合适的最终用户解决方案，就会发布这些发现。为此，他们需要时间来制定解决方案。

关于游戏资源漏洞，smea 还发现与任天堂 DS 游戏在 eShop 上销售的模拟器捆绑在一起 (称为“hachihachi”) 具有动态代码执行权限，而且最重要的是，它的 ROM 解析器容易受到任意代码执行的攻击[62]。 这意味着，通过 IOSU 内核漏洞的帮助，一个人可以修改已购买的 DS 虚拟控制器游戏的资源，这样一旦游戏启动，就可以提供任意代码执行 (就像浏览器被用于那样)。 好吧，这个漏洞利用方法最终在2016年11月发布，名字叫 haxchi。

不久之后，开发者 FIX94 fork 了 haxchi，并把它修改为能使用_脑锻炼_的 PAL 版本[63]，并在随后的几天又添加了更多游戏。 此外， FIX94实现了一个直截了当的 “安装程序”，将一个DS游戏自动转换为 “haxchi launcher”（为普通用户部署haxchi 提供便利）。 安装程序还依赖于由 Hykem 发现的 IOSU userland 漏洞。

如果还不够的话。 这里是另一个发现：Cafe OS的配置文件也可以被改变为启动任何已安装的频道而不是系统菜单。 幸好，DS 游戏也是频道，所以一旦Wii U启动，就可以自动启动haxchi (运行Homebrew)。 所以你看, 这些就被打包为了 冷启动破解。 然而，与 Homebrew 应用不同的是，这将引起一些人的恐慌，因为永久改变 Cafe OS 的启动配置可能导致破坏性的结果！

有趣的是，Haxchi 成了主流的破解方法后，可以看到 脑锻炼 上了 eShop 的销量排行榜，是有趣巧合？

解锁IOSU

现在用户可以在不依赖浏览器的情况下运行自制程序，是否还漏掉什么东西呢？ 好吧，签名检查还是要执行的，因此Starbuck可能还需要调整一下。

在这里， 自定义固件(CFW) 这个古老的术语出现了。 现在我们已经有了IOSU的内核漏洞和所有必需的加密密钥了，现在我们可以强迫Starbuck从SD卡启动一个替代的系统镜像(fw.img)。 这个新的系统可以移除许多‘烦人的东西’，诸如授权和签名检查。 好了，以上就是Wii U自制场景中所谓的‘CFW’。

尽管如此，CFW仍然需要一个启动器，例如一个(带有一套IOSU漏洞的) 自制程序来把Starbuck重启到我们的任意镜像当中去。 这项任务由Dimok和他在2016年10月发布的CFW 启动器 工具来处理[64]。

现在，关于实际使用的CFW，黑客们比如sema发布了一套名为 IOSUHAX 的工具，方便编写定制的 IOSU 固件镜像[65]。

IOSUHAX包含一个著名的工具 ‘重定向NAND’ (redNAND)。 这使得用户可以将NAND中的内容转存为一个镜像文件并存储在SD卡中，然后使Espresso和Starbuck都改为从那里启动。 这个环境的主要优点在于，任何在IOSU或Cafe OS中的改动均不会对NAND中的主系统造成永久的影响。 因此，任何在redNAND中的意外损坏均不会损害主机，这意味着黑客和开发者们可以使用redNAND对系统文件进行随意修改而不必担心会对主机造成不可逆的损伤。 这恰好是另一个能让安全研究人员的生活更轻松一点的工具。

因此，CFW（fw.img形式的文件）在网上陆续出现，每个都提供了不同类型的定制功能，包含移除签名检查甚至增加新的系统调用（与IOSU内核模块互动）以供自制程序使用。 总而言之，它们允许在系统菜单上以‘官方’通道来安装和运行自制程序。

调整Cafe OS

由于运行一个CFW很快变为了破解任意Wii U的首选方法，随后的几年的重点是简化这个过程所需的步骤。

2016年12月，我们看到CFW的开发不再需要fw.img了。 相反，漏洞改变了正在运行中的IOSU和Cafe OS，还禁用了签名检查并增加了新的系统调用。 FIX94的对Haxchi的分支以及Dimok的Mocha自定义固件[66] 就是很好的例子。

此外，在2017年之交，复杂的Wii U homebrew 应用井喷。 举几个例子：

晚些时候（到了2021年）， 开发者“Maschell”发布了一套新的工具，最终将haxchi 套装作为攻击wii的默认工具。 在此期间， Maschell 创建了Mocha CFW的另外一个版本，现在可以从“健康与安全”应用中启动(使用了一种新的方式去篡改游戏资源[71])， 因此不再需要购买脑锻炼或其他的DS游戏。 新的 CFW 套件还发布了一套集成的 API 来帮助开发者执行Cafe OS的插件。 这被包装在一个新的套装/环境下称为 Tiramisu [72]。

Image
新的环境加载器(Tiramisu的一部分) 允许用户在启动系统菜单(或任何其他选择的应用程序) 之前选择特定的补丁和插件集。

现在是故事结束的时候了。 当任天堂显然不再有兴趣继续更新的时候，画面仍在向前推进。 Nintendo Switch已在2017年发布，wiiu已经不值得继续维护了。

这就是全部了，伙计们。

Image
我在2017年夏天买的Wii U，它仍然放在电视下面。

好的，这就是关于 Wii U 的介绍。希望您阅读愉快。

有趣的是，我们可以想象在这段时间里，Wii U 实际上是在与第七代游戏机竞争，而不是即将发布的 PlayStation 4 和 Xbox One 竞争。 这种提前发布的做法让我想起了几年前由世嘉和NEC采用的做法(巧合的是，这两家公司都退出了主机竞争…)。

不管别人怎么说Wii U，我仍然认为它是一个非常棒的“复古”游戏系统，可以通过HDMI玩很多Wii和GameCube游戏。 我承认，这个系统的升级功能略显平庸，但我不需要为_复合_时代编写的游戏追求像素完美。

不管怎么说，既然最后一款基于PowerPC的游戏主机已经结束了，我想我以后会写一些关于基于ARM和x86的游戏主机的文章。不过，我也很好奇在不久的将来我们是否会看到一款基于RISC-V的游戏主机呢。 谁知道呢？ 无论如何，我都需要像往常一样花一些时间对网站进行维护工作。

下篇文章见！
Rodrigo

参与贡献

这篇文章是 游戏主机架构 系列的一部分。如果您觉得我的文章很有趣，请考虑捐赠。您的资助将用于购买工具和资源，以帮助我提高现有文章和即将发表的文章的质量。

Donate with PayPal
Become a Patreon

你也可以购买英语版本的电子书。我会将获得的利润视为捐赠。

Image

特别感谢下列人员的捐助：

- All of the generous eBook readers!
- Adam Obenauf
- Adrian Burgess
- Ahmed al-Hetmi
- Alberto Massidda
- Antonio Bellotta
- Ben Morris
- Bitmap Bureau
- CyberpunkDre
- Daniel Cassidy
- Dudeastic
- Dylan Garrett
- Elizabeth Isley
- Encapsulation
- eurasianwolf
- FoolishFriend
- Grady Haynes
- Gustavo Pezzi
- Hadlee Simons
- Holger Steffen
- James William Jones
- Jason Lizarraga
- Jason Lizarraga
- Josh Enders
- ltlollo
- Luke Wren
- Martin Atkins
- MCE
- Mia
- M Kenny
- Neil Moore
- Nick T.
- Olivier Cahagne
- Owen Christensen
- Pablo Moyano
- Payam Ghoreishi
- petey893
- Sanqui
- Scott Munro
- Simon Breil
- Thomas Finch
- Thomas Peter Berntsen
- Thomas Salter
- Toon Zonneveld

或者，您可以通过 建议更改 或 添加翻译 来提供帮助。

Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-wiiu,
    url = {https://www.copetti.org/writings/consoles/wiiu/},
    title = {Wii U Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2022}
}

or a IEEE style citation:

[1]R. Copetti, "Wii U Architecture - A Practical Analysis", Copetti.org, 2022. [Online]. Available: https://www.copetti.org/writings/consoles/wiiu/. [Accessed: day- month- year].
Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.

来源 / 继续阅读

反盗版

CPU

游戏

图形

I/O

操作系统

影像

Rodrigo Copetti

Rodrigo Copetti

希望你能喜欢这篇文章！如果想了解本文作者的相关信息，点击这里 如果你想支持他，请点击这里

rsslinkedintwittergithub facebookreddit