Hỗ trợ mô-đun kernel

Hình ảnh hạt nhân 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 thiết bị gắn các phân vùng. Để cho phép thiết bị gắn các phân vùng và tiếp tục khởi động, init ở giai đoạn đầu tiên được tăng cường để tải các mô-đun hạt nhân có trên ramdisk. Ramdisk được chia thành ramdisk chung và ramdisk 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. Bạn có thể định cấu hình thứ tự tải các mô-đun hạt nhân.

Vị trí mô-đun

Ramdisk là hệ thống tệp cho init, giai đoạn đầu và cho hình ảnh khôi phục/fastbootd trên thiết bị A/B và A/B ảo. Đây là một initramfs bao gồm hai tệp lưu trữ cpio được trình tải khởi động nối với nhau. Tệp 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 nhân của nhà cung cấp init giai đoạn đầu tiên, nằm trong /lib/modules/.
  • Tệp cấu hình modprobe, nằm trong /lib/modules/: modules.dep, modules.softdep, modules.alias, modules.options.
  • Tệp modules.load cho biết cần tải mô-đun nào trong giai đoạn đầu tiên và thứ tự tải trong /lib/modules/.
  • Mô-đun hạt nhân khôi phục của nhà cung cấp, dành cho thiết bị A/B và thiết bị A/B ảo, trong /lib/modules/
  • modules.load.recovery cho biết các mô-đun cần tải và thứ tự tải đối với các thiết bị A/B và A/B ảo trong /lib/modules.

Tệp lưu trữ cpio thứ hai được cung cấp cùng với GKI dưới dạng ramdisk của boot.img và được áp dụng trên đầu tệp lưu trữ đầu tiên, chứa first_stage_init và các thư viện mà tệp lưu trữ này phụ thuộc vào.

Tải mô-đun trong quá trình khởi chạy giai đoạn đầu

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 ổ đĩa ram. Tiếp theo, ứng dụng sẽ đọ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 là /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 được tải trước đó. Thứ tự yêu cầu có thể bị lệch để đá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ê các mô-đun đó trong BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Bản dựng này chạy depmod trên các mô-đun này và đặt các tệp cấu hình modprobe thu được 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ữ tệp đó 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ư trong ví dụ sau:

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 đủ

Cũng như trong các bản phát hành Android 10 trở xuống, các mô-đun hạt nhân được liệt kê trong BOARD_VENDOR_KERNEL_MODULES sẽ đượ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 các mô-đun hạt nhân từ /vendor vẫn giữ nguyên như các bản phát hành Android trước. Bạn có thể quyết định cách và thời điểm tải các mô-đun này, mặc dù thường thì việc này đượ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 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 nhân hệ điều hành 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 nêu trên để chỉ định các mô-đun nhân cần sao chép vào thiết bị. Nếu muốn tránh việc liệt kê các mô-đun hạt nhân trong tệp bản dựng nền tảng của thiết bị, thì nhà cung cấp 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 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 hạt nhân chưa được tạo nên 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 hạt nhân tạo một tệp lưu trữ zip chứa các mô-đun hạt nhân cần sao chép vào từng 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 sẽ 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.

Tệp lưu trữ zip của 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 tệp lưu trữ khi cần.

Khôi phục

Trong các bản phát hành Android trước, 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 12, 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ả mô-đun hạt nhân được liệt kê trong BOARD_RECOVERY_KERNEL_MODULES sẽ được tải trong init giai đoạn đầu. 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ìm hiểu về cách tạo phân vùng khởi động của nhà cung cấp (chứa ramdisk của nhà cung cấp được đề cập trên trang này), hãy xem phần Phân vùng khởi động.