Obsługa modułu jądra

Ogólny obraz jądra (GKI) może nie zawierać wymaganej obsługi sterowników umożliwić urządzeniu podłączanie partycji. Aby umożliwić urządzeniu podłączanie partycji aby można było kontynuować uruchamianie, pierwszy etap init jest ulepszony tak, aby wczytywać oraz moduły jądra systemu operacyjnego. Ramdysk dzieli się na ogólne i na dyskach RAM. Moduły jądra dostawcy są przechowywane w dysku ramdisk dostawcy. kolejność ładowania modułów jądra jest konfigurowalna.

Lokalizacja modułu

Ramdisk to system plików pierwszego etapu init, oraz obraz przywracania/szybki rozruch na urządzeniach A/B i wirtualnych A/B. To initramfs złożone z 2 archiwów cpio, które są połączone przez programu rozruchowego. Pierwsze archiwum cpio, przechowywane jako dysk ramdisk dostawcy. na partycji rozruchowej dostawcy, zawiera te komponenty:

  • Moduły jądra dostawcy init pierwszego etapu znajdujące się w /lib/modules/
  • modprobe plików konfiguracyjnych w lokalizacji /lib/modules/: modules.dep, modules.softdep, modules.alias, modules.options.
  • plik modules.load wskazujący, które moduły mają zostać załadowane; w ich pierwszej kolejności i w jakiej kolejności, /lib/modules/
  • Moduły jądra systemu przywracania dostawców dla urządzeń A/B i wirtualnych A/B w /lib/modules/
  • modules.load.recovery, który wskazuje moduły do wczytania; w określonej kolejności, w przypadku urządzeń A/B i wirtualnych A/B, /lib/modules

Drugie archiwum cpio, dostarczane z interfejsem GKI. jako dysku ramdy strony Boot.img i umieszczonego na niej zawiera element first_stage_init oraz biblioteki, od których zależy.

Moduł ładowany w trakcie inicjowania pierwszego etapu

Pierwszy etap init rozpoczyna się od odczytu konfiguracji modprobe pliki z folderu /lib/modules/ na dysku ramdisk. Następnie odczytuje listę modułów wymienionych w funkcji /lib/modules/modules.load (lub w przypadku odzyskiwania konta, /lib/modules/modules.load.recovery) i próby ładować każdy z modułów w odpowiedniej kolejności, zgodnie z konfiguracją określoną w wcześniej załadowane pliki. Żądane zamówienie może mieć wartość od do lub rozumienia zależności twardych.

Pomoc w tworzeniu, pierwszy etap

Aby określić moduły jądra do skopiowania do procesora Ramdisk dostawcy, wpisz je w BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Kompilacja działa depmod w tych modułach i umieszcza wynikową konfigurację modprobe. w serwerze ramdisk cpio dostawcy.

Kompilacja tworzy również plik modules.load i zapisuje go w cpio ramdisk dostawcy. Domyślnie zawiera on wszystkie moduły wymienione w BOARD_VENDOR_RAMDISK_KERNEL_MODULES Aby zastąpić treść parametru ten plik, użyj funkcji BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, jak pokazano na ilustracji 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

Tak jak w Androidzie 10 i starszych wersjach, moduły jądra wymienione w Aplikacje BOARD_VENDOR_KERNEL_MODULES są kopiowane przez platformę Androida na partycji dostawcy pod adresem /vendor/lib/modules. kompilacja platformy uruchamia w tych modułach depmod i kopiuje depmod – pliki wyjściowe na partycji dostawcy w tym samym czasie lokalizacji. Mechanizm wczytywania modułów jądra z /vendor pozostaje bez zmian co w poprzednich wersjach Androida. Decyzja należy do Ciebie jak i kiedy są ładowane, ale zwykle odbywa się to za pomocą init.rc skryptu.

Symbole wieloznaczne i zintegrowane kompilacje jądra

Dostawcy, którzy połączyli kompilację jądra urządzenia z kompilacją platformy Androida może napotkać problem podczas korzystania z wymienionych powyżej makr BOARD do określ moduły jądra do skopiowania na urządzenie. Jeśli dostawca chce uniknąć wyświetlając listę modułów jądra w plikach kompilacji platformy urządzenia, mogą użyć symbolu wieloznacznego ($(wildcard device/vendor/mydevice/*.ko). Pamiętaj, że symbol wieloznaczny nie działa w przypadku zintegrowanej kompilacji jądra, ponieważ wywołanie metody „pay” po wywołaniu są rozwinięte w pliku Makefile, moduły jądra nie zostały skompilowane, są puste.

Aby obejść ten problem, dostawca może utworzyć plik zip, którego kompilacja jądra systemu które zawiera moduły jądra, które chcesz skopiować na każdą partycję. Ustaw ścieżkę tego archiwum ZIP w BOARD_*_KERNEL_MODULES_ARCHIVE gdzie * to nazwa partycji (na przykład BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Kompilacja platformy Androida rozpakowuje archiwum ZIP w odpowiedniej lokalizacji i uruchamia depmod w modułach.

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

Odzyskanie

We wcześniejszych wersjach Androida moduły jądra wymagane do przywracania były określono w funkcji BOARD_RECOVERY_KERNEL_MODULES. W Androidzie 12 moduły jądra wymagane do przywracania są nadal określone za pomocą tego makra. Moduły jądra przywracania są jednak kopiowane do folderu zamiast ogólnego procesora ramdisk dostawcy. Domyślnie wszystkie wczytano moduły jądra wymienione w BOARD_RECOVERY_KERNEL_MODULES podczas init pierwszego etapu. Jeśli chcesz uzyskać tylko podzbiór tych wartości modułów do załadowania, określ zawartość tego podzbioru w polu BOARD_RECOVERY_KERNEL_MODULES_LOAD

Aby dowiedzieć się, jak utworzyć partycję rozruchową dostawcy (która zawiera dostawcę omawianego na tej stronie programu ramdisk), zobacz Uruchomienie partycje.