Поддержка модуля ядра

Образ ядра generic (GKI) может не содержать требуемой поддержки драйверов для включения устройства в монтирование разделов. Чтобы включить устройство в монтирование разделов и продолжить загрузку, первый этап init улучшен для загрузки модулей ядра, присутствующих на ramdisk. ramdisk разделен на generic и vendor ramdisk. Модули ядра vendor хранятся в vendor ramdisk. Порядок загрузки модулей ядра можно настраивать.

Расположение модуля

RAM-диск — это файловая система для первой стадии init, и для образа recovery/fastbootd на устройствах A/B и виртуальных устройствах A/B. Это initramfs состоящий из двух архивов cpio, которые объединяются загрузчиком. Первый архив cpio, который хранится как RAM-диск поставщика в разделе vendor-boot, содержит следующие компоненты:

  • Модули ядра поставщика первой стадии init , расположенные в /lib/modules/ .
  • Файлы конфигурации modprobe , расположенные в /lib/modules/ : modules.dep , modules.softdep , modules.alias , modules.options .
  • Файл modules.load , который указывает, какие модули следует загрузить на первом этапе инициализации и в каком порядке, в /lib/modules/ .
  • Модули ядра восстановления поставщика для устройств A/B и виртуальных устройств A/B в /lib/modules/
  • modules.load.recovery , который указывает модули для загрузки и порядок их загрузки для устройств A/B и виртуальных устройств A/B в /lib/modules .

Второй архив cpio, который поставляется вместе с GKI как ramdisk boot.img и применяется поверх первого, содержит first_stage_init и библиотеки, от которых он зависит.

Загрузка модуля на первом этапе инициализации

Первый этап init начинается со чтения файлов конфигурации modprobe из /lib/modules/ на ramdisk. Затем он считывает список модулей, указанных в /lib/modules/modules.load (или в случае восстановления, /lib/modules/modules.load.recovery ), и пытается загрузить каждый из этих модулей по порядку, следуя конфигурации, указанной в ранее загруженных файлах. Запрошенный порядок может быть изменен для удовлетворения жестких или мягких зависимостей.

Поддержка сборки, инициализация первого этапа

Чтобы указать модули ядра, которые необходимо скопировать в ramdisk cpio поставщика, перечислите их в BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Сборка запускает depmod на этих модулях и помещает полученные файлы конфигурации modprobe в ramdisk cpio поставщика.

Сборка также создает файл modules.load и сохраняет его в ramdisk поставщика cpio. По умолчанию он содержит все модули, перечисленные в BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Чтобы переопределить содержимое этого файла, используйте BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD , как показано в этом примере:

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

Поддержка сборки, полный Android

Как и в случае с Android 10 и более ранними выпусками, модули ядра, перечисленные в BOARD_VENDOR_KERNEL_MODULES , копируются сборкой платформы Android в раздел поставщика в /vendor/lib/modules . Сборка платформы запускает depmod для этих модулей и копирует выходные файлы depmod в раздел поставщика в том же месте. Механизм загрузки модулей ядра из /vendor остается таким же, как и в предыдущих выпусках Android. Вы сами решаете, как и когда загружать эти модули, хотя обычно это делается с помощью скриптов init.rc

Подстановочные знаки и интегрированные сборки ядра

Поставщики, которые объединяют сборку ядра своего устройства со сборкой платформы Android, могут столкнуться с проблемой использования вышеупомянутых макросов BOARD для указания модулей ядра, которые необходимо скопировать на устройство. Если поставщик хочет избежать перечисления модулей ядра в файлах сборки платформы устройства, он может использовать подстановочный знак ( $(wildcard device/vendor/mydevice/*.ko ). Обратите внимание, что подстановочный знак не работает в случае интегрированной сборки ядра, поскольку при вызове make и раскрытии макросов в makefile модули ядра не были собраны, поэтому макросы пусты.

Чтобы обойти эту проблему, поставщик может заставить свою сборку ядра создать zip-архив, содержащий модули ядра, которые нужно скопировать на каждый раздел. Задайте путь к этому zip-архиву в BOARD_*_KERNEL_MODULES_ARCHIVE где * — имя раздела (например, BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). Сборка платформы Android извлекает этот zip-архив в соответствующее место и запускает depmod для модулей.

ZIP-архив модуля ядра должен иметь правило make, которое гарантирует, что сборка платформы сможет сгенерировать архив при необходимости.

Восстановление

В предыдущих выпусках Android модули ядра, необходимые для восстановления, указывались в BOARD_RECOVERY_KERNEL_MODULES . В Android 12 модули ядра, необходимые для восстановления, по-прежнему указываются с помощью этого макроса. Однако модули ядра восстановления копируются в ramdisk cpio поставщика, а не в универсальный ramdisk cpio. По умолчанию все модули ядра, перечисленные в BOARD_RECOVERY_KERNEL_MODULES , загружаются во время первой стадии init . Если вы хотите, чтобы была загружена только часть этих модулей, укажите содержимое этой части в BOARD_RECOVERY_KERNEL_MODULES_LOAD .

Чтобы узнать о создании загрузочного раздела поставщика (содержащего RAM-диск поставщика, упомянутый на этой странице), см. раздел Загрузочные разделы .