RFC-0081：fastboot 启动

RFC-0081：fastboot boot
状态已接受
区域
  • 常规
说明

将基于 Zedboot 的网络启动流程替换为 fastboot 启动
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-03-09
审核日期（年-月-日）2021-03-25

修改此 RFC

修改 RFC 元数据

摘要

本文档建议弃用通过 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 协议。

实现

向后兼容性

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

安全性和隐私权注意事项

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

文档

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

缺点、替代方案和未知因素

缺点是，这会承诺在除已支持 fastboot 的其他 Fuchsia 引导加载程序中支持 fastboot。这意味着，随着新主板在 Fuchsia 中启动，在早期启动期间需要 fastboot 支持。这包括对 Intel NUC（https://fxbug.dev/42137791）上使用的 Gigaboot 启动加载程序以及基于 coreboot 的系统（如 Pixelbook）上 fastboot boot 的支持。

在先技术和参考资料

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