Общий образ ядра (GKI) может не содержать необходимой поддержки драйверов, позволяющей устройству монтировать разделы. Чтобы устройство могло монтировать разделы и продолжать загрузку, init
первого этапа улучшена для загрузки модулей ядра, присутствующих на виртуальном диске. Виртуальный диск разделен на универсальный и вендорный виртуальные диски. Модули ядра поставщика хранятся на виртуальном диске поставщика. Порядок загрузки модулей ядра настраивается.
Расположение модуля
Виртуальный диск — это файловая система для 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 и виртуальных устройств 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 11 модули ядра, необходимые для восстановления, по-прежнему указываются с помощью этого макроса. Однако модули ядра восстановления копируются на cpio виртуального диска поставщика, а не на общий cpio виртуального диска. По умолчанию все модули ядра, перечисленные в BOARD_RECOVERY_KERNEL_MODULES
, загружаются во время init
первого этапа. Если вы хотите загрузить только подмножество этих модулей, укажите содержимое этого подмножества в BOARD_RECOVERY_KERNEL_MODULES_LOAD
.
Связанная документация
Чтобы узнать о создании загрузочного раздела поставщика (который содержит виртуальный диск поставщика, упомянутый на этой странице), см. раздел Загрузочные разделы .