Embedded System/Embedded Linux Build Systems buildroot

Buildroot Linux 커널 설정 변경 및 패치 적용 기법: linux-savedefconfig와 BR2_GLOBAL_PATCH_DIR 활용

임베디드 친구 2025. 4. 25. 14:18
반응형

1. Buildroot 기반 Linux 커널 커스텀 빌드 배경: linux-menuconfig 및 Patch 적용의 필요성

임베디드 리눅스 개발 프로젝트에서 하드웨어 전용 드라이버를 추가하거나 시스템 커널 파라미터를 수정하는 작업은 필수적입니다. Buildroot는 통합 빌드 환경을 제공하지만, 빌드 디렉터리(output/build/linux-custom/) 내에서 직접 소스를 수정하는 방식은 make clean 수행 시 모든 수정 사항이 유실되는 치명적인 문제를 가지고 있습니다.

개발 프로세스의 지속 가능성을 확보하기 위해서는 make linux-menuconfig를 통한 설정 변경을 defconfig 파일로 영구 반영하고, 소스 코드 수정 사항을 패치 파일(.patch) 형태로 구조화하여 Buildroot 빌드 파이프라인에 통합해야 합니다. 본 포스팅에서는 BR2_GLOBAL_PATCH_DIR 및 linux-savedefconfig 명령어를 활용하여 안전하고 재현 가능한 커널 커스텀 환경을 구축하는 표준 방법론을 다룹니다.

2. Buildroot Linux 커널 설정 및 패치 적용 핵심 요약 (TL;DR)

  • 커널 설정 영구 저장: make linux-menuconfig로 옵션을 변경한 후 make linux-savedefconfig를 실행하여 덮어쓰기 방지용 defconfig 파일을 생성 및 반영합니다.
  • 패치 파일 자동 적용: BR2_GLOBAL_PATCH_DIR 옵션에 패치 경로를 지정하고 해당 디렉터리 내에 *.patch 파일을 배치하여 자동 적용합니다.
  • 빌드 갱신 및 검증: make linux-rebuild 명령을 통해 소스 재압축 해제 및 패치 재적용 프로세스를 수행합니다.

3. Buildroot Linux 커널 설정 변경 및 Custom Patch 상세 분석 및 구현

Buildroot에서 Linux 커널 제어를 수행할 때 사용하는 주요 커맨드와 설정 옵션의 역할은 다음과 같습니다.

구분 (Category) 명령어 / 옵션 (Command / Option) 대상 파일 / 경로 (Target File / Path) 핵심 역할 및 기능 (Functionality)
설정 수정 make linux-menuconfig output/build/linux-*/.config 임시 커널 Kconfig GUI 설정 인터페이스 실행
설정 저장 make linux-savedefconfig board/<vendor>/<board>/linux.defconfig 변경된 커널 설정값을 영구 저장용 defconfig로 추출
패치 지정 BR2_GLOBAL_PATCH_DIR board/<vendor>/<board>/patches 커널 및 패키지용 패치 파일 탐색 경로 지정
재빌드 make linux-rebuild output/build/linux-*/ 커널 소스 재compilation 및 이미지 재생성

3.1 Linux 커널 Kconfig 변경 및 defconfig 영구 저장

make linux-menuconfig를 사용해 .config를 변경하는 경우, 빌드 디렉터리가 초기화되면 해당 설정이 삭제됩니다. 설정을 영구적으로 유지하기 위해 다음 절차를 진행합니다.

  1. Buildroot 루트 디렉터리에서 커널 설정 인터페이스를 호출합니다.
$ make linux-menuconfig
  1. 필요한 드라이버 및 옵션을 설정한 후 저장하고 종료합니다.
  2. 변경된 설정을 소스 트리 외부의 영구 defconfig 파일로 저장합니다.
$ make linux-savedefconfig

이 명령어는 Buildroot 메인 설정(make menuconfig)의 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE 경로가 가리키는 파일로 최소화된 defconfig를 자동 업데이트합니다.

3.2 Custom Kernel Patch 작성 및 디렉터리 구조화

커널 소스 코드를 수정할 때 .mk 파일을 직접 수정하는 방식보다 BR2_GLOBAL_PATCH_DIR 글로벌 설정 방식을 권장합니다.

  1. 타겟 보드 전용 패치 디렉터리를 생성합니다.
$ mkdir -p board/custom-board/patches/linux
  1. 표준 diff -u 또는 Git 스타일의 패치 파일(0001-add-custom-driver-printk.patch)을 작성하여 해당 디렉터리에 위치시킵니다.
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -100,6 +100,8 @@
 
 int my_custom_function(void) {
+    /* Print debug log for custom patch verification */
     printk(KERN_INFO "Custom kernel patch applied!\n");
     return 0;
 }
  1. make menuconfig 진입 후 패치 경로를 설정합니다.
Build options --->
    (board/custom-board/patches) global patch directories

설정이 완료되면 BR2_GLOBAL_PATCH_DIR="board/custom-board/patches" 항목이 Buildroot .config에 반영되며, Buildroot는 빌드 시 patches/linux/ 하위의 모든 *.patch 파일을 알파벳순으로 자동 적용합니다.

3.3 커널 소스 재빌드 및 패치 검증

작성한 패치와 설정이 정상적으로 반영되었는지 검증하기 위해 커널 파이프라인 재빌드를 수행합니다.

  1. 기존 커널 소스의 컴파일 단계를 초기화하고 패치 재적용 및 재빌드를 수행합니다.
$ make linux-rebuild
  1. 패치 적용 여부는 압축이 해제된 빌드 수행 디렉터리에서 확인합니다.
$ cd output/build/linux-custom/
$ git status
# 또는 적용된 patch 로그 확인
$ cat .stamp_patched
  1. 최종 빌드 완료 후 산출물 생성을 확인합니다.
$ ls -l output/images/zImage output/images/Image

4. Buildroot Linux 커널 개발 및 디버깅 팁

1. make linux-dirclean을 활용한 clean 패치 빌드 테스트

패치 적용 실패 오류(Patch failed to apply)가 발생하거나 타겟 소스가 오염되었을 경우, 전체 make clean을 실행하지 않고 커널 빌드 디렉터리만 원복 후 재시도할 수 있습니다.

$ make linux-dirclean
$ make linux

2. Quick Source Modification을 위한 OVERRIDE_SRCDIR 활용

드라이버 개발 단계에서 매번 패치 파일(.patch)을 생성하고 linux-rebuild를 수행하는 것은 개발 효율성을 떨어뜨립니다. local.mk 파일에 로컬 커널 소스 경로를 바인딩하여 즉시 빌드 피드백을 얻을 수 있습니다.

# local.mk 파일 작성
LINUX_OVERRIDE_SRCDIR = /home/developer/src/linux-custom

5. Buildroot 커널 설정 및 패치 시 흔히 하는 실수 및 트러블슈팅

1. .config 파일 직접 수정 후 make clean 시 설정 유실

  • 증상: output/build/linux-custom/.config를 수동으로 변경하여 빌드했으나, 전체 빌드 재수행 시 변경 사항이 초기화됨.
  • 원인: Buildroot의 빌드 시스템은 빌드 수행 시 메인 설정에 지정된 defconfig 파일을 가져와 output/build/linux-custom/.config를 덮어씁니다.
  • 해결 방법: make linux-menuconfig 수정 완료 직후 반드시 make linux-savedefconfig를 실행하여 원본 defconfig 파일을 업데이트해야 합니다.

2. Patch File Naming 및 Path Offset 오설정으로 인한 빌드 실패

  • 증상: make linux 빌드 도중 1 out of 1 hunk FAILED 또는 cannot find file to be patched 에러 발생.
  • 원인: Diff 파일 생성 시 참조 경로의 뎁스(Depth, -p1 기준)가 맞지 않거나 다른 커널 버전을 대상으로 패치가 작성됨.
  • 해결 방법: 패치 파일 내 파일 경로가 a/drivers/char/file.c 및 b/drivers/char/file.c 형태로 작성되었는지 확인하고, 커널 소스 루트 디렉터리 기준으로 git diff를 실행하여 패치를 다시 추출합니다.

3. BR2_LINUX_KERNEL_PATCHES와 BR2_GLOBAL_PATCH_DIR 사용 혼선

  • 증상: 패치 파일을 디렉터리에 넣었으나 빌드 타임에 패치 적용 단계를 스킵함.
  • 원인: BR2_GLOBAL_PATCH_DIR 내에 패키지명 서브디렉터리(linux/)를 생성하지 않고 루트에 직접 .patch 파일만 배치함.
  • 해결 방법: BR2_GLOBAL_PATCH_DIR 구조를 사용할 때는 반드시 $(BR2_GLOBAL_PATCH_DIR)/linux/ 경로 하위에 패치 파일들을 위치시켜야 합니다.

6. 결론: 효율적인 Linux Kernel Customization 파이프라인

Buildroot 환경에서 Linux 커널을 커스터마이징할 때 output/build/ 내부를 직접 수정하는 방식은 형상 관리에 적합하지 않습니다. make linux-menuconfig 및 make linux-savedefconfig 명령을 사용해 설정 파일(defconfig)을 지속적으로 버전 관리 시스템에 업데이트하고, 소스 수정은 BR2_GLOBAL_PATCH_DIR 구조에 정형화된 패치 파일로 관리하는 것이 유지보수에 유리합니다.

반응형