{% set rfcid = “RFC-0075” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
This document proposes deprecating and eventually removing zedboot for device provisioning flows. Instead, replacing the flow via the fastboot based flashing, thereby improving stability and reliability of the device provisioning process.
Zedboot based provisioning or ‘paving’ is commonly used to bootstrap a Fuchsia device. Zedboot is actually an instance of the Zircon kernel with a minimal set of drivers and services.
Fastboot is a mechanism for communicating with bootloaders over USB and Ethernet. It is also used to provision a Fuchsia device. It is commonly referred to as ‘flashing’ a device.
Note: For the remainder of the doc, ‘paving’ is in reference to zedboot, ‘flashing’ is in reference to fastboot.
Zedboot based paving workflows depend on a large amount of the Fuchsia system to work properly, specifically:
These subsystems must be functioning before a paving workflow can be used for provisioning a Fuchsia system. On the other hand, the fastboot protocol is implemented directly in the bootloader and does not require any other dependencies to be able to bootstrap and provision devices with Fuchsia.
Some of the advantages to using fastboot include:
Single step provisioning flows for devices since the device is only required to be in bootloader mode to initiate the flashing process.
A boot server serving over UDP is not required to obtain the assets for provisioning. Only a set of prebuilt image assets are needed.
Compatibility and support across different versions and branches of Fuchsia platform. Avoiding the need for Large Scale Changes that impact developer and platform release processes.
Does not require careful build-time replacement of images to run in the Recovery (R)
partition in Fuchsia devices.
Some of the issues with Zedboot based provisioning are as follows:
Simplifying the provisioning process around ‘fastboot’ has advantages to the developer workflow, consolidates provisioning across all Fuchsia devices, and unblocks changes in low-level areas of the platform such as the storage layer.
Paving requires Zedboot version compatibility between the Fuchsia device and the Host which is executing the paving workflows, as well as FVM format compatibility between the Fuchsia device and the images the Host sends.
These versioning constraints are a significant pain point for developers when FVM and zedboot versions are rolled, especially for developers which may be switching between branches (which also implies the devices are frequently switching between older and newer versions of FVM or Zedboot).
The primary issue arises when developers need to downgrade devices across a Zedboot version boundary; in this case, the developer will need to reinitialize Zedboot on the device first, which either requires re-flashing the device or performing a two-step paving sequence that involves a best-effort repaving of Zedboot itself, ignoring the version mismatch. For the upgrade path, developers opt to use the standard system over the air (OTA) update procedure.
Fastboot also has version compatibility requirements and as additional Fuchsia images or files need to be written as part of the provisioning process the bootloader in some cases must be updated to support the new image format.
However, this format is much simpler and more stable than changes to higher level storage formats (e.g. FVM). Any changes to the bootloader, for example, can be handled by an OTA or a flashing workflow via fastboot. In most cases additional images can be added with no bootloader changes.
fastboot
is officially supported in bootloaders in Fuchsia products. It is used today for provisioning Fuchsia images onto devices.
After going through deprecation phase, Zedboot will be removed from the provisioning workflows and from relevant documentation.
The implementation will follow a deprecation and then migration process. Thus, various scripts and developer tooling that use paving will be:
No performance impact in the system.
Deprecating and removing Zedboot reduces the overall area of concern for Security. Primarily this is the broad attack surface and the level on control available to the operator, including access to the underlying filesystem.
Fastboot has gone through the appropriate security approval process and is approved for use in provisioning Fuchsia production devices.
Like with security, removing Zedboot reduces the area of concern for Privacy, and fastboot is approved for use with production devices.
Fastboot based provisioning is used by developers in Fuchsia today. Appropriate infrastructure in Fuchsia's CI/CQ systems will be requested to add support for Fastboot based provisioning. This ensures the fastboot flows are tested regularly.
Documentation for developer workflows will need to be updated to reflect the new flashing based flows.
The primary drawbacks are deprecating and migration of existing paving scripts and workflows to use flashing.
There also needs to be a commitment to support fastboot in other Fuchsia bootloaders besides U-Boot which has support already. This means, as new boards are brought up in Fuchsia, fastboot support is required during early bringup.
Support for Gigaboot bootloaders on the Intel NUC product is not fully complete but is in progress: https://fxbug.dev/42147743: NUC: support full device flashing.
SeaBIOS is the default bootloader for qemu but there are no paving workflows supported in qemu. Thus, fastboot support is not required.
Coreboot is used for booting Fuchsia on Pixelbook devices. Paving is the only supported provisioning flow for Pixelbook devices. Fastboot can be supported via the use of the depthcharge payload mechanism.
Note: Pixelbook devices are not currently supported in the Fuchsia CI/CQ infrastructure.
The RFC is written with the assumption that the primary workflow is provisioning devices with Fuchsia as the primary operating system. However, for general purpose x64 systems such as the Intel NUC, Zedboot supports setting up partition tables to enable this use case.
Zedboot is also used for the purposes of netbooting (booting devices from the Network).
boot
command that supports local boot of images. This can be to be extended to support a netboot like functionality.The flashing operation wipes the FTL (Flash Translation Layer) state on the device.
mexec
is a flow that allows to soft reboot a system with a new kernel and bootimage. Moving to a fastboot based provisioning flow does not impact this feature.
There is a large amount prior art on devices using Fastboot for provisioning. There are two examples listed below:
Android devices rely completely on fastboot based flows as documented here.
As Android devices go through various upgrades and changes, fastboot based flashing and provisioning provides a consistent developer flow and experience for bootstrapping systems and for restoring systems to factory state.
Linaro is a consortium that funds and promotes various projects around accelerating the product deployment in the Arm ecosystem. Fastboot is the common protocol and method used in provisioning linaro Linux firmwares across various Arm development and prototype boards such as 96boards.