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 ein Gerät zu ermöglichen , Partitionen zu montieren und das Booten fortzusetzen erste Stufe init verbessert wird , um die Kernel - Module auf einer RAM - Disk präsentieren zu laden. Die Ramdisk ist in generische und Vendor-Ramdisks unterteilt. Hersteller-Kernel-Module werden auf der Ramdisk des Herstellers gespeichert. Die Reihenfolge, in der Kernel-Module geladen werden, ist konfigurierbar.

Modulstandort

Der RAM - Disk ist das Dateisystem für die Erststufen- init, und für die Rückgewinnung / fastbootd Bild auf A / B und virtuellen A / B - Geräten. Es ist ein initramfs aus zwei cpio Archiven , die vom Bootloader verketteten erhalten. Das erste cpio-Archiv, das als Vendor-Ramdisk in der Vendor-Boot-Partition gespeichert wird, enthält diese Komponenten:

  • Erste Phase der init - Anbieter Kernel - Module, in /lib/modules/ .
  • modprobe Konfigurationsdateien, in /lib/modules/ : modules.dep , modules.softdep , modules.alias , modules.options .
  • Eine modules.load Datei, welche Module zur Last während der ersten Stufe init angibt, und in welcher Reihenfolge, in /lib/modules/ .
  • Vendor Recovery-Kernel - Module, für die A / B und virtuelle A / B - Geräte, in /lib/modules/
  • modules.load.recovery die die Module zu laden angibt, und in welcher Reihenfolge, für die A / B und virtuelle A / B - Geräte, in /lib/modules .

Das zweite cpio Archiv, das mit dem GKI als RAM - Disk der boot.img und angewandt auf der Oberseite der ersten zugeführt wird, enthält first_stage_init und die Bibliotheken von denen es abhängt.

Modulladen in der ersten Stufe init

Erste Phase der init durch das Lesen der modprobe Konfigurationsdateien aus beginnt /lib/modules/ auf der RAM - Disk. Als nächstes liest die Liste der Module in bestimmten /lib/modules/modules.load (oder im Fall der Genesung, /lib/modules/modules.load.recovery ) und versucht , jedes dieser Module zu laden , um die folgenden Konfiguration in den zuvor geladenen Dateien angegeben. Von der angeforderten Reihenfolge kann abgewichen werden, um harte oder weiche Abhängigkeiten zu erfüllen.

Build-Unterstützung, Initialisierung der ersten Phase

Um Kernelmodule angeben , werden in den Lieferanten Ramdisk cpio kopiert, Liste sie in BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Die Build - Läufe depmod auf diesen Modulen und setzt die resultierenden modprobe Konfigurationsdateien im Lieferanten Ramdisk cpio.

Der Build erstellt auch eine modules.load Datei und speichert sie in der Kreditoren Ramdisk cpio. Standardmäßig enthält es alle Module in aufgelistet BOARD_VENDOR_RAMDISK_KERNEL_MODULES . So überschreiben Sie den Inhalt dieser Datei, Verwendung 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 der Fall 10 in Android und niedrigeren Versionen von Kernel - Modulen in aufgelistet BOARD_VENDOR_KERNEL_MODULES werden von der Android - Plattform zu bauen in die Kreditoren Partition kopiert /vendor/lib/modules . Die Plattform Build läuft depmod auf diesen Modulen und kopiert die depmod Ausgabedateien in die Anbieter - Partition an der gleichen Stelle. Der Mechanismus zum Laden von Kernel - Modulen von /vendor bleibt das gleiche wie bei früheren Versionen von Android war. Es ist deine Entscheidung , wie und wann diese Module zu laden, obwohl dies typischerweise unter Verwendung erfolgt init.rc Skripten.

Wildcards und integrierte Kernel-Builds

Anbieter , die ihr Gerät Kernel Build mit der Android - Plattform zu bauen kombinieren kann zu einem Problem führen die oben genannten mit BOARD Makros Kernel - Module angeben , auf das Gerät kopiert werden. Wenn der Verkäufer wünscht Listing Kernel - Module in die Plattform zu erstellen Dateien zu vermeiden , das Gerät, können sie einen Platzhalter (verwenden $(wildcard device/vendor/mydevice/*.ko - $(wildcard device/vendor/mydevice/*.ko ). Beachten Sie, dass der Platzhalter nicht funktioniert im Falle eines integrierten Kernel-Build, denn wenn make aufgerufen wird und die Makros in Makefiles expandiert werden, wurden die Kernel-Module nicht gebaut, also sind die Makros leer.

Um dieses Problem zu umgehen, kann der Hersteller von seinem Kernel-Build ein ZIP-Archiv erstellen, das die Kernel-Module enthält, die auf jede Partition kopiert werden sollen. Legen Sie den Pfad des Zip - Archiv in BOARD_*_KERNEL_MODULES_ARCHIVE wo * ist der Name der Partition (wie BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). Die Android - Plattform zu bauen extrahiert dieses Zip - Archiv in die entsprechende Stelle und läuft depmod auf den Modulen.

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

Erholung

Aus dem Stand der Android Versionen von Kernel - Modulen für die Wiederherstellung erforderlich wurden in bestimmten BOARD_RECOVERY_KERNEL_MODULES . In Android 11 werden für die Wiederherstellung erforderliche Kernelmodule weiterhin mit diesem Makro angegeben. Die Wiederherstellungs-Kernel-Module werden jedoch auf das Ramdisk-cpio des Herstellers kopiert und nicht auf das generische Ramdisk-cpio. Standardmäßig werden alle Kernel - Module in aufgelistet BOARD_RECOVERY_KERNEL_MODULES werden während der ersten Stufe geladen init . Wenn Sie nur eine Teilmenge dieser Module sollen geladen werden, geben Sie den Inhalt dieser Teilmenge in BOARD_RECOVERY_KERNEL_MODULES_LOAD .

Um zu erfahren , eine Anbieter - Startpartition (die die Anbieter Ramdisk auf dieser Seite erwähnt enthält), siehe Bootpartitionen .