Jeonghun (James) Lee: Yocto-Basic

레이블이 Yocto-Basic인 게시물을 표시합니다. 모든 게시물 표시

2/21/2020

Yocto 기본문법 과 정보정리

1. Yocto 관련기본정보

이전에는 Chip Vendor의 Yocto를 가져다 사용하다보니, Yocto Version에 크게 신경을 쓰지 않았으나,
처음부터 Yocto를 전체 구성하려면 어쩔수 없이 호환성 부터 체크를 해야겠다는 생각이 들어 아래와 같이 정리한다.

1.1 Yocto 의 Version 정보확인

Yocto의 Main이라고 할 수 있는 Poky의 각각의 Version을 알아보도록하자.
이외 OpenEmbbedded 관련부분도 알아보도록 하자.

Yocto Poky Version (Branch)

Yocto의 Reference Distro Layer 인 Poky의 version 과 Codename (branch)

Codename	Yocto Project Version	Release Date	Current Version	Support Level	Poky Version	BitBake branch
Gatesgarth	3.2	Oct 2020		Dreaming	24.0	1.48
Dunfell	3.1	April 2020		Dev	23.0	1.46
Zeus	3.0	October 2019	3.0.2	Stable	22.0	1.44
Warrior	2.7	April 2019	2.7.3	Stable	21.0	1.42
Thud	2.6	Nov 2018	2.6.4	Community	20.0	1.40
Sumo	2.5	April 2018	2.5.3	EOL	19.0	1.38
Rocko	2.4	Oct 2017	2.4.4	EOL	18.0	1.36
Pyro	2.3	May 2017	2.3.4	EOL	17.0	1.34
Morty	2.2	Nov 2016	2.2.4	EOL	16.0	1.32
Krogoth	2.1	Apr 2016	2.1.3	EOL	15.0	1.30
Jethro	2.0	Nov 2015	2.0.3	EOL	14.0	1.28
Fido	1.8	Apr 2015	1.8.2	EOL	13.0	1.26
Dizzy	1.7	Oct 2014	1.7.3	EOL	12.0	1.24
Daisy	1.6	Apr 2014	1.6.3	EOL	11.0	1.22
Dora	1.5	Oct 2013	1.5.4	EOL	10.0	1.20
Dylan	1.4	Apr 2013	1.4.3*	EOL	9.0	1.18
Danny	1.3	Oct 2012	1.3.2	EOL	8.0	1.16
Denzil	1.2	Apr 2012	1.2.2	EOL	7.0	1.15
Edison	1.1	Oct 2011	1.1.2	EOL	6.0	1.13
Bernard	1.0	Apr 2011	1.0.2	EOL	5.0	1.11

Yocto(Poky) Release 관련사항

아래사이트에서 Poky의 Code Name이외 관련정보들을 더 확인가능
https://wiki.yoctoproject.org/wiki/Releases

Yocto(Poky) Branch(version) 와 Tag 파악

Pocky의 Branch 마다 소스구조 및 세부사항확인가능
https://git.yoctoproject.org/cgit/cgit.cgi/poky/refs/

1.2 Yocto 관련부분 정리한 부분

우선적으로 직접 정리한 부분을 링크

Yocto의 기본정보 와 동작 전체적인 흐름파악 (필요환경설정값 확인)

Yocto에 Reference Manual 기반으로 직접 정리했으며, 전체적인 흐름파악에 필요.

처음에 반드시 동작방식을 알아야함 (중요)
https://ahyuo79.blogspot.com/2015/10/yocto.html

Yocto (Poky) 기반으로 직접 내가 구성한 예

일반적으로 Chip vendor에서 제공해주는 Yocto 말고 직접 Poky 기반으로 구성
https://ahyuo79.blogspot.com/2018/02/raspberry-pi-systems-with-yoctohtml.html

1.3 Yocto 관련된 정리된 외부 Manual

Yocto 관련된 정리되 Manual들을 링크했으며, 처음보기에는 Bootlin의 Manual이 가장 쉽게 잘 정리되어 나와있다.

bootlin의 Yocto Reference Manual

bootlin의 Yocto Manual이 Update가 되었으며 관련부분을 링크 (각 보드에 적용된 부분확인)

TI의 BeagleBone 과 ST의 STM 예제

https://bootlin.com/training/yocto/
https://bootlin.com/doc/training/yocto/

Yocto Slide PDF 문서들
https://bootlin.com/doc/training/yocto/yocto-slides.pdf
https://bootlin.com/doc/training/yocto/yocto-labs.pdf

Yocto의 wiki

Yocto에 관련된 기본질문에 대한 해결방법

https://wiki.yoctoproject.org/wiki/How_do_I

OpenEmbedded Layer의 Recipes 관련검색

https://layers.openembedded.org/rrs/recipes/OE-Core/3.1/M4/

다양한 Yocto Recipe 예제 (Xilinx Yocto의 예제)

Xilinx에서 사용하는 Yocto로 다양한 예제를 확인가능
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips

recipe 작성방법 및 user configuration 설정방법

자신의 Recipe 작성 후 이를 user configuration에 등록방법
https://www.wolfssl.com/docs/yocto-openembedded-recipe-guide/

https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles

recipe 쉽게 작성방법 (recipetool 과 devtool 사용법)

yocto에서 제공하는 recipe 관련 tool을 이용하여 작성법으로,

주로 recpipetool 과 devtool 사용하지만, 나의 경우는 거의 직접 작성하는게 편하다.

https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#new-recipe-locate-or-automatically-create-a-base-recipe
https://www.lynxbee.com/creating-a-yocto-recipe-using-recipetool-script/

reciptetool 이용법
http://embeddedguruji.blogspot.com/2019/03/yocto-recipetool-tutorial.html

1.4 Yocto 의 공식 Manual

Yocto Project Quick Build

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html

Yocto의 Reference Manual

https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html

Yocto 의 Kernel 관련설정

https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html

Yocto 의 BSP Manual

BSP Layer 구성시 다시 한번 확인
https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html

Yocto 의 Bitbake User Manual

bitbake의 기본사용법 및 Recipe의 기본문법도 이곳에서 쉽게파악

https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html
https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#basic-syntax

Yocto 관련 Manual 의 Variable 관련내용

아래의 Recipe 작성시 필요한 변수 or 환경값을 이곳에서 찾자

https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#ref-variables-glossary
https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-variables-glossary

2. Yocto 의 Recipe/Config 의 기본지식

Yocto 의 경우 Layer의 config 를 비롯하여 각각의 recipes 및 User Configuration을 수정할 때 거의 동일한 것이 기본적인 환경변수의 Operator 지식이다.
이를 비롯하여 환경변수에 확장되는 Suffix 부분을 비롯하여 OVERRIDE부분을 알아두자.

2.1 Recipe/Config의 기본 Operators

Recipe 의 Value에 사용되어지는 Operators

Value, 즉 환경변수에 적용되어지는 Operator들의 동작방식

'=' expand the value when using the variable,
':=' immediately expand the value
"+=" append (with space)
"=+" prepend (with space)
".=" append (without space)
"=." prepend (without space)
"?=" assign if no other value was previously assigned, 이전에 할당이 없으면, 기본값
"??=" same as previous, with a lower precedence, 상위와 같지만 우선순위 더 떨어짐

상위 중 거의 쉽게 이해가 가는데, expand 개념만 이해가 가지 않아 예제로 정리

expand 와 immediately expand의 이해

= 와 := expand 이라고 하지만 Variable의 Assign으로 위치만 다를 뿐이다.
내 생각에 주의해야할 것은 recipe를 전체 Parsing할 때 동일한 이름의 변수가 있는 것들이 문제가 될수 있을 것 같다.

ex.1 
   A = "11"
   B = "B:${A}"   # 상위 A의 11을 미적용하고 마지막에 적용된 A로 적용 
   A = "22"      
   C := "C:${A}"
   echo $C   # C:22
   echo $B   # B:22

ex.2    
   T = "123"                          # 현재 값은 가지고 있지만,다시 T가 expand되며 그 값으로 대체 
   A := "${B} ${A} test ${test}"  # 현재위치에서 즉시 expand  
   B = "${T} bval"                    
   T = "456"               
   C = "cval"
   C := "${C}append"           # 이전값에 append를 즉시 추가 

   echo $A   #  test 123      # :=로 즉식 expand 해서 T가 123로 출력
   echo $B   #  456 bval      # 마지막 expand된 값으로 출력 
   echo $C   #  cvalappend    # 즉시 expand로 적용

expand operator 관련예제
  https://www.yoctoproject.org/pipermail/yocto/2012-March/005640.html
  https://books.google.co.kr/books?id=t9L8AwAAQBAJ&pg=PT123&lpg=PT123&dq=yocto+operators&source=bl&ots=vFEXcnCGEZ&sig=ACfU3U1pVLs35QUeINgp55iD9dU_wJ4XHA&hl=ko&sa=X&ved=2ahUKEwiiv9_m76LoAhWEfd4KHYK2CqIQ6AEwBHoECAkQAQ#v=onepage&q=yocto%20operators&f=false

+=, =+, .= and =. 의 사용은 $BUILDDIR/conf/local.conf 피하라고 하는데, 이유는 Parsing순서문제이다 (세부사항은 bootlin 문서참조 or 아래링크참조)
  https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-IMAGE_INSTALL

2.2 환경변수의 일반 Suffix 기능

환경변수 or Task function Suffix 의 이름에 각각의 이름이 존재하며, 이부분은 Operator로 동작한다.

환경변수의 Suffix 기능(_preprend/_append/_remove)

IMAGE_INSTALL_prepend: 상위 Operator 기능과 동일(without space)
IMAGE_INSTALL_append: 상위 Operator 기능과 동일(without space)
IMAGE_INSTALL_remove: 환경값 삭제

상위 operator 와 suffix 기능의 우선순위

ex. 3
A = "1"
A_append = "2"
A_append = "3"
A += "4"
A .= "5"
#  우선 operator 먼저 실행된 후 _append는 나중에 실행됨 
# A 값은 "1 4523" 된다고 한다.

Task Function의 Suffix operators

do_configure() { }: config 설정
do_configure_prepend() { }: do_configure 전에 실행
do_configure_append() { }: do_configure 후에 실행
do_compile() { }: do_compile 부분 실행
do_install() { }: do_install 부분실행
이외 생략

IMAGE_FSTYPES의 경우

상위 suffix operator를 동작이 안된다고 하며, 상위 보통 operator로 써야한다고 한다.

2.3 OVERRIDES의 기본개념 및 활용

value에 suffix "_"와 함께 소문자로 확장되어있는 것이 많이 존재하는데, 이부분은 OVERRIDES라는 것을 이용

주의해야할 것은 "-"로 확장되는것하고 다르므로 착각주의해야 할 것 같다

ex.1

# Selecting a Variable , 즉 변수의 선택이 가능 
# OVERRIDES를 이용하여 여러 변수 중 선택이 가능하며 반드시 소문자로만 작성 
OVERRIDES = "arch:os:machine"  # :로 분리되며, arch/os/machine 설정

# TEST_A 의 값이 아래와 같이 3개 존재하면 상위 OVERRIDES를 설정해서 arch or os or machine 중으로 설정 
TEST_A = "testdefault"
TEST_A_os = "testos"  # OVERRIDES로 os 가 존재하므로 이를 설정되며, TEST = TEST_os 와 동일
TEST_A_none = "testnone"

##TEST_A의 값은 "testos" 사용 

# TEST_B의 값 중 arch or os or machine 존재하지 않아서 기본값설정 
TEST_B = "testdefault"
TEST_B_del = "testdel"
TEST_B_none = "testnone"

##TEST_B의 값은 "testdefault" 사용 

# TEST_C의 값 중 os or machine 존재하지만 두개가 선택된 후 최종 마지막 선택된 machine선택 
TEST_C = "testdefault"
TEST_C_os = "testos"
TEST_C_machine = "testmachine"
TEST_C_none = "testnone"

##TEST_C의 값은 "testmachine" 사용

ex.2

# Appending and Prepending 에 확장 
DEPENDS = "glibc ncurses"
OVERRIDES = "mahcine:local # :로 분리되며, machine/local 설정

#DEPENDS_append 2개 존재하며, OVERRIDES로 machine을 설정했을 경우만 2번째 것은 설정가능 
DEPENDS_append =  "libxxx"     # 상위 DEPENDS 에 libxxx 추가 
DEPENDS_append_machine =  "libmad"  # OVERRIDES에 machine이 있어 동작 
# 최종 DEPENDS 값은 "glibc ncurses libxxx libmad "

https://www.yoctoproject.org/docs/2.7/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples

OVERRIDES 의 확장

MACHINEOVERRIDES 각 MACHINE 기반으로 설정시 변수설정가능

# 주석
MACHINE ?= "arm9"
MACHINEOVERRIDES ?= "${MACHINE}"

SRC_URI = "file://test0.config "
SRC_URI_append = "file://test1.config "
SRC_URI_append_arm9 = "file://test2.config "

# 최종 SRC_URI 값은 "file://test0.config file://test1.config file://test2.config "

FILESOVERRIDES : OVERRIDES의 세부설정이며, FILE에 적용
DISTROOVERRIDES: OVERRIDES의 세부설정이며 DISTRO 기준으로 적용

상위 3개의 OVERRIDES들의 설정은 최종 OVERRIDES에 포함적용되므로 세부적용시에는 상위 OVERRIDES를 사용하자.

3. Configuration 설정 과 Recipe 설정

Yocto의 Configuration은 아래의 Manual을 보면, Distro , Machine , Local 이지만, 각각 사용되는 곳을 보면 약간씩 달라진다.

User Configuration 설정: Build Directory 에 위치하며, 기본으로 두개의 설정 구성
Distro Configuration 설정: 아래의 Layer Configuration 과 구성되고, 별도로 구성
Machin Configuration 설정: BSP를 위해서 Layer Configuration 구성되고 별도구성
Layer Configuration 설정: 각 Layer마다 설정되는 기본 Configuration
Recipe 설정

Yocto의 Configuration 관련내용
https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#ref-varlocality-configuration

2/26/2018

Raspberry-Pi3 와 Linux Yocto 기본구성 과 이해

1. Yocto 구성설명

Yocto의 Quick Build 방법과 기존에 존재하는 Layer를 쉽게 추가하는 방법을 아래의 링크에서 쉽게 설명을 해주고 있으므로, 반드시 알아두자

Yocto의 사용법 (Cookbook)

Yocto에 대한 현재 Quick Guide / Reference Manul 와 Cookbook Topics 에서 쉽게확인
https://wiki.yoctoproject.org/wiki/Cookbook

OS Image에 추가하는 방법 (Cookbook Topics)

아래의 구성할 문서의 순서랑 거의 동일하며 Layer 추가하는 방법 및 수정방법이 괜찮다
https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image

Application 개발관련내용(Cookbook Topics)

기존의 bitbake-layers 와 다르게 devtool 을 이용한 recipe 추가방법이 새로움
https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK

Yocto 기본사용법확인

이전에 Yocto Reference Manual 기반으로 필요한 환경변수 및 구조설명
https://ahyuo79.blogspot.com/2015/10/yocto.html

https://yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#what-is-the-yocto-project

Layer 의 우선순위 (Layer Priority)

이전에 $ bitbake-layers show-layers 명령으로 우선순위를 보기는 했지만 우선순위 동작원리를 미쳐 파악을 못했다.

$ bitbake-layers show-layers  // Layer Priority 확인 및 구성확인 

$ bitbake-layers layerindex-show-depends meta-raspberrypi    // meta-raspberrypi의 의존성 확인, Layer를 추가할 때 의존성을 확인필요 

$ bitbake-layers -h 
usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h]  ...

BitBake layers utility

optional arguments:
  -d, --debug           Enable debug output
  -q, --quiet           Print only errors
  -F, --force           Force add without recipe parse verification
  --color COLOR         Colorize output (where COLOR is auto, always, never)
  -h, --help            show this help message and exit

subcommands:
  
    add-layer           Add one or more layers to bblayers.conf.
    remove-layer        Remove one or more layers from bblayers.conf.
    flatten             flatten layer configuration into a separate output
                        directory.
    show-layers         show current configured layers.
    show-overlayed      list overlayed recipes (where the same recipe exists
                        in another layer)
    show-recipes        list available recipes, showing the layer they are
                        provided by
    show-appends        list bbappend files and recipe files they apply to
    show-cross-depends  Show dependencies between recipes that cross layer
                        boundaries.
    layerindex-fetch    Fetches a layer from a layer index along with its
                        dependent layers, and adds them to conf/bblayers.conf.
    layerindex-show-depends
                        Find layer dependencies from layer index.
    create-layer        Create a basic layer

Use bitbake-layers  --help to get help on a specific command

https://dornerworks.com/blog/building-linux-with-yocto

상위 사이트에서 Layer의 우선순위에 대해서 너무 쉽게 그림으로 설명을 해주었지만,궁금한 사항이 두 가지가 더 생겼다.

궁금사항

Layer의 우선순위는 어떻게 정해지는 것인가?
Recipe의 우선순위는 어떻게 정해지는가?

1번째의 질문의 답은 처음 conf/bblayers.conf에서 정해지는 것으로 착각했으나, 각 개별 Layer의 conf에 BBFILE_PRIORITY_xxx , suffix는 layer 이름에 의해 정해진다.

meta-oe Layer 의 예제 (oe는 open embedded 약어)

$ vi meta-openembedded/meta-oe/conf/layer.conf    // 각 Layer의 conf에 의해 정의됨

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_PRIORITY_openembedded-layer = "6"        // openembedded layer 우선순위 

LAYERDEPENDS_openembedded-layer = "core"        //의존성 

LAYERSERIES_COMPAT_openembedded-layer = "thud warrior zeus"  // Yocto version 호환성

meta-networking Layer 예제

$ vi meta-openembedded/meta-networking/conf/layer.conf 

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \              // 등록되는 순서에 의해 동작될것이라고 생각 
            ${LAYERDIR}/recipes-*/*/*.bbappend"


BBFILE_PRIORITY_networking-layer = "5"     //networking layer의 우선순위 (같은 meta-openembdedded에 속해있지만 다름)

LAYERDEPENDS_networking-layer = "core"                // 의존성이 상당함 
LAYERDEPENDS_networking-layer += "openembedded-layer"
LAYERDEPENDS_networking-layer += "meta-python"

LAYERSERIES_COMPAT_networking-layer = "thud warrior zeus"

2번째의 질문의 답은 처음 Layer의 conf에서 BBFILES의 등록되는 순서가 아닐까 역시 잠시 착각 했는데, BBFILES은 등록만 할뿐 모든 Recipe는 사용하지 않는다는 사실을 깜빡했다.
잘 생각을 해보면, 최종 target image.bb파일이 존재하여, IMAGE_INSTALL에 들어간 Package들만을 설치진행한다.
기본으로 설치되는 부분은 class라는 공유개념이 존재하며,모든 recipe들은 사용하지 않는다.
즉 image -> core-image -> include ***.bb 확장되어가는 구조

2. Raspberry Pi 개발환경 구성

OS: Ubuntu 16.04_LTS 64bit
Window 기반의 Virtual Box 사용

기본설치

$ sudo apt install chrpath  diffstat gawk libncurses5-dev texinfo

makeinfo -> texinfo 변경

2.1 Raspberry PI 관련사항

Raspberry PI 설정 및 전체문서

https://wikidocs.net/book/483

Raspberry PI Kernel

https://wikidocs.net/3243
https://wikidocs.net/3244

Raspberry Android Build

http://airpage.org/xe/project_data/25990

2.2 Raspberry Pi Yocto 전체구성

상위 Raspberry PI Yocto 구성 를 보면 사용할 GIT는 아래와 같이 세개로 구성이 된다.

기본 Yocto 시스템 및 추가 metalayer들

git://git.yoctoproject.org/poky // 기본 Yocto System 인 Poky
git://git.openembedded.org/meta-openembedded // Yocto의 meta-layer (meta-oe) 추가
https://github.com/agherzan/meta-raspberrypi // Yocto의 meta-layer (meta-raspberrypi) 추가

Raspberry Pi Yocto 기본사용법 참고 사이트

  http://www.jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html
  http://www.yocto.co.kr/2016/01/yocto-project-2.html
  http://kernelhacks.com/raspberry-pi-3-with-yocto/

2.3 Yocto 구성 및 meta layer 추가

Yocto의 Reference Manual에 Reference Distribution Layer인 Poky를 구성한 후 각 필요한 meta layer들을 각각 추가하여 구성한다.

필요한 Raspberry Pi를 위한 BSP Layer 추가
Emdedded 관련된 기본인 Base Layer 추가

Yocto의 기본인 Poky (Reference Distribution Layer) 구성

Yocto의 기본시스템이 Pocky를 git로 download하여 아래와 같이 구성을 확인하자

$ mkdir raspberrypi
$ cd raspberrypi
$ git clone -b master  git://git.yoctoproject.org/poky

$ tree poky -L 1
poky
├── bitbake   // bin에 bitbake , bitbake-layers 가 존재하므로 중요   
├── contrib
├── documentation
├── LICENSE
├── LICENSE.GPL-2.0-only
├── LICENSE.MIT
├── meta
├── meta-poky
├── meta-selftest
├── meta-skeleton
├── meta-yocto-bsp
├── oe-init-build-env
├── README.hardware -> meta-yocto-bsp/README.hardware
├── README.OE-Core
├── README.poky -> meta-poky/README.poky
├── README.qemu
└── scripts  // devtool늘 비롯하여 각종 oe-xxxxx tools 제공 

$ cd poky
$ ls
LICENSE     README.hardware  README.qemu  documentation  meta-poky      meta-skeleton   oe-init-build-env
README.LSB  README.poky      bitbake      meta           meta-selftest  meta-yocto-bsp  scripts

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/

poky 에 meta-raspberrypi (BSP Layer) 추가

$ pwd
/home/jhlee/raspberrypi/poky

$ git clone -b master https://github.com/agherzan/meta-raspberrypi

$ tree -L 1 meta-raspberrypi
meta-raspberrypi
├── classes
├── conf
├── COPYING.MIT
├── docs
├── dynamic-layers
├── files
├── README.md
├── recipes-bsp
├── recipes-connectivity
├── recipes-core
├── recipes-devtools
├── recipes-graphics
├── recipes-kernel
├── recipes-multimedia
└── wic


$ ls
LICENSE     README.hardware  README.qemu  documentation  meta-openembedded  meta-raspberrypi  meta-skeleton   oe-init-build-env
README.LSB  README.poky      bitbake      meta           meta-poky          meta-selftest     meta-yocto-bsp  scripts

  https://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/
  https://github.com/agherzan/meta-raspberrypi
  http://meta-raspberrypi.readthedocs.io/en/latest/readme.html
  http://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/

poky 에 meta-oe (Base Layer) 추가

$ pwd
/home/jhlee/raspberrypi/poky

$ git clone -b master git://git.openembedded.org/meta-openembedded 

$ tree -L 1 meta-openembedded/
meta-openembedded/
├── contrib
├── COPYING.MIT
├── meta-filesystems
├── meta-gnome
├── meta-initramfs
├── meta-multimedia  // 이 아래의 4개의 layer만  rpi-build/conf/bblayers.conf 에 추가 
├── meta-networking
├── meta-oe
├── meta-perl
├── meta-python
├── meta-webserver
├── meta-xfce
└── README

https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
http://cgit.openembedded.org/meta-openembedded/tree/

Yocto poky 에서 구조확인가능

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/

2.4 이외의 meta-layer 추가방법

Cookbook을 보면 자세히 나오며 각각 Layer들을 추가하여 확장하기가 쉽다. 다만, Type은 반드시 확인을 해야한다.

OpenEmbeded Layer Index 의 meta-oe Layer 검색

meta-oe (meta-openembedded) Layer Type Base를 찾음
meta-raspberrypi 검색 과 Layer Type BSP 확인

Reference Manual에는 Layer Type은 3가지밖에 없지만, 이곳에는 다음과 같이 더 분류를 하고 의미가 조금 다른 것 같다.

Layer Type

Base: Emdedded에서 기본 Layer로 개발 Tools 및 Kernel 관련부부구성
Machine (BSP) : 각 개별 Board에 맞게 BSP 가 구성되어있어 선택
Distribution : Poky를 기반으로 확장된 배포판으로 구성되어짐
Miscellaneous : 개발환경 혹은 특정 ARCH에 의존적으로 구성이됨
Software : 쉽게 추가가능한 Opensource (이 Layer를 추가)

Base는 현재 meta-oe 와 openembedded-core 두 종류로 제공하고 있지만, meta-oe만 주로 사용한다

meta-oe : Embedded에서 필요한 개발 Tool 및 Kernel
openembedded-core: 많은 부분이 poky와 중복되는 것 같음

OpenEmbedded Layer Index
https://layers.openembedded.org/layerindex/branch/master/layers/

Yocto Site
http://git.yoctoproject.org/cgit.cgi/

3. Yocto의 설정확인 및 변경

bitbake를 사용하기 위해서 아래와 같이 기본빌드환경을 설정해줘야 한다

pocky 안에 oe-init-build-env를 실행하면, bitbake 사용 및 rpi-build directory가 생성이 된다.
물론 그냥 poky안에서 oe-init-build는 상관은 없지만, 모든 빌드내용이 rpi-build에 저장되기때문에 이를 외부를 분리하는 것이다.

$ source poky/oe-init-build-env rpi-build

build directory(rpi-build) 의 이름을 변경을 해도 상관없음

Raspberry PI Yocto 전체구성

물론 rpi-build를 poky 안에도 생성이 가능하지만 이를 외부를 분리하여 Yocto와 Build 부분을 분리한다.

$ tree -d -L 2
├── poky
│   ├── bitbake
│   ├── documentation
│   ├── meta
│   ├── meta-openembedded  // 추가될 layers로 하위 디렉토리에 layer가 존재 
│   ├── meta-poky
│   ├── meta-raspberrypi  // 추가될 layer
│   ├── meta-selftest
│   ├── meta-skeleton
│   ├── meta-yocto-bsp
│   └── scripts
└── rpi-build   // 이곳에서 빌드를 진행하므로, 추후 제거 할때도 이부분만 제거 (2.1 이후 생성)
    ├── cache 
    ├── conf             // 빌드할 Layers 및 MACHINE  설정 
    ├── downloads        // GIT Download   
    ├── sstate-cache
    └── tmp              // tmp/deploy/image/machine/xxxxx  배포

rpi-build 의 user configuration 설정

./conf/bblayers.conf // build할 Layer 추가
./conf/local.conf // build될 machine 설정

3.1 rpi-build/conf/bblayers.conf

본인이 bitbake를 이용하여 빌드하고자하는 각 Layer들을 적용을 하자

rpi-build/conf/bblayers.conf 에 Layer 추가

meta-openembedded의 경우 다수의 meta-layer로 구성이 되어있으므로 아래와 같이 추가.

$ cd rpi-build 
$ vi ./conf/bblayers.conf
.......
BBLAYERS ?= " \
  /home/jhlee/raspberrypi/poky/meta \
  /home/jhlee/raspberrypi/poky/meta-poky \
  /home/jhlee/raspberrypi/poky/meta-yocto-bsp \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-oe \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-multimedia \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-networking \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-python \
  /home/jhlee/raspberrypi/poky/meta-raspberrypi \
  "

3.2 rpi-build/conf/local.conf

MACHINE의 설정 및 전체 변수관련부분 설정 MACHINE이 아니더라도 본인이 원하는 부분을 설정을 하면 전체 적용되므로 중요

rpi-build/conf/local.conf 에 Machine 설정

이제 본인의 board machine을 찾았으니, 이를 적용하자 (상위 conf 제외한 이름)

$ cd rpi-build 
$ vi ./conf/local.conf 
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
MACHINE ?= "raspberrypi3-64"
# This sets the default machine to be qemux86 if no other machine is selected:
#MACHINE ??= "qemux86"

3.3 MACHINE의 Config 확인

conf/local.conf 에서 설정한 MACHINE 은 항상 동일한 이름으로 conf가 존재하며 이를 찾아 관련설정을 확실히 확인하자

MACHINE의 raspberrypi3-64.conf 확인

$ cd pocky 
$ find . -name machine | xargs ls        // MACHINE의 이름을 모를 경우 모든 BSP Layer 검색 
./meta/conf/machine:
include         qemuarm.conf    qemuarm64.conf   qemumips.conf     qemumips64.conf  
qemuppc.conf    qemux86-64.conf qemux86.conf

./meta-raspberrypi/conf/machine:
include/                raspberrypi-cm3.conf    raspberrypi0-wifi.conf  raspberrypi2.conf       raspberrypi3.conf       
raspberrypi-cm.conf     raspberrypi.conf        raspberrypi0.conf       raspberrypi3-64.conf  

./meta-selftest/conf/machine:
qemux86copy.conf

./meta-yocto-bsp/conf/machine:
beaglebone-yocto.conf  edgerouter.conf  genericx86-64.conf  genericx86.conf  include  mpc8315e-rdb.conf

or 
$ find . -name raspberrypi3-64.conf  // MACHINE 이름을 정확히 아는 경우

주로 확인해야 할 것이 UBOOT 설정 과 KERNEL 및 Device Tree 가 될 것 같다

지원 MACHINE 이름

https://layers.openembedded.org/layerindex/branch/master/machines/

4. Bitbake로 기본 빌드

bitbake는 상위 pocky->bitbake안에 존재하므로 이것이 PATH에 적용이 되지 않을 경우는 아래와 같이 동작하지 않는다.
다시 설정하고 싶다면 2.를 다시 설정하면 되며, 상위 저장된 설정도 기억하고 있다.

Bitbake로 빌드진행

$ bitbake core-image-base

빌드를 할 경우, 상당한 시간과 용량을 필요로 하며, 용량은 VDI의 경우 최소 50G로 잡자.
처음 30G (Ubuntu까지 설치된 상태)로 빌드를 진행을 했는데, 용량부족으로 실패했다.

4.1 core-image-minimal 와 core-image-base 차이

yocto에서 image를 생성하기 위해서 상위 target 설정이외 sato or x11 등 다양하게 확장제공하고 있지만, 일단 2개의 정확한 차이를 알아두고 어떻게 확장하는지 알아보자.

bitbake에서 image를 만들때 가장 많이 사용하는 Target or Recipe

core-image-minimal: 기본으로 boot하고 기본동작되는 확인
core-image-base: core-image-minimal 에 MACHINE의 HW의 모든기능을 제공 및 테스트 가능

core-image-base 와 core-image-minimal 각 위치확인

$ pwd
/home/jhlee/raspberrypi/poky

$ find . -name core-image-minimal*
./meta/recipes-core/images/core-image-minimal-mtdutils.bb
./meta/recipes-core/images/core-image-minimal-initramfs.bb
./meta/recipes-core/images/core-image-minimal.bb
./meta/recipes-core/images/core-image-minimal-dev.bb

$ find . -name core-image-base*
./meta/recipes-core/images/core-image-base.bb

core-image-minimal 의 구성확인

IMAGE_INSTALL : packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL} 직접정의
inherit core-image : core-image*.bbclass를 사용

$ cat ./meta/recipes-core/images/core-image-minimal.bb // 아래의 core-image.bbclass 부분과 비교 
SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit core-image

IMAGE_ROOTFS_SIZE ?= "8192"
IMAGE_ROOTFS_EXTRA_SPACE_append = "${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", "" ,d)}"

core-image-base 의 구성 (core-image.bbclass의 IMAGE_INSTALL 사용)

IMAGE_INSTALL: 설정정의가 없으므로, core-image*.bbclass에 정의된 것으로 동작
inherit core-image : core-image*.bbclass를 사용

$ cat ./meta/recipes-core/images/core-image-base.bb
SUMMARY = "A console-only image that fully supports the target device \
hardware."

IMAGE_FEATURES += "splash"

LICENSE = "MIT"

inherit core-image

core-image.bbclass ( inherit core-image 검색)

core-image-minimal 과 core-image-base 의 차이는 IMAGE_INSTALL 차이
core-image-base의 경우 packagegroup-base-extended 부분이 추가됨

$ find . -name core-image*bb* 
..
./meta/classes/core-image.bbclass
..
$ cat ./meta/classes/core-image.bbclass //  inherit core-image 관련부분 확인 

CORE_IMAGE_BASE_INSTALL = '\
    packagegroup-core-boot \
    packagegroup-base-extended \
    \
    ${CORE_IMAGE_EXTRA_INSTALL} \
    '

IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"  

inherit image

image.bbclass (inherit image)

image를 만드는 시작점인 것 같으며, 소스를 보면 전체 동작방식을 대충 이해가 가며 python으로도 구성이되어 소스내용이 길다.

$ find . -name image*bb*  // inherit image 관련부분 검색  
..
./meta/classes/image.bbclass

$ cat ./meta/classes/image.bbclass  
IMAGE_CLASSES ??= ""

# rootfs bootstrap install
# warning -  image-container resets this
ROOTFS_BOOTSTRAP_INSTALL = "run-postinsts"

# Handle inherits of any of the image classes we need
IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
# Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base
# in the non-Linux SDK_OS case, such as mingw32
IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
IMGCLASSES += "image_types_wic"
IMGCLASSES += "rootfs-postcommands"
IMGCLASSES += "image-postinst-intercepts"
inherit ${IMGCLASSES}
..... 너무길어 중략 (do_rootfs 비롯하여 다른 중요부분도 한번봐야함)

공통적으로 inherit core-image로 공유해서 사용되어지고 있으며, 이 부분은 bbclass 로 되어있고, 이 공유하며,
중요한 부분은 IMAGE_INSTALL 의 정의차이를 보면 될 것 같다.

아래링크참조
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-classes-core-image
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-classes-image
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html

4.2 core-image-xxx 확장 및 본인의 Image target 확장

recipe 내에서 include recipe-core/images/core-image-base.bb 추가하여 확장하는 구조이다.

raspberry pi target recipe 확장분석

core-image-minimal 기반으로 본인이 필요한 Package들을 IMAGE_INSTALL 추가하는 방식
rpi-basic-image는 앞으로 안 사용되어질 거라고 하는데, core-image-base 로 하면 될 것 같다.

$ vi meta-raspberrypi/recipes-core/images/rpi-basic-image.bb  
# Base this image on core-image-minimal
include recipes-core/images/core-image-minimal.bb

# Include modules in rootfs
IMAGE_INSTALL += " \
        kernel-modules \
        "

SPLASH = "psplash-raspberrypi"

IMAGE_FEATURES += "ssh-server-dropbear splash"

do_image_prepend() {
    bb.warn("The image 'rpi-basic-image' is deprecated, please use 'core-image-base' instead")
}

나만의 target image recipe 로 확장

IMAGE_INSTALL에 본인이 필요한 Package들을 정의하여 넣고, 새로운 Target Image recipe로 정의

$ vi meta-raspberrypi/recipes-core/images/core-image-jhlee.bb  
SUMMARY = "JHLee Sample Test Image"

# Base this image on core-image-minimal
include recipes-core/images/core-image-base.bb

# ssh server and systemd and tcpdump
IMAGE_INSTALL += "openssh systemd-analyze tcpdump"
        
export IMAGE_BASENAME = "core-image-jhlee"

recipe 검색
https://layers.openembedded.org/layerindex/branch/master/recipes/

4.3 SD Image 확인 및 Writing Image

How to find SD image

bitbake로 core-image-base 빌드 한 후 deploy에서 확인 (SD Image)

$ cd rpi-build/tmp/deploy/images/raspberrypi3-64
$ ls *.rpi*
core-image-base-raspberrypi3-64-20180526144104.rootfs.rpi-sdimg  core-image-base-raspberrypi3-64.rpi-sdimg

How To write SD Image

Linux에서 SD Disk를 접근가능하다면 Image Writing을 할수 있다. ( Virtual Box도 연결해서 하면되지만 절차가 복잡)

$ sudo dd if=core-image-base-raspberrypi3-64.rpi-sdimg of=/dev/sde bs=1M   // 이부분 SD Disk와 연결되었을 경우

상위명령어 대신 이 Image 파일을 Window로 가져와서 Win32DiskImager를 이용하자

Win32DiskImager

https://ahyuo.blogspot.com/2016/05/sd-card-writer-window.html

4.4 Bitbake Build 분석 및 에러사항

Bitbake 빌드 분석

WARNING: Host distribution "ubuntu-14.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Build Configuration:
BB_VERSION           = "1.37.0"
BUILD_SYS            = "x86_64-linux"        // HOST의 Build System 
NATIVELSBSTRING      = "universal-4.8"       // Ubuntu 일 경우 ubuntu로 표시  
TARGET_SYS           = "aarch64-poky-linux"  // Target system 이름 ARM을 사용할 경우 ARM이 표시됨 
MACHINE              = "raspberrypi3-64"     // Board의 Machine 이름   
DISTRO               = "poky"
DISTRO_VERSION       = "2.5"
TUNE_FEATURES        = "aarch64"              // Compiler 관련 설정  
TARGET_FPU           = ""                     // Hardware FPU 설정 
meta                 
meta-poky            
meta-yocto-bsp       = "master:13cc30cd7de4841990b600e83e1249c81a5171dd"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "master:d59b9806f743cea0168cddf942a31dcf446839e6"
meta-raspberrypi     = "master:7f7bc9e778b6def018c451ecb23f5169cd18f5ed"

문제사항 1

https://github.com/WebPlatformForEmbedded/meta-wpe/issues/151

$ bitbake core-image-base 
ERROR: Unable to start bitbake server
ERROR: Last 10 lines of server log for this session (/home/jhlee/raspberrypi/rpi-build/bitbake-cookerdaemon.log):
    self.cooker = bb.cooker.BBCooker(self.configuration, self.featureset)
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cooker.py", line 197, in __init__
    self.initConfigurationData()
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cooker.py", line 356, in initConfigurationData
    self.databuilder.parseBaseConfiguration()
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cookerdata.py", line 317, in parseBaseConfiguration
    raise bb.BBHandledException
bb.BBHandledException
ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH, please install them in order to proceed:
  chrpath gawk makeinfo

아래 Package 설치 후 문제해결 (상위에 모두 표시)

$ sudo apt install gawk
$ sudo apt-get install chrpath
$ sudo apt-get install texinfo

문제사항 2

WARNING: Host distribution "ubuntu-14.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
.......
ERROR: mpfr-native-3.1.5-r0 do_compile: oe_runmake failed
ERROR: mpfr-native-3.1.5-r0 do_compile: Function failed: do_compile (log file is located at /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203)
ERROR: Logfile of failure stored in: /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203
....
| x86_64-linux-libtool:   error: 'set_si_2exp.lo' is not a valid libtool object
| make[2]: *** [libmpfr.la] Error 1
| make[2]: Leaving directory `/home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/build/src'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/build/src'
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203)
ERROR: Task (virtual:native:/home/jhlee/raspberrypi/poky/meta/recipes-support/mpfr/mpfr_3.1.5.bb:do_compile) failed with exit code '1'

Ubuntu 16으로 변경 후 문제 해결 (처음 Ubuntu 14.04로 진행함)
https://stackoverflow.com/questions/36226828/yocto-bitbake-script-not-displaying-echo-statement

10/07/2015

YOCTO 기본사용방법

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을 반드시 참조해야한다.
하지만 기본구성과 기본사용법은 거의 비슷하므로 아래의 기본은 알아두도록하자

TI의 Arago Project

https://www.yoctoproject.org/product/arago-project

Freescale은 IMX6을 다루면서 잠시 아래와 같이 빌드했지만, Freescale에서 제공해주는 문서를 읽는 것이 더 편하게 느껴졌다.

Freescale iMX6

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이 우선되어야 할 것이다.

Yocto 모든 메뉴얼 소개

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

Source Repositories:

http://git.yoctoproject.org/cgit/cgit.cgi

3. Yocto 기본동작

Yocto project는 꼭 임베디드 소스 개발환경에 제공되는 시스템이 아니며, 아래의 구조를 보고 천천히 이해를 하자
각각의 소스를 가져와 패치를 하고 설정을 하며, 원하는 패키지를 생성 후 테스트를 걸쳐, Image를 생성한다. 이것이 기본 Yocto project의 구성이다.

http://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html

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는 다운로드하는 것

Embedded 시스템에서 보면 주요부분

Image Generation (Uboot 와 Kernel / Filesystem)
SDK
Package (rpm/deb/ipk) 다양한 Linux Package를 지원가능

최근에는 라지베리파이까지 지원되는 것으로 보아서 거의 관리부분은 Yocto 추세로 가는 것 같다.

QEMU의 지원

Target CPU 상위 User Configuration에서 설정 기준으로 Image가 생성되고 Depoly 된다
재미있는 것은 QEMU이라는 것이 존재하여 Target CPU를 테스트가 가상으로 TEST가 아래처럼 가능하다.

Quick Start

동작방식 및 처음사용법을 간단히 소개한다.
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

Distro Layer의 기본구성

전체 배포를 위한 규칙담당을 하기 때문에 많이 익숙해져야할 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 제공

BSP Layer의 기본구성

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

Software Layer의 기본구성

상위에서 설정된 배포방식으로 일반 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

모든 Distro 와 BSP layer 찾기

$ 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/

Metadata ( poky의 meta)

좀 더 자세히 알고자 한다면 각각의 recipes들을 살펴보자
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-meta

Custom Layer 구성

상위 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

build directory 설정방법

각 Yocto마다 이름은 조금씩 다를수 있지만, 기본은 enviornment 설정 후 bitbake를 사용가능
처음 source를 이용하여 build 설정할 경우(아래 예제참고)

build direcoty 생성
build의 User Configuration (Source에서 복사해옴)
build enviornment 설정가능 및 bitbake 와 yocto 명령사용가능

재설정 할 경우 (동일하게 입력, 아래 예제참고)

build directory 이미 기존생성것 이용
User configuration 이미 기존생성된것 이용
build enviornment 재설정 후 bitbake 및 yocto 명령어 이용가능

build directory 일반설정의 예

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는 전체 설정에 반영이 되므로 중요하며 관련세부설정도 알아보자.

User configuration 의 구성

build의 conf/bblayers.conf : Layer정보로 Layer를 이곳에 직접추가가능
build의 conf/local.conf : 전체환경 설정값 e.g MACHINE 설정
source의 bblayers.conf.sample 과 local.conf.sample: build의 원본파일

bblayers.conf 환경설정

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

Build의 Directory 기본구성

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 기본사용법

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의 종류에 따라 각 필요하는 부분이 다르므로 관련부분에 대해 알아두도록하자.

Metadata(Recipes)

(*.bb) 파일로 파일 설정 및 빌드 방법 , 종속 문제 및 Recipes의 Version 등 종합적인 관리를 한다.

Configuration Files

(*.conf)로 구성이 되며 다양한 모든 Configuration 설정 을 담당하며, Main에 존재하는 bitbake.conf의 경우는 Compiler 관련 옵션 및 전체 설정을 담당한다.

Classes

(*.bbclass) 로 되며, metadata files사이들의 공유에 유용하며, classes라는 별도의 directory가 존재한다.
모든 recipes와 class가 자동적으로 항상 include 된 후 base.bbclass의 경우는 특별하다고 한다.
한마디라로 상위 metadata를 include할 때 사용하며, 특정 metadata와 공유하여, 각 상속개념으로 사용되어진다.
recipe안에서 class를 사용한다면, inherit를 이용하여 class를 사용한다.

Append Files

(*.bbappend)로 는 말그대로 파일을 추가하는 기능이며, 대신 이것을 이용하기 위해서는
(*.bb)와 이름과 동일하게 (*.bbappend) suffix가 다르게 사용하는 것이다.

Bitbake의 구성요소
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#usingpoky-components-bitbake

Task

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

Source Mirrors의 기본구성

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에 따라 어떻게 사용방법이 다른지는 각각 파악하자

Task 작업

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}

Task 구성

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

Recipe의 경우 Package 기반으로 동작이 되기 때문에 Image를 만들 경우에도 사용되며, do_package를 이용하여 linux package를 지원한다.