1. Yocto Project
요즘 임베디드 프로그램에서 개발환경에서 yocto project로 빌드하는 것이 대세 인것 같다.
TI를 비롯하여, Freescale의 iMX6, Raspberry pi 보드 등 대부분의 BSP를 Yocto를 지원해주고 있다.
하지만, 한번 빌드를 시작하면, 용량이 상당하여, 시간과 데이타양이 부담스럽지만, 편하게 이용할 수 있어 좋은 것 같다.
bootloader 부터시작하여, kernel 및 filesystem에 들어가는 관련 application 및 GUI Interface의 전체 소스를 받고 빌드를 하며 사용하기 쉽다고 하지만,
막상 Yocto 기반으로 개발을 진행을 하면 소스 추가하는 방법과 이를 관리하는 방법도 배워야 하니, 배울게 점점 더 늘어나 진다.
1.1 각 칩제조사별 Yocto Project
현재 TI의 경우 AM33xx or AM43xx 일 경우 관련 Yocto를 제공해주고 있으며 다른 SOC는 현재 잘모르겠다.
그리고, 반드시 알아야할 것이 아래의 메뉴얼과 본인이 사용하는 Yocto 구조가 많이 상이할수가 있는데, 이부분은 반드시 관련 Version과 관련 제조사 Manual을
반드시 참조해야한다.
하지만 기본구성과 기본사용법은 거의 비슷하므로 아래의 기본은 알아두도록하자
https://www.yoctoproject.org/product/arago-project
Freescale은 IMX6을 다루면서 잠시 아래와 같이 빌드했지만, Freescale에서 제공해주는 문서를 읽는 것이 더 편하게 느껴졌다.
https://www.yoctoproject.org/organization/freescale-semiconductor
https://community.freescale.com/docs/DOC-1616
https://community.freescale.com/docs/DOC-93844
2. Yocto 기본매뉴얼
아래의 사이트에 가면 모든 메뉴얼이 존재하며, 반드시 가서 읽어봐야 하며, 가능하면,
최신 Manual을 읽는 것이 이해하는데 도움이 될 것이다.
이해를 한 다음에 본인 Version으로 가서 읽으면 이해가 쉬울 것 같다.
주의해야 할 사항은 아래 Manual 보다 칩제조사의 Manual이 우선되어야 할 것이다.
https://www.yoctoproject.org/documentation
http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html
2.1 중요부분메뉴얼 (V1.8)
현재 최신 버전인 1.8 Version으로 메뉴얼을 봤지만, 추후 개발한다면 관련 Version을 알아
자신의 Version에 맞게 알아두자
- 커널 및 BSP관련 개발 ( BSP부분 중요)
Yocto Project Linux Kernel Development Manual
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html
Yocto Project Development Manual
http://www.yoctoproject.org/docs/1.8/adt-manual/adt-manual.html
Yocto Project Board Support Package (BSP) Developer's Guide
http://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html
http://git.yoctoproject.org/cgit/cgit.cgi
3. Yocto 기본동작
Yocto project는 꼭 임베디드 소스 개발환경에 제공되는 시스템이 아니며, 아래의 구조를 보고 천천히 이해를 하자
각각의 소스를 가져와 패치를 하고 설정을 하며, 원하는 패키지를 생성 후 테스트를 걸쳐, Image를 생성한다. 이것이 기본 Yocto project의 구성이다.
- Yocto의 전체적인 동작방식 (상층의 화살표대로 보면 전체적인 이해가 됨)
- Source Mirrors 존재 및 관리 (관련 Project들의 Source 집합체)
- Source Mirror에서 Fetch (Download from remote Repositories)
- 좌측의 User Configuration Target 설정된 값들 기준으로 Build 를 진행
- Build를 진행을 하면 좌측의 Metadata 와 Machine/Policy Configuration에 이용
- Build 진행 후 Output이 생성되면 Package를 만들고 이를 QA TEST 진행
- Image 와 SDK도 생성하여 각각의 Output을 생성
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#source-fetching-dev-environment
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#patching-dev-environment
- User Configuration: 빌드를 Control하는 Metadata라고 하며 config file
- Metadata Layers: 상위 좌측의 3개 Metadata / Machine / Policy Configuration를 말함
- Source Files: 상위 Source Mirros를 말하며 보통 Git로 관리.
- Build System: Bitbake기반으로 recipe에 따라 source fetch / patch / build /package등을 진행한다
Fetcher / Fetching: Source는 다운로드하는 것
- Image Generation (Uboot 와 Kernel / Filesystem)
- SDK
- Package (rpm/deb/ipk) 다양한 Linux Package를 지원가능
최근에는 라지베리파이까지 지원되는 것으로 보아서 거의 관리부분은 Yocto 추세로 가는 것 같다.
Target CPU 상위 User Configuration에서 설정 기준으로 Image가 생성되고 Depoly 된다
재미있는 것은 QEMU이라는 것이 존재하여 Target CPU를 테스트가 가상으로 TEST가 아래처럼 가능하다.
동작방식 및 처음사용법을 간단히 소개한다.
http://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html
3.1 Yocto 전체구성
Yocto 전체구성을 보면 간단히 보면 Source 와 Build 구성이 된다.
- Yocto 관련부분 (i.MX는 Source 변경)
Yocto의 Poky를 비롯하여 추가된 Yocto 의 다양한 Layer 들 (Open Embedded Layer 및 BSP Layer)이며, 이 설정기반으로 Build에 구성한다.
Yocto의 관리 프로그램이라고 생각하면된다.
- Build (Yocto 기반으로 생성된 부분)
Source 기반으로 설정되어 생성되는 Directory 이며, Source 내부의 설정에 따라 변경이 되어진다.
User Configuration (conf/local.conf, conf/bblayers.conf) 를 비롯하여 각 필요한 소스를 Git로 Fetch(Download)를 하고 이를 Package를 진행하고 Image를 생성한다.
상위의 3. Yocto의 동작이 Build 내부에서 진행이 된다고 생각하면된다.
3.2 Yocto의 구성 (Poky)
Yocto는 Pocky만 있으면, 기본구성이 되어지며, 그리고 Yocto에 지원되는 다양한 Tool 및 Script들을 제공해주고 있다.
- Poky: Yocto의 기본구성이며 bitbake를 비롯하여 기본이되는 명령어들이 존재
- Open Embedded(OE): Yocto에서 많이 사용되어지는 Embedded Layer 들
- Chip 제조사의 meta-layer: TI or Freescale 들은 본인들의 Layer들을 제공
Pock 관련부분
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-core
Chip 업체가 BSP Layer를 구성한다면 Pocky 기반으로 BSP Layer를 만들고 구성을 할 것이며, OpenSource에서 필요한 것들은 Open Embedded에서 보충할 것이다
3.3 Yocto의 Layer의 종류
하단그림의
Layers 부분의 좌측의 3개로 구성이 되어있으며, bitbake에 의해 각각의 기능을 수행하며, 각 Layers들은 Source Directory에 존재하며
각각의 conf 와 recipes들이 존재하며, 중요하게 봐야할 부분이 BSP Layer 부분일 것이다.
- 각 Configuration 과 Layer의 관계
- Policy Configuration: Distro layer로 배포를 위해 전체 image or package 관련부분을 담당
- Machine Configuration: BSP layer로 target arch에 해당하는 부분에 해당
- Metadata : Software layer로 일반적인 open source들이 해당
Metadata, Machine Configuration, and Policy Configuration
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#metadata-machine-configuration-and-policy-configuration
전체 배포를 위한 규칙담당을 하기 때문에 많이 익숙해져야할 Layer이며
build directory의 conf/local.conf에 확인가능하며,
conf/layer.conf 와
conf/distro/***.conf가 존재하며, 보통 include 형식으로 연결되어있음.
- classes : (*.bbclass)를 가지고 있으며, 배포를 위해 공유
- conf : 상위에서 conf/local.conf에서 본인이 사용하는 distro layer 확인 (conf/distro/*.conf)
- receipe-* : 일반적인 배포를 위한 recipe와 다양한 기능의 recipe 제공
conf/layer.conf 와
conf/machine/machine_name.conf로 구성이 되며, 현재 사용중인 BSP Layer를 확인하고자 하면
build directory의 conf/local.conf 에서 확인가능
일반적으로 recipes-bsp, recipes-core, recipes-graphics, recipes-kernel 등으로 구성이되지만, 배포판마다 다를 수 있으므로 주의
BSP Layer의 구성
https://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html
상위에서 설정된 배포방식으로 일반 Open source를 Package를 진행하며, Layer이기 때문에
conf/layer.conf가 존재
Distro/BSP/Software layer 관련사항
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#distro-layer
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-meta-conf-machine
$ find yocto/sources -name distro // 모든 distro layer 위치확인가능
.../conf/ditro
.../conf/ditro
$ find yocto/sources -name machine // 모든 machine layer 위치확인가능
.../conf/machine
.../conf/machine
- Build 의 User Configuration 이용하여 Layer 정보찾기
Build directory 의 User Configuration 정보확인
$ cat yocto/build/conf/local.conf // 현재 build directory의 distro layer 확인
.....
MACHINE ??= 'armxxxxx' // 사용될 BSP Layer 확인가능 (??= 는 다른곳에서 설정안할 경우)
DISTRO ?= 'poky' // 사용될 Distro Layer 확인가능 (?= 주의)
DISTRO_FEATURES ?= //
PACKAGE_CLASSES ?= 'package_rpm' // Package를 기본 rpm 구성 이외 deb 과 ipk
.......
$ cat yocto/build/conf/bblayers.conf // 전체 Layer 확인 가능하며, Software Layer 구성확인가능
.........
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-poky \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-multimedia \
...
BBLAYERS += "추가될 Layer "
$ find yocto/sources/ -name poky*.conf // DISTRO로 사용하는 Distro layer 확인가능
$ find yocto/sources/ -name armxxxxx*.conf // MACHINE로 사용하는 BSP layer 확인가능
3.4 Yocto의 쉬운 Layer 확장 (중요)
Yocto는 본인이 가지고 있는 것에서 확장이 쉽게 가능하며 아래의 사이트에서 Layer를 찾아 추가하고
이를 build의
conf/bblayers.conf (User Configuration)에 적용하면 된다.
상위 BBLAYERS 부분에 추가
- Yocto를 확장가능하게 해줄 다양한 Layer들 (Open Embedded)
https://layers.openembedded.org/layerindex/branch/master/layers/
좀 더 자세히 알고자 한다면 각각의 recipes들을 살펴보자
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-meta
상위 3가지 종류 중 본인이 원하는 것을 선택해서 Layer를 직접구성
https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#understanding-and-creating-layers
4. Yocto의 Build Directory 기본구성
- 좌측은 Yocto의 Source
- 우측은 Yocto의 Build
- 각 Yocto마다 이름은 조금씩 다를수 있지만, 기본은 enviornment 설정 후 bitbake를 사용가능
- 처음 source를 이용하여 build 설정할 경우(아래 예제참고)
- build direcoty 생성
- build의 User Configuration (Source에서 복사해옴)
- build enviornment 설정가능 및 bitbake 와 yocto 명령사용가능
- 재설정 할 경우 (동일하게 입력, 아래 예제참고)
- build directory 이미 기존생성것 이용
- User configuration 이미 기존생성된것 이용
- build enviornment 재설정 후 bitbake 및 yocto 명령어 이용가능
poky의 것을 사용하지만 좀 더 좋게 하기 위해서 이를 기반으로 Shell Script을 이용하는 기능을 추가하여 구성하는 경우도 있음
$ source poky/oe-init-build-env build // build directory를 build로 생성
or
$ source poky/oe-init-build-env build-sample // build directory를 build-sample로 생성 (이름변경은 마음대로)
Linux Terminal에서 기본적으로
login 할때마다 build enviornment를 설정되지 않기때문에
매번설정해야함
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-core-script
4.1 User Configuration
build directory를 설정 한 후 각각의 bblayers.conf 와 local.conf는 전체 설정에 반영이 되므로 중요하며 관련세부설정도 알아보자.
- build의 conf/bblayers.conf : Layer정보로 Layer를 이곳에 직접추가가능
- build의 conf/local.conf : 전체환경 설정값 e.g MACHINE 설정
- source의 bblayers.conf.sample 과 local.conf.sample: build의 원본파일
- Layer 관련 추가 방법: BBLAYERS
- local.conf 일반환경설정 (개인환경설정)
local.conf는 전체 환경설정값으로 모두 적용이 되므로, 필요한 것 있다면, 일반 설정 이외
본인 환경설정도 이곳에 정의해서 설정가능하다.
아래설정은 Yocto에서 보통 사용되어지는 일반환경설정들이며, 이부분은 좀 자세히 알아두자.
- Build Parallelism Options: BB_NUMBER_THREADS , PARALLEL_MAKE , BB_NUMBER_PARSE_THREADS
- Target Machine: MACHINE (Board 설정 및 MPU 설정)
- Download Directory: DL_DIR (중요 각각의 Source를 Download 장소설정)
- Shared State Directory: SSTATE_DIR
- Build Output: Build의 될곳 TMPDIR
- Distro 관련설정: DISTRO DISTRO_FEATURES
- Package 종류설정: PACKAGE_CLASSES (rpm/ipk/deb) 중 설정 rpm이 default
- Package 설정: PACKAGECONFIG
- Image 설정: EXTRA_IMAGE_FEATURES
- Disk Monitor 설정: BB_DISKMON_DIRS 모니터하며, 이 내부 Command 사용
- PATCH 관련설정: PATCHRESOLVE (noop or user) 이며, patch가 실패했을 경우
- CLASS 관련설정: USER_CLASSES inherit해서 설정할 수 있는 CLASS 영역설정
User Configuration 사항아래참고
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#user-configuration
Yocto 기반으로 Source를 Download하고 이를 Pacakge 및 Image를 만들어 아래의 장소에 넣고 작업을 한다.
- build/tmp/deploy/images: Embedded System에 필요한 Image들
- build/tmp/deploy/rpm or deb : 각 Package들
- build/tmp/work : 보통 필요한 source들이 이 곳에 존재
- build/tmp/work-shared: 공유가 필요한 Source들은 이곳에 존재
Build 의 구성
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-build
4.2 Bitbake 기본사용법
bitbake는 Yocto를 전체를 Control 해주는 system이며, shell과 python 사용하여 관리를 해주고 배포를 진행한다
bitbake를 이용하여 아래와 같이 recipe를 실행을 해보고 세부 Task도 같이 실행을 해보자
$ bitbake foo // foo 는 recipe/target
$ bitbake foo -c bar // do_bar Task 함수 동작진행
or
$ bitbake -c bar foo
$ bitbake recipe -c bar -f // do_bar Task 함수 강제실행
$ bitbake recipe -g foo // graphviz를 제공
$ bitbake -h // 관련설명 확인 아래링크확인
$ bitbake -e // 설정되어지는 환경설정값을 전부출력 (너무 오래걸림)
$ bitbake -e | grep ^VAR // 값 설정되었는지 안되었는지 확인 및 검색
// 1. 본인이 원하는 환경설정값을 검색하여 값 확인
// 2. 이 값기준으로 검색하여 bb 파일 위치 파악
Bitbake Command (
https://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-command
Bitbake 전체 Manual
http://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html
4.3 Bitbake 실행시 Yocto Sources 구성요소
기본적으로 Layer기반으로 구성이 되며, 아래의 요소들이 각각 구성이 각 필요로 한다.
이전의 Layer의 종류에 따라 각 필요하는 부분이 다르므로 관련부분에 대해 알아두도록하자.
(*.bb) 파일로 파일 설정 및 빌드 방법 , 종속 문제 및 Recipes의 Version 등 종합적인 관리를 한다.
(*.conf)로 구성이 되며 다양한 모든 Configuration 설정 을 담당하며, Main에 존재하는 bitbake.conf의 경우는 Compiler 관련 옵션 및 전체 설정을 담당한다.
(*.bbclass) 로 되며, metadata files사이들의 공유에 유용하며, classes라는 별도의 directory가 존재한다.
모든 recipes와 class가 자동적으로 항상 include 된 후 base.bbclass의 경우는 특별하다고 한다.
한마디라로 상위 metadata를 include할 때 사용하며, 특정 metadata와 공유하여, 각 상속개념으로 사용되어진다.
recipe안에서 class를 사용한다면,
inherit를 이용하여 class를 사용한다.
(*.bbappend)로 는 말그대로 파일을 추가하는 기능이며, 대신 이것을 이용하기 위해서는
(*.bb)와 이름과 동일하게 (*.bbappend) suffix가 다르게 사용하는 것이다.
Bitbake의 구성요소
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#usingpoky-components-bitbake
do_xxxx 로 구성이 되어있으며,
Metadata(recipe) 안에 존재하며 이미 정해진 Task들도 존재하며, 본인 별도로 구성이 가능.
Task의 경우는 조금씩 달라질수 있으므로, 각각 Chip vendor에 따라 Yocto Manual을 참조
$ bitbake recipe -c task // Task 실행
$ bitbake recipe -c task -f // 강제로 Task 실행
일반적으로 사용되어지는 Task들 (Normal Recipe Task 참고)
- do_fetch
- do_unpack
- do_patch
- do_configure
- do_compile
- do_install
- do_package
- do_rootfs
Normal Recipe Task (참고)
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#normal-recipe-build-tasks
Kernel Task (참고)
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#kernel-related-tasks
Image Task
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#image-related-tasks
5. Bitbake의 순차적인 동작흐름
Bitbake의 시작을 보면 Source Mirror로 부터의 Source Fetch 진행를 시작으로 볼수 있겠으며, 이것이 행해지는 부분은 상위 Build Directory 안에서 진행이 된다.
bitbake 전체흐름
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#bitbake-dev-environment
- Local Projects : Yocto의 내부에 포함되어진 File들
- SCMs: Git , SVN
- Upstream Project Releases: 정식으로 Release된 압축파일들
5.1 Source Fetch (Source Download)
Source Mirrors에서
do_fetch를 이용하여
download 하고
do_unpack으로 압축을 풀고
build directory에서 진행한다
- sources: source의 recipe에 따라 fetch와 unpack를 진행
- download : source mirrors에서 Upstream Project Releases 파일을 받아 저장 및 SCM 주소저장
- build directory: download의 압축된 파일을 풀어 소스로 보관
사실 이 부분은 이해만 하고 recipe만들 경우 이미 Distro Layer에서 정해져있기 때문에 수정할 부분이 거의 없다고 생각하면 된다.
하지만, recipe를 만들 경우 Source Mirror에 따라 어떻게 사용방법이 다른지는 각각 파악하자
- do_fetch: Source Mirrors에서 Source들을 가져오는 작업
- do_unpack: 가져온 Source를 unpack하는 작업
- TMPDIR: 상위 그림의 Build에서 tmp
- PACKAGE_ARCH: 상위 그림을 보면 tmp/work/ 구성을 보면 알수 있다.
- PN: Package Name ( Recipe name, Recipe를 작성시 PN_PV_PR.bb)
- PV: Package Version ( Recipe version )
- PR: Package Revision ( Recipe revision, default r0, 이며 거의 잘 사용안함)
- WORKDIR: TMPDIR 안에 work
- S: Build Directory에서 Package Source 위치
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#source-fetching-dev-environment
5.2 Patching
Fetch를 하고, Download된 Source에 본인이 변경사항이 있다면, Source의 각 Layer의 receipe(*.bb)에
보통 *.bbappend를 만들어서 patch를 진행
이때 사용되어지는 Tool은
quilt (patch를 이용한 tool) 와 patch를 이용한다.
- S: Build directory의 Source의 위치이며, TMPDIR 기준으로 보면이해가 됨
- TMPDIR: Build directory 의 tmp
- Patch Files (*bb or *.bbappend)
- SRC_URI: 각 Patch를 넣으면 Patch가 동작 하며 Suffix를 상위 (아래링크 참조)
- FILESEXTRAPATHS_prepend: Patch할 File의 위치를 맨 앞에 등록
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#patching-dev-environment
5.3 Config 및 Compile
Open source일 경우, 각 Configuration이 필요한 경우가 많으며, 이때 각각을 설정하며, compile 시 옵션도 추가가 가능하다
- S: Build directory의 Source의 위치
- B: 기본적으로 S와 같지만, Build되는 곳을 말하는 것 같음
- D: 목적지로 상위그림을 보면 image로 install되면 세부적으로 {bindir} 와 {libdir}
- do_configure: download한 소스 configuration (meta/classes/autotools.bbclass) S 사용
- do_compile: build 작업 이며 S와 B 사용
- do_install : install작업이며 package 와 rootfs에 install 진행 (D의사용이지만, B도사용)
상위와 같이 구성이 되지만, do_configure는 생략이 가능하며, do_compile도 필요에 따라 생략이 가능하다.
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#configuration-and-compilation-dev-environment
5.4 Package Splitting
