Supporto modulo kernel Ker

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

Posizione del modulo

Il ramdisk è il file system per primo stadio init, e per il recupero / immagine fastbootd su A / B e dispositivi A / B virtuali. E 'un initramfs composte da due cpio che vengono concatenati dal bootloader. Il primo archivio cpio, che è memorizzato come ramdisk del fornitore nella partizione di avvio del fornitore, contiene questi componenti:

  • Prima fase di init vendor kernel moduli, che si trova in /lib/modules/ .
  • modprobe file di configurazione, che si trova in /lib/modules/ : modules.dep , modules.softdep , modules.alias , modules.options .
  • Un modules.load file indica quali moduli caricare durante la prima fase init, e in quale ordine, in /lib/modules/ .
  • I moduli di recupero-kernel vendor, per A / B e dispositivi A / B virtuali, in /lib/modules/
  • modules.load.recovery che indica i moduli di carico, e in quale ordine, per A / B e dispositivi A / B virtuali, in /lib/modules .

Il secondo archivio cpio, che viene fornito con la GKI come ramdisk del boot.img e applicato sulla parte superiore della prima, contiene first_stage_init e le librerie da cui dipende.

Caricamento del modulo nella prima fase di inizializzazione

Prima fase di init inizia con la lettura dei file di configurazione modprobe da /lib/modules/ sul ramdisk. Successivamente, si legge l'elenco dei moduli di cui /lib/modules/modules.load (o nel caso di recupero, /lib/modules/modules.load.recovery ) e tentativi per caricare ciascuna di tali moduli in ordine, seguendo la configurazione specificata nei file precedentemente caricati. L'ordine richiesto può essere deviato da per soddisfare le dipendenze hard o soft.

Supporto per build, inizializzazione della prima fase

Per specificare i moduli del kernel di essere copiati nella cpio fornitore ramdisk, elenco loro in BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Le piste di build depmod su questi moduli e mette i file di configurazione modprobe risultanti nella cpio fornitore ramdisk.

La build crea anche un modules.load di file e lo memorizza nella cpio fornitore ramdisk. Per default contiene tutti i moduli elencati nella BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Per sostituire il contenuto di quel file, uso 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 build, Android completo

Come è il caso in Android 10 e rilascia più bassi, moduli del kernel elencati BOARD_VENDOR_KERNEL_MODULES vengono copiati dal Android costruire la piattaforma nella partizione fornitore a /vendor/lib/modules . Le piste piattaforma di costruzione depmod su questi moduli, e copia i depmod output dei file nella partizione fornitore nella stessa posizione. Il meccanismo di caricamento moduli del kernel da /vendor rimane la stessa come per versioni precedenti di Android. E 'la vostra decisione come e quando caricare questi moduli, anche se in genere questo viene fatto utilizzando init.rc script.

Caratteri jolly e build del kernel integrate

I venditori che uniscono la loro compilazione del kernel dispositivo con Android costruire la piattaforma può incorrere in un problema utilizzando la suddetta BOARD macro per specificare i moduli del kernel da copiare sul dispositivo. Se il venditore vuole evitare di elencare i moduli del kernel nel file piattaforma di costruzione del dispositivo, è possibile utilizzare un carattere jolly ( $(wildcard device/vendor/mydevice/*.ko ). Si noti che il carattere jolly non funziona nel caso di un sistema integrato build del kernel, perché quando viene invocato make e le macro vengono espanse nei makefile, i moduli del kernel non sono stati compilati, quindi le macro sono vuote.

Per aggirare questo problema, il venditore potrebbe chiedere al proprio kernel di creare un archivio zip contenente i moduli del kernel da copiare su ciascuna partizione. Impostare il percorso di quella archivio zip in BOARD_*_KERNEL_MODULES_ARCHIVE dove * è il nome della partizione (come BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). La piattaforma di costruzione Android estrae questo archivio zip nella posizione appropriata e corre depmod sui moduli.

L'archivio zip del modulo kernel dovrebbe avere una regola di creazione che garantisca che la build della piattaforma possa generare l'archivio quando richiesto.

Recupero

In precedenti versioni di Android, i moduli del kernel necessari per il recupero sono stati specificati nel BOARD_RECOVERY_KERNEL_MODULES . In Android 11, i moduli del kernel necessari per il ripristino sono ancora specificati utilizzando questa macro. Tuttavia, i moduli del kernel di ripristino vengono copiati nel ramdisk cpio del fornitore, piuttosto che nel ramdisk cpio generico. Per default tutti i moduli del kernel cui BOARD_RECOVERY_KERNEL_MODULES vengono caricati durante la prima fase init . Se si desidera solo un sottoinsieme di questi moduli da caricare, specificare il contenuto di tale sottoinsieme in BOARD_RECOVERY_KERNEL_MODULES_LOAD .

Per ulteriori informazioni sulla creazione di una partizione di avvio fornitore (che contiene il ramdisk vendor menzionati in questa pagina), vedere Boot partizioni .