Suporte a módulos do kernel

Uma imagem genérica de kernel (GKI, na sigla em inglês) pode não conter o suporte necessário ao driver para permitir que um dispositivo ative partições. Para permitir que um dispositivo ative partições e continue a inicialização, o init de primeiro estágio é otimizado para carregar os módulos do kernel presentes em um ramdisk. O ramdisk é dividido em ramdisks genéricos e de fornecedores. Os módulos de kernel do fornecedor são armazenados no ramdisk do fornecedor. A ordem em que os módulos do kernel são carregados é configurável.

Local do módulo

O ramdisk é o sistema de arquivos para init, da primeira etapa e para a imagem recovery/fastbootd em dispositivos A/B e A/B virtual. É um initramfs composto por dois arquivos cpio concatenados pelo bootloader. O primeiro arquivo cpio, armazenado como o ramdisk do fornecedor na partição vendor-boot, contém estes componentes:

  • Módulos de kernel do fornecedor init da primeira etapa, localizados em /lib/modules/.
  • Arquivos de configuração modprobe, localizados em /lib/modules/: modules.dep, modules.softdep, modules.alias, modules.options.
  • Um arquivo modules.load que indica quais módulos carregar durante a inicialização da primeira etapa e em qual ordem, em /lib/modules/.
  • Módulos de kernel de recuperação do fornecedor para dispositivos A/B e A/B virtual em /lib/modules/
  • modules.load.recovery, que indica os módulos a serem carregados e em qual ordem para dispositivos A/B e A/B virtual, em /lib/modules.

O segundo arquivo cpio, fornecido com o GKI como o ramdisk do boot.img e aplicado sobre o primeiro, contém first_stage_init e as bibliotecas de que ele depende.

Carregamento de módulos na inicialização da primeira etapa

O init da primeira etapa começa lendo os arquivos de configuração do modprobe de /lib/modules/ no ramdisk. Em seguida, ele lê a lista de módulos especificados em /lib/modules/modules.load (ou, no caso de recuperação, /lib/modules/modules.load.recovery) e tenta carregar cada um desses módulos em ordem, seguindo a configuração especificada nos arquivos carregados anteriormente. O pedido pode ser desviado para satisfazer dependências obrigatórias ou opcionais.

Suporte a build, inicialização da primeira etapa

Para especificar os módulos do kernel a serem copiados para o cpio do ramdisk do fornecedor, liste-os em BOARD_VENDOR_RAMDISK_KERNEL_MODULES. O build executa depmod nesses módulos e coloca os arquivos de configuração modprobe resultantes no cpio do ramdisk do fornecedor.

O build também cria um arquivo modules.load e o armazena no cpio do ramdisk do fornecedor. Por padrão, ele contém todos os módulos listados em BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Para substituir o conteúdo desse arquivo, use BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, conforme mostrado neste exemplo:

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

Suporte de build, Android completo

Assim como no Android 10 e em versões anteriores, os módulos do kernel listados em BOARD_VENDOR_KERNEL_MODULES são copiados pelo build da plataforma Android para a partição do fornecedor em /vendor/lib/modules. O build da plataforma executa depmod nesses módulos e copia os arquivos de saída depmod para a partição do fornecedor no mesmo local. O mecanismo para carregar módulos do kernel de /vendor continua o mesmo das versões anteriores do Android. Você decide como e quando carregar esses módulos, embora normalmente isso seja feito usando scripts init.rc.

Caracteres curinga e builds de kernel integrados

Os fornecedores que combinam o build do kernel do dispositivo com o build da plataforma Android podem ter um problema ao usar as macros BOARD mencionadas acima para especificar os módulos do kernel a serem copiados para o dispositivo. Se o fornecedor quiser evitar listar módulos do kernel nos arquivos de build da plataforma do dispositivo, ele poderá usar um caractere curinga ($(wildcard device/vendor/mydevice/*.ko). Observe que o caractere curinga não funciona no caso de um build de kernel integrado, porque quando o make é invocado e as macros são expandidas em makefiles, os módulos do kernel não foram criados, então as macros estão vazias.

Para contornar esse problema, o fornecedor pode fazer com que o build do kernel crie um arquivo zip contendo os módulos do kernel a serem copiados em cada partição. Defina o caminho desse arquivo ZIP em BOARD_*_KERNEL_MODULES_ARCHIVE, em que * é o nome da partição (como BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). O build da plataforma Android extrai esse arquivo ZIP para o local apropriado e executa depmod nos módulos.

O arquivo zip do módulo do kernel precisa ter uma regra de criação que garanta que o build da plataforma possa gerar o arquivo quando necessário.

Recuperação

Em versões anteriores do Android, os módulos do kernel necessários para a recuperação eram especificados em BOARD_RECOVERY_KERNEL_MODULES. No Android 12, os módulos do kernel necessários para a recuperação ainda são especificados usando essa macro. No entanto, os módulos do kernel de recuperação são copiados para o cpio do ramdisk do fornecedor, em vez do cpio do ramdisk genérico. Por padrão, todos os módulos do kernel listados em BOARD_RECOVERY_KERNEL_MODULES são carregados durante o init da primeira etapa. Se você quiser carregar apenas um subconjunto desses módulos, especifique o conteúdo desse subconjunto em BOARD_RECOVERY_KERNEL_MODULES_LOAD.

Para saber como criar uma partição de inicialização do fornecedor (que contém o ramdisk do fornecedor mencionado nesta página), consulte Partições de inicialização.