Un'immagine kernel generica (GKI) può non contenere il supporto driver richiesto per
consentire a un dispositivo di montare le partizioni. Per consentire a un dispositivo di montare le partizioni
per continuare l'avvio, la init
di prima fase viene migliorata per caricare
moduli kernel presenti su un ramdisk. Il ramdisk è suddiviso in categorie generiche
ramdisk del tuo fornitore. I moduli kernel del fornitore sono archiviati nel ramdisk del fornitore. La
l'ordine in cui vengono caricati i moduli kernel è configurabile.
Posizione modulo
Il ramdisk è il file system per la prima fase init,
e per
immagine Recovery/fastbootd su dispositivi A/B e A/B virtuali. È una
initramfs
composto da due archivi cpio che vengono concatenati da
il bootloader. Il primo archivio Cpio, che viene memorizzato come ramdisk del fornitore
nella partizione Vendor-boot, contiene i seguenti componenti:
- Moduli kernel del fornitore
init
di prima fase, situati in/lib/modules/
. modprobe
file di configurazione, situato in/lib/modules/
:modules.dep
modules.softdep
modules.alias
emodules.options
.- Un file
modules.load
che indica quali moduli caricare durante l'inizializzazione della prima fase e in quale ordine,/lib/modules/
. - moduli di recupero del kernel del fornitore, per dispositivi A/B e virtuali A/B, in
/lib/modules/
modules.load.recovery
, che indica i moduli da caricare e in quale ordine, per i dispositivi A/B e A/B virtuali, in/lib/modules
.
Il secondo archivio cpio, fornito con GKI
come ramdisk di boot.img e applicato in alto
contiene first_stage_init
e le librerie da cui dipende.
Caricamento del modulo nell'init della prima fase
La prima fase init
inizia leggendo la configurazione modprobe
i file da /lib/modules/
sul ramdisk. Quindi legge l'elenco
di moduli specificati in /lib/modules/modules.load
(o nel caso
di recupero, /lib/modules/modules.load.recovery
) e tenta di
caricare ognuno di questi moduli in ordine, seguendo la configurazione specificata in
i file caricati in precedenza. L'ordine richiesto potrebbe essere deviato da a
che soddisfino dipendenze hard o soft.
Assistenza per la creazione, init di prima fase
Per specificare i moduli kernel da copiare nella cartella cpio ramdisk del fornitore, elenca
in BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. La build viene eseguita
depmod
su questi moduli e inserisce la configurazione modprobe risultante
nel cpio ramdisk del fornitore.
La build crea anche un file modules.load
e lo archivia nel
cpio di ramdisk del fornitore. Per impostazione predefinita, contiene tutti i moduli elencati in
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Per eseguire l'override dei contenuti
quel file, usa BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
, come mostrato
in questo esempio:
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \ device/vendor/mydevice-kernel/first.ko \ device/vendor/mydevice-kernel/second.ko \ device/vendor/mydevice-kernel/third.ko
Supporto allo sviluppo, versione Android completa
Come nel caso di Android 10 e versioni precedenti, i moduli kernel elencati in
Le BOARD_VENDOR_KERNEL_MODULES
vengono copiate dalla piattaforma Android
nella partizione del fornitore in /vendor/lib/modules
. La
della piattaforma esegue depmod
in questi moduli e copia
depmod
file di output contemporaneamente nella partizione del fornitore
in ogni località. Il meccanismo per caricare i moduli kernel da /vendor
rimane invariato rispetto alle release precedenti di Android. La decisione spetta a te
come e quando caricare questi moduli, anche se in genere questa operazione viene eseguita utilizzando
init.rc
script.
Caratteri jolly e build del kernel integrate
Fornitori che combinano la build del kernel del dispositivo con la build della piattaforma Android
potrebbe verificarsi un problema nell'utilizzo delle macro BOARD
indicate sopra per
e specificare i moduli kernel da copiare sul dispositivo. Se il fornitore vuole evitare
l'elenco dei moduli kernel nei file di build della piattaforma del dispositivo, possono utilizzare un carattere jolly
($(wildcard device/vendor/mydevice/*.ko
) Tieni presente che il carattere jolly non
funzionano nel caso di una build del kernel integrata, perché quando viene richiamato il comando
vengono espanse nei makefile, i moduli kernel non sono stati creati, quindi
sono vuote.
Per aggirare questo problema, il fornitore potrebbe chiedere alla sua build del kernel di creare un file zip
contenente i moduli kernel da copiare su ciascuna partizione.
Imposta il percorso dell'archivio ZIP in BOARD_*_KERNEL_MODULES_ARCHIVE
dove *
è il nome della partizione (ad esempio
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE
). Creazione della piattaforma Android
estrae l'archivio ZIP nella posizione appropriata ed esegue depmod
nei moduli.
L'archivio ZIP dei moduli kernel deve avere una regola make che garantisca che la piattaforma build possono generare l'archivio quando è necessario.
Ripristino
Nelle versioni precedenti di Android, i moduli del kernel richiesti per il ripristino erano
specificato in BOARD_RECOVERY_KERNEL_MODULES
. In Android 12,
i moduli kernel richiesti per il ripristino sono
specificate utilizzando questa macro. Tuttavia, i moduli del kernel di ripristino vengono copiati
la CPU ramdisk cpio del fornitore, anziché la cpio ramdisk generica. Per impostazione predefinita, tutte
i moduli kernel elencati in BOARD_RECOVERY_KERNEL_MODULES
sono stati caricati
durante la prima fase init
. Se vuoi solo un sottoinsieme di questi
moduli da caricare, specifica i contenuti di quel sottoinsieme in
BOARD_RECOVERY_KERNEL_MODULES_LOAD
.
Documentazione correlata
Scopri di più sulla creazione di una partizione di avvio del fornitore (che contiene il nome ramdisk menzionato in questa pagina), consulta Avvio partizioni di memoria.