Un'immagine del kernel generica (GKI) potrebbe non contenere il supporto del driver necessario per consentire a un dispositivo di montare le partizioni. Per consentire a un dispositivo di montare le partizioni e
continuare l'avvio, la init
di prima fase viene migliorata per caricare i
moduli del kernel presenti su un ramdisk. Il ramdisk è suddiviso in ramdisk generici e del fornitore. I moduli del kernel del fornitore sono archiviati nella ramdisk del fornitore. L'ordine in cui vengono caricati i moduli del kernel è configurabile.
Posizione del modulo
Il ramdisk è il file system per la prima fase init,
e per l'immagine recovery/fastbootd sui dispositivi A/B e A/B virtuali. Si tratta di un
initramfs
composto da due archivi cpio concatenati dal bootloader. Il primo archivio Cpio, archiviato come ramdisk del fornitore
nella partizione di avvio del fornitore, contiene i seguenti componenti:
- Moduli del kernel del fornitore
init
di primo livello, situati in/lib/modules/
. - File di configurazione
modprobe
, che si trovano in/lib/modules/
:modules.dep
,modules.softdep
,modules.alias
,modules.options
. - Un file
modules.load
che indica quali moduli caricare durante l'inizializzazione della prima fase e in quale ordine in/lib/modules/
. - Moduli del kernel di recupero del fornitore, per i 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 il GKI come ramdisk del file boot.img e applicato sopra il primo, contiene first_stage_init
e le librerie da cui dipende.
Caricamento del modulo nell'init della prima fase
La prima fase di init
inizia leggendo i file di configurazione di modprobe da /lib/modules/
sulla ramdisk. Successivamente, legge l'elenco
di moduli specificati in /lib/modules/modules.load
(o, in caso di recupero, /lib/modules/modules.load.recovery
) e tenta di caricare ciascuno di questi moduli in ordine, seguendo la configurazione specificata nei file caricati in precedenza. L'ordine richiesto potrebbe essere deviato per
soddisfare le dipendenze rigidi o software.
Assistenza per la creazione, init di prima fase
Per specificare i moduli del kernel da copiare nel file cpio del ramdisk del fornitore, elencali in BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. La compilazione viene eseguitadepmod
su questi moduli e i file di configurazione di modprobe risultanti vengono inseriti nel file cpio del ramdisk del fornitore.
La build crea anche un file modules.load
e lo memorizza nella
cpio ramdisk del fornitore. Per impostazione predefinita, contiene tutti i moduli elencati in
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Per eseguire l'override dei contenuti del file, utilizza 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 per le release di Android 10 e versioni precedenti, i moduli del kernel elencati in
BOARD_VENDOR_KERNEL_MODULES
vengono copiati dalla compilazione della piattaforma Android
nella partizione del fornitore in /vendor/lib/modules
. La build della piattaforma esegue depmod
su questi moduli e copia i file di output depmod
nella partizione del fornitore nella stessa posizione. Il meccanismo di caricamento dei moduli del kernel da /vendor
rimane invariato rispetto alle release precedenti di Android. Sta a te decidere come e quando caricare questi moduli, anche se in genere questa operazione viene eseguita utilizzando script init.rc
.
Segnaposto e build del kernel integrate
I fornitori che combinano la build del kernel del dispositivo con la build della piattaforma Android
potrebbero riscontrare un problema con l'utilizzo delle macro BOARD
sopra menzionate per
specificare i moduli del kernel da copiare sul dispositivo. Se il fornitore non desidera elencare i moduli kernel nei file di build della piattaforma del dispositivo, può utilizzare un carattere jolly ($(wildcard device/vendor/mydevice/*.ko
). Tieni presente che il carattere jolly non funziona con una build del kernel integrata, perché quando viene richiamato "make" e le macro vengono espanse nei makefile, i moduli del kernel non sono stati creati, quindi le macro sono vuote.
Per aggirare questo problema, il fornitore potrebbe creare con la build del kernel un'archiviazione zip contenente i moduli del kernel da copiare su ogni partizione.
Imposta il percorso dell'archivio ZIP in BOARD_*_KERNEL_MODULES_ARCHIVE
dove *
è il nome della partizione (ad esempio
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE
). La compilazione della piattaforma Android
estrae questo archivio ZIP nella posizione appropriata ed esegue depmod
sui moduli.
L'archivio ZIP del modulo del kernel deve avere una regola make che garantisca che la compilazione della piattaforma possa generare l'archivio quando necessario.
Ripristino
Nelle release Android precedenti, i moduli del kernel necessari per il recupero erano
specificati in BOARD_RECOVERY_KERNEL_MODULES
. In Android 12,
i moduli del kernel necessari per il recupero sono ancora
specificati utilizzando questa macro. Tuttavia, i moduli del kernel di recupero vengono copiati nel file cpio del ramdisk del fornitore anziché nel file cpio del ramdisk generico. Per impostazione predefinita, tutti i moduli del kernel elencati in BOARD_RECOVERY_KERNEL_MODULES
vengono caricati durante la prima fase init
. Se vuoi che venga caricato solo un sottoinsieme di questi moduli, specifica i contenuti di quel sottoinsieme in BOARD_RECOVERY_KERNEL_MODULES_LOAD
.
Documentazione correlata
Per informazioni sulla creazione di una partizione di avvio del fornitore (che contiene il ramdisk del fornitore menzionato in questa pagina), consulta Partizioni di avvio.