Es posible que una imagen de kernel genérica (GKI) no sea compatible con el controlador necesario para
habilitar un dispositivo para activar particiones. Para permitir que un dispositivo active particiones y
Para continuar con el inicio, se mejoró init
de primera etapa para cargar
módulos de kernel presentes en un disco RAM. El disco RAM se divide en unidades
discos RAM del proveedor. Los módulos de kernel del proveedor se almacenan en el disco RAM del proveedor. El
de carga de los módulos de kernel.
Ubicación del módulo
El disco RAM es el sistema de archivos para init,
de primera etapa y para el
de recuperación/fastbootd en dispositivos A/B y A/B virtuales. Es un
initramfs
compuesto por dos archivos cpio que se concatenan por
el bootloader. El primer archivo cpio, que se almacena como el ramdisk del proveedor
en la partición de inicio del proveedor, contiene estos componentes:
- Primera etapa de los módulos de kernel del proveedor
init
, ubicados en/lib/modules/
- Archivos de configuración
modprobe
, ubicados en/lib/modules/
:modules.dep
,modules.softdep
modules.alias
ymodules.options
- Un archivo
modules.load
que indica qué módulos cargar durante el inicio de la primera etapa y en qué orden, en/lib/modules/
- Los módulos de 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 cargarán en qué orden, para dispositivos A/B y A/B virtuales, en/lib/modules
El segundo archivo cpio, que se proporciona con el GKI
como el ramdisk del boot.img y aplicado sobre el archivo
primero, contiene first_stage_init
y las bibliotecas de las que depende.
Carga del módulo en el init de la primera etapa
La primera etapa de init
comienza por leer la configuración de modprobe.
de /lib/modules/
en el ramdisk. Luego, lee la lista
de los módulos especificados en /lib/modules/modules.load
(o en el caso
de recuperación, /lib/modules/modules.load.recovery
) e intenta
cargar cada uno de esos módulos en orden, siguiendo la configuración especificada en
los archivos cargados previamente. Es posible que el pedido solicitado se desvíe de
satisfacen dependencias duras o blandas.
Compatibilidad de compilación, init de primera etapa
Para especificar los módulos de kernel que se copiarán en el ramdisk del proveedor, enumera
en BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. La compilación se ejecuta
depmod
en estos módulos y coloca la configuración de modprobe resultante.
en el ramdisk del proveedor.
La compilación también crea un archivo modules.load
y lo almacena en el
ramdisk del proveedor cpio De forma predeterminada, contiene todos los módulos enumerados 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
Compatibilidad de compilación, Android completo
Como es el caso de Android 10 y versiones anteriores, los módulos de kernel que se enumeran en
Los archivos BOARD_VENDOR_KERNEL_MODULES
se copian en la plataforma de Android.
compilar en la partición del proveedor en /vendor/lib/modules
. El
compilación de la plataforma ejecuta depmod
en estos módulos y copia los
depmod
archivos de salida en la partición del proveedor en la misma
ubicación. El mecanismo para cargar módulos de kernel desde /vendor
sigue siendo el mismo que en las versiones anteriores de Android. Depende de ti
cómo y cuándo cargar los módulos, aunque, por lo general, esto se hace
init.rc
.
Comodines y compilaciones de kernel integrados
Proveedores que combinan la compilación de kernel de su dispositivo con la compilación de la plataforma de Android
puede tener un problema cuando se usan las macros de BOARD
mencionadas anteriormente para
especificar los módulos de kernel que se copiarán en el dispositivo. Si el proveedor desea evitar
los módulos de kernel en los archivos de compilación de la plataforma del dispositivo, se 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 de kernel integrada, ya que, cuando se invoca a Make y
las macros se expanden en archivos makefile, los módulos de kernel no se compilan, por lo que
están vacíos.
Para solucionar este problema, el proveedor puede hacer que su compilación de kernel cree un archivo ZIP
archivo que contiene los módulos de kernel que se copiarán en cada partición.
Establecer 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 de Android
extrae este archivo ZIP en la ubicación adecuada y ejecuta depmod
en los módulos.
El archivo ZIP del módulo de kernel debe tener una regla de Make que garantice que la plataforma build puede generar el archivo cuando sea necesario.
Recuperación
En versiones anteriores de Android, los módulos de kernel necesarios para la recuperación se
especificadas en BOARD_RECOVERY_KERNEL_MODULES
. En Android 12,
los módulos de kernel necesarios para la recuperación
especificada con esta macro. Sin embargo, los módulos de kernel de recuperación se copian en
en lugar del ramdisk cpio del proveedor. De forma predeterminada, todas
se cargaron los módulos de kernel enumerados en BOARD_RECOVERY_KERNEL_MODULES
durante la primera etapa init
. Si solo quieres un subconjunto de estos
los módulos que se cargarán, especifica el contenido de ese subconjunto en
BOARD_RECOVERY_KERNEL_MODULES_LOAD
Documentación relacionada
Para aprender a crear una partición de inicio del proveedor (que contiene el nombre del ramdisk mencionados en esta página), consulta Inicio particiones.