Unterstützung für Kernelmodule

Ein generisches Kernel-Image (GKI) enthält möglicherweise nicht die erforderliche Treiberunterstützung, damit ein Gerät Partitionen bereitstellen kann. Damit ein Gerät Partitionen einbinden und weiterhin booten kann, wird die erste Phase init so erweitert, dass die Kernelmodule auf einer RAM-Disk geladen werden. Die Ramdisk ist in generische und Anbieter-Ramdisks unterteilt. Anbieter-Kernelmodule werden in der Anbieter-Ramdisk gespeichert. Die Reihenfolge, in der Kernelmodule geladen werden, ist konfigurierbar.

Modulposition

Die Ramdisk ist das Dateisystem für die erste Phase von init, und für das Recovery-/Fastbootd-Image auf A/B- und virtuellen A/B-Geräten. Es handelt sich um 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 die folgenden Komponenten:

  • init-Vendor-Kernelmodule der ersten Phase, die sich in /lib/modules/ befinden.
  • modprobe-Konfigurationsdateien im Verzeichnis /lib/modules/: modules.dep, modules.softdep, modules.alias, modules.options.
  • Eine modules.load-Datei, die angibt, welche Module während der Initialisierung der ersten Phase in /lib/modules/ geladen werden sollen und in welcher Reihenfolge.
  • Anbietermodule für den Recovery-Kernel für A/B- und Virtual A/B-Geräte in /lib/modules/
  • modules.load.recovery, das die zu ladenden Module und ihre Reihenfolge für A/B- und Virtual A/B-Geräte in /lib/modules angibt.

Das zweite CPIO-Archiv, das mit dem GKI als Ramdisk des boot.img bereitgestellt und auf das erste angewendet wird, enthält first_stage_init und die Bibliotheken, von denen es abhängt.

Modulladen in der ersten Phase der Initialisierung

Die erste Phase init beginnt mit dem Lesen der modprobe-Konfigurationsdateien aus /lib/modules/ auf der Ramdisk. Als Nächstes wird die Liste der in /lib/modules/modules.load (oder im Fall der Wiederherstellung in /lib/modules/modules.load.recovery) angegebenen Module gelesen und versucht, jedes dieser Module in der angegebenen Reihenfolge zu laden. Dabei wird die Konfiguration verwendet, die in den zuvor geladenen Dateien angegeben ist. Die angeforderte Reihenfolge kann abweichen, um harten oder weichen Abhängigkeiten gerecht zu werden.

Build-Unterstützung, erste Phase der Initialisierung

Wenn Sie Kernelmodule angeben möchten, die in die Vendor-Ramdisk-CPIO kopiert werden sollen, listen Sie sie in BOARD_VENDOR_RAMDISK_KERNEL_MODULES auf. Beim Build wird depmod für diese Module ausgeführt und die resultierenden modprobe-Konfigurationsdateien werden in das Vendor-Ramdisk-CPIO eingefügt.

Beim Build wird auch eine modules.load-Datei erstellt und im Vendor-Ramdisk-CPIO gespeichert. Standardmäßig enthält es alle in BOARD_VENDOR_RAMDISK_KERNEL_MODULES aufgeführten Module. Um den Inhalt dieser Datei zu überschreiben, verwenden Sie 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, vollständiges Android

Wie bei Android 10 und niedrigeren Versionen werden Kernelmodule, die in BOARD_VENDOR_KERNEL_MODULES aufgeführt sind, vom Android-Plattform-Build in die Anbieterpartition unter /vendor/lib/modules kopiert. Beim Plattform-Build wird depmod für diese Module ausgeführt und die depmod-Ausgabedateien werden an denselben Speicherort in die Anbieterpartition kopiert. Der Mechanismus zum Laden von Kernelmodulen aus /vendor ist derselbe wie bei früheren Android-Versionen. Sie entscheiden, wie und wann Sie diese Module laden. In der Regel erfolgt dies jedoch über init.rc-Scripts.

Platzhalter und integrierte Kernel-Builds

Bei Anbietern, die ihren Geräte-Kernel-Build mit dem Android-Plattform-Build kombinieren, kann es zu Problemen bei der Verwendung der oben genannten BOARD-Makros kommen, um Kernelmodule anzugeben, die auf das Gerät kopiert werden sollen. Wenn der Anbieter vermeiden möchte, dass Kernelmodule in den Plattform-Build-Dateien des Geräts aufgeführt werden, kann er einen Platzhalter ($(wildcard device/vendor/mydevice/*.ko) verwenden. Beachten Sie, dass der Platzhalter bei einem integrierten Kernel-Build nicht funktioniert, da die Kernelmodule noch nicht erstellt wurden, wenn „make“ aufgerufen und die Makros in Makefiles erweitert werden. Die Makros sind also leer.

Um dieses Problem zu umgehen, kann der Anbieter seinen Kernel-Build so konfigurieren, dass ein ZIP-Archiv mit den Kernelmodulen erstellt wird, die in jede Partition kopiert werden sollen. Legen Sie den Pfad des ZIP-Archivs in BOARD_*_KERNEL_MODULES_ARCHIVE fest, wobei * der Name der Partition ist (z. B. BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Beim Erstellen der Android-Plattform wird dieses ZIP-Archiv an den entsprechenden Speicherort extrahiert und depmod für die Module ausgeführt.

Das ZIP-Archiv des Kernelmoduls sollte eine Make-Regel enthalten, die dafür sorgt, dass das Archiv bei Bedarf im Rahmen des Plattform-Builds generiert werden kann.

Recovery

In früheren Android-Versionen wurden die für die Wiederherstellung erforderlichen Kernelmodule in BOARD_RECOVERY_KERNEL_MODULES angegeben. In Android 12 werden für die Wiederherstellung erforderliche Kernelmodule weiterhin mit diesem Makro angegeben. Die Recovery-Kernel-Module werden jedoch in das Vendor-Ramdisk-CPIO und nicht in das generische Ramdisk-CPIO kopiert. Standardmäßig werden alle in BOARD_RECOVERY_KERNEL_MODULES aufgeführten Kernelmodule während der ersten Phase von init geladen. Wenn Sie nur einen Teil dieser Module laden möchten, geben Sie den Inhalt dieses Teils in BOARD_RECOVERY_KERNEL_MODULES_LOAD an.

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