Kernel-Modul-Unterstützung

Ein generisches Kernel-Image (GKI) enthält möglicherweise nicht die erforderliche Treiberunterstützung, damit ein Gerät Partitionen bereitstellen kann. Um es einem Gerät zu ermöglichen, Partitionen einzuhängen und mit dem Booten fortzufahren, wird First-Stage- init erweitert, um die auf einer Ramdisk vorhandenen Kernel-Module zu laden. Die Ramdisk ist in generische und Hersteller-Ramdisks unterteilt. Anbieter-Kernel-Module werden auf der Anbieter-Ramdisk gespeichert. Die Reihenfolge, in der Kernel-Module geladen werden, ist konfigurierbar.

Modulstandort

Die Ramdisk ist das Dateisystem für die Initialisierung der ersten Stufe und für das Wiederherstellungs-/ init, -Image auf A/B- und virtuellen A/B-Geräten. Es ist ein initramfs , das aus zwei cpio-Archiven besteht, die vom Bootloader verkettet werden. Das erste cpio-Archiv, das als Vendor-Ramdisk in der Vendor-Boot-Partition gespeichert ist, enthält diese Komponenten:

  • Kernel-Module der ersten Stufe des init -Herstellers, die sich in /lib/modules/ befinden.
  • modprobe Konfigurationsdateien, die sich in /lib/modules/ befinden: modules.dep , modules.softdep , modules.alias , modules.options .
  • Eine modules.load -Datei, die angibt, welche Module während der Initialisierung der ersten Phase geladen werden sollen, und in welcher Reihenfolge, in /lib/modules/ .
  • Recovery-Kernel-Module des Anbieters für A/B- und virtuelle A/B-Geräte in /lib/modules/
  • modules.load.recovery , die die zu ladenden Module und deren Reihenfolge für A/B- und virtuelle A/B-Geräte in /lib/modules angibt.

Das zweite cpio-Archiv, das als Ramdisk des boot.img mit der GKI geliefert und auf das erste gelegt wird, enthält first_stage_init und die Bibliotheken, von denen es abhängt.

Laden des Moduls in der Initialisierung der ersten Stufe

init der ersten Stufe beginnt mit dem Lesen der modprobe-Konfigurationsdateien aus /lib/modules/ auf der Ramdisk. Als nächstes liest es die Liste der Module, die in /lib/modules/modules.load (oder im Falle einer Wiederherstellung, /lib/modules/modules.load.recovery ) angegeben sind, und versucht, jedes dieser Module der Reihe nach zu laden, gefolgt von Konfiguration, die in den zuvor geladenen Dateien angegeben ist. Von der angeforderten Reihenfolge kann abgewichen werden, um harte oder weiche Abhängigkeiten zu erfüllen.

Build-Unterstützung, Init der ersten Stufe

Um Kernel-Module anzugeben, die in das Hersteller-Ramdisk-cpio kopiert werden sollen, listen Sie sie in BOARD_VENDOR_RAMDISK_KERNEL_MODULES auf. Der Build führt depmod auf diesen Modulen aus und legt die resultierenden modprobe-Konfigurationsdateien in der Hersteller-Ramdisk cpio ab.

Der Build erstellt auch eine modules.load -Datei und speichert sie auf der Ramdisk cpio des Anbieters. Standardmäßig enthält es alle in BOARD_VENDOR_RAMDISK_KERNEL_MODULES aufgelisteten Module. Um den Inhalt dieser Datei zu überschreiben, verwenden BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD , wie in diesem Beispiel gezeigt:

BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
    device/vendor/mydevice-kernel/first.ko \
    device/vendor/mydevice-kernel/second.ko \
    device/vendor/mydevice-kernel/third.ko

Build-Unterstützung, volles Android

Wie bei Android 10 und niedrigeren Versionen werden die in BOARD_VENDOR_KERNEL_MODULES aufgelisteten Kernelmodule vom Android-Plattform-Build in die Vendor-Partition unter /vendor/lib/modules kopiert. Der Plattform-Build führt depmod auf diesen Modulen aus und kopiert die depmod Ausgabedateien in die Vendor-Partition am selben Speicherort. Der Mechanismus zum Laden von Kernel-Modulen von /vendor bleibt derselbe wie bei früheren Versionen von Android. Es ist Ihre Entscheidung, wie und wann Sie diese Module laden, obwohl dies normalerweise mit init.rc Skripten geschieht.

Wildcards und integrierte Kernel-Builds

Anbieter, die ihren Geräte-Kernel-Build mit dem Android-Plattform-Build kombinieren, können auf ein Problem stoßen, wenn sie die oben erwähnten BOARD -Makros verwenden, um Kernel-Module anzugeben, die auf das Gerät kopiert werden sollen. Wenn der Anbieter vermeiden möchte, Kernel-Module in den Plattform-Build-Dateien des Geräts aufzulisten, kann er einen Platzhalter verwenden ( $(wildcard device/vendor/mydevice/*.ko ). Beachten Sie, dass der Platzhalter im Fall eines integrierten Moduls nicht funktioniert Kernel-Build, denn wenn make aufgerufen wird und die Makros in Makefiles erweitert wurden, wurden die Kernel-Module nicht gebaut, sodass die Makros leer sind.

Um dieses Problem zu umgehen, kann der Hersteller von seinem Kernel-Build ein ZIP-Archiv erstellen lassen, das die Kernel-Module enthält, die auf jede Partition kopiert werden sollen. Legen Sie den Pfad dieses ZIP-Archivs in BOARD_*_KERNEL_MODULES_ARCHIVE wobei * der Name der Partition ist (z. B. BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). Der Android-Plattform-Build extrahiert dieses ZIP-Archiv an den entsprechenden Speicherort und führt depmod auf den Modulen aus.

Das ZIP-Archiv des Kernelmoduls sollte eine Make-Regel haben, die sicherstellt, dass der Plattform-Build das Archiv bei Bedarf generieren kann.

Wiederherstellung

In früheren Android-Versionen wurden die für die Wiederherstellung erforderlichen Kernelmodule in BOARD_RECOVERY_KERNEL_MODULES angegeben. In Android 11 werden Kernel-Module, die für die Wiederherstellung erforderlich sind, immer noch mit diesem Makro angegeben. Allerdings werden die Wiederherstellungs-Kernel-Module auf das Ramdisk-CPIO des Herstellers kopiert und nicht auf das generische Ramdisk-CPIO. Standardmäßig werden alle Kernel-Module, die in BOARD_RECOVERY_KERNEL_MODULES aufgelistet sind, während der ersten Stufe init geladen. Wenn nur eine Teilmenge dieser Module geladen werden soll, geben Sie den Inhalt dieser Teilmenge in BOARD_RECOVERY_KERNEL_MODULES_LOAD an.

Informationen zum Erstellen einer Anbieter-Boot-Partition (die die auf dieser Seite erwähnte Anbieter-Ramdisk enthält) finden Sie unter Boot-Partitionen .