Supporto dei moduli del kernel

Un'immagine kernel generica (GKI) potrebbe non contenere il supporto driver richiesto per consentire a un dispositivo di montare le partizioni. Per consentire a un dispositivo di montare le partizioni e di continuare l'avvio, la prima fase di init viene migliorata per caricare i moduli del kernel presenti su un ramdisk. Il ramdisk è suddiviso in ramdisk generici e ramdisk del fornitore. I moduli del kernel del fornitore sono archiviati nel ramdisk del fornitore. L'ordine in cui vengono caricati i moduli kernel è configurabile.

Posizione del modulo

Il ramdisk è il file system per init, di primo livello e per l'immagine di 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, memorizzato come ramdisk del fornitore nella partizione vendor-boot, contiene questi componenti:

  • Moduli del kernel del fornitore init di prima fase, che si trovano 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 ripristino del fornitore, per dispositivi A/B e A/B virtuali, 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 sopra il primo, contiene first_stage_init e le librerie da cui dipende.

Caricamento del modulo in init di prima fase

La prima fase di init inizia leggendo i file di configurazione di modprobe da /lib/modules/ sul ramdisk. Successivamente, legge l'elenco dei moduli specificati in /lib/modules/modules.load (o in caso di ripristino, /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 modificato per soddisfare le dipendenze hard o soft.

Build support, first-stage init

Per specificare i moduli del kernel da copiare nel file cpio ramdisk del fornitore, elencali in BOARD_VENDOR_RAMDISK_KERNEL_MODULES. La build viene eseguita depmod su questi moduli e inserisce i file di configurazione modprobe risultanti nel file cpio ramdisk del fornitore.

La build crea anche un file modules.load e lo memorizza nel cpio ramdisk del fornitore. Per impostazione predefinita, contiene tutti i moduli elencati in BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Per ignorare i contenuti di questo 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 per la build, Android completo

Come nelle versioni Android 10 e precedenti, i moduli del kernel elencati in BOARD_VENDOR_KERNEL_MODULES vengono copiati dalla build della piattaforma Android nella partizione del fornitore in /vendor/lib/modules. La compilazione 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 versioni precedenti di Android. Spetta a te decidere come e quando caricare questi moduli, anche se in genere questa operazione viene eseguita utilizzando gli script init.rc.

Caratteri jolly e build del kernel integrati

I fornitori che combinano la build del kernel del dispositivo con la build della piattaforma Android potrebbero riscontrare un problema durante l'utilizzo delle macro BOARD sopra menzionate per specificare i moduli del kernel da copiare sul dispositivo. Se il fornitore vuole evitare di elencare i moduli del 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 nel caso di una build del kernel integrata, perché quando viene richiamato make e le macro vengono espanse nei makefile, i moduli del kernel non sono stati compilati, quindi le macro sono vuote.

Per risolvere questo problema, il fornitore potrebbe creare un archivio zip contenente i moduli del kernel da copiare in 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 build 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 di make che garantisca che la build della piattaforma possa generare l'archivio quando necessario.

Ripristino

Nelle versioni precedenti di Android, i moduli del kernel necessari per il ripristino erano specificati in BOARD_RECOVERY_KERNEL_MODULES. In Android 12, i moduli del kernel necessari per il ripristino sono ancora specificati utilizzando questa macro. Tuttavia, i moduli del kernel di ripristino vengono copiati in vendor ramdisk cpio, anziché in ramdisk cpio generico. Per impostazione predefinita, tutti i moduli del kernel elencati in BOARD_RECOVERY_KERNEL_MODULES vengono caricati durante la prima fase di init. Se vuoi caricare solo un sottoinsieme di questi moduli, specifica i contenuti di questo sottoinsieme in BOARD_RECOVERY_KERNEL_MODULES_LOAD.

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.