Unterstützung für Kernelmodule

Ein generisches Kernel-Image (GKI) enthält möglicherweise nicht die erforderliche Treiberunterstützung für ein Gerät zum Bereitstellen von Partitionen aktivieren. Um einem Gerät das Bereitstellen von Partitionen zu ermöglichen Um den Bootvorgang fortzusetzen, wird init der ersten Phase optimiert, um den Kernelmodule auf einer Ramdisk Die Ramdisk ist in verschiedene anbieter-ramdisks. Die Kernel-Module des Anbieters werden im Anbieter-RAMdisk gespeichert. Die die Reihenfolge, in der Kernelmodule geladen werden, konfigurierbar ist.

Modulstandort

Ramdisk ist das Dateisystem für init, der ersten Phase und für die Wiederherstellungs-/Fastbootd-Image auf A/B- und virtuellen A/B-Geräten. Es ist ein initramfs besteht aus zwei cpio-Archiven, die durch dem Bootloader. Das erste cpio-Archiv, das als Anbieter-RAMdisk gespeichert wird in der Anbieter-Boot-Partition enthält folgende Komponenten:

  • Kernel-Module des Anbieters init der ersten Phase, die sich in /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 geladen werden sollen und in welcher Reihenfolge /lib/modules/.
  • Kernelmodule für die Wiederherstellung von Anbietern für A/B- und virtuelle A/B-Geräte in /lib/modules/
  • modules.load.recovery gibt an, welche Module geladen werden sollen. für A/B- und virtuelle A/B-Geräte. /lib/modules.

Das zweite cpio-Archiv, das mit der GKI bereitgestellt wird als ramdisk von boot.img und auf den enthält first_stage_init und die Bibliotheken, von denen es abhängig ist.

Modul wird in der ersten Initialisierungsphase geladen

init der ersten Phase beginnt mit dem Lesen der Modprobe-Konfiguration Dateien von /lib/modules/ auf der Ramdisk Als Nächstes wird die Liste der Module, die in /lib/modules/modules.load angegeben sind (oder im Fall von der Wiederherstellung, /lib/modules/modules.load.recovery) und versucht, jedes dieser Module der Reihe nach gemäß der im die zuvor geladenen Dateien. Die angeforderte Bestellung kann von bis abweichen. sowohl harte als auch weiche Abhängigkeiten.

Support aufbauen, erste Phase der Initialisierung

Um die Kernelmodule anzugeben, die in den Anbieter "ramdisk cpio" kopiert werden sollen, geben Sie sie in BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Der Build wird ausgeführt depmod für diese Module und fügt die resultierende Modprobe-Konfiguration ein vom Anbieter ramdisk cpio.

Der Build erstellt außerdem eine modules.load-Datei und speichert sie im Anbieter ramdisk cpio. Standardmäßig enthält sie alle Module, die in BOARD_VENDOR_RAMDISK_KERNEL_MODULES Um den Inhalt von verwenden Sie BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, wie im in diesem Beispiel:

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 älteren Releases werden die in den BOARD_VENDOR_KERNEL_MODULES werden von der Android-Plattform kopiert in die Anbieterpartition unter /vendor/lib/modules einbauen. Die Plattform-Build führt depmod auf diesen Modulen aus und kopiert die depmod-Ausgabedateien in die Anbieterpartition Standort. Der Mechanismus zum Laden von Kernelmodulen aus /vendor wie bei früheren Android-Versionen. Die Entscheidung liegt bei Ihnen. wie und wann diese Module geladen werden. init.rc-Scripts.

Platzhalter und integrierte Kernel-Builds

Anbieter, die ihren Geräte-Kernel-Build mit dem Android-Plattform-Build kombinieren kann bei der Verwendung der oben genannten BOARD-Makros zur geben Sie die Kernelmodule an, die auf das Gerät kopiert werden sollen. Wenn das Zulieferunternehmen die Kernelmodule in den Build-Dateien der Geräteplattform befinden, können sie einen Platzhalter verwenden, ($(wildcard device/vendor/mydevice/*.ko) Beachten Sie, dass der Platzhalter funktionieren bei einem integrierten Kernel-Build, denn wenn der Befehl „make“ die Makros in Makefiles erweitert werden, die Kernelmodule nicht erstellt wurden, sodass die Makros sind leer.

Um dieses Problem zu umgehen, lässt der Anbieter möglicherweise eine ZIP-Datei vom Kernel-Build erstellen. Archiv mit den Kernelmodulen, die in jede Partition kopiert werden sollen. Pfad dieses ZIP-Archivs in BOARD_*_KERNEL_MODULES_ARCHIVE festlegen Dabei ist * der Name der Partition (z. B. BOARD_VENDOR_KERNEL_MODULES_ARCHIVE. Entwicklung der Android-Plattform extrahiert dieses ZIP-Archiv an den entsprechenden Speicherort und führt depmod aus. zu den Modulen.

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

Recovery

In früheren Android-Releases waren die für die Wiederherstellung erforderlichen Kernelmodule angegeben in BOARD_RECOVERY_KERNEL_MODULES. In Android 12 Für die Wiederherstellung erforderliche Kernel-Module sind immer noch mit diesem Makro angegeben werden. Die Kernelmodule für die Wiederherstellung werden jedoch vom Anbieter „ramdisk cpio“ und nicht vom generischen „ramdisk cpio“. Standardmäßig alle In BOARD_RECOVERY_KERNEL_MODULES aufgeführte Kernelmodule sind geladen init in der ersten Phase. Wenn Sie nur eine Teilmenge davon zu ladenden Module, geben Sie den Inhalt dieser Teilmenge in BOARD_RECOVERY_KERNEL_MODULES_LOAD

Weitere Informationen zum Erstellen einer Anbieter-Boot-Partition (die den Anbieter enthält von Ramdisk), siehe Boot Partitionen