پشتیبانی از ماژول هسته

یک تصویر هسته عمومی (GKI) ممکن است شامل پشتیبانی درایور مورد نیاز برای فعال کردن یک دستگاه برای نصب پارتیشن‌ها نباشد. برای فعال کردن یک دستگاه برای نصب پارتیشن‌ها و ادامه بوت شدن، init مرحله اول برای بارگذاری ماژول‌های هسته موجود در ramdisk بهبود یافته است. ramdisk به ramdisk های عمومی و فروشنده تقسیم می‌شود. ماژول‌های هسته فروشنده در ramdisk فروشنده ذخیره می‌شوند. ترتیب بارگذاری ماژول‌های هسته قابل تنظیم است.

محل ماژول

ramdisk فایل سیستمی برای init, مرحله اول و برای image ریکاوری/fastbootd روی دستگاه‌های A/B و A/B مجازی است. این یک initramfs است که از دو آرشیو cpio تشکیل شده است که توسط بوت لودر به هم متصل می‌شوند. اولین آرشیو cpio که به عنوان ramdisk فروشنده در پارتیشن vendor-boot ذخیره می‌شود، شامل این اجزا است:

• ماژول‌های هسته فروشنده init مرحله اول، واقع در /lib/modules/ .
• فایل‌های پیکربندی modprobe ، واقع در /lib/modules/ : modules.dep ، modules.softdep ، modules.alias ، modules.options .
• فایل modules.load که نشان می‌دهد کدام ماژول‌ها در طول مرحله اول راه‌اندازی (init) و به چه ترتیبی در /lib/modules/ بارگذاری شوند.
• ماژول‌های بازیابی هسته فروشنده، برای دستگاه‌های A/B و A/B مجازی، در /lib/modules/
• modules.load.recovery که ماژول‌های بارگذاری شده و ترتیب آنها را برای دستگاه‌های A/B و Virtual A/B در /lib/modules نشان می‌دهد.

دومین آرشیو cpio که به همراه GKI به عنوان ramdisk فایل boot.img ارائه شده و بر روی آرشیو اول اعمال می‌شود، شامل first_stage_init و کتابخانه‌هایی است که به آنها وابسته است.

بارگذاری ماژول در مرحله اول init

مرحله اول init با خواندن فایل‌های پیکربندی modprobe از /lib/modules/ روی ramdisk آغاز می‌شود. در مرحله بعد، لیست ماژول‌های مشخص شده در /lib/modules/modules.load (یا در صورت بازیابی، /lib/modules/modules.load.recovery ) را می‌خواند و سعی می‌کند هر یک از این ماژول‌ها را به ترتیب و طبق پیکربندی مشخص شده در فایل‌های بارگذاری شده قبلی بارگذاری کند. ترتیب درخواستی ممکن است برای برآورده کردن وابستگی‌های سخت‌افزاری یا نرم‌افزاری تغییر کند.

پشتیبانی ساخت، شروع مرحله اول

برای مشخص کردن ماژول‌های هسته که باید در cpio مربوط به ramdisk فروشنده کپی شوند، آنها را در BOARD_VENDOR_RAMDISK_KERNEL_MODULES فهرست کنید. این build، depmod را روی این ماژول‌ها اجرا می‌کند و فایل‌های پیکربندی modprobe حاصل را در cpio مربوط به ramdisk فروشنده قرار می‌دهد.

این نسخه همچنین یک فایل modules.load ایجاد می‌کند و آن را در ramdisk cpio مربوط به vendor ذخیره می‌کند. به طور پیش‌فرض، این فایل شامل تمام ماژول‌های فهرست شده در 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

پشتیبانی ساخت، اندروید کامل

همانطور که در اندروید ۱۰ و نسخه‌های پایین‌تر مشاهده می‌شود، ماژول‌های هسته فهرست‌شده در BOARD_VENDOR_KERNEL_MODULES توسط نسخه ساخت پلتفرم اندروید در پارتیشن vendor در /vendor/lib/modules کپی می‌شوند. نسخه ساخت پلتفرم، depmod روی این ماژول‌ها اجرا می‌کند و فایل‌های خروجی depmod را در پارتیشن vendor در همان مکان کپی می‌کند. مکانیسم بارگذاری ماژول‌های هسته از /vendor مانند نسخه‌های قبلی اندروید باقی می‌ماند. این تصمیم شماست که چگونه و چه زمانی این ماژول‌ها را بارگذاری کنید، اگرچه معمولاً این کار با استفاده از اسکریپت‌های init.rc انجام می‌شود.

وایلدکاردها و ساخت‌های یکپارچه هسته

فروشندگانی که ساختار هسته دستگاه خود را با ساختار پلتفرم اندروید ترکیب می‌کنند، ممکن است در استفاده از ماکروهای BOARD ذکر شده در بالا برای مشخص کردن ماژول‌های هسته که باید روی دستگاه کپی شوند، با مشکل مواجه شوند. اگر فروشنده بخواهد از فهرست کردن ماژول‌های هسته در فایل‌های ساختار پلتفرم دستگاه خودداری کند، می‌تواند از یک wildcard ( $(wildcard device/vendor/mydevice/*.ko ) استفاده کند. توجه داشته باشید که wildcard در مورد ساختار هسته یکپارچه کار نمی‌کند، زیرا وقتی make فراخوانی می‌شود و ماکروها در makefiles گسترش می‌یابند، ماژول‌های هسته ساخته نشده‌اند، بنابراین ماکروها خالی هستند.

برای حل این مشکل، فروشنده ممکن است از هسته خود بخواهد که یک فایل فشرده (zip) حاوی ماژول‌های هسته که قرار است روی هر پارتیشن کپی شوند، ایجاد کند. مسیر آن فایل فشرده را در BOARD_*_KERNEL_MODULES_ARCHIVE تنظیم کنید که در آن * نام پارتیشن است (مانند BOARD_VENDOR_KERNEL_MODULES_ARCHIVE ). ساختار پلتفرم اندروید این فایل فشرده را در مکان مناسب استخراج کرده و depmod را روی ماژول‌ها اجرا می‌کند.

بایگانی فشرده ماژول هسته باید دارای یک قانون ساخت باشد که تضمین کند نسخه ساخت پلتفرم می‌تواند در صورت نیاز، بایگانی را تولید کند.

بهبودی

در نسخه‌های قبلی اندروید، ماژول‌های کرنل مورد نیاز برای بازیابی در BOARD_RECOVERY_KERNEL_MODULES مشخص می‌شدند. در اندروید ۱۲، ماژول‌های کرنل مورد نیاز برای بازیابی همچنان با استفاده از این ماکرو مشخص می‌شوند. با این حال، ماژول‌های کرنل بازیابی به جای cpio عمومی ramdisk، در cpio ramdisk فروشنده کپی می‌شوند. به طور پیش‌فرض، تمام ماژول‌های کرنل ذکر شده در BOARD_RECOVERY_KERNEL_MODULES در طول init مرحله اول بارگذاری می‌شوند. اگر فقط می‌خواهید زیرمجموعه‌ای از این ماژول‌ها بارگذاری شوند، محتوای آن زیرمجموعه را در BOARD_RECOVERY_KERNEL_MODULES_LOAD مشخص کنید.

مستندات مرتبط

برای کسب اطلاعات در مورد ایجاد یک پارتیشن بوت فروشنده (که شامل ramdisk فروشنده ذکر شده در این صفحه است)، به بخش پارتیشن‌های بوت مراجعه کنید.