Supporto del modulo kernel

Un'immagine del kernel generica (GKI) potrebbe non contenere il supporto del driver richiesto per consentire a un dispositivo di montare partizioni. Per consentire a un dispositivo di montare partizioni e di continuare l'avvio, la prima fase init è stata 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 nel ramdisk del fornitore. L'ordine in cui vengono caricati i moduli del kernel è configurabile.

Posizione del modulo

Il ramdisk è il filesystem per init, della prima fase e per l'immagine di ripristino/avvio rapido su dispositivi A/B e A/B virtuali. È un initramfs composto da due archivi cpio che vengono concatenati dal bootloader. Il primo archivio cpio, memorizzato come ramdisk del fornitore nella partizione di avvio del fornitore, contiene questi componenti:

  • Moduli del kernel del fornitore init di prima fase, situati in /lib/modules/ .
  • File di configurazione modprobe , situati in /lib/modules/ : modules.dep , modules.softdep , modules.alias , modules.options .
  • Un file modules.load che indica quali moduli caricare durante la prima fase di inizializzazione 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 Virtual A/B, in /lib/modules .

Il secondo archivio cpio, fornito con la GKI come ramdisk di boot.img e applicato sopra al primo, contiene first_stage_init e le librerie da cui dipende.

Caricamento del modulo nella prima fase init

La prima fase 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 il comando configurazione specificata nei file precedentemente caricati. L'ordine richiesto può essere deviato per soddisfare dipendenze hard o soft.

Costruisci supporto, init di prima fase

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

La build crea anche un file modules.load e lo memorizza nel ramdisk cpio del fornitore. Per impostazione predefinita contiene tutti i moduli elencati in BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Per sovrascrivere il contenuto di quel 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 creazione, Android completo

Come nel caso di Android 10 e versioni precedenti, i moduli del kernel elencati in BOARD_VENDOR_KERNEL_MODULES vengono copiati dalla piattaforma Android creata 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 per caricare i moduli del kernel da /vendor rimane lo stesso delle versioni precedenti di Android. Sta a te decidere come e quando caricare questi moduli, anche se in genere ciò viene fatto utilizzando gli script init.rc

Caratteri jolly e build del kernel integrate

I fornitori che combinano la build del kernel del dispositivo con la build della piattaforma Android potrebbero riscontrare problemi utilizzando le macro BOARD sopra menzionate per specificare i moduli del kernel da copiare sul dispositivo. Se il fornitore desidera 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 un integrato kernel build, 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 fornitore potrebbe fare in modo che la build del kernel crei un archivio zip contenente i moduli del kernel da copiare su ciascuna partizione. Imposta il percorso dell'archivio zip in BOARD_*_KERNEL_MODULES_ARCHIVE dove * è il nome della partizione (come 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 kernel dovrebbe avere una regola make che garantisca che la build della piattaforma possa generare l'archivio quando richiesto.

Recupero

Nelle versioni precedenti di Android, i moduli del kernel richiesti per il ripristino erano specificati in BOARD_RECOVERY_KERNEL_MODULES . In Android 11, i moduli del kernel richiesti per il ripristino vengono ancora specificati utilizzando questa macro. Tuttavia, i moduli del kernel di ripristino vengono copiati sul ramdisk cpio del fornitore, anziché sul ramdisk cpio generico. Per impostazione predefinita tutti i moduli del kernel elencati in BOARD_RECOVERY_KERNEL_MODULES vengono caricati durante la prima fase init . Se desideri che venga caricato solo un sottoinsieme di questi moduli, specifica il contenuto di quel 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), vedere Partizioni di avvio .