Unterstützung für Kernel-Module

Ein generisches Kernel-Image (GKI) enthält möglicherweise nicht die erforderliche Treiberunterstützung, um einem Gerät das Mounten von Partitionen zu ermöglichen. Um einem Gerät das Mounten von Partitionen und das Fortsetzen des Bootens zu ermöglichen, wird die erste init -Stufe erweitert, um die auf einer Ramdisk vorhandenen Kernel-Module zu laden. Die Ramdisk ist in generische und Hersteller-Ramdisk unterteilt. Kernelmodule des Anbieters werden auf der Ramdisk des Anbieters gespeichert. Die Reihenfolge, in der Kernelmodule geladen werden, ist konfigurierbar.

Modulstandort

Die Ramdisk ist das Dateisystem für init, der ersten Stufe und für das Wiederherstellungs-/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 diese Komponenten:

  • init -Kernelmodule des Anbieters der ersten Stufe, die sich in /lib/modules/ befinden.
  • modprobe Konfigurationsdateien in /lib/modules/ : modules.dep , modules.softdep , modules.alias , modules.options .
  • Eine Datei modules.load , die angibt, welche Module während der ersten Initialisierungsphase in der Reihenfolge geladen werden sollen, in /lib/modules/ .
  • Hersteller-Recovery-Kernel-Module für A/B- und Virtual A/B-Geräte in /lib/modules/
  • modules.load.recovery , das 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 mit dem GKI als Ramdisk von boot.img geliefert und auf das erste angewendet wird, enthält first_stage_init und die Bibliotheken, von denen es abhängt.

Laden des Moduls in der ersten Init-Stufe

Die erste init -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 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 Ramdisk-CPIO des Anbieters 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 im CPIO des Anbieters Ramdisk ab.

Der Build erstellt außerdem eine Datei modules.load und speichert sie im CPIO der Ramdisk des Anbieters. 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, volles Android

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

Platzhalter und integrierte Kernel-Builds

Anbieter, die ihren Gerätekernel-Build mit dem Android-Plattform-Build kombinieren, können bei der Verwendung der oben genannten BOARD Makros auf ein Problem stoßen, um Kernel-Module anzugeben, die auf das Gerät kopiert werden sollen. Wenn der Anbieter die Auflistung von Kernelmodulen in den Plattform-Build-Dateien des Geräts vermeiden möchte, kann er einen Platzhalter ( $(wildcard device/vendor/mydevice/*.ko ) verwenden. Beachten Sie, dass der Platzhalter im Fall eines integrierten nicht funktioniert Kernel-Build, denn wenn make aufgerufen wird und die Makros in Makefiles erweitert werden, wurden die Kernel-Module noch nicht erstellt, 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 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 auf den Modulen aus.

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

Erholung

In früheren Android-Versionen wurden die für die Wiederherstellung erforderlichen Kernelmodule in BOARD_RECOVERY_KERNEL_MODULES angegeben. In Android 11 werden für die Wiederherstellung benötigte Kernel-Module weiterhin über dieses Makro angegeben. Die Wiederherstellungskernelmodule werden jedoch auf das Ramdisk-CPIO des Anbieters und nicht auf das generische Ramdisk-CPIO kopiert. Standardmäßig werden alle in BOARD_RECOVERY_KERNEL_MODULES aufgeführten Kernelmodule während der ersten init -Phase 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 Hersteller-Boot-Partition (die die auf dieser Seite erwähnte Hersteller-Ramdisk enthält) finden Sie unter Boot-Partitionen .