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 Version 3 des Boot-Image-Headers 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: <ph type="x-smartling-placeholder">- </ph>
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
auf3
oder höher fest.Setzen Sie
BOARD_RAMDISK_USE_LZ4
auftrue
, 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
mitvendor_boot
und allen anbieterspezifischen Liste der OTA-Partitionen auf dem Gerät.Kopieren Sie Ihr Gerät
fstab
in/first_stage_ramdisk
imvendor_boot
und nicht derboot
-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
auf4
. Setzen Sie
BOARD_VENDOR_RAMDISK_FRAGMENTS
auf eine Liste mit Ramdisk des logischen Anbieters. invendor_boot
einzuschließende Fragmentnamen.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 aufmkbootimg
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äreDLKM
, wenn nicht anders angegeben.
So erstellen Sie Wiederherstellungsressourcen als eigenständige recovery
-RAMdisk in vendor_boot
:
- Setzen Sie
BOARD_BOOT_HEADER_VERSION
auf4
. - Setzen Sie
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
auftrue
. - Setzen Sie
BOARD_INCLUDE_RECOVERY_RAMDISK_IN_VENDOR_BOOT
auftrue
. - Dadurch wird ein Ramdisk-Fragment des Anbieters hinzugefügt, dessen
ramdisk_name
recovery
ist undramdisk_type
istVENDOR_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
.