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