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 bereitstellen und den Bootvorgang fortsetzen kann, wird die erste Phase von init erweitert, um die Kernelmodule auf einem RAM-Disk zu laden. Das RAM-Disk wird in generische und RAM-Disks von Anbietern unterteilt. Anbieter-Kernelmodule werden im Anbieter-Ramdisk gespeichert. Die Reihenfolge, in der Kernelmodule geladen werden, ist konfigurierbar.

Modulstandort

Das RAM-Disk 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 ist ein initramfs, das aus zwei cpio-Archiven besteht, die vom Bootloader verkettet werden. Das erste CPIO-Archiv, das als Anbieter-Ramdisk in der Anbieter-Boot-Partition gespeichert ist, enthält die folgenden Komponenten:

  • Erste Phase: init-Anbieterkernelmodule unter /lib/modules/
  • modprobe-Konfigurationsdateien, die sich in /lib/modules/ befinden: modules.dep, modules.softdep, modules.alias, modules.options.
  • Eine modules.load-Datei, die angibt, welche Module in der ersten Phase der Initialisierung in /lib/modules/ geladen werden sollen und in welcher Reihenfolge.
  • Wiederherstellungskernelmodule von Anbietern für A/B- und virtuelle A/B-Geräte in /lib/modules/
  • modules.load.recovery, in dem die zu ladenden Module und die Reihenfolge für A/B- und virtuelle A/B-Geräte in /lib/modules angegeben sind.

Das zweite CPIO-Archiv, das mit der GKI als RAM-Disk der boot.img geliefert und über das erste angewendet wird, enthält first_stage_init und die Bibliotheken, von denen es abhängt.

Modulladen in der ersten Phase der Initialisierung

In der ersten Phase von init werden die Modprobe-Konfigurationsdateien aus /lib/modules/ auf dem RAM-Disk gelesen. Als Nächstes wird die Liste der in /lib/modules/modules.load (oder bei der Wiederherstellung in /lib/modules/modules.load.recovery) angegebenen Module gelesen und versucht, jedes dieser Module in der Reihenfolge gemäß der in den zuvor geladenen Dateien angegebenen Konfiguration zu laden. Von der angeforderten Reihenfolge kann abgewichen werden, um harte oder weiche Abhängigkeiten zu erfüllen.

Build-Unterstützung, Erstphase der Initialisierung

Wenn Sie Kernelmodule angeben möchten, die in das CPIO-Ramdisk des Anbieters kopiert werden sollen, listen Sie sie in BOARD_VENDOR_RAMDISK_KERNEL_MODULES auf. Beim Build wird depmod auf diesen Modulen ausgeführt und die resultierenden modprobe-Konfigurationsdateien werden in das cpio-RAM-Disk des Anbieters abgelegt.

Außerdem wird beim Build eine modules.load-Datei erstellt und im RAM-Disk-CPIO des Anbieters gespeichert. Standardmäßig enthält es alle in BOARD_VENDOR_RAMDISK_KERNEL_MODULES aufgeführten Module. Verwenden Sie BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, um den Inhalt dieser Datei zu überschreiben, 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-Support, vollständige Android-Funktionen

Wie bei Android 10 und niedriger werden die in BOARD_VENDOR_KERNEL_MODULES aufgeführten Kernelmodule von der Android-Plattform in die Anbieterpartition unter /vendor/lib/modules kopiert. Der Plattform-Build führt depmod auf diesen Modulen aus und kopiert die depmod-Ausgabedateien in die Anbieterpartition am selben Speicherort. Der Mechanismus zum Laden von Kernelmodulen aus /vendor bleibt unverändert, wie er in früheren Android-Releases der Fall war. Sie entscheiden, wie und wann diese Module geladen werden. Normalerweise geschieht dies mithilfe von init.rc-Scripts.

Platzhalter und integrierte Kernel-Builds

Bei Anbietern, die ihren Geräte-Kernel-Build mit dem Android-Plattform-Build kombinieren, können Probleme auftreten, wenn sie die oben erwähnten BOARD-Makros zur Angabe der Kernelmodule angeben, die auf das Gerät kopiert werden sollen. Wenn der Anbieter Kernelmodule nicht in den Plattform-Builddateien des Geräts auflisten möchte, kann er einen Platzhalter ($(wildcard device/vendor/mydevice/*.ko) verwenden. Der Platzhalter funktioniert jedoch nicht bei einem integrierten Kernel-Build, da die Kernelmodule noch nicht erstellt wurden, wenn „make“ aufgerufen und die Makros in den Makefiles erweitert werden. Die Makros sind also leer.

Um dieses Problem zu umgehen, kann der Anbieter bei der Kernel-Build-Erstellung ein ZIP-Archiv mit den Kernelmodulen erstellen, die auf jede Partition kopiert werden sollen. Legen Sie den Pfad dieses ZIP-Archivs in BOARD_*_KERNEL_MODULES_ARCHIVE fest, 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 für die Module aus.

Das ZIP-Archiv des Kernelmoduls sollte eine Make-Regel haben, die dafür sorgt, dass das Archiv bei Bedarf vom Plattform-Build generiert werden kann.

Wiederherstellung

In früheren Android-Releases 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 Kernel-Module für die Wiederherstellung werden jedoch zum Anbieter ramdisk cpio kopiert und nicht in das generische ramdisk cpio. Standardmäßig werden alle in BOARD_RECOVERY_KERNEL_MODULES aufgeführten Kernelmodule während der ersten Phase von init geladen. Wenn nur ein Teil dieser Module geladen werden soll, geben Sie den Inhalt dieses Teils in BOARD_RECOVERY_KERNEL_MODULES_LOAD an.

Informationen zum Erstellen einer Bootpartition des Anbieters (die das auf dieser Seite erwähnte RAM-Disk des Anbieters enthält) finden Sie unter Bootpartitionen.