RFC-0081：fastboot 启动

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

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

修改此 RFC

修改 RFC 元数据

摘要

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

实现

向后兼容性

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

安全性和隐私权注意事项

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

文档

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

缺点、替代方案和未知事项

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

在先技术和参考文档

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