【读书笔记】https://source.android.google.cn/devices/bootloader

https://source.android.google.cn/devices/bootloader
本文主要记录aosp官网关于bootloader的相关资料

Bootloader

A bootloader is a vendor-proprietary image responsible for bringing up the kernel on a device. It guards the device state and is responsible for initializing the Trusted Execution Environment (TEE) and binding >its root of trust.

The bootloader is comprised of many things including splash screen. To start boot, the bootloader may directly flash a new image into an appropriate partition or optionally use recovery to start the reflashing >process that will match how it is done for OTA. Some device manufacturers create multi-part bootloaders and then combine them into a single bootloader.img file. At flash time, the bootloader extracts the >individual bootloaders and flashes them all.

Most importantly, the bootloader verifies the integrity of the boot and recovery partitions before moving execution to the kernel and displays the warnings specified in the section Boot state.

我们目前ATV9是非A/B分区，到 ATV10的时候需要分区调整，应为system-as-root必须要求为A/B分区。
Android10会支持动态分区，即通过支持OTA升级的方式重新分区。

Partition Layout

In Android 10, the root file system is no longer included in ramdisk.img and is instead merged into system.img (that is, system.img is always created as if BOARD_BUILD_SYSTEM_ROOT_IMAGE was set). Devices >launching with Android 10:

Use a system-as-root partition layout (automatically enforced by the build with no options to change the behavior).
Must use a ramdisk, which is required for dm-linear.
Must set BOARD_BUILD_SYSTEM_ROOT_IMAGE to false. This setting is used only to differentiate between devices that use a ramdisk and devices that don't use a ramdisk (and instead mount system.img >directly).

The meaning of a system-as-root configuration differs between Android 9 and Android 10. In an Android 9 system-as-root configuration, BOARD_BUILD_SYSTEM_ROOT_IMAGE is set to true, which forces the build to >merge the root file system into system.img then mount system.img as the root file system (rootfs). This configuration is mandatory for devices launching with Android 9 but is optional for devices upgrading >to Android 9 and for devices running lower versions of Android. In an Android 10 system-as-root configuration, the build always merges $TARGET_SYSTEM_OUT and $TARGET_ROOT_OUT into system.img; this config is >the default behavior for all devices running Android 10.

Android 10 makes further changes to support dynamic partitions, a userspace partitioning system that enables over-the-air (OTA) updates to create, resize, or destroy partitions. As part of this change, the >Linux kernel can no longer mount the logical system partition on devices running Android 10, so this operation is handled by the first stage init.

在Android10中fastboot将从bootloader移动到用户空间，bootloader与recovery可合二为一

Moving Fastboot to User Space

Android 10 adds support for resizable partitions by relocating the fastboot implementation from bootloader to user space. This relocation enables moving the flashing code into a maintainable and testable >common location with only the vendor-specific parts of fastboot implemented by a Hardware Abstraction Layer (HAL).
Unified fastboot and recovery

Because userspace fastboot and recovery are similar, you can merge them into one partition/binary. Advantages include less space use and fewer partitions overall, as well as the ability for fastboot and >recovery to share their kernel and libraries.

To support fastbootd, the bootloader must implement a new boot control block (BCB) command of boot-fastboot. To enter fastbootd mode, bootloader should write boot-fastboot into the command field of the BCB >message and leave the recovery field of BCB unchanged (to enable restart of interrupted recovery tasks). The status, stage, and reserved fields remain unchanged as well. The bootloader is expected to load >and boot into the recovery image upon seeing boot-fastboot in the BCB command. Recovery then parses the BCB message and switches to fastbootd mode.