Unterstützung für Kernelmodule

Ein generisches Kernel-Image (Generic 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 von init so erweitert, dass die Kernelmodule auf einer Ramdisk geladen werden. Die Ramdisk ist in generische und Anbieter-Ramdisks unterteilt. Anbieter-Kernelmodule werden auf 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 in /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 gibt die Module an, die für A/B- und Virtual A/B-Geräte in /lib/modules geladen werden sollen, und zwar in der Reihenfolge, in der sie geladen werden sollen.

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-Support, 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 bleibt derselbe wie bei früheren Android-Releases. Sie entscheiden, wie und wann diese Module geladen werden. In der Regel erfolgt dies jedoch über init.rc-Scripts.

Platzhalter und integrierte Kernel-Builds

Anbieter, die ihren Geräte-Kernel-Build mit dem Android-Plattform-Build kombinieren, können Probleme mit den oben genannten BOARD-Makros haben, wenn sie Kernel-Module angeben, die auf das Gerät kopiert werden sollen. Wenn der Anbieter vermeiden möchte, Kernelmodule in den Plattform-Build-Dateien des Geräts aufzulisten, kann er einen Platzhalter ($(wildcard device/vendor/mydevice/*.ko) verwenden. Bei einem integrierten Kernel-Build funktioniert der Platzhalter jedoch nicht, 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 auf 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 die für die Wiederherstellung erforderlichen 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.