RFC-0081：fastboot 启动

摘要

本文档建议弃用通过 Zedboot 的 netsvc 加载 RAM。而是建议将基于 netsvc 的 RAM 加载流程替换为基于 fastboot boot 的流程。

设计初衷

无需加载 netsvc RAM，我们就可以避免 Zedboot 和引导加载程序之间重复此功能。此 RFC 与 RFC Deprecate Zedboot-based paving for provisioning devices 保持一致，旨在逐步采用 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。
• 弃用 Zedboot，如 RFC Deprecate Zedboot-based paving for provisioning devices 中所述。

向后兼容性

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

安全和隐私权注意事项

已解锁的“dev”引导加载程序将支持 fastboot boot。fastboot boot 对已锁定的引导加载程序和已解锁的“正式版”引导加载程序的支持正在考虑中，但未在此 RFC 中定义。

文档

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

缺点、替代方案和未知情况

缺点是，除了已经支持 fastboot 的 Fuchsia 引导加载程序之外，我们还必须承诺在其他 Fuchsia 引导加载程序中支持 fastboot。这意味着，在 Fuchsia 中启动新开发板时，需要在早期启动期间提供 fastboot 支持。这包括对 Intel NUC 上使用的 Gigaboot 引导加载程序 (https://fxbug.dev/42137791) 和 Pixelbook 等基于 coreboot 的系统上的 fastboot boot 的支持。

在先技术和参考文档

Fastboot 是一种成熟的机制，在 Android 设备中使用。