박지의 IT 공부블로그

임베디드 리눅스 장치에서의 GDB 디버깅

pak-ji — Tue, 16 Jun 2026 15:46:22 +0900

개요

GDB란?

C, C++, Rust, Go 등 다양한 언어로 개발된 프로그램을 코드 단위로 디버깅하기 위한 대표적인 리눅스 환경의 디버거로, 실행되기 전의 프로그램 혹은 실행되고 있는 중인 프로그램에 이 디버거를 붙여서 활용가능하다. 또한, 프로그램이 비정상적으로 종료되었을 경우 생성되는 Postmortem 파일인 코어파일을 디버깅하기 위해서도 활용가능하다.

원격 디버깅이란?

임베디드 리눅스로 동작하는 장치는 메모리 등이 현저히 부족한 환경이 대다수로, 대부분의 임베디드 장치에서는 디버깅을 위한 심볼이나 관련 도구들을 저장하기 힘들다. 그래서, 이를 해결하기 위해 디버깅을 위한 SDK 들은 모두 호스트 환경에 두고 이에 따라 타겟의 프로그램을 원격으로 디버깅할 수 있도록 타겟에는 에이전트를 두는 방식으로 원격 디버깅한다.

본 페이지에서는 GDB를 활용해 임베디드 리눅스 장치에 원격 디버깅을 위한 gdbserver 에이전트를 빌드시키는 방법과 호스트 환경에서 타겟의 에이전트를 통해 간단한 프로그램을 디버깅하는 방법을 설명한다. 또한, 비정상적인 동작(Seg Fault 등)으로 종료된 프로그램에 대한 코어 파일을 생성시키는 방법 그리고 코어 파일을 GDB를 활용해 원격으로 디버깅하는 방법을 설명하고 마무리한다.

임베디드 리눅스 GDB 활성화

임베디드 리눅스 장치에 gdbserver 에이전트를 빌드시키려면, 위 그림과 같이 이미지 레시피의 IMAGE_INSTALL 변수에 gdbserver를 추가해주어야 한다. (반드시 :append 사용하기)

이제, 이미지에 gdbserver를 빌드시킨 후 임베디드 리눅스 장치를 플래싱한다.

필자는 Raspberry Pi 4를 사용하고 있어서 SD 카드로 이미지를 구워주었다. 이를 위해서 bzcat과 dd 명령을 활용하였다.

# 이미지에 gdbserver를 빌드시키기
(Host)$ source oe-init-build-env build
(Host)$ bitbake <target_image>

# 빌드된 이미지를 타겟 장치에 플래싱
# Raspberry Pi 4의 경우는 아래 명령을 사용 (참조링크: https://pak-j.tistory.com/96)
(Host)$ cd tmp/deploy/images/raspberrypi4/
# SD 카드와 같은 Block 장치의 경우 fdisk 명령 등으로 완전히 초기화시킨 후 아래 명령 진행
(Host)$ bzcat core-image-full-cmdline-raspberrypi4.wic.bz2 | sudo dd of=/dev/<blkfile-name>

플래싱이 완료되었다면 타겟(임베디드 리눅스 장치)으로 접근(SSH 혹은 Serial 활용)하여 아래 명령을 통해 gdbserver가 정상적으로 빌드되었는지 확인한다.

(Target)$ gdbserver --version

타겟에 정상적으로 gdbserver가 빌드된 것을 확인하였다면, 이제 타겟을 디버깅하기 위한 개발용 SDK를 호스트 환경에 설치해주어야 한다. 이를 위해 아래 명령을 실행시킨다.

(Host)$ bitbake -c populate_sdk <target_image>

bitbake에서 -c 옵션은 특정 태스크(do_install, do_rootfs 등)만을 실행시키기 위해 활용한다. 이 -c 옵션을 활용해서 타겟 개발용 SDK를 호스트 환경에 설치해줄 수 있으며, 이때 사용하는 것이 populate_sdk 태스크이다.

타겟 개발용 SDK 설치가 완료되었다면, SDK를 호스트 환경에서 사용할 수 있도록 아카이브 해제와 디렉터리 위치 조정 등을 수행해주어야 한다. 이 과정은 한번에 수행할 수 있도록 Yocto에서 쉘 스크립트 형태로 제공한다.

cd build/tmp/deploy/sdk
./<target_image_sdk>.sh

SDK 설치 중

SDK 설치 완료

쉘 스크립트(.sh)를 통한 설치 과정 중 SDK의 설치 경로를 Default로 설정하였다면, 타겟 개발용 SDK는 /opt/poky/<poky-version> 하위에 설치된다. 설치가 완료되었다면 이제 타겟 개발용 SDK가 설치된 경로로 이동하여 SDK 환경설정을 위한 스크립트 실행시켜준다.

cd /opt/poky/<poky-version>
source <sdk_env>

여기까지 진행되었다면 호스트에는 타겟 이미지의 디버깅 심볼과 타겟용 GDB가 들어있는 개발용 SDK 설치가 완료되었으며, 타겟에는 호스트 환경에서의 원격 디버깅을 위한 에이전트인 gdbserver 설치가 완료되었다.

이제 호스트와 타겟에 세팅된 디버깅 환경을 활용한 GDB 원격 디버깅 방법을 다음 섹션에서 설명한다.

임베디드 리눅스 GDB 원격 디버깅

먼저 타겟에서 디버깅할 애플리케이션에 gdbserver 에이전트를 다음과 같이 붙여준다.

# SSH 환경으로 설명
(Target)$ gdbserver :<port_number> <app_name>

위와 같이 타겟 환경을 세팅하였다면, 이제 호스트에서 타겟의 gdbserver 에이전트로 붙이기 위한 작업을 다음과 같이 수행한다.

# 쉘 스크립트를 통해 타겟 개발용 SDK 환경을 호스트에 설정하였다면,
# 환경 변수($GDB)에 타겟의 cross-gdb가 세팅되어 있다.
(Host)$ $GDB /opt/poky/<poky-version>/sysroots/<application-binary-path>

# 실행되는 타겟의 바이너리에 대한 디버깅 심볼을 찾기 위해 sysroot를 등록한다.
(Host)$ (gdb) set sysroot /opt/poky/<poky-version>/sysroots/<target-sysroot-directory>

# (Optional) 만약 애플리케이션 소스 파일이 타겟 sysroot에 존재하지 않다면,
# 아래 명령으로 직접 애플리케이션 소스 파일의 위치를 등록해준다.
(Host)$ (gdb) directory path/to/poky/…/<application-source-directory>/

# 타겟에서 대기 중인 gdbserver 에이전트에 아래 명령을 활용해 붙어준다.
(Host)$ (gdb) target remote <target-ip>:<gdbserver-port-number>

호스트에서 타겟의 gdbserver 에이전트에 붙게되었다면 이제 아래 사진과 같이 GDB 명령을 활용해 소스 레벨에서의 디버깅을 수행하면 된다. 본 페이지에서는 GDB 명령에 대한 내용은 생략한다.

호스트에서의 GDB 원격 디버깅 화면

만약 디버깅 할 애플리케이션이 타겟이 부팅될 때 자동으로 실행되어 초기 단계의 디버깅이 불가할 경우, 리눅스의 init 프로그램(SysVinit, Busybox, Systemd 등)에서 참조하는 데몬 실행 명령을 다음과 같이 설정해주면 된다.

# SysVinit
start-stop-daemon -S -x /usr/bin/gdbserver -- :<port-number> /usr/bin/<app-bin>

# systemd
ExecStart=/usr/bin/gdbserver :<port-number> /usr/bin/<app-bin>

또한, 이미 실행 중인 애플리케이션에 gdbserver 에이전트를 붙여주는 방법도 존재한다.

(Target)$ gdbserver --attach :<port-number> $(pidof <app-bin>)

임베디드 리눅스 코어파일 생성방법

애플리케이션의 소스레벨 문제(Seg Fault 등)가 항시 발생하지 않고, 간헐적으로 발생하는 경우가 존재할 것이다. 이때에는 GDB를 붙여놓아도 문제를 곧바로 찾아내긴 어렵기 때문에 Postmortem 방식으로 디버깅을 수행해주어야 한다. 다시 말해, 애플리케이션의 비정상적인 종료에 대한 사후 분석을 수행해야 한다.

이를 위해 리눅스에서는 비정상적인 종료가 발생된 애플리케이션의 메모리를 그대로 덤프를 떠서 바이너리 형식의 파일로 저장해두는 기능을 제공한다. 이때 생성된 파일을 코어 파일이라고 불리운다.

코어 파일을 생성하기 위해선, 리눅스 시스템에서는 다음과 같은 명령을 활용해 코어 파일의 생성 경로와 허용 용량을 세팅해주어야 한다.

# 코어 파일의 생성 경로를 지정
# %e = 실행된 애플리케이션의 파일 이름
# %p = 실행된 애플리케이션의 프로세스 ID(PID)
# %s = 실행된 애플리케이션이 종료될 때 발생된 시그널 번호
# %t = 실행된 애플리케이션의 코어 덤프 발생 타임스탬프
(Target)$ sudo vi /etc/sysctl.conf
(Target)$ (vi) kernel.core_pattern=/tmp/core.%e.%p.%s.%t

# 재부팅 되어야 위에 설정한 코어 덤프에 대한 설정이 시스템 상에 적용된다.
(Target)$ sudo reboot

# ulimit의 -c 옵션은 애플리케이션에서 생성할 코어 파일의 용량을 설정하기 위해 사용한다.
# 기본적으로 코어 파일의 허용 용량은 0 이다.
# ulimit 설정은 재부팅하면 사라지므로, 계속 유지를 위해선 데몬 스크립트에 넣어두는게 좋다.
(Target)$ sudo ulimit -c unlimited

테스트를 위해서 kill 명령을 활용해 SEGV 시그널을 프로세스에 발생시켜 Seg Fault가 일어나게끔 한다.

Seg Fault가 발생된 프로세스는 코어 덤프를 수행한 뒤 /tmp 하위에 코어 파일을 생성시킨다. 이 코어 파일은 호스트 환경에서 GDB를 활용해 분석(디버깅) 가능하다.

# 호스트에서 타겟에 저장된 코어 파일을 다운로드
(Host)$ scp <target-user>@<target-ip>:/tmp/<core-file> <download-path>

# 호스트에 타겟의 개발용 SDK 환경 세팅
(Host)$ cd /opt/poky/<poky-version>
(Host)$ source <sdk_env>

# 호스트에 타겟의 개발용 SDK 환경을 잘 세팅되었는지 확인
(Host)$ echo $GDB
(Host)$ echo $SDKTARGETSYSROOT

# Not Stripped 실행 파일 찾기
(Host)$ find ~/workspace/rpi4-poky/build/tmp/work -name onestep -type f
(Host)$ file <not-stripped-app-bin>

# 코어 파일을 Not Stripped 실행 파일과 함께 GDB로 열기
(Host)$ $GDB /path/to/<not-stripped-app-bin> /path/to/<core-file>

# 실행되는 타겟의 바이너리에 대한 디버깅 심볼을 찾기 위해 sysroot를 등록한다.
(Host)$ (gdb) set sysroot /opt/poky/<poky-version>/sysroots/<target-sysroot-directory>

# (Optional) 만약 애플리케이션 소스 파일이 타겟 sysroot에 존재하지 않다면,
# 아래 명령으로 직접 애플리케이션 소스 파일의 위치를 등록해준다.
(Host)$ (gdb) directory path/to/poky/…/<application-source-directory>/

# GDB 명령을 활용해 디버깅을 수행한다.
(Host)$ (gdb) list
(Host)$ (gdb) bt

위 디버깅을 통해 Sleep 도중에 kill 명령에 의해 SIGSEGV이 발생되어 비정상적인 종료가 일어난 것을 알 수 있다.

결론

본 페이지에서는 임베디드 리눅스 환경에서 GDB와 gdbserver를 활용하여 원격 디버깅 환경을 구성하고, 호스트에서 타겟 애플리케이션을 소스 레벨로 분석하는 방법을 정리하였다.

임베디드 장치는 저장공간과 메모리 제약으로 인해 타겟 내부에 모든 디버깅 도구와 심볼을 포함하기 어렵다. 따라서 타겟에는 gdbserver만 배치하고, 호스트에는 Yocto SDK를 설치하여 Cross-GDB, Debugging Symbol, Target sysroot를 활용하는 방식이 일반적이다.

또한 이미 실행 중인 프로세스에는 gdbserver --attach 방식으로 붙을 수 있으며, 부팅 시 자동 실행되는 애플리케이션은 init script 또는 systemd의 실행 명령을 gdbserver로 감싸 초기 실행 시점부터 디버깅할 수 있다.

마지막으로, 간헐적으로 발생하는 Segmentation Fault와 같은 문제는 코어 덤프를 활성화하여 사후 분석할 수 있다. 이때 코어 파일은 살아 있는 프로세스가 아니므로 gdbserver로 원격 attach하는 방식이 아니라, 호스트로 가져온 뒤 not-stripped 실행파일과 SDK sysroot를 함께 사용하여 GDB에서 분석해야 한다.

결국 임베디드 리눅스 디버깅 환경의 핵심은 다음 세 가지로 정리할 수 있다.

타겟에는 gdbserver를 포함시킨다.
호스트에는 Yocto SDK와 심볼 포함 실행파일을 준비한다.
실시간 문제는 원격 디버깅으로, 종료된 문제는 코어 덤프 분석으로 접근한다.

이 구성을 갖추면 제한적인 임베디드 환경에서도 애플리케이션의 실행 흐름, 크래시 원인, 메모리 상태를 비교적 빠르고 정확하게 추적할 수 있다.

References

임베디드 리눅스 프로그래밍 완전정복 3/e, 19장 GDB로 디버깅하기

SysVinit(System V init)이란?

pak-ji — Fri, 5 Jun 2026 16:54:29 +0900

개요

init란?

init은 root 권한을 가진 첫번째로 실행되는 프로세스로 PID 1번을 갖는다.
init은 사용자 공간 앱의 부트 순서를 제어하고 이를 실행시키는 역할을 한다.
init 프로세스를 통해 실행된 유저 앱은 데몬(Daemon)이라고 부른다.
init 프로세스는 부팅시점부터 종료때까지 시스템의 모든 데몬에 대한 라이프사이클을 제어한다.
이러한 Linux의 init 프로그램에는 아래와 같이 3가지 종류가 존재한다.

init 프로그램 종류

BusyBox
- 매우 낮은 복잡도를 가진 시스템에서 사용하기에 적절하다.
- 실행된 데몬의 로그를 정리하는 기능이 부족하다.
- 1KB 이하의 크기로 동작시킬 수 있는 init 프로그램이다.
- SysVinit와 유사한 형태로 데몬을 관리한다.
SysVinit
- 중간 정도의 복잡도를 가진 시스템에서 사용하기 적절하다.
- 실행된 데몬의 로그를 정리하는 기능이 부족하다.
- 1KB 가량의 크기로 동작시킬 수 있는 init 프로그램이다.
- BusyBox와 유사한 형태로 데몬을 관리한다.
Systemd
- 높은 복잡도를 가진 시스템에서 사용하기 적절하다.
- 실행된 데몬의 로그를 정리하는 기능이 매우 풍부하다. (systemd-journald)
- 30MB 이상의 크기로 동작시킬 수 있는 init 프로그램이다. (Desktop Linux에 주로 활용)
- 메모리와 디스크 용량이 충분한 Embedded Linux에서도 많이 사용된다.
- BusyBox와 SysVinit과는 다른 형태로 데몬을 관리한다.

본 페이지에서는 앞서 설명한 세가지 init 프로그램 중 SysVinit에 대해서만 설명한다. 또한, 이 페이지는 임베디드 리눅스를 학습하면서 정리하는 것이므로 Yocto(4.0 LTS)를 기준으로 설명한다.

SysVinit

Yocto 시스템을 통해 빌드된 리눅스 배포판이 init 프로그램으로 SysVinit을 사용하기 위해서는 루트 설정 파일인 build/conf/local.conf의 가장 마지막 줄에 다음과 같이 작성주어야 한다.

INIT_MANAGER = “sysvinit”

# init 프로그램을 BusyBox나 Systemd로 변경할 때에는 아래와 같이 작성한다.
# INIT_MANAGER = “busybox”
# INIT_MANAGER = “Systemd”

SysVinit은 총 8가지의 런레벨을 갖고있다.

필자가 실무를 접할 때에는 0, 5, 6 레벨만 주로 활용했었다.

S: 일반 런레벨(0~6)과는 다른 부팅 전용 특수 런레벨
0: 시스템 종료 시 실행되는 런레벨
1~5: 시스템 부팅이 완료된 후 사용자 앱을 실행시키기 위한 런레벨
6: 시스템 재시작 시 실행되는 런레벨

사용자 앱을 실행시키기 위한 5가지 런레벨은 Upstream Linux의 경우에는 주로 다음과 같이 할당하여 사용한다.

1: 단일 사용자
2: 네트워크 구성 요소를 사용하지 않는 다중 사용자
3: 네트워크 구성 요소를 사용하는 다중 사용자
4: 사용하지 않음
5: 그래픽 로그인을 사용하는 다중 사용자 (가장 많이 사용하는 런레벨)

SysVinit에서는 이러한 여러 런레벨을 자유자재로 변경할 수 있으며, 이를 위해 아래와 같은 명령을 활용해 런레벨을 자유자재로 변경가능하다.

# Runlevel 0
$ halt
$ /etc/init.d/rc 0

# Runlevel 1~5
$ /etc/init.d/rc <1~5>

# Runlevel 6
$ reboot
$ /etc/init.d/rc 6

위 명령 예시를 활용하여 리눅스 시스템을 특정 런레벨로 변경하게 되면, init 프로그램(SysVinit)은 해당 런레벨에 해당하는 모든 데몬을 재실행(kill → start)시킨다. 각 런레벨에 해당하는 데몬은 /etc/rc<1~5>.d 디렉터리 하위에 쉘 스크립트 형태로 관리된다.

위 캡쳐는 런레벨 5에 해당하는 데몬들을 관리하기 위한 스크립트 파일들이다. 파일의 형태를 보면 알 수 있듯이, 실제로는 /etc/init.d 하위에 데몬을 종료/실행시키기 위한 스크립트 파일들이 작성되고, 이 파일들을 각 런레벨에 맞춰 링크하는 형식으로 존재한다.

그리고 링크된 파일 이름의 앞에는 S00(K00도 존재함)를 붙이는 것을 알 수 있다. 이는 다음을 의미한다.

S00
- S는 Start를 의미하며, init 프로세스가 이를 보고 데몬 실행(start) 명령을 내린다.
- 00은 실행 순서를 의미하며, S00이 가장 먼저 실행되고 S99이 가장 늦게 실행된다.
K00
- K는 Kill을 의미하며, init 프로세스가 이를 보고 데몬 종료(stop) 명령을 내린다.
- 00은 종료 순서를 의미하며, K00이 가장 먼저 종료되고 K99이 가장 늦게 종료된다.

또한, 데몬을 실행시키기 위한 스크립트는 일반적으로 다음과 같은 뼈대를 갖는다.

export와 같은 환경변수도 주로 스크립트에 작성하며, 고객사별로 다르게 환경변수를 관리하기 위해서 configs/ 디렉터리를 추가로 생성하는 경우도 존재한다.

#! /bin/sh

case “$1” in
	start)
		echo “Start user daemon”
		start-stop-daemon -S -n <app-name> -x <app-start-command>
	stop)
		echo “Kill user daemon”
		start-stop-daemon -K -n <app-name>
	*)
		echo “Usage: $0 {start|stop}”
		exit 1
csac

exit 0

스크립트 파일 내용과 같이 특정 런레벨을 실행(halt, reboot, /etc/init.d/rc 등)할 시, 해당하는 런레벨의 데몬 관리 스크립트(/etc/rc<0~6>.d/*)로 접근하여 start 혹은 stop 명령을 내리게 된다.

쉘 스크립트에서 $0은 파일명을 나타내고 $1은 첫번째 인자를 나타낸다.

정리하자면, SysVinit은 특정 유저 앱을 데몬 형태로 실행시키기 위해 다음과 같은 순서를 따른다.

init 프로그램 실행
현재 시스템의 런레벨 확인 (/etc/inittab에서 initdefault가 작성된 줄의 런레벨을 통해서)
현재 런레벨에 해당하는 디렉터리로 이동 (/etc/rc<0~6>.d/)
디렉터리에 존재하는 모든 스크립트를 실행 (S00 부터 S99까지 순서대로)
유저 앱이 백그라운드로 실행되어 데몬 형태로 동작

필자도 Busybox나 SysVinit을 직접적으로 사용을 해본적은 있지만 단순히 데몬을 실행시키기 위한 용도로만 활용했었다. 그러나 이번 계기로 init 프로그램이 무엇인지 다시 한번 알 수 있게 되었고, 리눅스의 init 프로그램에는 어떤 것들이 있는지, 그리고 각 init 프로그램가 어떠한 환경에서 사용하면 되는지, 또한 init 프로그램 중 SysVinit가 어떠한 순서에 따라서 유저 앱을 실행하는지 익힐 수 있게 되었다.

References

임베디드 리눅스 프로그래밍 완전정복 3/e, 13장 시스템구동: init 프로그램

[Yocto 학습] 9장: Poky를 활용한 Raspberry Pi 4 유저 애플리케이션 빌드

pak-ji — Sat, 30 May 2026 00:17:14 +0900

개요

Poky로 빌드된 Raspberry Pi 4 이미지는 완전히 순수한 형태로 존재한다. 다시 말해, 기본적인 쉘 명령이나 유틸리티를 제외한 아무런 애플리케이션이 올라가 있지 않다. 따라서, 유저 애플리케이션을 이미지에 빌드시키기 위해서는 직접 새 애플리케이션을 구현하고 이를 이미지에도 빌드될 수 있도록 레시피 파일을 작성해주어야 한다.

본 페이지에서는 예제로 “Hello, World”를 출력하는 C언어 유저 애플리케이션을 구현 후, 이를 Raspberry Pi 4 이미지내에 함께 빌드 될 수 있도록 레시피를 작성하는 방법에 대해서 설명한다.

Raspberry Pi 4 사용자 설정을 위한 커스텀 레이어

새로운 유저 애플리케이션을 구현 후 패키지화하여 이미지에 빌드시키기 위해 아래와 같은 커스텀 레이어(meta-custom)를 작성하였다. 본 레이어를 생성하고 구성하는 방법은 앞 8장에 작성되어 있으니 참고하길 바란다.

참고로 새 레이어를 생성하기 위해서는 아래와 같은 명령을 따른다.

source path/to/poky/oe-init-build-env build

# 새 레이어 생성
bitbake-layers create-layer path/to/poky/meta-custom

# 생성된 새 레이어를 빌드에 추가 (build/conf/bblayers.conf에 자동으로 레이어 경로가 등록됨)
bitbake-layers add-layer path/to/poky/meta-custom

레시피 파일이 저장된 각 디렉터리의 역할은 다음과 같다.

recipes-applications
- 사용자 예제 애플리케이션(hello)을 이미지에 빌드시키기 위해 활용
recipes-connectivity
- 와이파이 연결을 위한 설정 파일을 이미지에 빌드시키기 위해 활용
- 이미 앞 8장에서 다룬 내용
recipes-core
- 유저 애플리케이션을 패키지 형태로 이미지에 빌드시키기 위해 활용

본 페이지에서는 recipes-applications에 들어가는 유저 애플리케이션(hello-app)을 구현하기 파일(C, Makefile)과 이를 빌드하기 위한 레시피 파일의 세부 내용을 어떻게 구성하면 되는지 다음 섹션부터 설명한다.

Raspberry Pi 4 유저 애플리케이션 구현

가장 먼저, Hello World가 출력되는 유저 애플리케이션을 구현하기 위해 아래 두 파일을 작성한다.

vi path/to/poky/meta-custom/recipes-applications/hello-app/files/hello-app.c
vi path/to/poky/meta-custom/recipes-applications/hello-app/files/Makefile

hello-app.c는 다음과 같은 내용으로 작성한다.

#include <stdio.h>

int main() {
    printf(“Hello, pakji !!\n”);
    return 0;
}

hello-app을 컴파일 할 Makefile은 다음과 같은 내용으로 작성한다.

TARGET = hello
SRCS = hello-app.c

all: $(TARGET)

$(TARGET): $(SRCS)
    $(CC) $(CFLAGS) $(LDFLAGS) -o $(TARGET) $(SRCS)

clean:
    rm -f $(TARGET)

유저 애플리케이션 구현을 마쳤으면, 이제 이 애플리케이션을 위한 레시피를 작성하여서 패키지 형태로 이미지에 빌드되도록 해준다. 이 과정은 다음 섹션을 참조하면 된다.

Raspberry Pi 4 유저 애플리케이션 패키지 등록

유저 애플리케이션을 이미지에 빌드되도록 하기 위한 이미지 레시피(core-image-full-cmdline)의 IMAGE_INSTALL 변수에 hello-app 패키지를 등록한다.

vi path/to/poky/meta-custom/recipes-core/images/core-image-full-cmdline.bbappend

# core-image-full-cmdline.bbappend

IMAGE_INSTALL:append = " … hello-app"

패키지를 등록하였다면 이제 이 패키지를 빌드시키기 위한 레시피 파일을 작성해준다.

vi path/to/poky/meta-custom/recipes-applications/hello-app/hello-app.bb

# hello-app.bb

SUMMARY = "Hello example application"
LICENSE = "CLOSED"

SRC_URI += " \
    file://hello-app.c \
    file://Makefile \
"

S = "${WORKDIR}"

do_compile() {
    oe_runmake
}

do_install() {
    install -d ${D}${bindir}
    install -m 0755 ${WORKDIR}/hello ${D}${bindir}/hello
}

FILES:${PN} += "${bindir}/hello"

gcc나 make 명령을 실행시켜서 직접 컴파일이 가능하지만, 비트베이크의 빌드 시스템을 제대로 활용하기 위해선 제공하는 도구를 그대로 사용하는 것이 가장 적절하다. 왜냐하면, 빌드 시스템에서 관련 툴체인 등을 자동으로 불러와 사용할 수 있기 때문이다. 이를 위해 Makefile 등을 비트베이크에서 파싱할 수 있는 형태로 작성을 해주어야 한다. 그리고 Makefile의 경우에는 oe_runmake 명령문을 작성해서 간단하게 컴파일이 가능하다.

.bb 레시피는 패키지 빌드에 필요한 메타데이터를 정의하는 파일이다. 레시피의 do_install 단계에서 설치한 파일이 최종 패키지와 rootfs에 포함되려면, 해당 파일이 어떤 패키지에 포함될지 패키징 규칙에 의해 매핑되어야 한다. 기본 패키징 경로에 포함되지 않는 파일은 FILES:${PN} 등을 사용해 명시적으로 지정한다.

앞 8장에서는 새로운 패키지를 정의하는 .bb 레시피가 아니라, 기존 레시피를 확장하는 .bbappend 파일을 작성하였다. 따라서 원본 레시피에서 이미 정의된 패키징 설정을 그대로 사용할 수 있었고, 추가한 결과물이 기존 FILES 변수에 포함되는 경로에 설치되었기 때문에 별도로 FILES:${PN}을 작성하지 않았다.

Raspberry Pi 4 이미지 빌드 및 결과

유저 애플리케이션 구현과 레시피 파일의 작성을 마쳤다면, 이제 이미지 빌드를 수행하고 이에 대한 결과를 Raspberry Pi 4에서 확인한다.

source path/to/poky/oe-init-build-env build
bitbake core-image-full-cmdline

빌드가 정상적으로 완료되면, rootfs/usr/bin/ 경로에 유저 애플리케이션(hello)이 저장되어 있는 것을 확인할 수 있다.

이제 빌드가 완료된 이미지 파일(.wic.bz2)을 SD 카드에 구워준다. 이를 위해 다음 명령을 사용한다.

※ SD 카드는 fdisk 명령 등을 활용해 완전히 초기화된 상태로 사용하는 것을 권장한다.

cd path/to/poky/build/tmp/deploy/images/raspberrypi4/
bzcat core-image-full-cmdline-raspberrypi4.wic.bz2 | sudo dd of=/dev/sde

이미지 굽기가 끝났다며 이제 SD 카드를 Raspberry Pi 4에 꽂은 후 부팅한다. 부팅을 하게 되면 앞 8장 과정에서 진행하였던 와이파이 연결을 활용해 Raspberry Pi 4로 원격으로 접근한 뒤 hello 결과를 확인한다. 기본적으로 이미지에서 SSH 서버를 제공하고 있을 것이므로 IP 주소를 활용해 원격 접근하면 된다.

# powershell 등 터미널 프로그램 활용

ssh root@<ip_address>

원격 접근을 하였다면 이제 hello 명령을 실행시켜서 결과를 확인한다.

끝.

Yocto 학습을 끝마치며

임베디드 리눅스 개발자는 필요한 디바이스 드라이버를 직접 구현하고, 해당 드라이버를 활용하는 애플리케이션까지 함께 개발할 수 있어야 한다고 생각한다. 나아가 이를 빌드 시스템에 통합하여 최종적으로 이미지 형태로 배포할 수 있는 역량도 중요하다.

또한 애플리케이션 개발 과정에서 필요한 네트워크, 이미지, 오디오 등 특수 목적 라이브러리를 크로스 컴파일 환경에서 사용할 수 있도록 구성하고, 동적 라이브러리의 경우 타깃 이미지에 함께 포함되도록 배포 구조를 설계할 수 있어야 한다.

뿐만 아니라 특정 하드웨어 장치에 맞는 리눅스 BSP를 구성하는 능력도 필요하다. 즉, 부트로더, 커널, 디바이스 드라이버와 같은 저수준 소프트웨어 요소를 하드웨어 특성에 맞게 설정하고 빌드하여, 안정적으로 동작하는 임베디드 리눅스 시스템을 구축할 수 있어야 한다고 생각한다.

이번 Yocto 학습은 내가 앞으로 어떤 역량을 더 갖춰야 하는지 명확히 인식하게 해준 과정이었다. 지금까지는 주로 드라이버와 애플리케이션 개발 역량을 중심으로 학습해왔지만, 임베디드 리눅스 시스템을 실제 제품 수준으로 구성하기 위해서는 그보다 더 넓은 관점이 필요하다는 것을 알게 되었다. 드라이버와 애플리케이션을 빌드 시스템에 통합하고, 필요한 라이브러리를 크로스 컴파일 환경에 맞게 구성하며, 최종 이미지를 생성하고, 하드웨어에 맞는 BSP까지 다룰 수 있어야 비로소 하나의 완성된 임베디드 리눅스 시스템을 구축할 수 있다고 생각한다. 따라서 앞으로는 현재의 역량에 만족하지 않고 Yocto, BSP, 커널, 라이브러리 통합, 이미지 배포 과정까지 지속적으로 학습하며 더 깊이 있는 임베디드 리눅스 개발자로 성장해 나가야겠다.

[Yocto 학습] 8장: Poky를 활용한 Raspberry Pi 4 와이파이 초기화

pak-ji — Fri, 29 May 2026 14:15:08 +0900

개요

Poky로 빌드된 Raspberry Pi 4의 이미지는 기본적으로 유선 이더넷 드라이버를 커널 빌트인 형태로 제공하지만, 와이파이 드라이버는 커널 모듈 형태로 제공한다. 하지만, 이미지를 빌드 후 rootfs를 살펴보면 와이파이 드라이버가 관련 디렉터리(/lib/modules/…/drivers/…)에 존재하지 않아 실질적으로 Raspberry Pi 4의 내장 와이파이를 유저가 사용하지 못하는 문제가 발생한다.

이를 해결하기 위해선 두가지 방법이 존재한다.

와이파이 드라이버/유틸리티가 빌트인으로 컴파일 될 수 있도록 커널 컴파일 옵션 조정
와이파이 드라이버/유틸리티가 모듈로 제공되도록 비트베이크 빌드 옵션 조정

위에서 1.의 방법은 커널 자체를 재컴파일해야 됨으로 오랜 시간이 걸린다. 하지만 1.과 다르게 2.의 방식은 기존에 컴파일되어 있는 드라이버와 유틸리티가 이미지의 rootfs에 포함될 수 있게끔만 하면 되기 때문에 비교적 빠르게 결과를 확인할 수 있다.

따라서, 본 페이지에서는 2.의 방법으로 Raspberry Pi 4의 내장 와이파이를 유저 영역에서 사용할 수 있게끔 관련 드라이버와 유틸리티를 모듈 형태로 이미지(rootfs)에 포함되게끔 하는 방법을 설명한다.

※ 본 페이지는 앞 7장의 내용에 이어서 설명하는 페이지이기 때문에 이해를 돕기 위해선 7장의 내용을 숙지하고 오는 편이 좋다.

Raspberry Pi 4 내장 와이파이 모듈 조사

와이파이 드라이버를 이미지에 등록하기 위해선 가장 먼저, Raspberry Pi 4에서 사용 중인 내장 와이파이 모듈에 대한 정보를 알아야한다.

이를 위해, ChatGPT(든든한 녀석..)에 물어보니 Broadcom BCM43455 계열의 와이파이 모듈인 CYW43455를 사용하는 것을 확인할 수 있었고, 해당 모듈의 드라이버는 brcmfmac이라는 것을 알 수 있었다.

이와 관련된 패키지가 존재하는지 찾아보기 위해 아래 명령을 활용하였다.

source path/to/poky/oe-init-build-env build
oe-pkgdata-util list-pkgs | grep bcm43455
oe-pkgdata-util list-pkgs | grep brcmfmac

명령어 실행 결과 linux-firmware-bcm43455와 kernel-module-brcmfmac이라는 패키지가 존재하는 것을 찾을 수 있었다.

커널 모듈을 나타내는 패키지의 경우 일반적으로 kernel-module-* 이라는 접두사가 붙는다.

이제, 이 패키지들을 앞 7장에서 빌드를 완료한 Raspberry Pi 4 이미지에 등록될 수 있도록 새로운 레이어를 생성하고 함께 빌드될 수 있도록 해준다. 이에 대한 설명은 다음 섹션에서 이어서 진행한다.

Raspberry Pi 4 사용자 설정을 위한 커스텀 레이어 생성

Poky(Yocto) 기반의 프로젝트의 경우, 이미지의 수정이나 드라이버 및 애플리케이션 추가를 위해선 새로운 레이어를 생성하는 것이 일반적이다. 따라서, 본 섹션에서는 와이파이 드라이버와 유틸리티를 추가로 이미지에 빌드시키기 위해 커스텀 레이어(meta-custom)를 새로이 생성한다.

새 레이어를 생성하기 위해 다음 명령을 따른다.

레이어 이름의 경우 주로 meta-* 접두사를 붙이는게 일반적이다. (Optional)

source path/to/poky/oe-init-build-env build

# 새 레이어 생성
bitbake-layers create-layer path/to/poky/meta-custom

# 생성된 새 레이어를 빌드에 추가 (build/conf/bblayers.conf에 자동으로 레이어 경로가 등록됨)
bitbake-layers add-layer path/to/poky/meta-custom

새 레이어(meta-custom) 생성을 마치면 기본적으로 recipes-example이라는 디렉터리가 존재하지만, 본 페이지에서는 recipes-example 디렉터리를 삭제 후 아래 사진과 같은 구성으로 레시피 디렉터리와 파일을 생성하였다.

아래와 같은 구성으로 디렉터리와 파일을 미리 구성해두면, 본 페이지에서 설명하는 내용을 따라오기 편할 것이기 때문에 미리 새 레이어를 아래와 같은 구성으로 생성(mkdir와 touch 명령을 활용하여)해두는 것을 추천한다. 각 레시피 파일(.bb, .bbappend)의 세부 내용은 다음 섹션에서 찬찬히 설명한다.

레시피 파일이 저장된 각 디렉터리의 역할은 다음과 같다.

recipes-applications
- 사용자 예제 애플리케이션(hello)을 이미지에 빌드시키기 위해 활용
- 본 페이지(8장)에서는 설명하지 않으며, 다음 9장에서 설명할 예정
recipes-connectivity
- 와이파이 연결을 위한 설정 파일을 이미지에 빌드시키기 위해 활용
recipes-core
- 와이파이 연결을 위한 드라이버/유틸리티를 이미지에 빌드시키기 위해 활용

이제 각 레시피 파일에 어떠한 세부 내용들이 작성되어야 와이파이 드라이버와 유틸리티 그리고 설정 파일이 이미지에 함께 빌드될 수 있는지 설명한다.

Raspberry Pi 4 와이파이 드라이버 및 유틸리티 패키지 등록

가장 먼저, 이미지 빌드 시에 와이파이 드라이버와 유틸리티가 이미지에 포함될 수 있도록 해주어야 한다. 그러기 위해선 기존 이미지 레시피 파일에 내용을 추가해주어야 한다. 앞 장에서부터 이미지 레시피는 core-image-full-cmdline을 사용하였기 때문에 이를 기준으로 설명한다.

기존 core-image-full-cmdline.bb 레시피 파일은 poky/meta/recipes-extended/images/ 하위에 위치한다.

기존 이미지 파일에 내용을 추가하기 위해 .bbappend 파일을 생성한다.

vi path/to/poky/meta-custom/recipes-core/images/core-image-full-cmdline.bbappend

.bbappend 형태로 파일을 생성하였기 때문에, 기존 core-image-full-cmdline.bb 파일이 빌드 과정에서 파싱된 후 이어서 동일한 패키지 명을 가진 .bbappend 파일이 파싱된다. 여기서 주요한 점은 반드시 core-image-full-cmdline으로 .bbappend 파일을 생성해야 한다. 그렇지 않으면, 비트베이트는 다른 패키지라고 인식을하고 기존 이미지 파일(core-image-full-cmdline)과는 다른 패키지에 대한 레시피 파일(.bbappend)이라고 판단하게 되는 문제가 발생한다.

생성한 core-image-full-cmdline.bbappend 파일 내부에는 아래와 같이 내용을 작성한다. 앞서 살펴보았던 드라이버 관련 패키지와 함께 와이파이 유틸리티 패키지를 이미지에서 추가로 빌드할 수 있도록 하는 줄이다.

IMAGE_INSTALL 변수는 CORE_IMAGE_EXTRA_INSTALL 변수와 유사한 역할을 하며, 이미지 빌드 시 추가될 패키지를 정의하기 위해 사용된다. (5장 참조)

IMAGE_INSTALL:append = " linux-firmware-bcm43455 kernel-module-brcmfmac wpa-supplicant"

이제 이미지가 “bitbake core-image-full-cmdline” 명령으로 빌드될 때 Raspberr Pi 4의 내장 와이파이 모듈을 동작시키기 위한 관련 드라이버와 유틸리티를 자동으로 rootfs에 설치할 것이다. 다음 섹션에서는 Raspberry Pi 4에서 접근할 와이파이 AP에 대한 설정 파일이 이미지에 함께 빌드될 수 있도록 하는 방법을 설명한다.

Raspberry Pi 4 와이파이 설정 파일 오버라이딩

Poky로 빌드한 Rasbperry Pi 4 이미지의 경우 네트워크 인터페이스를 관리하기 위해 ifupdown와 wpa_suppilcant 유틸리티를 활용한다. 여기서 ifupdown의 경우에는 기본적으로 Raspberry Pi 4 이미지가 빌드될 때 함께 설치가 되지만 wpa_supplicant는 함께 설치되지 않는다. 그렇기 때문에 앞 섹션에서 IMAGE_INSTALL에 wpa-supplicant 패키지가 빌드될 수 있도록 해주었다.

Yocto에서 패키지명의 언더바(_) 뒤에는 패키지버전(PV)을 나타내는 곳이기 때문에 기존 wpa_supplicant라는 이름을 가진 유틸리티는 Yocto에서 wpa-supplicant라는 이름으로 관리된다.

ifupdown은 init-ifupdown 이라는 패키지명으로 관리되고 있는 것을 “oe-pkgdata-util find-path /etc/network/interfaces” 명령을 활용해 확인하였다. 이 /etc/network/interfaces 파일은 ifupdown 유틸리티가 특정 네트워크 인터페이스를 활성화시킬 때 참조하는 설정 파일이다.

기존의 /etc/network/interfaces는 위와 같은 내용으로 작성되어 있다. 여기서 중점적으로 볼 부분은 wlan0 인터페이스이다. 이 파일에서는 wlan0 인터페이스를 부팅 과정에서 자동으로 활성화 시켜주지 않고 있으며, 또한 “ifup wlan0”와 같은 명령으로 wlan0 인터페이스가 활성화 될 때에는 /etc/wpa_supplicant.conf 파일을 참조하여 wlan0 인터페이스를 초기화하는 것까지 파악하였다.

본 과정에서는 이 /etc/network/interfaces 파일을 아래와 같은 내용으로 오버라이딩 될 수 있도록, 새 interfaces 파일을 생성한다.

vi path/to/poky/meta-custom/recipes-connectivity/init-updown/files/interfaces

새로이 생성된 interfaces 파일은 아래와 같은 내용으로 작성한다. 이 파일은 wlan0 인터페이스가 부팅 과정에서 자동으로 활성화(auto wlan0) 될 수 있도록 하고, 활성화 과정에서는 /etc/wpa_supplicant.conf 파일을 참조하여 초기화 될 수 있도록 한다.

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wireless interfaces
auto wlan0
iface wlan0 inet dhcp
        wpa-conf /etc/wpa_supplicant.conf

# Wired or wireless interfaces
auto eth0
iface eth0 inet dhcp
iface eth1 inet dhcp

이제 생성된 interfaces 파일이 기존의 /etc/network/interfaces 파일을 오버라이딩 할 수 있도록 하기 위해 .bbappend 파일을 아래와 같이 생성해준다.

vi path/to/poky/meta-custom/recipes-connectivity/init-updown/init-updown_%.bbappend

생성한 init-updown_%.bbappend 파일의 내용은 아래와 같이 작성해준다. 이 레시피 파일은 기존의 init-updown.bb 레시피 파일의 do_install()이 끝난 후 실행된다. 그렇기 때문에 기존의 /etc/network/interfaces 파일을 새 interfaces 파일로 덮어쓸 수 있게된다.

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://interfaces"

do_install:append() {
    install -m 0644 ${WORKDIR}/interfaces ${D}${sysconfdir}/network/interfaces
}

init-updown 패키지의 오버라이딩을 위한 관련 파일 생성을 마쳤다면, 이제 앞선 방법과 동일한 방식으로 wpa_supplicant.conf 파일이 /etc/ 하위에 오버라이딩하는 방법을 설명한다.

가장 먼저, 새 wpa_supplicant.conf 파일을 생성해준 뒤 Raspberry Pi 4에서 접근할 와이파이 AP에 대한 SSID와 PW를 wpa_passphrase 명령으로 생성해준다.

cd path/to/meta-custom/recipes-connectivity/wpa-supplicant/files/
touch wpa_supplicant.conf
wpa_passphrase “SSID” “PW” >> wpa_supplicant.conf

생성된 wpa_supplicant.conf 내용은 아래 파일과 같은 형식으로 작성되어야 한다. 이 페이지를 따라하는 독자 환경에서의 와이파이 AP에 대한 SSID와 PW는 다를 것이므로 network = {} 내부의 내용은 다를 것이다. 하지만, 가장 윗 줄의 ctrl_interface는 동일하게 작성되어야 하므로 추가로 작성해준다.

ctrl_interface=DIR=/var/run/wpa_supplicant

# Typical minimal wifi setup:
network={
        ssid="KT_GiGA_5G_61DA"
        key_mgmt=WPA-PSK
        psk=c1eecfdaada84f88402828aeabe864cf3bc8e9ebf98365039dd59d5e3c802066
}

이제 생성된 wpa_supplicant.conf 파일이 기존의 /etc/wpa_supplicant.conf 파일을 오버라이딩 할 수 있도록 하기 위해 .bbappend 파일을 아래와 같이 생성해준다.

vi path/to/poky/meta-custom/recipes-connectivity/wpa-supplicant/wpa-supplicant_%.bbappend

생성한 wpa-supplicant_%.bbappend 파일의 내용은 아래와 같이 작성해준다. 이 레시피 파일은 기존의 wpa-supplicant.bb 레시피 파일의 do_install()이 끝난 후 실행된다. 그렇기 때문에 기존의 /etc/wpa_supplicant.conf 파일을 새 wpa_supplicant.conf 파일로 덮어쓸 수 있게된다.

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://wpa_supplicant.conf"

do_install:append() {
    install -m 0600 ${WORKDIR}/wpa_supplicant.conf ${D}${sysconfdir}/wpa_supplicant.conf
}

이제 Raspberry Pi 4의 내장 와이파이 모듈을 사용하기 위한 드라이버와 유틸리티 그리고 설정 파일을 이미지에 빌드시키기 위한 모든 준비 과정을 마쳤다. 다음 섹션에서는 실제 빌드를 수행 후 이미지를 SD 카드에 구운 뒤 Raspberry Pi 4에서 어떠한 결과가 나타나는지 확인한다.

Raspberry Pi 4 이미지 빌드 후 부팅 결과

앞 섹션 과정을 이미지에 빌드 시키기 위해 아래 명령을 실행한다.

source path/to/poky/oe-init-build-env build
bitbake core-image-full-cmdline

이미지 빌드를 성공적으로 마쳤다면, 빌드가 완료된 이미지가 저장된 경로에 위치한 .wic.bz2 파일을 SD 카드에 구워준다. 이를 위해 다음 명령을 사용한다.

※ SD 카드는 fdisk 명령 등을 활용해 완전히 초기화된 상태로 사용하는 것을 권장한다.

cd path/to/poky/build/tmp/deploy/images/raspberrypi4/
bzcat core-image-full-cmdline-raspberrypi4.wic.bz2 | sudo dd of=/dev/sde

이미지 굽기가 끝났다며 이제 SD 카드를 Raspberry Pi 4에 꽂은 후 부팅한다. 부팅 후 dmesg와 ip a 명령을 실행하면 관련 와이파이 드라이버가 실행된 결과를 커널 로그에 찍혀있는 것을 확인할 수 있으며, 동시에 wlan0 인터페이스가 자동으로 AP를 찾은 후 IP 주소를 할당받은 것을 확인 가능하다.

[Yocto 학습] 7장: Poky를 활용한 Raspberry Pi 4 이미지 빌드

pak-ji — Tue, 26 May 2026 14:18:09 +0900

개요

필자는 Yocto 학습을 위해 Windows 11 머신을 활용하고 있는 중이다. 그래서 WSLv2를 설치하고 그 위에 Ubuntu를 올려서 학습 환경을 구성하였다.

만약, 베어메탈로 Ubuntu 머신을 구성해서 사용한다면 Raspberry Pi 4의 SD 카드를 머신에서 구울 때 Passthrough가 필요 없겠지만, 앞서 설명하였다시피 필자는 WSL에 Ubuntu를 올려서 Yocto를 학습하고 있는터라 물리적인 장치(SD 카드)를 WSL/Ubuntu에서 인식되게 하려면 Passthrough를 구성하는 과정이 필수적으로 필요하다.

따라서, 본 페이지에서는 WSL/Ubuntu 환경에서 Yocto를 활용해 Raspberry Pi 4의 이미지를 빌드하는 과정을 먼저 설명하고, 그 이후에 SD 카드를 WSL/Ubuntu로 Passthrough하여 이미지를 굽는 과정을 설명한다.

Raspberry Pi 4 이미지 빌드

Raspberry Pi 4 이미지 빌드를 위해 가장 먼저, Poky 빌드 환경을 Git으로부터 다운로드 받는다.

git clone git://git.yoctoproject.org/poky -b kirkstone

Poky 빌드 환경을 다운로드 받았다면, 이제 Raspberry Pi를 빌드를 위한 레이어를 오픈 임베디드 프로젝트로부터 다운로드 받는다.

cd poky
source oe-init-build-env build
bitbake-layers layerindex-fetch meta-raspberrypi

Poky 빌드 환경과 Raspberry Pi 빌드 레이어를 다운로드 받았다면, 이제 Bitbake가 빌드를 수행할 때 Raspberry Pi 4 머신을 타겟으로 빌드할 수 있도록 설정 파일(conf/local.conf)을 수정한다.

vi build/conf/local.conf

이제 Raspberry Pi 4 빌드를 위해 Bitbake 명령으로 이미지 빌드를 수행한다. (꽤 오랜 시간 걸림.. WSL 환경 기준)

bitbake core-image-full-cmdline

Raspberry Pi 4 빌드가 완료되었다면 .wic.bz2 형식의 이미지 파일이 생성되었을 것이다. .wic 형식은 이미지 구성을 위한 디스크의 파티션 분할과 각 파티션에 대한 파일 포맷을 정의하기 위해 사용한다. Linux의 dd 명령은 이 .wic에 정의된 이미지 구성을 참조하여 SD 카드를 굽는다. (bz2는 압축 파일 형식이다.)

생성된 이미지 파일(.wic.bz2)은 poky/build/tmp/deploy/images/raspberrypi/ 하위에 위치한다.

이제, 이미지를 SD 카드에 굽기 위해 WSL/Ubuntu 환경으로 SD 카드를 Passthrough 하는 과정을 설명한다. 만약, 본인의 머신이 Passthrough가 굳이 필요하지 않는 환경이라면 다음 섹션(SD 카드를 WSL/Ubuntu로 Passthrough)은 생략하면 된다.

SD 카드를 WSL/Ubuntu로 Passthrough

Windows 머신에서 Powershell을 관리자 모드로 실행시킨 후 아래 명령을 입력한다.

winget install dorssel.usbipd-win

usbipd-win은 Windows 머신에 꽂힌 SD 카드를 WSL로 Passthrough하기 위해 사용하는 툴이다. 해당 툴을 다운로드 받은 뒤 SD 카드가 꽂힌 슬롯의 BUSID를 찾는다.

usbipd list

필자는 Windows 머신으로 삼성 갤럭시북을 사용하고 있으며, 이 갤럭시북에서 제공하는 SD 카드 슬롯은 Genesys Logic USB3.9 Card Reader로 인식된다. 인식된 슬롯은 BUSID는 2-16임을 최종적으로 확인하였다.

확인된 BUSID 값을 활용해 다음 명령을 통해 WSL 환경으로 Passthrough 한다. Passthrough 과정에서 WSL/Ubuntu 머신은 반드시 켜져있어야 한다.

usbipd bind --busid 2-16
usbipd attach --wsl --busid 2-16

이제 WSL/Ubuntu 머신에서 아래 명령을 실행시키면 SD 카드가 정상적으로 인식되는 것을 확인가능하다.

lsblk

위 그림에서 볼 수 있듯이 필자가 사용하던 SD 카드는 FAT32 형식으로 포맷되어 있다. 그래서 FAT32으로 포맷된 파티션을 제거하여 완전히 초기화된 상태의 SD 카드로 만들어주었다.

sudo fdisk /dev/sde

### fdisk 명령 ###
d # 디스크의 파티션 삭제
p # 디스크의 현재 파티션 확인
w # 디스크를 현재 상태로 저장 후 종료

이제 앞 섹션에서 생성한 이미지 파일(.wic.bz2)을 SD 카드로 구워준다. 굽는 과정은 다음 섹션을 참조하면 된다.

SD 카드에 Raspberry Pi 4 이미지 굽기

SD 카드에 Raspberry Pi 4 이미지를 굽기 위해서 dd 명령을 다음과 같이 활용한다.

bzcat core-image-full-cmdline-raspberrypi4.wic.bz2 | sudo dd of=/dev/sde

SD 카드로 이미지가 정상적으로 구워졌는지 확인하기 위해 lsblk와 mount 명령을 사용할 수 있다.

이제, Raspberry Pi 4 이미지가 구워진 SD 카드를 하드웨어(Raspberry Pi 4)에 꽂은 후 전원을 인가하여 부팅을 수행한다. 결과는 다음 섹션을 참조하면 된다.

구워진 SD 카드로 Raspberry Pi 4 부팅

하드웨어(Raspberry Pi 4)에 이미지가 구워진 SD 카드를 꽂은 후 전원을 인가하면, HDMI 케이블을 통해 다음과 같은 화면이 출력되는 것을 확인가능하다.

부팅이 완료된 후에는 계정명을 root로 입력하면 쉘이 실행되는 것을 확인할 수 있다.

※ 다음 장부터는 본 페이지에서 구성한 Raspberry Pi 4의 Poky 빌드 환경을 활용해 기본적인 WiFi 설정(8장)과 Hello 예제 애플리케이션(9장)을 빌드하여 이미지에 등록하는 방법에 대해서 설명한다.

트러블슈팅

gcc와 binutils 크로스컴파일 과정 중 의존성 문제 발생

이미지가 빌드되는 과정 중 gcc와 binutils 패키지가 정상적으로 빌드되지 않고 종료된 것을 확인하였다. 이를 위해 빌드 로그를 분석해보니 주로 링커가 라이브러리를 연결하는 과정에서 문제가 발생한 것이였다. WSL 환경에서 빌드를 수행하다보니 한정된 메모리를 사용하는 것이 문제가 된 것 같다. 그래서 이를 해결하고자 아래와 같은 방법으로 gcc와 binutils에 대한 빌드 캐시를 삭제하고 다시 설치를 진행하였다.

[Yocto 학습] 6장: 레시피(.bb, .bbappend) 커스터마이징 방법 - 2

pak-ji — Tue, 12 May 2026 16:48:14 +0900

.bbappend 레시피의 사용 목적

일반적으로 프로젝트에는 필요한 기능을 이미 제공하는 일련의 레이어가 존재한다. 이러한 기존의 레이어에서 특정 요구사항을 반영하기 위해 변경을 가해야한다.
이를 위해서 .bbappend 파일을 활용 할 수 있으며, 이를 통해 기존 레이어 구조를 유지한 채로 변경이 가능하다.
.bbappend의 파일명에는 % 와일드카드를 사용할 수 있으며, 주로 패키지의 버전별로 요구사항을 반영할 때 활용가능하다.
예를 들어, app_1.2.3.bb 파일이 존재할 때 다음과 같은 규칙으로 .bbappend 파일을 생성할 수 있다.

.bbappend로 .bb에 작성된 태스크 확장방법

앞 “3장: 비트베이크 문법”에서 :append와 :prepend 키워드를 살펴보았었다.
이 두 키워드는 변수의 확장뿐만 아니라 태스크의 확장 또한 가능하다.

do_install:append() {
	# append task
}

예를 들어, 기존 레시피의 do_install()에 추가 태스크를 작업하려면 위와 같이 작성 가능하다.

.bbappend로 .bb에 작성된 빌드 옵션 수정 방법

Yocto 프로젝트의 경우 다양한 Make, Cargo, Autotools 등 다양한 빌드 시스템을 제공한다. 따라서, Yocto에서는 이를 위해 각 빌드 시스템의 빌드 옵션을 수정할 수 있는 변수들을 제공한다.

빌드 시스템	변수
Autotools	EXTRA_OECONF
Cargo	EXTRA_OECARGO
CMake	EXTRA_OECMAKE
Make	EXTRA_OEMAKE
Meson	EXTRA_OEMESON
NPM	EXTRA_OENPM
SCons	EXTRA_OESCONS
WAF	EXTRA_OEWAF

Autotools 기반의 애플리케이션을 빌드하기 위한 빌드 옵션은 다음과 같이 작성할 수 있다.

# 새 기능 활성화 및 예전 기능 비활성화
EXTRA_OECONF += “--enable-new-feature --disable-old-feature”

# arm 환경일 경우, 새 기능 활성화
EXTRA_OECONF:append:arm = “--enable-new-feature”

.bbappend로 .bb에 작성된 소스에 패치를 적용하는 방법

새 패치를 적용해야 하는 경우, 패치 파일을 비트베이크가 찾을 수 있도록 해주어야 한다.
비트베이크는 패키지를 빌드하기 위한 소스 파일의 경로를 FILESPATH 변수로 검색한다.
레시피에서는 일반적으로 FILESPATH를 건들이지 않고 FILESEXTRAPATH를 수정한다.

# 예시 1. 새 패치 적용 방법

FILESEXTRAPATHS:prepend := “${THISDIR}/${PN}-${PV}:”
SRC_URI += “file://newpatch.patch”

—
# 예시 2. 새 설정 설치 방법

FILESEXTRAPATHS:prepend := “${THISDIR}/${PN}-${PV}:”
SRC_URI += “file://newconfig.conf

do_install:append() {
install -D -m 644 ${WORKDIR}/newconfig.conf ${D}${sysconfdir}/newconfig.conf
}

예시 1은 새 패치를 적용하기 위한 .patch 파일을 등록하는 .bbappend 예시이다.
예시 2는 새 설정을 이미지에 설치하기 위한 .conf 파일을 등록하는 .bbappend 예시이다.
예시 1과 2에 사용된 THISDIR과 PN 그리고 PV 변수는 다음과 같은 역할을 한다.
- THISDIR: 현재 .bbappend가 위치한 디렉터리 경로
- PN: 패키지 이름 (Ex. app_1.2.3.bbappend에서 app 부분)
- PV: 패키지 버전 (Ex. app_1.2.3.bbappend에서 1.2.3. 부분)
비트베이크는 패키지를 빌드하기 위한 소스 파일을 다음과 같은 순서로 검색한다.
1. <recipe>-<version>/
2. <recipe>/
3. files/

주로 패치 파일은 <recipe>/files/ 하위에 존재한다.

FILESPATH 혹은 FILESEXTRAPATH 등과 같은 변수가 잘 설정되었는지 확인하기 위해 bitbake-getvar 명령을 확인해볼 수 있다.

레시피에서 참조하는 rootfs 경로 변수

아래 예시와 같이 레시피에 sysconfdir 등의 경로 변수가 사용되는 경우가 존재한다.
이는 일반적인 리눅스의 rootfs 이미지의 루트(/) 경로를 기반한다.

변수	기본 경로
base_bindir	/bin
base_sbindir	/sbin
sysconfdir	/etc
localstatedir	/var
datadir	/usr/share
bindir	/usr/bin
sbindir	/usr/sbin
libdir	/usr/lib 또는 /usr/lib64
libexecdir	/usr/libexec
includedir	/usr/include

기본적으로 이 경로들은 poky/meta/conf/bitbake.conf 파일에서 시작되어 설정된다.

FILESEXTRAPATHS:prepend := “${THISDIR}/${PN}-${PV}:”
SRC_URI += “file://newconfig.conf

do_install:append() {
install -D -m 644 ${WORKDIR}/newconfig.conf ${D}${sysconfdir}/newconfig.conf
}

예를 들어, 위와 같은 .bbappend 레시피 파일이 존재할 경우,
- ${D}${sysconfdir}은 /tmp/.../image/etc/를 나타낸다.
- 이렇듯 레시피 결과물은 rootfs 구조를 따라 최종적으로 이미지로 변환되기 전에 임시 저장된다.

레시피를 활용해 커널 컴파일 옵션을 변경하는 방법

리눅스 커널은 오픈소스로 관리되는 커널이기 때문에 매우 방대한 소스를 가지고 있다.
그렇기에 커널 컴파일 옵션 설정 또한 패키지 관리에 중요한 능력이라고 볼 수 있다.
본 절에서는 리눅스 커널 컴파일 옵션을 .cfg 파일로 생성하는 방법을 알아본다.
가장 먼저, 아래 명령을 통해서 커널 컴파일 옵션 메뉴를 실행시킨다.

$ bitbake virtual/kernel -c menuconfig

컴파일 옵션 메뉴를 실행시켰으면, 필요한 옵션을 활성화/비활성화한다.
본 절에서는 커널에 CAN 버스를 활성화시키는 것을 예시로 든다.

menuconfig을 통해 CAN 버스를 활성화하였다면 Save하여 .config 파일로 저장한다.
그후 아래 명령을 통해서 기존 컴파일 옵션과 다른 부분을 .cfg 파일로 생성해낸다.

$ bitbake virtual/kernel -c diffconfig

생성된 설정 파일(.cfg)에 대한 경로가 출력되는 것을 볼 수 있다.

.cfg 파일은 일반적인 리눅스 커널 컴파일을 위한 설정 파일과 동일한 형식임을 확인가능하다.
이렇게 생성된 .cfg 파일과 .bbappend 레시피 파일을 함께 활용해 커널 등의 컴파일 옵션을 수정 가능하다.
이는 KConfig을 활용하는 여러 프로젝트(U-Boot, Linux Kernel, BusyBox 등)에서 활용가능한 방법이다.

# 다음 장에서는 실제로 레이어를 구성하고 이를 위한 레시피를 작성해서 컴파일을 완료한 뒤에 라즈베리파이를 부팅시키는 예제를 설명한다.

[Yocto 학습] 5장: 레시피(.bb, .bbappend) 커스터마이징 방법 - 1

pak-ji — Tue, 12 May 2026 16:15:44 +0900

레시피의 종류

비트베이크의 레시피에는 두 종류의 레시피가 존재하며, 각 레시피는 간략히 다음과 역할을 한다.
- Image 레시피: 패키지들을 묶어 최종 파일 시스템 구조(rootfs)를 생성
- Package 레시피: 소스코드를 가져와 컴파일하고 하나의 패키지로 생성

Image 레시피

# 1.

require recipes-extended/images/core-image-full-cmdline.bb

IMAGE_FEATURES:remove = "splash"
CORE_IMAGE_EXTRA_INSTALL += "myapp"

-------------------------
# 2.

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh splash"
CORE_IMAGE_EXTRA_INSTALL += "strace myapp"

Image 레시피는 기본적으로 위와 같은 구조를 가진다.
1.의 경우, 기존의 core-image-full-cmdline 레시피를 그대로 불러와 이를 수정하는 방법이다.
2.의 경우, 이미지 생성을 위한 새 레시피를 작성하는 방법이다. 이땐 core-image를 레시피에서 상속한다.
위 레시피에 사용된 IMAGE_FEATURES와 CORE_IMAGE_EXTRA_INSTALL 변수는 다음의 역할을 한다.
IMAGE_FEATURES
- 이미지에 특정한 기능을 활성화하기 위해 사용하는 변수이다.
- allow-root-login: SSH로 Root로 로그인할 수 있게 허용해주는 기능
- allow-empty-password: SSH에서 빈 암호를 사용해 Root로 로그인할 수 있게 허용해주는 기능
- empty-root-password: 빈 암호로 Root로 로그인 하기 위해 활성화 해줘야하는 기능
- serial-autologin-root: 시리얼 콘솔에서 자동으로 Root로 접근을 허용해주는 기능
- dbg-pkgs: 이미지에 설치된 모든 패키지에 디버그 심볼을 설치하는 기능
- 이 외에도 더 많은 기능을 제공하며 다음 링크를 참조하면 된다. → 링크
CORE_IMAGE_EXTRA_INSTALL
- 이미지에 새 패키지를 등록하기 위한 변수이다.
- Package 레시피로 작성된 패키지를 해당 변수에 등록해주면 된다.
- 여기에 패키지가 등록되어야, Package 레시피가 빌드 시스템에 의해 빌드된다.
- 레시피 간의 의존 관계(DEPENDS, RDEPENDS 등)에 따라서도 Package 레시피는 빌드되기도 한다.

Package 레시피

DESCRIPTION = "Simple Helloworld Application"
SECTION = "examples"
LICENSE = "MIT"

SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "a1b2c3d4e5f6g7h8i9j0..."
SRC_URI[sha256sum] = "z9y8x7w6v5u4t3s2r1q0..."

S = "${WORKDIR}"

do_compile() {
	${CC} helloworld.c -o helloworld
}

do_install() {
	install -D -m 0755 helloworld ${D}${bindir}/helloworld
}

Image 레시피 혹은 의존 관계에 따라 Package 레시피는 비트베이크에 의해서 빌드가 진행된다.
위 Package 레시피는 이미지에 등록될 때 /usr/bin 하위에 바이너리 실행 파일로 등록되는 예제이다.
Package 레시피에서 사용되는 SRC_URI, D, bindir 등의 변수는 다음과 같은 역할을 한다.
SRC_URI
- 빌드 과정 중 do_fetch 태스크 과정에서 소스코드를 다운로드받는 경로를 지정
- SRC_URI[md5sum, sha256sum]은 다운로드 받은 소스가 변경되지 않았는지 확인하기 위한 목적
- 이 변수에 대한 자세한 내용은 "[Yocto 학습] 2장"을 참고
D
- 임시 rootfs 경로를 나타냄
- 기본적으로 build/tmp/work/.../<recipe>/<version>/imgae/ 경로로 설정됨
bindir
- rootfs 중 /usr/bin 경로를 가리킴
- ${bindir} 말고도 ${base_bindir}, ${base_sbindir} 등 다양한 rootfs 경로를 비트베이크에서 제공함
- 다양한 rootfs 경로는 다음 장에서 이어서 설명

autotools 클래스

Autotools 기반 프로젝트를 자동으로 configure/build/install 해주는 표준 클래스이다.
즉, autoconf와 automake 그리고 libtool 기반의 프로젝트의 자동 빌드를 수행해준다.
대표적으로 소스에 configure.ac, Makefile.am 등 있는 경우 자동 빌드를 수행해준다.

dbus-wait 패키지를 예로 들자면, 해당 패키지는 autoconf와 automake 기반의 프로젝트이다.
따라서, 패키지의 소스에는 configure.ac와 Makefile.am이 존재한다.
이 패키지를 빌드하기 위해서 위 캡쳐와 같이 레시피에서는 inherit autotools을 사용하는 것을 볼 수 있다.
inherit은 특정 클래스를 레시피에서 상속받아 사용하기 위한 키워드이다.

※ 다음 장에서는 레시피의 태스크 확장, 소스 패치, rootfs 경로 변수 등을 설명한다.

[Yocto 학습] 4장: 레이어(meta-*) 생성 방법

pak-ji — Sun, 10 May 2026 22:03:35 +0900

레이어 종류

Poky에는 총 3개 종류의 레이어(BSP, Distro, Software)가 존재하며, 이에 대한 설명은 본 절에서 진행한다.
간략하게 각 레이어의 역할은 다음과 같다.
- BSP: 하드웨어(보드)를 부팅시키기 위한 패키지(부트로더, 커널 등)를 정의 (하드웨어에 완전 종속)
- Distro: OS에서 어떠한 정책으로 시스템을 운영할 것인지를 정의 (하드웨어에 일부 종속)
- Software: 서비스하려는 시스템이 어떠한 기능들을 제공할 것인지를 정의 (하드웨어에 완전 독립)

BSP(Board Support Package) 레이어

특정 하드웨어(보드)를 부팅하고 동작시키기 위한 하드웨어 지원 레이어이다.
Poky를 다운로드 받으면 기본적으로 meta-yocto-bsp라는 레이어가 존재한다.
meta-yocto-bsp에는 머신 설정 파일과 패키지 등 BSP를 위한 레퍼런스로 활용 가능하다.

Distro(배포판) 레이어

rootfs read-only, package format(rpm/deb 등), debug symbol 추가 등 OS 정책을 정의하는 레이어이다.
Poky를 다운로드 받으면 기본적으로 meta-poky라는 레이어가 존재한다.
새 제품을 구성할 때에 OS의 정책을 설정해야 한다면 meta-poky를 복사해서 주로 사용한다.

Software 레이어

애플리케이션과 라이브러리 등 기능 패키지를 제공하는 레이어이다.
하드웨어에 종속되지 않으며 독립적으로 구성가능한 레이어이다.
meta-java, meta-qt5, meta-browser 등 다양한 Software 레이어가 존재한다.
Software 레이어는 Poky를 다운로드 받을 때 기본적으로 제공되지 않는다.
따라서, Software 레이어는 필요에 따라 새로 작성하거나 다운로드 받아 사용한다.

외부 레이어 추가 방법

새 레이어를 직접 작성해야하는지 아니면, 기존에 작성된 레이어를 사용해야 되는지 애매한 경우가 있다.
이땐, https://layers.openembedded.org/로 접근하여 필요한 레이어를 새로 작성할 필요가 있는지 확인한다.

위 사이트로 접근하면 오픈임베디드에서 관리하는 여러 레이어를 확인 가능하다.
현재 사용 중인 Poky의 버전(master, kirkstone 등)을 선택한 후 적절한 레이어를 검색하면 된다.

$ git clone <reposiotry-url>

적절한 레이어를 찾았다면, 레이어의 Repository 주소를 사용해 다운로드 받는다.

$ cd path/to/poky/build/
$ bitbake-layers add-layer ../meta-<layer>

레이어를 다운로드 받았다면 빌드 디렉터리로 이동한 후 bitbake-layers add-layer 명령을 실행시킨다.
bitbake-layers add-layer를 실행하면 자동으로 meta-<layer>가 빌드 시스템에 자동 등록된다.

위 캡쳐는 meta-oe와 meta-java 레이어를 다운로드 받은 후 bitbake-layers add-layer로 등록한 결과이다.
bitbake-layers add-layer 명령으로 레이어를 등록하면, 자동으로 build/conf/bblayers.conf가 업데이트된다.
오픈임베디드에서 내려받은 대부분의 레이어의 경우 meta-oe에 종속되므로, 반드시 meta-oe를 먼저 등록해주어야 한다.

새 레이어 생성 방법

만약, 위 절에서 설명한 방법으로 검색해보아도 필요한 레이어가 보이지 않는다면 직접 작성해준다.

$ bitbake-layers create-layer path/to/poky/meta-newlayer

새 레이어를 생성할 때에는 bitbake-layers create-layer라는 명령을 활용한다.
이 명령을 사용할 때에 레이어가 생성될 위치는 반드시 Poky 하위로 설정한다.

$ cd path/to/poky/build/
$ bitbake-layers add-layer ../meta-newlayer

새로운 레이어(meta-newlayer)를 생성하였다면, 이제 빌드 시스템에서 이를 인지할 수 있도록 한다.
앞 절에서 설명하였다시피, bitbake-layers add-layer 명령으로 새 레이어를 빌드 시스템에 인지시킬 수 있다.

새롭게 생성한 레이어가 정상적으로 등록하면 위와 같은 결과를 확인가능하다.

※ 다음 장에서 새롭게 생성한 레이어 내부 메타데이터(레시피 등)를 커스텀하는 방법을 설명한다.

[Yocto 학습] 3장: 비트베이크(bitbake) 문법

pak-ji — Tue, 5 May 2026 20:14:57 +0900

클래스와 레시피

비트베이크는 클래스(.bbclass)와 레시피(.bb, .bbappend) 파일을 작성하기 위해 Python과 Shell Script가 혼합된 형태의 코드를 사용한다.
여기에는 =, ?=, +=, .=, :=, :append, :prepend, OVERRDIES, ${@<python-command>} 등 다양한 문법이 존재한다. 각 문법들이 비트베이크에서는 어떠한 형식으로 해석하는지 본 페이지를 통해 설명한다.

변수 할당

비트베이크의 변수 할당에는 아래와 같이 3가지 타입의 변수 할당 연산자(=, ?=, ??=)가 존재한다.

= (deferred assignment)

지연 변수 할당을 위해 사용하는 연산자이다.
여기서 지연(deferred)에 대한 개념 설명은 뒤 변수 확장 섹션에서 추가 설명한다.

FOO = "bar"

위 예시와 같이 사용하여, 특정 변수(FOO)에 특정 값("bar")을 할당가능하다.

?= (soft assignment)

=보다 낮은 순위의 변수 할당을 위해 사용하는 연산자이다.
?=는 주로 특정 변수에 기본값(default)을 할당할 때에 사용한다.

FOO ?= "bar"

위 예시와 같이 사용하여, 특정 변수(FOO)에 기본 값("bar")을 할당가능하다.

FOO = "bar"
FOO ?= "BAR"

앞에서 ?=는 =보다 낮은 우선순위를 갖는다고 하였다. 이에 대한 설명을 위해 위와 같은 예시 코드를 작성하였다.
비트베이크는 레시피 내용을 파싱하고 빌드를 실행할 때 ?=보다 높은 우선순위인 =로 변수의 값을 할당한다.
따라서, 비트베이크는 FOO에 "bar" 값을 할당하여 빌드를 수행하게 된다.

??= (weak default assignment)

?=보다 낮은 순위의 변수 할당을 위해 사용하는 연산자이다.

FOO  ?= "barbar"
FOO   = "barbarbar"
FOO ??= "bar"

앞서 설명하였다시피 비트베이크는 레시피의 파싱을 수행하고 빌드를 진행할 때 변수 할당 연산자의 우선순위를 따진다. 그렇기 때문에, FOO에는 "barbarbar"가 담겨져 최종적으로 빌드가 수행된다. 다시 말해, 변수 할당 연산자는 "= > ?= > ??="와 같은 관계를 가진다.
이 세가지 연산자는 특정 레시피가 빌드될 때에 여러 환경의 조합으로 변수에 기본값(?=, ??=)을 사용할 지 혹은 지연된 값(=)을 사용할 지 목적에 따라 유연하게 사용될 수 있다.

변수 확장

A = "aValue"
B = "before-${A}-after"

비트베이크에는 변수 확장이라는 개념이 존재한다.
예를 들어, 위 예시와 같이 작성되어 있다면 B에는 "before-aValue-after"라는 값으로 확장된다.

A = "aValue"
B = "before-${A}-after"
A = "aNewValue"

여기서 일반적인 순차적 모델에 기반한 프로그래밍 언어를 접했던 개발자라면 B는 당연히 "before-aValue-after"이다.
하지만 비트베이크는 빌드를 하는 그 순간까지 B를 "before-${A}-after" 형태로 저장해두며, 빌드를 수행(태스크가 실행되는)하는 그때, B에 A의 값을 대입시켜 "before-aNewValue-after"로 완성시킨다.

A = "aValue"
B := "before-${A}-after"
A = "aNewValue"

여기서 한가지 재미난 점은 :=(immediate assignment) 연산자를 사용하면 즉시 변수를 확장할 수 있다는 점이다.
다시 말해, 위와 같은 예시에서 B는 :=로 인해서 즉시 "before-aValue-after"로 확장된다는 것이다.

MIRROR = "http://internal"
SRC_URI := "${MIRROR}/pkg.tar.gz"

한가지 예시로 특정 소스를 내려받을 때 MIRROR 서버의 경로가 즉시 반영되어야 하는 경우가 존재한다.
만약, 비트베이크가 빌드를 수행할 때에 MIRROR 값이 도중에 변경된다면 소스를 내려받는 경로가 달라져 빌드 결과물의 버전에 이상이 생길 수 있다. 그렇기에 적절하게 =와 :=를 사용하여 레시피 파일을 작성할 수 있어야 한다.

문자열 추가/삭제

빌드를 수행할 때에 특정 변수에 할당된 문자열 값에 여러 값들을 추가 혹은 삭제해야 하는 경우가 존재할 것이다. 이때에는 아래와 같은 5가지 타입의 할당자(+=, .=, :append, :prepend, :remove)를 사용가능하다.

+= (append with space), =+ (prepend with space)

A = "aValue"
A += "AfterNewValue" # 1. aValue AfterNewValue
A =+ "BeforeNewValue" # 2. BeforeNewValue aValue AfterNewValue

+=와 =+를 통해서 특정 변수에 공백으로 구분된 문자열을 추가할 수 있다.
+=를 사용하게 되면, A 변수 뒤에 공백 문자와 추가할 문자열이 붙는다. (위 예시의 1. 참조)
=+를 사용하게 되면, A 변수 앞에 공백 문자와 추가할 문자열이 붙는다. (위 예시의 2. 참조)

.= (append without space), =. (prepend without space)

A = "aValue"
A .= "AfterNewValue" # 1. aValueAfterNewValue
A =. "BeforeNewValue" # 2. BeforeNewValueaValueAfterNewValue

.=와 =.를 통해서 특정 변수에 공백 없이 문자열을 추가할 수 있다.
.=를 사용하게 되면, A 변수 뒤에 추가할 문자열이 공백 없이 붙는다. (위 예시의 1. 참조)
=.를 사용하게 되면, A 변수 앞에 추가할 문자열이 공백 없이 붙는다. (위 예시의 2. 참조)

:append, :prepend

A = "aValue"
A:append  = "AfterNewValue" # 1. aValueAfterNewValue
A:prepend = "BeforeNewValue" # 2. BeforeNewValueaValueAfterNewValue

:append와 :prepend를 통해서 특정 변수에 공백 없이 문자열을 추가할 수 있다.
:append를 사용하게 되면, A 변수 뒤에 추가할 문자열이 공백 없이 붙는다. (위 예시의 1. 참조)
:prepend를 사용하게 되면, A 변수 앞에 추가할 문자열이 공백 없이 붙는다. (위 예시의 2. 참조)
이 두 연산자는 바로 앞 절의 연산자(.=, =.)와 동일한 연산을 수행하는 것을 알 수 있다. 하지만 아래 예시와 같이 연산이 실행되는 순서에서 차이가 존재한다.

A:append = "AfterNewValue"
A = "aValue" # 1. aValueAfterNewValue
B .= "AfterNewValue"
B = "aValue" # 2. aValue

:append 연산은 변수에 특정 값이 할당될 때에 동작한다. 따라서, 위 예시의 1.과 같은 결과를 확인가능하다.
.= 연산은 변수에 즉각적으로 할당된다. 따라서, 위 예시의 2.와 같은 결과를 확인가능하다.

:remove

FOO = "1 2"
FOO:remove = "2 3"
FOO += "3"
FOO:append = " 4"

공백으로 구분된 문자열 중 특정 문자열을 삭제하기 위해 :remove 연산을 사용할 수 있다.
:remove 연산의 경우에는 문자열 추가 연산(+=, .=, :append 등)이 모두 실행된 후에 실행되는 연산자이다.
따라서, 위 예시에서 FOO에는 "1 4"가 최종적으로 저장된다.

조건적 변수 할당

OVERRIDES

OVERRIDES = "linux:arm:x86" # 콜론(:)으로 조건에 해당하는 문자열을 구분

A = "value"
A:arm = "armValue" # 1. armValue
A:append:x86 = " x86Value" # 2. armValue x86Value
A:append:non = " nonValue" # 3. armValue x86Value

비트베이크는 파싱을 수행할 때 조건에 따른 변수 할당이 가능하며, 이때에는 OVERRIDES라는 변수를 참조한다.
위 1.~3. 예시와 같이 :<condition> 형식으로 조건적으로 값을 할당 가능하다.
조건이 맞을 경우에는 위 예시의 1.과 같이 A 변수가 변경되는 모습을 확인 가능하다.
조건이 맞을 때 문자열을 추가하고 싶다면 2.와 같이 :append와 :<condition>을 함께 사용하면 된다.
당연히 조건이 맞지 않을 때에는 3.과 같은 결과를 확인 가능하다.

파일 포함

include, require

# hello.inc

DESCRIPTION = "Hello application"
LICENSE = "MIT"
SRC_URI = "file://hello.c"

-----------------------------------

# hello.bb

include hello.inc
require hello.inc

include hello_tmp.inc # 1. Warning
require hello_tmp.inc # 2. Parse Error

클래스와 레시피에는 .inc 파일의 내용을 포함시킬 수 있으며, 이를 위해 include와 require 키워드를 사용한다.
include는 가져오려는 .inc 파일이 존재하지 않으면 Warning을 발생시키지만 빌드는 종료되지 않는다.
require는 가져오려는 .inc 파일이 존재하지 않으면 Parse Error를 발생시키고 빌드가 종료된다.
비트베이크에서 클래스와 레시피에 .inc 파일을 포함할 때에는 .inc 파일의 내용을 그대로 복사/붙여넣기 한다.
레시피에서 특정 클래스를 상속할 때에는 include나 require을 사용하지 않고 inherit 키워드를 사용한다.

파이썬 변수

${@<python-command>}

A = "${@time.strftime('%Y%m%d', time.gmtime())}"

변수 할당을 수행할 때에는 ${@<python-command>}와 같은 형식으로 파이썬 함수를 사용가능하다.

A = "${@d.getVar('MACHINE')}"

파이썬 함수에서는 비트베이크의 Bitbake Datastore Object로 접근할 수 있으며, 이때에는 d 객체를 활용한다.

함수 정의

Dash 셸(/bin/sh) 함수

do_hello() {
    echo "hello, world"
    echo "${MACHINE}"
}

addtask hello before do_fetch

Python 함수

python do_hello {
    print("hello, world")
    print(d.getVar("MACHINE")
}

addtask hello before do_fetch

태스크를 정의할 때에는 Dash Shell과 Python3 기반으로 작성가능하다.
Python으로 태스크를 정의할 때에는 함수명 앞에 python을 붙여준다.
새롭게 정의된 태스크는 addtask 명령을 통해 비트베이크에 등록가능하다.
(여기서 addtask 명령의 문법은 다루지 않는다.)

[Yocto 학습] 2장: 비트베이크(bitbake)란?

pak-ji — Sun, 3 May 2026 15:50:01 +0900

비트베이크란?

비트베이크는 GNU Make와 유사한 도구로 Python과 Shell Script가 혼합된 형태의 코드를 파싱하여 타겟 플랫폼 이미지를 빌드하는 툴(엔진)이다.
비트베이크는 메타데이터라는 것을 파싱하여 빌드를 수행하며, 메타데이터에는 3가지 유형이 존재한다.
- 환경설정(*.conf): 빌드 전체 동작 방식과 정책을 결정하는 변수 집합, 어떠한 레이어와 머신 등을 사용할 지 결정
- 레시피(*.bb, *.bbappend): “하나의 패키지를 어떻게 빌드할지”를 정의, Python과 Shell Script를 활용
- 클래스(*.bbclass): 여러 레시피에서 공통으로 사용하는 빌드 로직을 정의, Python과 Shell Script를 활용
- 레이어(meta-*): 비트베이크가 참조할 메타데이터(환경설정, 레시피, 클래스)를 논리적으로 묶어서 관리하는 단위
비트베이크는 일반적으로 다음과 같은 처리 순서를 가진다.
(각 과정에서 더 상세한 내용이 있지만 간략하게만 작성하면..)
1. 타겟 플랫폼 이미지를 빌드시키기 위한 비트베이크의 빌드 환경 준비 (source oe-init-build-env <target>)
2. 타겟 플랫폼 이미지인 <target>을 빌드하기 위한 비트베이크 실행 (bitbake <recipe_name>)
3. 비트베이크가 실행되면서 <target> 디렉터리 하위의 conf/bblayers.conf 확인
4. conf/bblayers.conf의 BBLAYERS 변수에 선언된 레이어(meta-*)들의 경로를 확인
5. 레이어 디렉터리의 하위에 존재하는 conf/layer.conf를 확인
6. conf/layer.conf의 BBFILES 변수에 선언된 레시피들의 경로를 참조하여 의존성에 맞춰서 빌드 수행

환경 설정 파일(bblayers.conf, layer.conf)에 대해서

bblayers.conf

<target>/conf/bblayers.conf

"source oe-init-build-env <target>"를 시행하면 기본적으로 위 그림과 같은 bblayers.conf 파일이 생성된다.
bblayers.conf에서 BBPATH와 BBFILES는 그다지 중요하진 않으며, BBLAYRES가 가장 중요하다.
BBLAYERS 변수에는 <target>을 빌드하기 위해 필요한 레이어 목록을 선언하며, 각 레이어는 공백으로 구분된다.
비트베이크가 실행(bitbake 명령으로)되면 이 BBLAYERS에 있는 레이어 목록을 찾아가 레시피를 찾는다.

layer.conf

meta-poky/conf/layers.conf

비트베이크는 conf/bblayers.conf의 BBLAYERS에 선언된 레이어를 접근한 뒤 conf/layer.conf를 찾는다.
layer.conf에는 패키지를 빌드하기 위한 레시피의 경로가 작성되어 있다. (패키지가 합쳐저 <target> 이미지 생성)
layer.conf의
- BBPATH는 레이어 경로를 비트베이크로 전달하기 위해 사용하는 변수이다.
- BBFILE은 레이어 하위의 패키지를 빌드하기 위한 레시피 파일의 경로를 나타내는 변수이다.
- BBFILE_COLLECTIONS는 레이어가 비트베이크로 식별되기 위한 본인의 식별자(ID)를 등록하는 변수이다.
- BBFILE_PATTERN_<collection>은 BBFILE 중에서 식별자가 바라볼 레시피를 구분하기 위한 변수이다.
- BBFILE_PRIORITY_<collection>은 식별자가 식별하고 있는 레시피의 우선순위를 설정하기 위한 변수이다.
- 일반적으로 BBFILE_COLLECTIONS와 BBFILE_PATTERN, BBFILE_PRIOIRTY는 한몸처럼 움직인다.
- LAYERDEPENDS_<collection>은 레이어가 의존하는 레이어가 무엇인지 나타내기 위해 사용하는 변수이다.

bitbake-layers show-layers 실행 결과

"bitbake-layers show-layers" 명령을 활용해 <target>을 빌드하기 위해 필요한 레이어 목록을 확인할 수 있다.
이 명령은 "source oe-init-build-env" 명령을 실행시켜서 비트베이크가 실행될 수 있는 환경을 세팅한 후에 실행 가능하다.

비트베이크의 빌드 과정 중 의존성 처리

비트베이크는 빌드 과정에서 아래 두가지 유형의 의존성을 처리한다.
- 컴파일(빌드) 의존성: 타겟 이미지에 들어가는 바이너리 혹은 실행 환경(QEMU 등) 등을 컴파일하기 위해 호스트에서만 필요한 의존성으로, -native 접미사를 레시피 파일에 붙여(Ex. qemu-native_6.2.0.bb) 표현된다.
- 런타임 의존성: 타겟에서 특정 바이너리를 실행하기 위한 의존성으로, 동적 라이브러리나 인터프리터 등이 존재한다. 컴파일 의존성과 다르게 -native 접미사가 붙지 않은 레시피 파일로 표현된다.
또한, 비트베이크는 레시피 간의 의존성을 처리하기 위해 DEPENDS와 RDEPENDS 변수를 작성한다.
(PROVIDES도 있는데 이는 그렇게 중요한지는 모르겠다.. 나중에 중요해보이면 추가로 정리해야겠다.)
- DEPENDS: 해당 레시피가 빌드하기 전에 반드시 먼저 빌드되어야 하는 패키지를 의미한다.
- RDEPENDS: 컴파일된 패키지가 타겟 환경에서 실행될 때 반드시 필요한 패키지를 의미한다.

비트베이크의 태스크 종류

비트베이크는 빌드를 위해 태스크를 실행시키며, 이 태스크는 레시피 파일에 의해서 작성된다.
비트베이크는 레시피 파일에 태스크를 정의하기 위한 프레임워크를 제공한다.
비트베이크에서 제공하는 태스크는 다음과 같으며, 이를 실행되는 순서대로 정리하였다.
1. do_fetch
  - 패키지를 빌드하기 위한 소스를 가져오는(다운로드하는) 단계이다.
  - 소스를 가져올 때에는 Remote(Git 등)나 Local(Disk)에서 가져올 수 있다.
2. do_unpack
  - do_fetch를 통해서 가져온 소스를 빌드할 수 있도록 풀어내는 단계이다.
  - 만약, 소스가 tar 등으로 압축되어 있다면 압축을 해제한다.
  - 만약, 소스가 Git을 통해 Clone 되었다면 Checkout을 수행한다.
3. do_patch
  - do_unpack이 끝난 빌드 소스에 Patch를 적용시키는 단계이다.
  - 이 단계에서 *.patch 파일을 통해서 소스를 Patch 할 수 있다.
  - Patch가 적용된 소스가 최종적으로 이미지 빌드에 사용된다.
4. do_configure, do_compile, do_install
  - do_configure, do_compile, do_install 단계별로 빌드를 수행한다.
  - do_congiure: 패키지를 빌드하기 위해 설정하는 단계이다.
  - do_compile: 패키지를 실제 컴파일하는 단계이다.
  - do_install: 컴파일된 패키지를 임시 디렉터리(${D})에 설치하는 단계이다.
  - 동일한 환경 변수의 이름이더라도 각 단계마다 사용 목적이 다르다.
5. do_package
  - do_install로 인해서 임시 디렉터리에 설치된 패키지를 논리적으로 분할하는 단계이다.
  - 논리적으로 분할할 때에는 패키지의 유형(디버깅 심볼, 문서, 라이브러리 등)에 따라 수행된다.
6. do_rootfs
  - do_package에 의해서 논리적으로 분할된 패키지들을 활용해 Root File System을 생성하는 단계이다.

비크베이크가 do_fetch 단계에서 소스 다운로드하는 방법

(Yocto 학습을 위해 살펴보고 있는 서적에서 소스 다운로드하는 부분을 상세히 설명하고 있어서 추가로 정리한다.)

비트베이크는 패키지들을 빌드하는 태스크의 가장 첫 단계인 do_fetch에서 소스를 다운로드 받는다.
비트베이크는 소스코드를 다운로드 받기 위해 OpenSSH, cURL, Git 등을 백엔드(Fetcher Backend)로 사용한다.
- OpenSSH는 Remote에 존재하는 tar.gz 등과 같은 압축 파일을 가져오기 위해 주로 활용한다.
- cURL은 Remote에 존재하는 tar.gz 등과 같은 압축 파일을 가져오기 위해 활용된다.
- Git은 Remote에 존재하는 Git Repository를 가져오기 위해 활용된다.

meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb

비트베이크는 do_fetch 단계에서 레시피 파일에 작성된 SRC_URI를 참고하여 소스를 가져온다.
- SRC_URI의 ${PV}는 패키지 버전을 의미하며, 레시피 이름에 있는 버전(pm-tuils_1.4.1.bb)으로 대체된다.
- SRC_URI가 ssh://로 되어 있다면 OpenSSH를 활용해 소스를 다운로드 받는다.
- SRC_URI가 http:// 혹은 https://로 되어 있다면 cURL을 활용해 소스를 다운로드 받는다.
- SRC_URI가 git://으로 되어 있다면 Git을 활용해 소스를 다운로드(Clone) 받는다.
- SRC_URI가 file://로 되어 있다면 cp 등의 명령을 활용해 Local(Disk)에 존재하는 소스를 복사한다.
다운로드가 완료된 소스의 경우에는 DL_DIR 환경 변수에 등록된 경로에 저장된다.
- 기본적으로 ${DL_DIR}은 <target>/downloads 디렉터리로 설정된다.
- <target>/conf/local.conf 파일에서 ${DL_DIR}의 경로를 재정의 가능하다.
Remote에서 다운로드 할 때에는 MIRRORS, PREMIRROS 환경 변수로 미러 서버를 설정가능하다.
- <target>/conf/local.conf 파일에서 MIRRORS와 PREMIRROS를 재정의 가능하다.
Remote에서 다운로드 할 때 네트워크 접근을 할 수 없게 하려면 BB_NO_NETWORK를 활성화하면 된다.
- <target>/conf/local.conf 파일에서 BB_NO_NETWORK = "1"을 작성해서 활성화 가능하다.

박지의 IT 공부블로그

임베디드 리눅스 장치에서의 GDB 디버깅

개요

GDB란?

원격 디버깅이란?

임베디드 리눅스 GDB 활성화

임베디드 리눅스 GDB 원격 디버깅

임베디드 리눅스 코어파일 생성방법

결론

References

SysVinit(System V init)이란?

개요

init란?

init 프로그램 종류

SysVinit

References

[Yocto 학습] 9장: Poky를 활용한 Raspberry Pi 4 유저 애플리케이션 빌드

개요

Raspberry Pi 4 사용자 설정을 위한 커스텀 레이어

Raspberry Pi 4 유저 애플리케이션 구현

Raspberry Pi 4 유저 애플리케이션 패키지 등록

Raspberry Pi 4 이미지 빌드 및 결과

Yocto 학습을 끝마치며

[Yocto 학습] 8장: Poky를 활용한 Raspberry Pi 4 와이파이 초기화

개요

Raspberry Pi 4 내장 와이파이 모듈 조사

Raspberry Pi 4 사용자 설정을 위한 커스텀 레이어 생성

Raspberry Pi 4 와이파이 드라이버 및 유틸리티 패키지 등록

Raspberry Pi 4 와이파이 설정 파일 오버라이딩

Raspberry Pi 4 이미지 빌드 후 부팅 결과

[Yocto 학습] 7장: Poky를 활용한 Raspberry Pi 4 이미지 빌드

개요

Raspberry Pi 4 이미지 빌드

SD 카드를 WSL/Ubuntu로 Passthrough

SD 카드에 Raspberry Pi 4 이미지 굽기

구워진 SD 카드로 Raspberry Pi 4 부팅

트러블슈팅

gcc와 binutils 크로스컴파일 과정 중 의존성 문제 발생

[Yocto 학습] 6장: 레시피(*.bb, *.bbappend) 커스터마이징 방법 - 2

.bbappend 레시피의 사용 목적

.bbappend로 .bb에 작성된 태스크 확장방법

.bbappend로 .bb에 작성된 빌드 옵션 수정 방법

.bbappend로 .bb에 작성된 소스에 패치를 적용하는 방법

레시피에서 참조하는 rootfs 경로 변수

레시피를 활용해 커널 컴파일 옵션을 변경하는 방법

[Yocto 학습] 5장: 레시피(*.bb, *.bbappend) 커스터마이징 방법 - 1

레시피의 종류

Image 레시피

Package 레시피

autotools 클래스

[Yocto 학습] 4장: 레이어(meta-*) 생성 방법

레이어 종류

BSP(Board Support Package) 레이어

Distro(배포판) 레이어

Software 레이어

외부 레이어 추가 방법

새 레이어 생성 방법

[Yocto 학습] 3장: 비트베이크(bitbake) 문법

클래스와 레시피

변수 할당

= (deferred assignment)

?= (soft assignment)

??= (weak default assignment)

변수 확장

문자열 추가/삭제

+= (append with space), =+ (prepend with space)

.= (append without space), =. (prepend without space)

:append, :prepend

:remove

조건적 변수 할당

OVERRIDES

파일 포함

include, require

파이썬 변수

${@<python-command>}

함수 정의

Dash 셸(/bin/sh) 함수

Python 함수

[Yocto 학습] 2장: 비트베이크(bitbake)란?

비트베이크란?

[Yocto 학습] 6장: 레시피(.bb, .bbappend) 커스터마이징 방법 - 2

[Yocto 학습] 5장: 레시피(.bb, .bbappend) 커스터마이징 방법 - 1