RFC-0081：fastboot 启动

RFC-0081：fastboot boot
状态	已接受
领域	常规
说明	将基于 Zedboot 的网络启动流程替换为 fastboot boot
Gerrit 更改	498344
作者	andresoportus@google.com
审核人	amituttam@ boetger@google.com bradenkell@google.com cpu@google.com curtisgalloway@google.com dpursell@google.com raggi@google.com tkilbourn@google.com travisg@google.com alizhang@google.com
提交日期（年-月-日）	2021-03-09
审核日期（年-月-日）	2021-03-25

摘要

本文档提议废弃通过 Zedboot 的 netsvc 加载 RAM。相反，它提议将基于 netsvc 的 RAM 加载流替换为基于 fastboot boot 的流。

设计初衷

如果没有 netsvc RAM 加载，我们可以避免在 Zedboot 和引导加载程序之间重复使用此功能。此 RFC 与 RFC 弃用基于 Zedboot 的预配设备同时围绕使用 fastboot 而不是 Zedboot，从而允许最终废弃和移除 Zedboot。

背景

Netsvc RAM 加载通常用于使用 Zedboot 的启动工作流。不过，支持 fastboot boot 的引导加载程序已经提供了此功能，例如，通过网络加载部署到设备的 build 的 RAM，并通过 USB 提供 RAM 加载。Zedboot 最初只是作为使用引导加载程序的一种简单网络替代方案而开发的，因为 UEFI 引导加载程序在质量方面各不相同，并且在某些情形下 fastboot 不够可靠。对于 Fuchsia 当前支持且正在获得足够出色支持或支持（例如 https://fxbug.dev/42137791）的目标而言，这不是什么问题。在不支持 fastboot 的平台上，系统会提供备用选项，即将 Fuchsia 刷写到 USB 设备并从中启动。

设计

fastboot 是一种成熟的机制，正在 Android 设备中加以使用。支持 Fuchsia 的引导加载程序必须遵循 fastboot 协议。

实现

• 需要更新引导加载程序。例如，需要修改 Gigaboot 以实现 fastboot boot https://fxbug.dev/42137791。
• 需要更新 fx 脚本，以将 fx netboot 用户重定向到 fastboot boot（我们可能需要将这些流程封装在 fx/ffx 辅助命令中，以使其尽可能简单）。
• 基础架构需要转换为 fastboot https://fxbug.dev/42124288。
• 如 RFC Deprecate Zedboot-based paving for configure devices（废弃用于配置设备的基于 Zedboot 的铺路功能）中所述，Zedboot 弃用。

向后兼容性

更新 fx 脚本并移除 Zedboot 后，netsvc 将无法向后兼容。

安全和隐私权注意事项

已解锁的“dev”引导加载程序支持 fastboot boot。我们正在考虑对已锁定的引导加载程序和未锁定的“prod”引导加载程序提供 fastboot boot 支持，但未在本 RFC 中定义。

文档

您需要更新开发者工作流程的文档，以反映基于 fasboot boot 的新流程。

缺点、替代方案和问题

但缺点是，这种做法承诺在除已支持 fastboot 的引导加载程序之外，在其他 Fuchsia 引导加载程序中支持 fastboot。这意味着，随着在 Fuchsia 中启动新开发板，早期启动期间需要支持 fastboot。这包括在 Intel NUC (https://fxbug.dev/42137791) 和基于 coreboot 的系统（如 Pixelbook）上使用 Gigaboot 引导加载程序上的 fastboot boot 的支持。

现有艺术和参考资料

fastboot 是一种成熟的机制，已在 Android 设备中投入使用。