Hình ảnh nhân hệ điều hành chung (GKI) có thể không chứa tính năng hỗ trợ trình điều khiển cần thiết để
cho phép một thiết bị gắn các phân vùng. Để cho phép thiết bị gắn kết các phân vùng và
để tiếp tục khởi động, init ở giai đoạn đầu tiên sẽ được tăng cường để tải
các mô-đun nhân hệ điều hành có trên ổ đĩa ramdisk. Ổ đĩa RAM được chia thành các thành phần chung và
ổ đĩa cứng của nhà cung cấp. Các mô-đun nhân hệ điều hành của nhà cung cấp được lưu trữ trong ổ đĩa ram của nhà cung cấp. Chiến lược phát hành đĩa đơn
thứ tự tải các mô-đun nhân có thể định cấu hình.
Vị trí mô-đun
Ổ đĩa RAM là hệ thống tệp cho init, giai đoạn đầu tiên và cho
hình ảnh khôi phục/khởi động nhanh trên các thiết bị A/B và A/B ảo. Đó là
initramfs bao gồm 2 tệp lưu trữ cpio được nối với nhau
trình tải khởi động. Kho lưu trữ cpio đầu tiên, được lưu trữ dưới dạng ổ đĩa ramdisk của nhà cung cấp
trong phân vùng khởi động của nhà cung cấp có chứa các thành phần sau:
- Các mô-đun nhân của nhà cung cấp
initgiai đoạn đầu tiên, nằm trong/lib/modules/. modprobetệp cấu hình, nằm trong/lib/modules/:modules.dep,modules.softdepmodules.alias,modules.options.- Tệp
modules.loadcho biết cần tải mô-đun nào trong giai đoạn đầu và theo thứ tự nào trong giai đoạn đầu/lib/modules/. - Các mô-đun nhân hệ điều hành khôi phục của nhà cung cấp, cho thiết bị A/B và thiết bị A/B ảo, trong
/lib/modules/ modules.load.recoverycho biết các mô-đun cần tải và đối với các thiết bị A/B và A/B ảo, theo thứ tự nào trong/lib/modules.
Kho lưu trữ cpio thứ hai, được cung cấp cùng với GKI
làm ramdisk của boot.img và được áp dụng ở đầu
trước tiên, chứa first_stage_init và các thư viện mà nó phụ thuộc vào.
Đang tải mô-đun trong khởi tạo giai đoạn đầu tiên
init giai đoạn đầu tiên bắt đầu bằng cách đọc cấu hình mô-đun thử nghiệm
từ /lib/modules/ trên ổ đĩa ram. Tiếp theo, Chrome sẽ đọc danh sách
của mô-đun được chỉ định trong /lib/modules/modules.load (hoặc trong trường hợp
phục hồi, /lib/modules/modules.load.recovery) và cố gắng
tải từng mô-đun đó theo thứ tự, theo cấu hình được chỉ định trong
các tệp đã tải trước đó. Đơn đặt hàng đã yêu cầu có thể bị lệch từ đến
đáp ứng các phần phụ thuộc cứng hoặc mềm.
Xây dựng khả năng hỗ trợ, khởi tạo giai đoạn đầu
Để chỉ định các mô-đun nhân cần sao chép vào cpio ramdisk của nhà cung cấp, hãy liệt kê
chúng trong BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Bản dựng chạy
depmod trên các mô-đun này rồi đặt cấu hình mô-đun thử nghiệm thu được
trong cpio ramdisk của nhà cung cấp.
Bản dựng này cũng tạo một tệp modules.load và lưu trữ tệp này trong
cpio ramdisk của nhà cung cấp. Theo mặc định, tệp này chứa tất cả các mô-đun được liệt kê trong
BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Để ghi đè nội dung của
tệp đó, hãy sử dụng BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD, như minh hoạ
trong ví dụ này:
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
device/vendor/mydevice-kernel/first.ko \
device/vendor/mydevice-kernel/second.ko \
device/vendor/mydevice-kernel/third.ko
Hỗ trợ bản dựng, Android đầy đủ
Tương tự như trong các bản phát hành Android 10 trở xuống, các mô-đun nhân được liệt kê trong
BOARD_VENDOR_KERNEL_MODULES do nền tảng Android sao chép
tạo vào phân vùng nhà cung cấp tại /vendor/lib/modules. Chiến lược phát hành đĩa đơn
bản dựng nền tảng chạy depmod trên các mô-đun này và sao chép
depmod tệp xuất vào phân vùng nhà cung cấp cùng lúc
vị trí. Cơ chế tải các mô-đun nhân từ /vendor
vẫn giữ nguyên như đối với các bản phát hành Android trước đó. Đó là quyết định của bạn
cách thức và thời điểm tải các mô-đun này, mặc dù thông thường, việc này được thực hiện bằng cách sử dụng
init.rc tập lệnh.
Ký tự đại diện và bản dựng nhân hệ điều hành tích hợp
Những nhà cung cấp kết hợp bản dựng hạt nhân của thiết bị với bản dựng nền tảng Android
có thể gặp sự cố khi sử dụng macro BOARD được đề cập ở trên để
chỉ định các mô-đun nhân cần sao chép vào thiết bị. Nếu nhà cung cấp muốn tránh
liệt kê các mô-đun nhân trong tệp bản dựng nền tảng của thiết bị, các mô-đun này có thể dùng ký tự đại diện
($(wildcard device/vendor/mydevice/*.ko). Xin lưu ý rằng ký tự đại diện không
hoạt động trong trường hợp bản dựng hạt nhân tích hợp, vì khi make được gọi và
macro được mở rộng trong tệp makefile, các mô-đun nhân chưa được xây dựng, vì vậy, macro
trống.
Để khắc phục vấn đề này, nhà cung cấp có thể yêu cầu bản dựng nhân hệ điều hành tạo một tệp zip
tệp lưu trữ chứa các mô-đun nhân sẽ được sao chép vào mỗi phân vùng.
Đặt đường dẫn của tệp lưu trữ zip đó trong BOARD_*_KERNEL_MODULES_ARCHIVE
trong đó * là tên của phân vùng (chẳng hạn như
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE). Bản dựng nền tảng Android
trích xuất tệp lưu trữ zip này vào vị trí thích hợp và chạy depmod
trên các mô-đun.
Kho lưu trữ zip mô-đun nhân phải có quy tắc tạo đảm bảo nền tảng bản dựng có thể tạo tệp lưu trữ khi cần.
Khôi phục
Trong các bản phát hành Android trước đây, các mô-đun nhân cần thiết để khôi phục là
được chỉ định trong BOARD_RECOVERY_KERNEL_MODULES. Trong Android 12,
các mô-đun nhân cần thiết để khôi phục vẫn là
được chỉ định bằng macro này. Tuy nhiên, mô-đun nhân hệ điều hành khôi phục được sao chép vào
cpio ramdisk của nhà cung cấp, thay vì cpio ramdisk chung. Theo mặc định, tất cả
các mô-đun nhân hệ điều hành liệt kê trong BOARD_RECOVERY_KERNEL_MODULES đã được tải
trong giai đoạn đầu tiên của init. Nếu bạn chỉ muốn một số
các mô-đun sẽ được tải, hãy chỉ định nội dung của tập hợp con đó trong
BOARD_RECOVERY_KERNEL_MODULES_LOAD.
Tài liệu liên quan
Để tìm hiểu về cách tạo phân vùng khởi động nhà cung cấp (trong đó chứa ramdisk được đề cập trên trang này), xem Khởi động .