Hình ảnh hạt nhân chung (GKI) có thể không chứa hỗ trợ trình điều khiển cần thiết để cho phép thiết bị gắn kết 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 được cải tiến để tải các mô-đun hạt nhân có trên đĩa RAM. Đĩa RAM được chia thành đĩa RAM chung và đĩa RAM của nhà cung cấp. Các mô-đun hạt nhân của nhà cung cấp được lưu trữ trong ramdisk của nhà cung cấp. Thứ tự tải các mô-đun hạt nhân có thể được 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 recovery/fastbootd trên các thiết bị A/B và A/B ảo. Đó là một initramfs bao gồm hai kho lưu trữ cpio được nối với nhau bằng bộ nạp khởi động. Kho lưu trữ cpio đầu tiên, được lưu trữ dưới dạng ramdisk của nhà cung cấp trong phân vùng khởi động của nhà cung cấp, chứa các thành phần sau:
- Các mô-đun hạt nhân của nhà cung cấp
initgiai đoạn đầu, nằm trong/lib/modules/. - tập tin cấu hình
modprobe, nằm trong/lib/modules/:modules.dep,modules.softdep,modules.alias,modules.options. - Tệp
modules.loadcho biết mô-đun nào sẽ tải trong quá trình khởi tạo giai đoạn đầu tiên và theo thứ tự nào, theo/lib/modules/. - Mô-đun hạt nhân phục hồi của nhà cung cấp, dành cho thiết bị A/B và A/B ảo, trong
/lib/modules/ -
modules.load.recoverycho biết các mô-đun sẽ tải và theo thứ tự nào đối với các thiết bị A/B và A/B ảo, trong/lib/modules.
Kho lưu trữ cpio thứ hai, được cung cấp cùng với GKI dưới dạng đĩa ram của boot.img và được áp dụng lên trên kho lưu trữ thứ nhất, chứa first_stage_init và các thư viện mà nó phụ thuộc vào.
Đang tải mô-đun trong init giai đoạn đầu
Quá trình init giai đoạn đầu tiên bắt đầu bằng cách đọc các tệp cấu hình modprobe từ /lib/modules/ trên ramdisk. Tiếp theo, nó đọc danh sách các mô-đun được chỉ định trong /lib/modules/modules.load (hoặc trong trường hợp khôi phục, /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 tin được tải trước đó. Thứ tự được yêu cầu có thể bị sai lệch để đáp ứng sự phụ thuộc cứng hoặc mềm.
Xây dựng hỗ trợ, khởi tạo giai đoạn đầu
Để chỉ định các mô-đun hạt nhân sẽ được 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 và đặt các tệp cấu hình modprobe kết quả vào cpio ramdisk của nhà cung cấp.
Bản dựng cũng tạo một tệp modules.load và lưu trữ nó trong cpio ramdisk của nhà cung cấp. Theo mặc định, nó 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ư 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.koHỗ trợ xây dựng, Android đầy đủ
Giống như trường hợp của Android 10 và các bản phát hành thấp hơn, các mô-đun hạt nhân được liệt kê trong BOARD_VENDOR_KERNEL_MODULES được bản dựng nền tảng Android sao chép vào phân vùng của nhà cung cấp tại /vendor/lib/modules . Bản dựng nền tảng chạy depmod trên các mô-đun này và sao chép các tệp đầu ra depmod vào phân vùng của nhà cung cấp ở cùng một vị trí. Cơ chế tải mô-đun hạt nhân từ /vendor vẫn giống như các bản phát hành trước của Android. Bạn có thể quyết định cách thức và thời điểm tải các mô-đun này, mặc dù việc này thường được thực hiện bằng cách sử dụng tập lệnh init.rc
Ký tự đại diện và bản dựng kernel tích hợp
Các nhà cung cấp kết hợp bản dựng hạt nhân thiết bị của họ với bản dựng nền tảng Android có thể gặp sự cố khi sử dụng macro BOARD đã đề cập ở trên để chỉ định các mô-đun hạt nhân sẽ được 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 hạt nhân trong các tệp xây dựng nền tảng của thiết bị, họ có thể sử dụng ký tự đại diện ( $(wildcard device/vendor/mydevice/*.ko ). Lưu ý rằng ký tự đại diện không hoạt động trong trường hợp được tích hợp xây dựng hạt nhân, bởi vì khi thực hiện được gọi và các macro được mở rộng trong các tệp tạo tệp, các mô-đun hạt nhân chưa được xây dựng, do đó các macro trống.
Để giải quyết vấn đề này, nhà cung cấp có thể yêu cầu bản dựng kernel của họ tạo một kho lưu trữ zip chứa các mô-đun kernel sẽ được sao chép vào mỗi phân vùng. Đặt đường dẫn của kho 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 kho 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 hạt nhân phải có quy tắc tạo để đảm bảo bản dựng nền tảng có thể tạo kho lưu trữ khi được yêu cầu.
Sự hồi phục
Trong các bản phát hành Android trước đây, các mô-đun hạt nhân cần thiết để khôi phục đã được chỉ định trong BOARD_RECOVERY_KERNEL_MODULES . Trong Android 11, các mô-đun hạt nhân cần thiết để khôi phục vẫn được chỉ định bằng macro này. Tuy nhiên, các mô-đun hạt nhân 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 hạt nhân được liệt kê trong BOARD_RECOVERY_KERNEL_MODULES đều được tải trong giai đoạn đầu init . Nếu bạn chỉ muốn tải một tập hợp con của các mô-đun này, 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 của nhà cung cấp (chứa đĩa ram của nhà cung cấp được đề cập trên trang này), hãy xem Phân vùng khởi động .