Une image de noyau générique (GKI) peut ne pas contenir la prise en charge du pilote requise pour permettre à un appareil de monter des partitions. Pour permettre à un appareil d'installer des partitions et de continuer à démarrer, le init
de première étape est amélioré pour charger les modules du noyau présents sur un disque RAM. Le ramdisk est divisé en ramdisks génériques et spécifiques au fournisseur. Les modules du noyau du fournisseur sont stockés dans le disque RAM du fournisseur. L'ordre dans lequel les modules du noyau sont chargés est configurable.
Emplacement du module
Le ramdisk est le système de fichiers pour le init,
de première étape et pour l'image recovery/fastbootd sur les appareils A/B et A/B virtuels. Il s'agit d'un initramfs
composé 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 vendor-boot, contient les composants suivants :
- Modules du noyau du fournisseur
init
de première phase, 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 l'initialisation de la première étape, et dans quel ordre, dans/lib/modules/
. - Modules recovery-kernel du fournisseur, pour les appareils A/B et Virtual A/B, dans
/lib/modules/
modules.load.recovery
, qui indique les modules à charger et dans quel ordre pour les appareils A/B et Virtual A/B, dans/lib/modules
.
La deuxième archive cpio, fournie avec le GKI en tant que ramdisk du boot.img et appliquée au-dessus de la première, contient first_stage_init
et les bibliothèques dont il dépend.
Chargement du module lors de l'initialisation de la première phase
La première phase de init
commence par la lecture des fichiers de configuration modprobe à partir de /lib/modules/
sur le disque RAM. Il lit ensuite la liste des modules spécifiés dans /lib/modules/modules.load
(ou dans le cas de la 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. L'ordre demandé peut être modifié pour satisfaire les dépendances strictes ou souples.
Ajout de la compatibilité, init de première phase
Pour spécifier les modules du noyau à copier dans le cpio ramdisk du fournisseur, listez-les dans BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. La compilation exécute depmod
sur ces modules et place les fichiers de configuration modprobe résultants dans le cpio du disque RAM du fournisseur.
La compilation crée également un fichier modules.load
et le stocke dans le cpio du ramdisk du fournisseur. Par défaut, il contient tous les modules listé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
Assistance pour la compilation, Android complet
Comme c'est le cas dans Android 10 et les versions antérieures, les modules du noyau listés dans BOARD_VENDOR_KERNEL_MODULES
sont copiés par la compilation de la plate-forme Android dans la partition du fournisseur à l'adresse /vendor/lib/modules
. La compilation de la plate-forme exécute depmod
sur ces modules et copie les fichiers de sortie depmod
dans la partition du fournisseur au même emplacement. Le mécanisme de chargement des modules du noyau à partir de /vendor
reste le même que pour les versions précédentes d'Android. Vous décidez comment et quand charger ces modules, mais cela se fait généralement à l'aide de scripts init.rc
.
Caractères génériques et builds de kernel intégrés
Les fournisseurs qui combinent la compilation du noyau de leur appareil avec la compilation de la plate-forme Android peuvent rencontrer un problème lors de l'utilisation des macros BOARD
mentionnées ci-dessus pour spécifier les modules du noyau à copier sur l'appareil. Si le fournisseur souhaite éviter de lister les modules du noyau dans les fichiers de compilation de la plate-forme de l'appareil, il peut utiliser un caractère générique ($(wildcard device/vendor/mydevice/*.ko
). Notez que le caractère générique ne fonctionne pas dans le cas d'une compilation de noyau intégrée, car lorsque make est appelé et que les macros sont développées dans les makefiles, les modules du noyau n'ont pas été compilés, de sorte que les macros sont vides.
Pour contourner ce problème, le fournisseur peut demander à la compilation du noyau de créer une archive ZIP 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ù *
correspond au nom de la partition (par exemple, BOARD_VENDOR_KERNEL_MODULES_ARCHIVE
). La compilation de la plate-forme Android extrait cette archive ZIP à l'emplacement approprié et exécute depmod
sur les modules.
L'archive zip du module du noyau doit comporter une règle de compilation qui permet à la compilation de la plate-forme de générer l'archive si nécessaire.
Récupération
Dans les versions précédentes d'Android, les modules du noyau requis pour la récupération étaient spécifiés dans BOARD_RECOVERY_KERNEL_MODULES
. Dans Android 12, les modules du noyau requis pour la récupération sont toujours spécifiés à l'aide de cette macro. Toutefois, les modules du noyau de récupération sont copiés dans le cpio du ramdisk du fournisseur, et non dans le cpio du ramdisk générique. Par défaut, tous les modules du noyau listés dans BOARD_RECOVERY_KERNEL_MODULES
sont chargés lors de la première phase de init
. Si vous ne souhaitez charger qu'un sous-ensemble de ces modules, spécifiez le contenu de ce sous-ensemble dans BOARD_RECOVERY_KERNEL_MODULES_LOAD
.
Documentation associée
Pour savoir comment créer une partition de démarrage du fournisseur (qui contient le disque RAM du fournisseur mentionné sur cette page), consultez Partitions de démarrage.