Es posible que una imagen genérica del kernel (GKI) no sea compatible con el controlador necesario para permitir que un dispositivo active particiones. Para permitir que un dispositivo active particiones y continúe con el inicio, se mejoró el elemento init
inicial para que cargue los módulos de kernel presentes en un disco RAM. El disco RAM se divide en discos RAM de proveedores y genéricos. Los módulos de kernel del proveedor se almacenan en el disco RAM del proveedor. Puedes configurar el orden en el que se cargan los módulos de kernel.
Ubicación del módulo
El disco RAM es el sistema de archivos para init,
de la primera etapa y para la imagen de recuperación/fastbootd en dispositivos A/B y A/B virtuales. Es un initramfs
compuesto por dos archivos cpio que el cargador de arranque concatena. El primer archivo cpio, que se almacena como el ramdisk del proveedor en la partición vendor-boot, contiene estos componentes:
- Módulos del kernel del proveedor de la primera etapa
init
, ubicados en/lib/modules/
- Archivos de configuración de
modprobe
, ubicados en/lib/modules/
:modules.dep
,modules.softdep
,modules.alias
,modules.options
. - Un archivo
modules.load
que indica qué módulos cargar durante la inicialización de la primera etapa y en qué orden, en/lib/modules/
. - Módulos del kernel de recuperación del proveedor, para dispositivos A/B y A/B virtuales, en
/lib/modules/
modules.load.recovery
, que indica los módulos que se deben cargar y en qué orden para los dispositivos A/B y A/B virtuales, en/lib/modules
.
El segundo archivo cpio, que se proporciona con el GKI como el disco RAM de boot.img y se aplica sobre el primero, contiene first_stage_init
y las bibliotecas de las que depende.
Carga de módulos en la inicialización de primera etapa
La etapa 1 de init
comienza con la lectura de los archivos de configuración de modprobe desde /lib/modules/
en el disco RAM. A continuación, lee la lista de módulos especificados en /lib/modules/modules.load
(o en el caso de recuperación, /lib/modules/modules.load.recovery
) y trata de cargar cada uno de esos módulos en orden, siguiendo la configuración especificada en los archivos cargados anteriormente. Es posible que el orden solicitado se desvíe para satisfacer dependencias obligatorias o no obligatorias.
Compila la compatibilidad, inicialización de primera etapa
Para especificar los módulos del kernel que se copiarán en el cpio del disco RAM del proveedor, enuméralos en BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. La compilación ejecuta depmod
en estos módulos y coloca los archivos de configuración de modprobe resultantes en el cpio del disco RAM del proveedor.
La compilación también crea un archivo modules.load
y lo almacena en el cpio de ramdisk del proveedor. De forma predeterminada, contiene todos los módulos que se enumeran en BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Para anular el contenido de ese archivo, usa BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
, como se muestra en este ejemplo:
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \ device/vendor/mydevice-kernel/first.ko \ device/vendor/mydevice-kernel/second.ko \ device/vendor/mydevice-kernel/third.ko
Asistencia para la compilación, Android completo
Al igual que en Android 10 y versiones anteriores, la compilación de la plataforma de Android copia los módulos del kernel que se enumeran en BOARD_VENDOR_KERNEL_MODULES
en la partición del proveedor en /vendor/lib/modules
. La compilación de la plataforma ejecuta depmod
en estos módulos y copia los archivos de salida de depmod
en la partición del proveedor en la misma ubicación. El mecanismo para cargar módulos del kernel desde /vendor
sigue siendo el mismo que en versiones anteriores de Android. Tú decides cómo y cuándo cargar estos módulos, aunque, por lo general, esto se hace con secuencias de comandos init.rc
.
Comodines y compilaciones de kernel integradas
Los proveedores que combinan la compilación del kernel del dispositivo con la compilación de la plataforma de Android pueden tener problemas para usar las macros BOARD
mencionadas anteriormente para especificar los módulos del kernel que se copiarán en el dispositivo. Si el proveedor desea evitar que se incluyan módulos del kernel en los archivos de compilación de la plataforma del dispositivo, puede usar un comodín ($(wildcard device/vendor/mydevice/*.ko
). Ten en cuenta que el comodín no funciona en el caso de una compilación del kernel integrada, ya que, cuando se invoca make y se expanden las macros en los archivos makefile, los módulos del kernel no se han compilado, por lo que las macros están vacías.
Para solucionar este problema, es posible que la compilación del kernel del proveedor cree un archivo ZIP que contenga los módulos del kernel que se copiarán en cada partición.
Establece la ruta de acceso de ese archivo ZIP en BOARD_*_KERNEL_MODULES_ARCHIVE
, donde *
es el nombre de la partición (como BOARD_VENDOR_KERNEL_MODULES_ARCHIVE
). La compilación de la plataforma Android extrae este archivo ZIP en la ubicación adecuada y ejecuta depmod
en los módulos.
El archivo ZIP del módulo del kernel debe tener una regla de compilación que garantice que la compilación de la plataforma pueda generar el archivo cuando sea necesario.
Recuperación
En versiones anteriores de Android, los módulos del kernel necesarios para la recuperación se especificaban en BOARD_RECOVERY_KERNEL_MODULES
. En Android 12, los módulos del kernel necesarios para la recuperación aún se especifican con esta macro. Sin embargo, los módulos del kernel de recuperación se copian en el cpio del ramdisk del proveedor, en lugar del cpio del ramdisk genérico. De forma predeterminada, todos los módulos del kernel que se enumeran en BOARD_RECOVERY_KERNEL_MODULES
se cargan durante la primera etapa de init
. Si solo deseas cargar un subconjunto de estos módulos, especifica el contenido de ese subconjunto en BOARD_RECOVERY_KERNEL_MODULES_LOAD
.
Documentación relacionada
Para obtener información sobre cómo crear una partición de inicio del proveedor (que contiene el ramdisk del proveedor que se menciona en esta página), consulta Particiones de inicio.