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

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

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

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

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

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

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

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

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

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

При сборке также создается файл modules.load и сохраняется на виртуальном диске поставщика 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 и раскрытии макросов в make-файлах модули ядра не были собраны, поэтому макросы пусты.

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

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

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

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

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