독일에 있는 자동차 소프트웨어 개발자

회사에서 개발자 대상으로 Yocto Training 자료 정리하는 중에 도움이 될 만한 자료가 있어 공유하고자 한다. 첫번째 두 세션은 Yocto 프로젝트에 대한 개념을 소개하고 나머지 두 세션은 layer, image, application 생성에 대한 실습을 하면서 필요한 yocto 개념을 설명한다. Yocto는 임베디드 개발에서 프로그래밍을 하는 것에 대한 기본 지식을 가지고 이해해야 해서 약간의 사전 지식이 필요하다. Yocto 프로젝트에 대한 짧은 소개 - 개념 잡기 (5분) Getting started with Yocto (1:03:26) Embedded Linux 에 대한 간단한 정의부터 시작해서 1시간 동안 Yocto Project에 대해 소개한다. 아래 총 4개의 세션으로 나누어져 있는 ..

Yocto 기반으로 임베디드 리눅스를 개발할때 일반적으로 많이 사용하는 개발 환경을 소개하고자 한다. 다들 알고 글을 읽고 있겠지만 간단히 Yocto에 대해서 다시 소개하자면 하드웨어 아키텍처와 무관하게 커스텀 임베디드 리눅스를 만들기 위한 빌드 프레임워크이다. 자세한 내용은 https://www.yoctoproject.org/ 를 방문해서 문서와 함께 살펴보면 된다. Yocto 기반으로 개발을 해본 분들은 알고 있겠지만 일단 Yocto 자체를 배우는 것에 대한 시간이 소요된다. 오죽하면 "욕나오고 토나온다고 해서" 욕토라고 하겠는가? :) 물론 Yocto 원어는 10의 -24승, 아주 작은 단위를 말한다. 이유야 어찌되었건 그만큼 Yocto 환경에서 개발하는데 어렵다는 의미이다. 그럼 왜그렇게 다들 어..

Yocto 프로젝트에서는 CI와 연동하여 QEMU에서 자동화 테스트를 할 수 있는 image test framework인 oeqa를 제공을 한다. 이 테스트는 ssh를 통해 타깃 시스템에서 실행이 되고 테스트 스크립트를 파이썬으로 작성이 된다. 이 테스트의 구현 사항은 testimage.bbclass에 구현이 되어 있다. 위의 그림은 Yocto QEMU 이미지 빌드후 QEMU를 실행하는 과정이다. Yocto 자동화 테스트를 하려면 테스트 환경 설정 및 테스트 케이스를 파이썬 스크립트로 작성해야 한다. 테스트 케이스 구현 테스트 케이스는 일반적으로 /lib/oeqa/runtime/cases 에 위치를 한다. Poky의 테스트 케이스를 참고하려면 다음 링크를 가서 하나씩 살펴보면 된다. 아래 예제는 conn..

Yocto 프로젝트는 가능한 모든 컴포넌트를 직접 빌드하여 사용한다. 그렇기 때문에 빌드 시간이 오래 걸리고 이를 보완하기 위해 PREMIRROR와 Shared State Cache를 사용하여 빌드 시간을 단축한다. 하지만 여전히 의존성 등의 문제로 수정하지 않은 컴포넌트를 전체 컴파일하기도 한다. 이를 보완하기 위해 ccache를 사용할 수 있다. ccache ccache (https://ccache.dev/) 는 컴파일러 캐시이다. 이전에 컴파일 했던 캐시를 저장했다가 다시 재사용하여 컴파일 속도를 빠르게 한다. GCC, Clang 등의 컴파일러를 지원하고 윈도우, 맥, 리눅스 등의 운영체제에서 동작한다. Yocto에 ccache 적용하기 yocto에는 ccache.bbclass가 있다. 그 파일 안..

honister 3.4 버전에서 Yocto 오버라이드 문법이 변경되었다. "_"를 사용 하던 것이 ":" 로 변경되었다. 예를 들면 아래와 같다. 기존 문법 SRC_URI_qemux86 = "file://somefile" 신규 문법 SRC_URI:qemux86 = "file://somefile" 물론 기존 변수 이름에 _를 사용하여 약간 헤깔리는 경우가 있다. BBFILE_PATTERN, SRC_URI, PREFERRED_VERSION_xxx, SRCREV_xxx 등이 있다. 위의 것들은 변경 없이 기존과 같이 사용한다. 문법 변경사항을 쉽게 적용하기 위해 Yocto에서는 script를 제공하니 한꺼번에 변경하려면 아래 스크립트를 사용하면 된다. $ /scripts/contrib/convert-overr..

Yocto에서는 빌드 과정 중 각 컴포넌트의 태스크를 빌드할 때 사용한 리소스(CPU, Disk) 사용량 및 빌드 시간을 저장할 수 있다. 이는 빌드 시간을 최적화하는데 많은 도움을 준다. 빌드 통계를 활성화 하는 방법은 conf 파일 (ex, local.conf)에 다음 라인을 추가하여 빌드하면 된다. INHERIT += "buildstat" 빌드를 하면 아래 그림과 같이 build/tmp/buildstats/[timestamp] 디렉토리에 레시피 디렉토리가 있고 그 디렉토리 안에 태크스 별로 파일이 생성된다. 아래는 zip 컴포넌트의 do_compile 태스크 결과 파일이다. 이 파일들만을 가지고는 분석하기 어렵기 때문에 yocto에서는 시각화할 수 있는 python 스크립트를 제공한다. 다음 명령어..

Yocto dunfell (3.1)이 릴리스되기 전까지 Yocto는 기본적으로 6개월 주기의 릴리스 과정을 거치고 새로운 버전이 릴리스되면 이전버전의 유지보수를 멈추었다. 하지만 많은 요구사항 중에 하나는 Kernel과 같이 LTS (Long Term Support)를 해달라는 것이였고 Board 미팅에서 지원하기로 결정했다. 그 시작은 Yocto dunfell (3.1)부터였고 2년간 유지보수를 하기로 결정하였다. 하지만 2년이 지나서도 커뮤니티 및 보드 멤버 회사에서 추가적인 유지보수를 요구하였고 dunfell은 4년 동안 유지보수를 하기로 결정하였다. 그리고 그 다음 LTS 버전은 kirkstone (4.0)이고 이미 릴리스가 되어 있다. 현재 프로젝트는 dunfell을 사용하고 있고 필자의 동료가..

QNX를 SafeOS로 사용하고 있는데 빌드 시스템이 엉망이다. QNX에서는 기본적으로 제공하는 것은 단순 Makefile + 약간 QNX 수정사항이 들어가 있는 qconfig.mk 파일을 사용한다. 작은 프로젝트는 괜찮지만 의존성과 형상관리를 잘 하면서 빌드를 잘 할 수 있는 도구들이 어떤 것이 있을까 생각해보았다. 회사에서는 CMake를 기반으로 한번 더 감싼 빌드 시스템을 사용하였고 Docker 환경에서 돌아간다. 코드는 모두 소스가 아니고 일부는 바이너리로 제공되고 뭔가 CMake로 커버하기에는 불안정하고 workaround가 많다. QNX는 SDP (Software Development Platform) 에서 toolchain, 기본 바이너리 등을 제공한다. SDP를 받을 때 SoC 벤더의 So..

Macbook에서 Docker를 이용한 Yocto 빌드 환경 설정을 하는 것에 대해서는 https://yocto.tistory.com/158 에서 소개하였다. 이 글에서는 Yocto 빌드 후 생성된 qemu 이미지를 docker 환경 내에서 실행하여 docker host 환경과 실행된 qemu 내부의 shell 간의 네트워킹을 하는 방법에 대해서 설명하고자 한다. TUN/TAP (https://en.wikipedia.org/wiki/TUN/TAP) 환경을 root유저로 만들어서 실행을 하여 네트워크를 구성하는 것을 권장하지만 docker 환경 내이고 쉽게 테스트를 하기 위해 여기에서는 qemu를 실행할 때 user networking 환경인 slirp를 이용하여 구성한다. 이전 글에서도 설명했지만 실행은..

Yocto 빌드는 원칙적으로 툴체인을 포함한 모든 컴포넌트를 직접 빌드해서 사용한다. 컴포넌트를 빌드할 때 host 빌드 서버의 라이브러리들을 참고해서는 안된다. 이번에는 dunfell에서 잘 빌드되던 컴포넌트가 kirkstone으로 오면서 아래와 같은 에러가 발생했다. aarch64-poky-linux/11.3.0/ld: cannot find /lib/libc.so.6: No such file or directory /lib/libc.so.6 이 경로를 참조하면 안된다. sysroot의 경로를 제대로 참고해야하기 때문에 LDFLAGS += "-L${STAGING_LIBDIR}" 한줄을 yocto recipe에 라이브러리 PATH를 staging 에 명시적으로 넣어주면 된다.