Obsługa modułu jądra

Ogólny obraz jądra (GKI) może nie zawierać wymaganej obsługi sterowników, która umożliwia urządzeniu montowanie partycji. Aby umożliwić urządzeniu montowanie partycji i kontynuowanie uruchamiania, ulepszono etap init w pierwszej fazie, aby wczytywał moduły jądra znajdujące się na dysku RAM. Dysk RAM jest podzielony na ogólny i dostawcy. Moduły jądra dostawcy są przechowywane na dysku RAM dostawcy. Kolejność wczytywania modułów jądra można skonfigurować.

Lokalizacja modułu

Dysk RAM to system plików na potrzeby etapu init, w pierwszej fazie oraz obrazu recovery/fastbootd na urządzeniach A/B i wirtualnych A/B. Jest to initramfs składający się z 2 archiwów cpio, które są łączone przez program rozruchowy. Pierwsze archiwum cpio, które jest przechowywane jako dysk RAM dostawcy w partycji vendor-boot, zawiera te komponenty:

  • Moduły jądra dostawcy na etapie init w pierwszej fazie, znajdujące się w /lib/modules/.
  • Pliki konfiguracyjne modprobe znajdujące się w /lib/modules/: modules.dep, modules.softdep, modules.alias, modules.options.
  • Plik modules.load, który wskazuje, które moduły mają być wczytywane podczas etapu init w pierwszej fazie i w jakiej kolejności, w /lib/modules/.
  • Moduły jądra dostawcy na potrzeby odzyskiwania na urządzeniach A/B i wirtualnych A/B w /lib/modules/
  • modules.load.recovery , który wskazuje moduły do wczytania oraz ich kolejność na urządzeniach A/B i wirtualnych A/B w /lib/modules.

Drugie archiwum cpio, które jest dostarczane z GKI jako dysk RAM boot.img i stosowane na pierwszym, zawiera first_stage_init oraz biblioteki, od których zależy.

Wczytywanie modułów na etapie init w pierwszej fazie

Etap init w pierwszej fazie rozpoczyna się od odczytania plików konfiguracyjnych modprobe z /lib/modules/ na dysku RAM. Następnie odczytuje listę modułów podaną w /lib/modules/modules.load (lub w przypadku odzyskiwania w /lib/modules/modules.load.recovery) i próbuje wczytać każdy z tych modułów w kolejności, zgodnie z konfiguracją podaną w wcześniej wczytanych plikach. Żądana kolejność może zostać zmieniona, aby spełnić zależności twarde lub miękkie.

Obsługa kompilacji, etap init w pierwszej fazie

Aby określić moduły jądra, które mają zostać skopiowane do archiwum cpio dysku RAM dostawcy, wymień je w BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Kompilacja uruchamia depmod w tych modułach i umieszcza wynikowe pliki konfiguracyjne modprobe w archiwum cpio dysku RAM dostawcy.

Kompilacja tworzy też plik modules.load i zapisuje go w archiwum cpio dysku RAM dostawcy. Domyślnie zawiera on wszystkie moduły wymienione w BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Aby zastąpić zawartość tego pliku, użyj BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, jak pokazano w tym przykładzie:

BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
    device/vendor/mydevice-kernel/first.ko \
    device/vendor/mydevice-kernel/second.ko \
    device/vendor/mydevice-kernel/third.ko

Obsługa kompilacji, pełna wersja Androida

Podobnie jak w Androidzie 10 i starszych wersjach, moduły jądra wymienione w BOARD_VENDOR_KERNEL_MODULES są kopiowane przez kompilację platformy Androida do partycji dostawcy w /vendor/lib/modules. Kompilacja platformy uruchamia depmod w tych modułach i kopiuje pliki wyjściowe depmod do partycji dostawcy w tej samej lokalizacji. Mechanizm wczytywania modułów jądra z /vendor pozostaje taki sam jak w poprzednich wersjach Androida. To Ty decydujesz, jak i kiedy wczytać te moduły, chociaż zwykle odbywa się to za pomocą skryptów init.rc.

Symbole wieloznaczne i zintegrowane kompilacje jądra

Dostawcy, którzy łączą kompilację jądra urządzenia z kompilacją platformy Androida, mogą mieć problem z używaniem wspomnianych powyżej makr BOARD do określania modułów jądra, które mają zostać skopiowane na urządzenie. Jeśli dostawca nie chce wymieniać modułów jądra w plikach kompilacji platformy urządzenia, może użyć symbolu wieloznacznego ($(wildcard device/vendor/mydevice/*.ko). Pamiętaj, że symbol wieloznaczny nie działa w przypadku zintegrowanej kompilacji jądra, ponieważ gdy wywoływane jest polecenie make, a makra są rozwijane w plikach makefile, moduły jądra nie zostały jeszcze skompilowane, więc makra są puste.

Aby obejść ten problem, dostawca może utworzyć kompilację jądra, która utworzy archiwum zip zawierające moduły jądra do skopiowania na każdą partycję. Ustaw ścieżkę do tego archiwum zip w BOARD_*_KERNEL_MODULES_ARCHIVE gdzie * to nazwa partycji (np. BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Kompilacja platformy Androida rozpakowuje to archiwum zip w odpowiedniej lokalizacji i uruchamia depmod w modułach.

Archiwum zip modułu jądra powinno mieć regułę make, która zapewnia, że kompilacja platformy może w razie potrzeby wygenerować archiwum.

Regeneracja

W poprzednich wersjach Androida moduły jądra wymagane do odzyskiwania były określane w BOARD_RECOVERY_KERNEL_MODULES. W Androidzie 12 moduły jądra wymagane do odzyskiwania są nadal określane za pomocą tego makra. Moduły jądra odzyskiwania są jednak kopiowane do archiwum cpio dysku RAM dostawcy, a nie do archiwum cpio ogólnego dysku RAM. Domyślnie wszystkie moduły jądra wymienione w BOARD_RECOVERY_KERNEL_MODULES są wczytywane podczas etapu init w pierwszej fazie. Jeśli chcesz wczytać tylko podzbiór tych modułów, określ jego zawartość w BOARD_RECOVERY_KERNEL_MODULES_LOAD.

Aby dowiedzieć się, jak utworzyć partycję rozruchową dostawcy (która zawiera dysk RAM dostawcy wymieniony na tej stronie), przeczytaj artykuł Partycje rozruchowe.