Prise en charge des modules kernel

Une image de noyau générique (GKI) peut ne pas contenir la prise en charge requise du pilote pour permettent à un périphérique d'installer des partitions. Pour permettre à un périphérique d’installer des partitions et pour poursuivre le démarrage, l'init de première étape est améliorée pour charger et les modules du noyau présents sur un ramdisk. Le ramdisk est divisé en trois parties les ramdisks du fournisseur. Les modules de noyau du fournisseur sont stockés dans le ramdisk du fournisseur. La l'ordre de chargement des modules du noyau est configurable.

Emplacement du module

Le ramdisk est le système de fichiers de la première étape init, et une image de récupération/fastbootd sur des appareils A/B et virtuels A/B. Il s'agit d'un initramfs composée de deux archives cpio qui sont concaténées par le bootloader. La première archive cpio, stockée en tant que ramdisk du fournisseur dans la partition du fournisseur-boot, contient les composants suivants:

  • Modules de noyau du fournisseur init de premier niveau, situés dans /lib/modules/
  • Fichiers de configuration modprobe, situés dans /lib/modules/: modules.dep, modules.softdep modules.alias, modules.options.
  • Un fichier modules.load qui indique les modules à charger lors de la première étape de l'initialisation, et dans quel ordre /lib/modules/
  • Les modules de noyau de récupération pour les appareils A/B et virtuels A/B des fournisseurs sont disponibles dans /lib/modules/
  • modules.load.recovery, qui indique les modules à charger ; dans quel ordre, pour les périphériques A/B et A/B virtuels, /lib/modules

La seconde archive CPio, fournie avec l'API GKI, comme ramdisk de boot.img et appliqué sur le contient d'abord first_stage_init et les bibliothèques dont il dépend.

Chargement du module dans la première étape de l'initialisation

La première étape du init commence par la lecture de la configuration modprobe de /lib/modules/ sur le ramdisk. Ensuite, il lit la liste des modules spécifiés dans /lib/modules/modules.load (ou dans le cas de récupération, /lib/modules/modules.load.recovery) et tente de charger chacun de ces modules dans l'ordre, en suivant la configuration spécifiée dans les fichiers précédemment chargés. La commande demandée peut être passée de à pour satisfaire les dépendances dures ou douces.

Prise en charge de la compilation, initialisation de première étape

Pour spécifier les modules du noyau à copier dans le fournisseur ramdisk cpio, listez dans BOARD_VENDOR_RAMDISK_KERNEL_MODULES. La compilation s'exécute depmod sur ces modules et place la configuration modprobe obtenue dans le fournisseur ramdisk cpio.

La compilation crée également un fichier modules.load et le stocke dans le du fournisseur ramdisk cpio. Par défaut, il contient tous les modules répertoriés dans BOARD_VENDOR_RAMDISK_KERNEL_MODULES Pour remplacer le contenu de ce fichier, utilisez BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, comme indiqué dans cet exemple:

BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
    device/vendor/mydevice-kernel/first.ko \
    device/vendor/mydevice-kernel/second.ko \
    device/vendor/mydevice-kernel/third.ko

Prise en charge de la compilation, version complète d'Android

Comme dans Android 10 et versions antérieures, les modules du noyau répertoriés dans Les BOARD_VENDOR_KERNEL_MODULES sont copiés par la plate-forme Android dans la partition des fournisseurs à l'emplacement /vendor/lib/modules. La Platform Build exécute depmod sur ces modules et copie le depmod les fichiers de sortie dans la partition du fournisseur en même temps l'emplacement. Mécanisme de chargement des modules du noyau depuis /vendor reste le même que pour les versions précédentes d'Android. C'est à vous de décider comment et quand charger ces modules, bien que généralement cela se fasse en utilisant init.rc scripts.

Caractères génériques et builds de noyau intégrés

Fournisseurs qui combinent le build du noyau de leur appareil avec le build de la plate-forme Android peut rencontrer un problème en utilisant les macros BOARD mentionnées ci-dessus pour spécifier les modules du noyau à copier sur le périphérique. Si le fournisseur souhaite éviter listant les modules du noyau dans les fichiers de compilation de la plate-forme de l'appareil, ils peuvent utiliser un caractère générique ($(wildcard device/vendor/mydevice/*.ko). Notez que le caractère générique dans le cas d'une compilation de noyau intégrée, car quand make est appelé et que sont développées dans les fichiers makefile, les modules du noyau n'ayant pas été compilés, les macros sont vides.

Pour contourner ce problème, le fournisseur peut demander à son noyau de créer un fichier zip archive contenant les modules du noyau à copier sur chaque partition. Définissez le chemin d'accès de cette archive ZIP dans BOARD_*_KERNEL_MODULES_ARCHIVE. où * est le nom de la partition (par exemple, BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). La version de la plate-forme Android extrait cette archive ZIP dans l'emplacement approprié et exécute depmod. sur les modules.

L'archive zip du module du noyau doit avoir une règle make qui garantit que la plateforme peut générer l'archive si nécessaire.

Récupération

Dans les versions précédentes d'Android, les modules de noyau nécessaires à la récupération étaient spécifié dans BOARD_RECOVERY_KERNEL_MODULES. Sous Android 12, les modules du noyau nécessaires à la récupération spécifiée à l'aide de cette macro. Cependant, les modules du noyau de récupération sont copiés le fournisseur ramdisk cpio, plutôt que le ramdisk cpio générique. Par défaut, tous les modules du noyau répertoriés dans BOARD_RECOVERY_KERNEL_MODULES sont chargés lors de la init de première étape. Si vous ne voulez qu'un sous-ensemble modules à charger, spécifiez le contenu de ce sous-ensemble BOARD_RECOVERY_KERNEL_MODULES_LOAD

Pour en savoir plus sur la création d'une partition de démarrage fournisseur (qui contient le fournisseur ramdisk mentionné sur cette page), consultez Botte partitions.