Tại sao chỉ cần thay thế .config mà không cần biên dịch lại toàn bộ Kernel?

Việc sử dụng file cấu hình trực tiếp từ thiết bị đang chạy mang lại nhiều lợi ích quan trọng trong quá trình phát triển driver:

1. Tối ưu hóa thời gian phát triển

• Biên dịch toàn bộ (Full Compilation): Quá trình build kernel cho các dòng chip như RK3588 có thể mất từ 30 phút đến hơn 1 giờ tùy vào hiệu năng máy tính. Nó tạo ra kernel image, hàng nghìn driver tích hợp và các file device tree.
• Chuẩn bị môi trường (modules_prepare): Chỉ mất chưa đầy một phút. Quá trình này chỉ tạo ra các tệp tiêu đề (header) và thông tin biểu tượng (symbol) cần thiết để biên dịch module bên ngoài.

2. Giữ nguyên nền tảng hệ điều hành

Thiết bị của bạn (ví dụ: Orange Pi) đã có một bản Kernel (Image) đang chạy ổn định. Mục tiêu của bạn là viết một module rời (file .ko). Miễn là module này được xây dựng dựa trên cùng một "bản thiết kế" với kernel đang chạy, bạn có thể nạp nó vào hệ thống mà không cần cài đặt lại toàn bộ hệ điều hành.

3. Nguyên lý của sự tương thích (Alignment)

Khi biên dịch một driver bên ngoài, trình biên dịch cần xác định ba yếu tố:

1. .config: Các tính năng nào đang được bật? (Ví dụ: SPI, I2C, hay GPIO).
2. Header files: Các định nghĩa thanh ghi và khai báo hàm.
3. Module.symvers: "Chữ ký" của các hàm mà kernel cung cấp (như spi_sync).

Lệnh make modules_prepare sẽ dựa vào file .config bạn cung cấp để chuẩn bị sẵn sàng các yếu tố này, đảm bảo driver biên dịch ra sẽ tương thích hoàn toàn với kernel trên board.

4. Khi nào bắt buộc phải biên dịch lại toàn bộ?

• Thay đổi mã nguồn cốt lõi của kernel (logic lập lịch, quản lý bộ nhớ).
• Sửa đổi các driver bắt buộc phải tích hợp sẵn (Built-in), không thể tách rời thành file .ko (như driver đĩa hệ thống).
• Cần cập nhật file Device Tree Binary (.dtb).

Quy trình thực hiện đồng bộ cấu hình và biên dịch driver

Giai đoạn 1: Trích xuất cấu hình từ thiết bị thực tế

Thực hiện trên terminal của board phát triển để lấy file cấu hình hiện tại:

# Sao chép file cấu hình hệ thống
cp /boot/config-$(uname -r) ~/running_board_config

# Chuyển file về máy chủ Ubuntu biên dịch (thay IP và đường dẫn tương ứng)
scp ~/running_board_config dev_user@192.168.1.100:/home/dev_user/kernel_source/

Giai đoạn 2: Khởi tạo môi trường nguồn Kernel trên Ubuntu

Đây là bước then chốt để tránh lỗi "Invalid module format" khi nạp driver.

# 1. Truy cập thư mục mã nguồn Kernel
cd /home/dev_user/kernel_source/linux-5.10-rk35xx

# 2. Ghi đè file cấu hình từ board vào mã nguồn
cp ~/running_board_config .config

# 3. Thiết lập biến môi trường cho trình biên dịch chéo
export ARCH=arm64
export CROSS_COMPILE=/opt/toolchains/gcc-arm-11.2-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-

# 4. Đồng bộ cấu hình (tự động xử lý các tùy chọn mặc định còn thiếu)
make olddefconfig

# 5. Xây dựng các công cụ kịch bản hỗ trợ
make scripts

# 6. Chuẩn bị header và phiên bản cho module bên ngoài
make modules_prepare

Giai đoạn 3: Biên dịch Driver mục tiêu

Giả sử bạn đang phát triển driver cho cảm biến có tên motion_sensor_driver.c.

# 1. Di chuyển vào thư mục chứa code driver
cd /home/dev_user/projects/drivers/motion_sensor

# 2. Dọn dẹp các tệp tạm cũ
make clean

# 3. Biên dịch module
make

# 4. Kiểm tra thông tin phiên bản (vermagic)
modinfo motion_sensor.ko | grep vermagic

Lưu ý: Giá trị vermagic thu được phải khớp hoàn toàn với kết quả lệnh uname -r trên board phát triển.

Giai đoạn 4: Triển khai và kiểm tra

1. Khởi động lại board phát triển để đảm bảo bộ nhớ kernel sạch.
2. Chuyển file .ko mới vừa biên dịch lên board.
3. Nạp driver bằng lệnh:

sudo insmod motion_sensor.ko

Tại sao quy trình này hiệu quả?

• olddefconfig: Đảm bảo các tùy chọn như CONFIG_MODVERSIONS và LOCALVERSION khớp tuyệt đối với kernel đang chạy.
• modules_prepare: Tạo ra file Module.symvers chứa dấu vân tay của các hàm kernel, ngăn chặn lỗi kernel panic hoặc crash khi nạp module.