Diese Seite wurde von der Cloud Translation API übersetzt.

Anbieter-Bootpartitionen

Mit Android 11 wurde das Konzept des generischen Kernels eingeführt Bild (GKI). Um das Booten eines beliebigen Geräts mit der GKI zu ermöglichen, 11 Geräte können die Boot-Image-Kopfzeile Version 3 verwenden. In Version 3 werden alle anbieterspezifischen Informationen bei der boot Partition erstellt und in eine neue vendor_boot-Partition verschoben. Ein ARM64-Gerät die mit Android 11 auf dem Linux-Kernel 5.4 gestartet werden, die Partition vendor_boot und das aktualisierte Partitionsformat boot, um die Tests mit der Google-KI bestehen.

Android 12-Geräte können Boot-Image-Header-Version 4, das die Aufnahme von Ramdisks mehrerer Anbieter in den vendor_boot unterstützt -Partition an. Ramdisk-Fragmente mehrerer Anbieter werden nacheinander verkettet im Abschnitt „Vendor ramdisk“ des Anbieters. Eine Ramdisk-Tabelle des Anbieters wird verwendet, um Layout des Abschnitts „Vendor ramdisk“ (Anbieter-ramdisk) und die Metadaten der einzelnen anbieter-ramdisk Fragment.

Partitionsstruktur

Die Bootpartition des Anbieters ist mit virtuellem A/B ausgestattet und wird durch Android geschützt. Verifizierter Bootmodus.

Version 3

Die Partition besteht aus einem Header, der Anbieter-RAMdisk und dem Gerätebaum-Blob .

Abschnitt	Anzahl der Seiten
Boot-Header des Anbieters (n Seiten)	`n = (2112 + page_size - 1) / page_size`
Anbieter ramdisk (o Pages)	`o = (vendor_ramdisk_size + page_size - 1) / page_size`
DTB (Seiten)	`p = (dtb_size + page_size - 1) / page_size`

Version 4

Die Partition besteht aus einem Header. alle Ramdisk-Fragmente des Anbieters, verkettet), der Device Tree Blob (DTB) und der Anbieter-Ramdisk-Tabelle.

Abschnitt	Anzahl der Seiten
Boot-Header des Anbieters (n Seiten)	`n = (2128 + page_size - 1) / page_size`
Ramdisk-Fragmente des Anbieters (o-Seiten)	`o = (vendor_ramdisk_size + page_size - 1) / page_size`
DTB (Seiten)	`p = (dtb_size + page_size - 1) / page_size`
Ramdisk-Tabelle des Anbieters (Q-Seiten)	`q = (vendor_ramdisk_table_size + page_size - 1) / page_size`
Bootconfig (r-Seiten)	`r = (bootconfig_size + page_size - 1) / page_size`

Bootheader des Anbieters

Der Inhalt des Anbieter-Bootpartitions-Headers besteht hauptsächlich aus Daten die aus der Vergangenheit Boot-Image-Header. Es enthält auch Informationen zum Anbieter ramdisk.

Version 3

struct vendor_boot_img_hdr_v3
{
#define VENDOR_BOOT_MAGIC_SIZE 8
    uint8_t magic[VENDOR_BOOT_MAGIC_SIZE];
    uint32_t header_version;
    uint32_t page_size;           /* flash page size we assume */

    uint32_t kernel_addr;         /* physical load addr */
    uint32_t ramdisk_addr;        /* physical load addr */

    uint32_t vendor_ramdisk_size; /* size in bytes */

#define VENDOR_BOOT_ARGS_SIZE 2048
    uint8_t cmdline[VENDOR_BOOT_ARGS_SIZE];

    uint32_t tags_addr;           /* physical addr for kernel tags */

#define VENDOR_BOOT_NAME_SIZE 16
    uint8_t name[VENDOR_BOOT_NAME_SIZE]; /* asciiz product name */
    uint32_t header_size;         /* size of vendor boot image header in
                                   * bytes */
    uint32_t dtb_size;            /* size of dtb image */
    uint64_t dtb_addr;            /* physical load address */

};

Version 4

struct vendor_boot_img_hdr_v4
{
#define VENDOR_BOOT_MAGIC_SIZE 8
    uint8_t magic[VENDOR_BOOT_MAGIC_SIZE];
    uint32_t header_version;
    uint32_t page_size;           /* flash page size we assume */

    uint32_t kernel_addr;         /* physical load addr */
    uint32_t ramdisk_addr;        /* physical load addr */

    uint32_t vendor_ramdisk_size; /* size in bytes */

#define VENDOR_BOOT_ARGS_SIZE 2048
    uint8_t cmdline[VENDOR_BOOT_ARGS_SIZE];

    uint32_t tags_addr;           /* physical addr for kernel tags */

#define VENDOR_BOOT_NAME_SIZE 16
    uint8_t name[VENDOR_BOOT_NAME_SIZE]; /* asciiz product name */
    uint32_t header_size;         /* size of vendor boot image header in
                                   * bytes */
    uint32_t dtb_size;            /* size of dtb image */
    uint64_t dtb_addr;            /* physical load address */

    uint32_t vendor_ramdisk_table_size; /* size in bytes for the vendor ramdisk table */
    uint32_t vendor_ramdisk_table_entry_num; /* number of entries in the vendor ramdisk table */
    uint32_t vendor_ramdisk_table_entry_size; /* size in bytes for a vendor ramdisk table entry */
    uint32_t bootconfig_size; /* size in bytes for the bootconfig section */
};

#define VENDOR_RAMDISK_TYPE_NONE 0
#define VENDOR_RAMDISK_TYPE_PLATFORM 1
#define VENDOR_RAMDISK_TYPE_RECOVERY 2
#define VENDOR_RAMDISK_TYPE_DLKM 3

struct vendor_ramdisk_table_entry_v4
{
    uint32_t ramdisk_size; /* size in bytes for the ramdisk image */
    uint32_t ramdisk_offset; /* offset to the ramdisk image in vendor ramdisk section */
    uint32_t ramdisk_type; /* type of the ramdisk */
#define VENDOR_RAMDISK_NAME_SIZE 32
    uint8_t ramdisk_name[VENDOR_RAMDISK_NAME_SIZE]; /* asciiz ramdisk name */

#define VENDOR_RAMDISK_TABLE_ENTRY_BOARD_ID_SIZE 16
    // Hardware identifiers describing the board, soc or platform which this
    // ramdisk is intended to be loaded on.
    uint32_t board_id[VENDOR_RAMDISK_TABLE_ENTRY_BOARD_ID_SIZE];
};

vendor_ramdisk_size ist die Gesamtgröße aller Ramdisk-Fragmente des Anbieters.
ramdisk_type gibt den RAM-Disk-Typ an. Mögliche Werte sind:
- VENDOR_RAMDISK_TYPE_NONE gibt an, dass der Wert nicht angegeben ist.
- VENDOR_RAMDISK_TYPE_PLATFORM-RAMdisks enthalten plattformspezifische Bits. Sie müssen vom Bootloader immer in den Arbeitsspeicher geladen werden.
- VENDOR_RAMDISK_TYPE_RECOVERY RAMdisks enthalten Wiederherstellungsressourcen. Die Bootloader muss diese beim Starten zur Wiederherstellung in den Arbeitsspeicher laden.
- VENDOR_RAMDISK_TYPE_DLKM RAMdisks enthalten einen dynamischen, ladbaren Kernel Module.
ramdisk_name ist der eindeutige Name der Ramdisk.
board_id ist ein Vektor von anbieterdefinierten Hardware-IDs.

Bootloader-Unterstützung

Da die Bootpartition des Anbieters Informationen wie die Flash-Seitengröße, Kernel, Ramdisk-Ladeadressen, DTB selbst). muss der Bootloader sowohl auf Boot- als auch auf Anbieter-Boot zugreifen können. damit genügend Daten für den Startvorgang vorhanden sind.

Der Bootloader muss die generische Ramdisk sofort nach vom Anbieter ramdisk (die Formate CPIO, Gzip und Lz4 unterstützen diese Art von Verkettung). Richten Sie das allgemeine Ramdisk-Image nicht seitenaus und führen Sie keine und dem Ende der Anbieter-RAMdisk im Arbeitsspeicher. Nach dem Beim Dekomprimieren des Kernels wird die verkettete Datei in ein initramfs-, Das Ergebnis ist eine allgemeine Ramdisk-Datei, anbieter-ramdisk-dateistruktur.

Da die generische ramdisk und die anbieter-ramdisk verkettet werden, müssen sie sich im im selben Format. Das GKI-Boot-Image verwendet eine lz4-komprimierte generische Ramdisk. Gerät, das GKI-kompatibel ist, muss eine LZ4-komprimierte Anbieter-Ramdisk verwenden. Die Konfiguration dafür ist unten zu sehen.

Die Bootloader-Anforderungen zur Unterstützung von Bootconfig werden unter Implementieren Bootconfig

Ramdisks von mehreren Anbietern (Version 4)

Bei Boot-Image-Header-Version 4 kann der Bootloader entweder eine Teilmenge oder alle Anbieter-RAMdisks, die während des Bootvorgangs als initramfs geladen werden sollen. Die Die Ramdisk-Tabelle des Anbieters enthält die Metadaten jeder Ramdisk und kann dem bei der Entscheidung, welche Ramdisks geladen werden sollen. Der Bootloader kann entscheiden, um die ausgewählten Ramdisks des Anbieters zu laden, solange die generische Ramdisk zuletzt geladen.

Beispielsweise kann der Bootloader das Laden von Anbieter-RAMdisks des Typs VENDOR_RAMDISK_TYPE_RECOVERY beim normalen Starten, um Ressourcen zu sparen. Anbieter-RAMdisks vom Typ VENDOR_RAMDISK_TYPE_PLATFORM und VENDOR_RAMDISK_TYPE_DLKM werden in den Arbeitsspeicher geladen. Andererseits können Zulieferunternehmen Ramdisks vom Typ VENDOR_RAMDISK_TYPE_PLATFORM, VENDOR_RAMDISK_TYPE_RECOVERY und VENDOR_RAMDISK_TYPE_DLKM werden beim Starten zur Wiederherstellung in den Arbeitsspeicher geladen .

Alternativ kann der Bootloader die Ramdisk-Tabelle des Anbieters ignorieren und den gesamten Ramdisk-Bereich des Anbieters. Dies hat denselben Effekt wie das Laden Die Ramdisk-Fragmente des Anbieters in der Partition vendor_boot.

Build-Support

So implementieren Sie die Bootunterstützung des Anbieters für ein Gerät:

Legen Sie BOARD_BOOT_HEADER_VERSION auf 3 oder höher fest.
Setzen Sie BOARD_RAMDISK_USE_LZ4 auf true, wenn Ihr Gerät GKI-konform ist oder wenn Andernfalls wird eine generische LZ4-komprimierte RAM-Disk verwendet.
Legen Sie für BOARD_VENDOR_BOOTIMAGE_PARTITION_SIZE eine geeignete Größe für Ihr Gerät unter Berücksichtigung der Kernel-Module, die auf dem Anbieter-Rampdisk enthalten sein müssen.
Aktualisieren Sie AB_OTA_PARTITIONS mit vendor_boot und allen anbieterspezifischen Liste der OTA-Partitionen auf dem Gerät.
Kopieren Sie Ihr Gerät fstab in /first_stage_ramdisk im vendor_boot und nicht der boot-Partition. Beispiel: $(LOCAL_PATH)/fstab.hardware:$(TARGET_COPY_OUT_VENDOR_RAMDISK)/first_stage_ramdisk/fstab.$(PRODUCT_PLATFORM)

So fügen Sie mehrere Anbieter-RAMdisks in vendor_boot ein:

Setzen Sie BOARD_BOOT_HEADER_VERSION auf 4.
Setzen Sie BOARD_VENDOR_RAMDISK_FRAGMENTS auf eine Liste mit Ramdisk des logischen Anbieters. in vendor_boot einzuschließende Fragmentnamen.

Wichtig :Unter Android 12 und höher wird die Verwendung von der Name default ist reserviert. Dem Anbieter "ramdisk" den Namen "default" geben Fragmente sind unter keinen Umständen zulässig. Weitere Informationen finden Sie in der Fastboot to Userspace page unter mkbootimg.
Um eine vordefinierte Ramdisk des Anbieters hinzuzufügen, BOARD_VENDOR_RAMDISK_FRAGMENT.$(vendor_ramdisk).PREBUILT zu den vordefinierten Pfad.
Um eine Ramdisk des DLKM-Anbieters hinzuzufügen, BOARD_VENDOR_RAMDISK_FRAGMENT.$(vendor_ramdisk).KERNEL_MODULE_DIRS in den Liste der einzuschließenden Kernelmodulverzeichnisse.
BOARD_VENDOR_RAMDISK_FRAGMENT.$(vendor_ramdisk).MKBOOTIMG_ARGS festlegen auf mkbootimg Argumente. Dies sind die --board_id[0-15] und --ramdisk_type für das Ramdisk-Fragment des Anbieters. Für DLKM-Anbieter-ramdisk: Der Standardwert von --ramdisk_type wäre DLKM, wenn nicht anders angegeben.

So erstellen Sie Wiederherstellungsressourcen als eigenständige recovery-RAMdisk in vendor_boot:

Setzen Sie BOARD_BOOT_HEADER_VERSION auf 4.
Setzen Sie BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT auf true.
Setzen Sie BOARD_INCLUDE_RECOVERY_RAMDISK_IN_VENDOR_BOOT auf true.
Dadurch wird ein Ramdisk-Fragment des Anbieters hinzugefügt, dessen ramdisk_name recovery ist und ramdisk_type ist VENDOR_RAMDISK_TYPE_RECOVERY. Die Ramdisk enthält dann Alle Wiederherstellungsdateien, d. h. Dateien, die unter $(TARGET_RECOVERY_ROOT_OUT)

mkbootimg-Argumente

Argumentation	Beschreibung
`--ramdisk_type`	Der Typ der Ramdisk ist `NONE`, `PLATFORM`, `RECOVERY` oder `DLKM`.
`--board_id[0-15]`	Geben Sie den Vektor `board_id` an. Der Standardwert ist `0`.

Es folgt eine Beispielkonfiguration:

BOARD_KERNEL_MODULE_DIRS := foo bar baz
BOARD_BOOT_HEADER_VERSION := 4
BOARD_VENDOR_RAMDISK_FRAGMENTS := dlkm_foobar
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.KERNEL_MODULE_DIRS := foo bar
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.MKBOOTIMG_ARGS := --board_id0 0xF00BA5 --board_id1 0xC0FFEE

Die resultierende vendor_boot würde zwei Ramdisk-Fragmente von Anbietern enthalten. Die Das erste ist die „Standard“- ramdisk mit dem DLKM-Verzeichnis baz und der restlichen Dateien in $(TARGET_VENDOR_RAMDISK_OUT). Das zweite ist der dlkm_foobar für ramdisk, das die DLKM-Verzeichnisse foo und bar enthält ist der Standardwert für --ramdisk_type DLKM.