Search

'Yocto'에 해당되는 글 3건

  1. 2016.10.02 Yocto 내부 파일 분석
  2. 2016.10.01 Yocto 작동방식
  3. 2016.10.01 Yocto 튜토리얼 (2)

Yocto 내부 파일 분석

컴퓨터공부 2016.10.02 15:50 Posted by 아는 개발자 아는 개발자

Yocto 프로젝트를 다운 받고 나면 c 코드는 하나도 없고 대부분 .bb, .inc로 이뤄진 스크립트 파일들이 대부분인 것을 확인 할 수 있다. 소스코드 하나 없이 위 파일들만 있으면 설정한 보드에서 동작하는 이미지가 나온다는 것이 신기하기도 하다.


눈치를 챈 사람들도 있겠지만 이 .bb, .inc 파일들은 스크립트이다. 이미지를 만들 때 필요한 소스 코드들을,


  • 어디서 읽어올 것인지 (do_fetch)
  • 어떤 설정을 줄 것인지 (do_configure)
  • 어떤 컴파일 명령을 줄 것인지 (do_compile)
  • 어디에 설치 할 것인지(do_install)
에 대한 정보들을 담고 있다. 잘 생각해보면 위의 작업들은 우리가 특정 파일들을 다운받고 빌드 할 때까지 이뤄지는 작업들과 굉장히 유사하다. 예를 들면 linux 4.2 버전을 받고 커널을 빌드 할 때 개발자의 과정들을 보면

  1. 원격 저장소로부터 소스코드들을 다운받는다. ( git clone ~ )
  2. .config 파일을 만든다 ( make config )
  3. 컴파일 실행 make ARCH=x86 ~
  4. 빌드 이미지를 특정 경로로 옮기기 cp zImage { directory }

로 이뤄져 있다. yocto는 이러한 수작업들을 하나의 파일내에서 모두 정리 될 수 있도록 만들어 주는 편리한 시스템이다.


직접 코드를 한 번 보자. poky/meta/recipes-core/glibc/glibc_2.23.bb 스크립트의 내용은 다음과 같다.

 
require glibc.inc

LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
      file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
      file://posix/rxspencer/COPYRIGHT;md5=dc5485bb394a13b2332ec1c785f5d83a \
      file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"

DEPENDS += "gperf-native"

SRCREV ?= "e742928c1592b43db6809db4f39e67be151cdd27"

SRCBRANCH ?= "release/${PV}/master"

GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+\.\d+(\.\d+)*)"

SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
           file://0005-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch \
           file://0006-readlib-Add-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch \
           file://0007-ppc-sqrt-Fix-undefined-reference-to-__sqrt_finite.patch \
           file://0008-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch \
           file://0009-Quote-from-bug-1443-which-explains-what-the-patch-do.patch \
           file://0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \
           file://0011-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch \
           file://0012-Make-ld-version-output-matching-grok-gold-s-output.patch \
           file://0013-sysdeps-gnu-configure.ac-handle-correctly-libc_cv_ro.patch \
           file://0014-Add-unused-attribute.patch \
           file://0015-yes-within-the-path-sets-wrong-config-variables.patch \
           file://0016-timezone-re-written-tzselect-as-posix-sh.patch \
           file://0017-Remove-bash-dependency-for-nscd-init-script.patch \
           file://0018-eglibc-Cross-building-and-testing-instructions.patch \
           file://0019-eglibc-Help-bootstrap-cross-toolchain.patch \
           file://0020-eglibc-cherry-picked-from.patch \
           file://0021-eglibc-Clear-cache-lines-on-ppc8xx.patch \
           file://0022-eglibc-Resolve-__fpscr_values-on-SH4.patch \
           file://0023-eglibc-Install-PIC-archives.patch \
           file://0025-eglibc-Forward-port-cross-locale-generation-support.patch \
           file://0026-When-disabling-SSE-make-sure-fpmath-is-not-set-to-us.patch \
           file://CVE-2016-3706.patch \
           file://CVE-2016-4429.patch \
"

SRC_URI += "\
           file://etc/ld.so.conf \
           file://generate-supported.mk \
"

SRC_URI_append_class-nativesdk = "\
           file://0001-nativesdk-glibc-Look-for-host-system-ld.so.cache-as-.patch \
           file://0002-nativesdk-glibc-Fix-buffer-overrun-with-a-relocated-.patch \
           file://0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch \
           file://0004-nativesdk-glibc-Allow-64-bit-atomics-for-x86.patch \
"

S = "${WORKDIR}/git"
B = "${WORKDIR}/build-${TARGET_SYS}"

PACKAGES_DYNAMIC = ""

# the -isystem in bitbake.conf screws up glibc do_stage
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir}"

GLIBC_BROKEN_LOCALES = " _ER _ET so_ET yn_ER sid_ET tr_TR mn_MN gez_ET gez_ER bn_BD te_IN es_CR.ISO-8859-1"

#
# We will skip parsing glibc when target system C library selection is not glibc
# this helps in easing out parsing for non-glibc system libraries
#
COMPATIBLE_HOST_libc-musl_class-target = "null"
COMPATIBLE_HOST_libc-uclibc_class-target = "null"

EXTRA_OECONF = "--enable-kernel=${OLDEST_KERNEL} \
                --without-cvs --disable-profile \
                --disable-debug --without-gd \
                --enable-clocale=gnu \
                --enable-add-ons \
                --with-headers=${STAGING_INCDIR} \
                --without-selinux \
                --enable-obsolete-rpc \
                ${GLIBC_EXTRA_OECONF}"

EXTRA_OECONF += "${@get_libc_fpu_setting(bb, d)}"
EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'libc-inet-anl', '--enable-nscd', '--disable-nscd', d)}"


do_patch_append() {
    bb.build.exec_func('do_fix_readlib_c', d)
}

do_fix_readlib_c () {
	sed -i -e 's#OECORE_KNOWN_INTERPRETER_NAMES#${EGLIBC_KNOWN_INTERPRETER_NAMES}#' ${S}/elf/readlib.c
}

do_configure () {
# override this function to avoid the autoconf/automake/aclocal/autoheader
# calls for now
# don't pass CPPFLAGS into configure, since it upsets the kernel-headers
# version check and doesn't really help with anything
        (cd ${S} && gnu-configize) || die "failure in running gnu-configize"
        find ${S} -name "configure" | xargs touch
        CPPFLAGS="" oe_runconf
}

rpcsvc = "bootparam_prot.x nlm_prot.x rstat.x \
	  yppasswd.x klm_prot.x rex.x sm_inter.x mount.x \
	  rusers.x spray.x nfs_prot.x rquota.x key_prot.x"

do_compile () {
	# -Wl,-rpath-link <staging>/lib in LDFLAGS can cause breakage if another glibc is in staging
	unset LDFLAGS
	base_do_compile
	(
		cd ${S}/sunrpc/rpcsvc
		for r in ${rpcsvc}; do
			h=`echo $r|sed -e's,\.x$,.h,'`
			rm -f $h
			${B}/sunrpc/cross-rpcgen -h $r -o $h || bbwarn "${PN}: unable to generate header for $r"
		done
	)
	echo "Adjust ldd script"
	if [ -n "${RTLDLIST}" ]
	then
		prevrtld=`cat ${B}/elf/ldd | grep "^RTLDLIST=" | sed 's#^RTLDLIST="\?\([^"]*\)"\?$#\1#'`
		if [ "${prevrtld}" != "${RTLDLIST}" ]
		then
			sed -i ${B}/elf/ldd -e "s#^RTLDLIST=.*\$#RTLDLIST=\"${prevrtld} ${RTLDLIST}\"#"
		fi
	fi

}

# Use the host locale archive when built for nativesdk so that we don't need to
# ship a complete (100MB) locale set.
do_compile_prepend_class-nativesdk() {
    echo "complocaledir=/usr/lib/locale" >> ${S}/configparms
}

require glibc-package.inc

BBCLASSEXTEND = "nativesdk"


스크립트 내용이 많은데 여기서 몇가지만 간추려서 설명을 하고자 한다.


  • SRC_URI: 저장소를 읽어오는 위치와 적용할 패치 파일들이 담겨있다. 가장 상위에 있는 텍스트, ${GLIBC_GIT_URI}는 읽어올 주소를 의미하고, branch는 어떤 브랜치로 checkout할 것인지이다. 그 아래 있는 패치 파일들은 소스코드를 받은 후 적용할 패치파일들이다. Yocto에서 빌드 할 때 패치파일들을 자동으로 적용해준다.
  • do_configure(): 빌드할 config 파일을 만들어 주는 작업이다. 여기에 새로운 내용을 넣어서 config 파일을 만들 수 있다.
  • do_compile(): compile 명령을 내리는 작업이다. compile시에 넣고 싶은 명령을 넣을 수 있다.
  • do_install(): 위 코드에는 빠져있지만 컴파일이 완료된 후 생성되는 빌드 결과물들을 특정 이미지에 놓는 명령들이 포함되어있다.
위의 작업들은 한 파일내에 모두 존재하는 것이 아니고 여러 개의 파일들이 얽혀서 이뤄진다. require * 은 다른 파일들을 포함하는 작업(C언어의 include와 유사)인데 다른 파일의 스크립트 내용도 포함해서 작업이 이뤄진다. 한 파일 내에 모든 작업이 없다면 다른 파일에 있을 가능성이 높으니 참고하자.

가끔 %.bbapend라는 파일이 있는데 이 파일은 말 그래도 bb 파일에 덧붙이는 용도다. 주로 메인 보드가 아닌 다른 보드에서 컴파일 옵션이나 패치파일을 추가 해줘야 하는 경우에 사용한다.


위 설명 yocto파일들을 완벽히 이해 할 수는 없지만 어떻게 수정하면 되겠구나 감 정도는 잡을 수 있게 된다.

'컴퓨터공부' 카테고리의 다른 글

objdump 를 이용한 바이너리 깨보기  (0) 2018.05.29
그래픽 소프트웨어, 라이브러리 정리  (0) 2018.05.06
Yocto 내부 파일 분석  (0) 2016.10.02
Yocto 작동방식  (0) 2016.10.01
Yocto 튜토리얼  (2) 2016.10.01
Yocto란?  (2) 2016.09.16

Yocto 작동방식

컴퓨터공부 2016.10.01 13:51 Posted by 아는 개발자 아는 개발자

Yocto 공식 홈페이지에 있는 yocto 아키텍쳐에 따르면 yocto는 다음과 같은 방식으로 구동된다.




위의 그림은 개발자가 하는 일과 yocto가 하는 일이 뒤섞여 있다. 각각을 나눠서 설명해보면 다음과 같다.


개발자


1. 개발자가 빌드 스크립트를 작성한다.


Metadata(.bb + patches) 파일들을 작성한다. Yocto로 개발시 개발자가 주로 하는 일이다.


2. 환경설정, Machine 등을 설정한다


Machine(BSP) configuration, Policy Configuration, User Configuration. 주로 build 환경 설정 후 conf폴더 내의 .conf 파일들을 수정하는 작업을 말한다. 개발자가 작성/다운 받은 레시피들 중에서 어떤 machine 환경에서 빌드할 것인지 설정하는 작업이다.


3. bitbake 명령어로 빌드한다


작성한 Metadata 파일과 설정 환경에 따라서 Yocto를 구동시킨다. 여기까지가 개발자가 하는 일이다. 중간에 문제가 없으면 나머지는 yocto가 알아서 해준다.


이제 yocto는 개발자가 작성한 스크립트에 맞춰서 빌드를 시작한다. 빌드 작업은 다음과 같이 이뤄진다.


Yocto


1. 소스 코드를 받아온다.


Metadata에 .bb 파일을 보면 SRC_URI가 있고 여기에 주소가 입력되어 있다. 이건 위 주소에서 파일들을 받아오라는 뜻이다. 


2. 패치를 적용한다. 


Patch Application, SRC_URI에 가끔 file://somepatch.patch 로 패치파일이 들어가 있는 경우가 있다. 이건 소스를 받고 패치 파일을 적용하라는 뜻이다. 


3. Config 파일 만들고 빌드 시작


Configuration/Compile 리눅스를 컴파일 할 때를 생각해보면 먼저 config 파일을 만들고 다음 그 config 파일을 토대로 compile을 한다. 이것도 똑같다. 1, 2에서 받아온 소스코드들을 가지고 configuration 작업을 하고 compile을 하는 것이다. 리눅스 같은 OS 코드 뿐만 아니라 gcc 컴파일러도 받아온다.


4. 생성된 package 파일들 분석


만들어진 파일들을 분석해 package 형태로 만든다. 그리고 각각의 연관 관계를 분석한다.


5. Generation


만들어지 파일들을 ipk, rpm, deb 파일의 형태로 만든다. 어디든 쉽게 적용 할 수 있게 압축된 형태로 제공하는 것이다.


6. 이미지 생성


만들어진 파일들을 모두 통합해서 통합 이미지를 만든다. 이 이미지는 아까 개발자가 입력한 Machine에 빌드 할 수 있는 이미지이다.


이미 PC에 설치된 소스코드까지 모두 받아오기 때문에 용량을 많이 잡아먹는 문제점이 있지만 


  • 다른 사람들과 공통된 작업 환경을 만들어 준다는 점
  • 원하는 환경에 맞춰서 빌드 해준다는 점
  • 한 번만 맞춰두면 컴파일러 에러는 신경쓰지 않아도 된다는 점

을 생각해본다면 Yocto는 이득인 것 같다.


'컴퓨터공부' 카테고리의 다른 글

objdump 를 이용한 바이너리 깨보기  (0) 2018.05.29
그래픽 소프트웨어, 라이브러리 정리  (0) 2018.05.06
Yocto 내부 파일 분석  (0) 2016.10.02
Yocto 작동방식  (0) 2016.10.01
Yocto 튜토리얼  (2) 2016.10.01
Yocto란?  (2) 2016.09.16

Yocto 튜토리얼

컴퓨터공부 2016.10.01 13:00 Posted by 아는 개발자 아는 개발자

Yocto 공식 매뉴얼 사이트(http://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html)를 참고해서 


yocto를 한번도 다뤄보지 않은 사람이 qemux86(가상머신)로 구동 할 수 있는 이미지를 만드는 방법을 소개한다


1. 먼저 PC OS 버전에 따라서 yocto 빌드에 필요한 기본 라이브러리들을 설치해야 한다.


Ubuntu를 사용하는 경우는 다음과 같다.

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat libsdl1.2-dev xterm

2. 최신 yocto 릴리즈 프로젝트를 받는다.

     $ git clone git://git.yoctoproject.org/poky
     Cloning into 'poky'...
     remote: Counting objects: 226790, done.
     remote: Compressing objects: 100% (57465/57465), done.
     remote: Total 226790 (delta 165212), reused 225887 (delta 164327)
     Receiving objects: 100% (226790/226790), 100.98 MiB | 263 KiB/s, done.
     Resolving deltas: 100% (165212/165212), done.
     $ git checkout jethro

프로젝트 파일을 받고 폴더 내부를 보면 이상한 meta-* 폴더들만 가득할 것이다. 위 폴더는 특정 타겟 빌드에 필요한 스크립트를 갖고있다. 일단 무시하자.


3. 작업 환경 설정하기

$ source oe-init-build-env

oe-init-build-env 파일은 host PC에 필드 환경을 정의해주는 스크립트다. 복잡하게 생각하기 싫으니 일단 실행하고 보자. 그럼 자동으로 build 폴더가 생성되고 이동하게 된다.


build 폴더 안에는 conf 폴더가 있고 그안에는 bblayer.conf, local.conf 이런 애들이 있다. 딱 봐도 설정을 해주는 녀석들로 보인다. 한번 파일을 열어보자.


bblayer.conf

 
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ~/TASKSPACE/poky/meta \
  ~/TASKSPACE/poky/meta-poky \
  ~/TASKSPACE/poky/meta-yocto-bsp \
  "


아까 본 meta-* 로 시작하는 이상한 폴더들의 경로명이 가득하다. 이 파일은 참조할 스크립트들의 경로를 지정하는 것이다. 어떠한 폴더 파일들을 볼 것인지 개발자가 직접 설정 할 수 있다.


local.conf

 
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86"


이미지가 구동될 타겟을 선택하는 파일이다. 한 번쯤 볼만한 qemuarm, qemuarm64 같은 녀석들이 주석처리 되어있고 작성자가 말한 qemux86은 주석처리 되어 있지 않다. 자동으로 설정되는 것 같다.


4. 이미지를 빌드

bitbake core-image-sato

qemux86에서 구동 할 수 있는 이미지를 만드는 작업이다. 컴퓨터 환경에 따라서 다르지만 1-2시간 정도 소요된다. 


5. 빌드 종료


빌드가 마치면 파일들은 build/tmp/deploy/images/qemux86/ 에 있다. 이 이미지를 가지고 qemux86을 실행해 구동해보자.


Yocto를 이용해 qemux86에 구동 할 수 있는 기본 이미지를 만드는 작업이다. 다음 포스팅에는 yocto의 작동 방식에 대해 소개한다.

'컴퓨터공부' 카테고리의 다른 글

objdump 를 이용한 바이너리 깨보기  (0) 2018.05.29
그래픽 소프트웨어, 라이브러리 정리  (0) 2018.05.06
Yocto 내부 파일 분석  (0) 2016.10.02
Yocto 작동방식  (0) 2016.10.01
Yocto 튜토리얼  (2) 2016.10.01
Yocto란?  (2) 2016.09.16
  1. PTR 2018.03.13 15:59  댓글주소  수정/삭제  댓글쓰기

    ...
    build-essential chrpath socat libsdl1.2-dev xter
    ...
    xterm 인데 m이 빠졌네요. xter가 뭔지 한참 찾았어요.ㅠㅠ.
    아뭏든 감사합니다. 많은 도움이 됐어요.