Suporte a módulos do kernel

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

Local do módulo

O ramdisk é o sistema de arquivos do init, de primeiro estágio e da imagem de recuperação/fastbootd em dispositivos A/B e virtuais A/B. É um initramfs composto por dois arquivos cpio concatenados por pelo carregador de inicialização. O primeiro arquivo cpio, armazenado como ramdisk do fornecedor na partição de inicialização do fornecedor, contém estes componentes:

  • Módulos de kernel do fornecedor init de primeiro estágio, localizados em /lib/modules/.
  • modprobe arquivos de configuração, 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 do primeiro estágio, e em que ordem, /lib/modules/.
  • Módulos de recuperação de kernel do fornecedor para dispositivos A/B e A/B virtuais, em /lib/modules/
  • modules.load.recovery, que indica os módulos a serem carregados; em que ordem, para dispositivos A/B e A/B virtuais, /lib/modules.

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

Carregamento de módulo no init de primeiro estágio

O init de primeiro estágio começa com a leitura da configuração do modprobe. arquivos de /lib/modules/ no ramdisk. Em seguida, ele lê a lista dos 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 em os arquivos carregados anteriormente. O pedido solicitado pode ser desviado de para que satisfaçam dependências difíceis ou flexíveis.

Suporte a build, init de primeiro estágio

Para especificar os módulos do kernel a serem copiados para o ramdisk cpio do fornecedor, liste eles em BOARD_VENDOR_RAMDISK_KERNEL_MODULES. O build é executado depmod nesses módulos e coloca a configuração modprobe resultante. no ramdisk cpio do fornecedor.

O build também cria um arquivo modules.load e o armazena na fornecedor do ramdisk cpio. Por padrão, ele contém todos os módulos listados em BOARD_VENDOR_RAMDISK_KERNEL_MODULES: Para substituir o conteúdo de nesse 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 a builds, Android completo

Como acontece no Android 10 e nas versões anteriores, os módulos do kernel listados em BOARD_VENDOR_KERNEL_MODULES são copiadas pela plataforma Android na partição do fornecedor em /vendor/lib/modules. A O build da plataforma executa depmod nesses módulos e copia a depmod arquivos de saída na partição do fornecedor ao mesmo o local. O mecanismo para carregar módulos do kernel de /vendor. permanece a mesma de versões anteriores do Android. A decisão é sua como e quando carregar esses módulos, embora normalmente isso seja feito usando init.rc.

Caracteres curinga e builds de kernel integrados

Fornecedores que combinam o build do kernel do dispositivo com o build da plataforma Android pode encontrar 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 que listarem os módulos do kernel nos arquivos de build da plataforma do dispositivo, poderão usar um caractere curinga ($(wildcard device/vendor/mydevice/*.ko). O caractere curinga não funcionam no caso de uma compilação de kernel integrado, porque quando o make é invocado e a são expandidas em makefiles, os módulos do kernel não foram criados, então as macros não estão vazios.

Para contornar esse problema, o fornecedor pode solicitar que o build do kernel crie um arquivo ZIP arquivo 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 deve ter uma regra de criação que garanta que a plataforma build possa gerar o arquivo quando necessário.

Recuperação

Em versões anteriores do Android, os módulos do kernel necessários para recuperação eram especificado em BOARD_RECOVERY_KERNEL_MODULES. No Android 12, os módulos necessários para recuperação ainda não especificada usando essa macro. No entanto, os módulos do kernel de recuperação são copiados o cpio do ramdisk do fornecedor, em vez do cpio genérico do ramdisk. Por padrão, todas módulos do kernel listados em BOARD_RECOVERY_KERNEL_MODULES são carregados durante o init de primeiro estágio. Se você quiser apenas um subconjunto módulos a serem carregados, especifique o conteúdo desses subconjuntos em BOARD_RECOVERY_KERNEL_MODULES_LOAD:

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