KSEM WETI PG April 20, 2015 Yocto
Historia Projekt - framework do budowania dystrybucji Linux dla systemów wbudowych Wyrósł na bazie projektu OpenZaurus dla Sharp Zaurus Personal Digital Assistants (PDAs). W 2001 roku Sharp Corporation przedstawił SL-5000 PDA, nazywany Zaurus, z dystrybucją Linux o nazwie Lineo. Niedługo po tym Chris Larson uruchomił projekt OpenZaurus - system operacyjny oparty na systemie buildroot. Programiści zaczęli rozszerzać projekt o kolejne pakiety programów dla coraz bardziej licznych platform sprzętowych. Styczeń 2003 - społeczność skupiona wokół OpenZaurus rozpoczęła dyskusję o rozwijaniu nowego do budowania dystrybucji Linux dla systemów wbudowanych. Chris Larson, Michael Lauer, and Holger Schurig rozpoczęli pracę nad. Marzec 2011 - połączenie projektów i Yocto pod nazwą OE-Core. Yocto
Bitbake i metadane Dwa zasadnicze elementy projektu - build engine (napisany w Python-ie) Metadata (metadane) - instrukcje budowania dla From OE user s manual: unlike single project tools like make [] is not based on one makefile or a closed set of interdependent makefiles, but collects and manages an open set of largely independent build descriptions (package recipes) and builds them in proper order. Yocto
Outline Yocto Yocto
Yocto. Źródło: P. Raghavan, Amol Lad, Sriram Neelakandan, Embedded Linux system design and development analizuje przepisy (recipes) i pliki konfiguracyjne, aby ustalić, co i jak ma być zbudowane Pobiera z sieci kod źródłowy Buduje obrazy zbiorów pakietów i plików
Implementacja w Python ie na bazie menadżera pakietów Gentoo (emerge) Pobiera kody źródłowe z sieci, jako tarballs (archiwa.tar) lub z repozytoriów (svn, cvs, git...) Instaluje patch-e zawarte w opisach pakietów Domyślnie buduje najnowsze wersje wszystkich kompontentów Buduje wskazane wersje kompilatorów i kompilatorów skrośnych (crosscompilers) oraz narzędzi konfiguracyjnych (autoconf...) Konfiguruje, kompiluje i lokuje pakiety (kopiuje do plików), włącznie z bibliotekami C Potrafi kompilować równolegle dla kilku różnych architektur sprzętowych Buduje obrazy systemów plików, obsługuje formaty pakietów:.rpm,.ipk,.deb Yocto
Formaty pakietów Linux deb - skrót od Deborah, imienia byłej żony twórcy Debiana, Iana Murdocka. Format pakietu instalacyjnego używanego przez dystrybucję operacyjnego Linux Debian GNU/Linux i pochodnych (Progeny, Ubuntu, Corel). Instalator: dpkg. Używa Makefile do kontroli procesu budowania pakietu. rpm - skrót od Red Hat Package Manager. Format pakietu instalacyjnego używanego przez dystrybucję operacyjnego Red Hat Linux (aktualnie również przez dystrybucje Fedora, SUSE, Mandriva, PLD). Instalator: rpm. Używa własnego narzędzia do kontroli procesu budowania pakietu (rpmbuild) Makra RPM są tłumaczone na przepisy dla Makefile. ipk - wcześniej ipkg (Itsy Package Management System) Format pakietu instalacyjnego używanego przez dystrybucje pochodne Debiana dla systemów wbudowanych (Unslung, OpenWrt, Openmoko, webos, Gumstix, the ipaq, QNAP NASes) oraz i. Instalator: opkg (kiedyś ipkg) Yocto
Bitbake - proces budowania obrazu Yocto Źródło: www.denx.de/wiki/
Outline Yocto Yocto
(Metadata) Cztery funkcjonalne katogorie metadanych: Przepisy, ang. Recipes (*.bb) instrukcje dla do zbudowania pojedynczego pakietu. Opisują pakiet, jego zależności i ewentualne specjalne akcje potrzebne do jego zbudowania Klasy, ang. Classes (*.bbclass) enkapsulują funkcjonalnści przepisów. Pełnią rolę podobną do klas w obiektowych językach programowania Zadania, ang. Tasks używane do grupowania pakietów w systemie plików. Mają relatywnie prostą budowę, zwykle składają się z kilku linii definiujących zależności miedzy pakietami. Konfiguracje, ang. Configuration (*.conf) określają ogólne zachowanie (local configuration, machine/distro configuration). Yocto
Outline Yocto Yocto
Praca z Pobranie : git clone git://git.openembedded.org/openembedded-core Pobranie (do katalogu openembedded-core): git clone git://github.com/openembedded/bitbake Yocto Konfiguracja : http://docs.openembedded.org/usermanual/html/gettingoe_configuring_oe.html
Struktura katalogów przestrzeni roboczej my_oe/ bitbake bin... OE.mtn openembedded _MTN ==> special Monotone directory classes conf contrib files packages ==> package rule files, bitbake recipes tasks/ ==> base tasks, useful tasks groups in file recipes conf machine/ ==> machine rule files distro/ ==> distro rule files site Yocto
Konfiguracja środowiska Bitbake powinien być zawsze dostępny jako plik wykonywalny. W starszych wersjach OE należy ustawić zmienne środowiskowe BBPATH i BBFILES: $ export PATH=$PATH:${HOME}/my_OE/bitbake/bin/ $ export BBPATH=${HOME}/my_OE/build:${HOME}/my_OE/openembedded $ export BBFILES=${HOME}/my_OE/openembedded/packages/ /.bb Jeśli pracujemy z najnowszą wersją OE, konfigurację środowiska definiuje plik oe-init-build-env: Yocto $ source./oe init build env [<build directory>]
Plik local.conf Plik konfiguracyjny w katalogu roboczym: my_oe/ build/ conf/ local.conf Podstawowy plik konfiguracyjny ze zmiennymi OE. Najważniejsze z nich to: MACHINE = "any_available_machine_type" DISTRO = "any_available_distro" OE wykorzystuje tą informację jako punkt wyjściowy do zbudowania kompilatora skrośnego dla docelowej architektury oraz zbudowania dystrybucji OS dla tej architektury. Yocto
Budowa dystrybucji (distro) Budowa przykładowego obrazu: ~/my_oe/build$ bitbake core image minimal I włączamy ulubiony kanał YouTube... ;) Yocto
Budowa dystrybucji (distro) Po pierwszej kompilacji utworzony zostaje nowy katalog tmp, którego używa jako katalogu wyjściowego: ~/my_oe/build/tmp/ cache/ cross/ ==> cross tools (gcc, ldd,...) deploy/ images ==> final image files (cpio, jffs2, ext3,...) ipk ==> final packets rootfs/ ==> final rootfs layout. staging/ ==> shared items availables for the whole system. stamps/ ==> magnagement stamps. work/ ==> where bitbake uncompress, configure, compile,... Yocto
Yocto - najmniejsza jednostka układu SI. Prefiks yocto oznacza 10^-24. Projekt powstał na bazie. Rdzeń projektu Yocto to system Poky (autor: Richard Purdie). Listopad 2010 - pod opieką Linux Foundation. od 2011 - i rozwijane razem jako zbiór pakietów OE-Core. Yocto
Elementy Yocto Poky - system do budowania OS Wirtualny obraz hosta do pracy z Yocto Instalator Application Development Toolkit (ADT) dla hosta Dla różnych platform: wstępnie zbudowane (prebuild) łańcuchy narzędzi (toolchains) wstępnie zbudowane pakiety w formie binarnej wstępne zbudowane obrazy Nowa wersja Yocto pojawia się raz na ok. 6 miesięcy. Najnowsza to Yocto 1.8.1 Fido (wcześniejsza: Yocto 1.7.1 Dizzy). Yocto
Outline Yocto Yocto
Narzędzie Poky służy do budowania elementów Linux: obraz bootloadera, obraz jądra Linux, obraz plików, toolchains i software development kits (SDKs) do tworzenia aplikacji. - początkowa struktura (footprint) obrazu: od wersji minimalnej (shell) do pełnego Linux z interfejsem użytkownika Sato (oparty na GNOME Mobile and Embedded (GMAE)). Możliwe jest dodawanie nowych warstw metadanych dla rozszerzenia funkcjonalności (nowy rodzaj obrazu, dodatkowy board support package (BSP) dla nowej platformy sprzętowej). Yocto
Przygotowanie środowiska pracy Profesjonalna stacja robocza programisty powinna spełniać następujące wymagania: system wieloprocesorowy symetryczny (symmetric multiprocessing,smp) co najmniej 8 GB pamięci, szybki dysk twardy szybkie łącze internetowe Wymagane oprogramowanie: OS Linux (jako system natywny lub wirtualny) Tar w wersji 1.24 lub wyższej Python w wersji 2.7.3 lub wyższej (ale nie Python 3) Instalacja wymaganych pakietów: Yocto $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gccmultilib build-essential chrpath socat libsdl1.2-dev xterm make xsltproc docbook-utils fop dblatex xmlto autoconf automake libtool libglib2.0-dev python-gtk2 bsdmainutils screen
Outline Yocto Yocto
Środowisko do wirtualizacji ( hosta) Yocto
= abstrakcja zasobów. Rodzaje: Emulacja API - wprowadzenie do głównego operacyjnego otoczenia API aplikacji pochodzące z innego. Przykład: Wine (ang. Wine is not emulator) - implementacja WinAPI dla środowiska Unix/X11. Emulacja pełna stanowi sposób na uruchamianie aplikacji pochodzących z niekompatybilnego komputera, w stosunku do wykorzystywanego (np. PC/Mac). Emulowane są podstawowe podzespoły komputera (CPU, RAM, HDD, CD itp.) wraz z systemem operacyjnym (virtual OS), zapewniając dużą przenośność. Emulator wykonuje w pętli wszystko to, co robiłby rzeczywisty procesor maszyny emulowanej, co prowadzi do spadku wydajności pracy komputera. Przykład: QEMU. Yocto
wiele systemów operacyjnych na tej samej platformie sprzętowej i systemowej przy maksymalnej możliwej wydajności. Procesy operacyjnego gościa ( emulowanego) wykonywane są bezpośrednio na zasobach sprzętowych komputera. Dopiero w sytuacji, gdy operacje takie nie dadzą się bezpośrednio wykonać, wirtualizator emuluje je. Hipernadzorca (ang. hypervisor), menedżer maszyn wirtualnych (ang. Virtual Machine Manager) narzędzie niezbędne do prowadzenia procesu wirtualizacji. Nazwa pochodzi od supervisor (ang. nadzorca) programu kontrolującego pracę komputera. Decyduje, które procesy wirtualizowanego OS można wykonywać bezpośrednio na zasobach sprzętowych, a które należy emulować. Jeżeli określona operacja nie daje się wykonać bezpośrednio na danym zasobie sprzętowym (błąd ochrony), jest przechwytywana i emulowana przez hipernadzorcę. Pośredniczy w przekazywaniu przerwań pomiędzy wirtualnym systemem a zasobami sprzętowymi Przykłady: VMware Workstation, Virtual Box Yocto
Docker - kontenery Kontenery - sposób na separację aplikacji od operacyjnego oraz fizycznej infrastruktury wykorzystywanej do połączeń z siecią. Są one instalowane poza jądrem operacyjnego i wirtualizują środowisko określonej aplikacji. Pierwowzór - chroot w systemach UNIX. Komenda Linux ograniczająca zasoby, który może wykorzystywać proces i każdy wywoływany przez niego proces-dziecko. Kontenery wspierane przez system Linux (LXC, Linux Kernel Containers) - jedna z najnowocześniejszych metod wirtualizacji aplikacji. LXC pozwala na przydział zasobów CPU, pamięci, dysków i sieci dla aplikacji odizolowanych od OS LXC separuje drzewa procesów, dostęp do sieci, ID użytkownika, dostęp do plików. Kontenery Linux są elastyczne, ponieważ pozwalają administratorowi wirtualizować pojedynczą aplikację, a nie cały system operacyjny z wykorzystaniem VM. Yocto
Docker Docker - aplikacja pracującą na podbudowie w postaci LXC Zarządza obrazami oraz asystuje we wdrożeniach wirtualizacji aplikacji. Dostarcza automatyzacji oraz mechanizmów szybkiego tworzenia kontenerów LXC. Dockerem był wewnętrznym projektem rozwijanym w firmie dotcloud. W marcu 2013 Docker został udostępniony publicznie. Aktualnie jest zintegrowany z szeregiem innych narzędzi m.in. Ansible, Chef, OpenStack, Pupper, Salt. Jest też dołączony do RHEL, OpenShift PaaS, Google Compute Engine, Deis, a także Amazon Web Services Elastic Beanstalk. Standard wirtualizacji aplikacji dla system Linux. Yocto
Docker a wirtualna maszyna Yocto Źródło: http://patg.net/containers,virtualization,docker/2014/06/05/docker-intro/
Docker Strona domowa: https://www.docker.com/ Instalacja w Debianie: $ sudo apt get install docker.io Pierwsze uruchomienie w Debianie (stworzenie kontenera): $ sudo docker run nazwa_obrazu Uruchomienie kontenera (lista kontenerów: docker ps -a): $ sudo docker start nazwa_kontenera Yocto Uruchomienie ze współdzielonym katalogiem: $ sudo docker run v /var/logs/on/host:/var/logs/in/container
Emulator QEMU Quick EMUlator - szybki emulator dostępny jako otwarte oprogramowanie. Umożliwia uruchomienie kilku systemów operacyjnych jednocześnie na jednej maszynie. Emulacja wielu architektur CPU. Sama aplikacja może działać w dwóch trybach: użytkownika uruchamianie procesów Linux skompilowanych na innym typie procesora niż bieżący (np. aplikacje 64-bitowe na procesorze 32-bitowym). emulowany jest cały system, łącznie z procesorem, dyskiem twardym oraz odpowiednimi urządzeniami peryferyjnymi. Możliwe uruchamianie i instalowanie OS na różne architektury: x86, x86_64, ARM, SPARC, SPARC64, PowerPC, PowerPC64, MIPS, m68k (Coldfire), SH-4, Alpha, CRIS.vvv więcej na: http://osworld.pl/qemu-emulator-procesora/ Yocto
Outline Yocto Yocto
System Poky - platformy sprzętowe System Poky obsługuje wirtualne maszyny QEMU dla następujących architektur: ARM (qemuarm) x86 (qemux86) x86-64 (qemux86-64) PowerPC (qemuppc) MIPS (qemumips, qemumips64) Obsługuje też wybrane pakiety BSP (Board Support Packages) dla platform sprzętowych: Texas Instruments Beaglebone (beaglebone) Freescale MPC8315E-RDB (mpc8315e-rdb) Maszyny PC oparte na układach Intel x86 (genericx86 i genericx86-64) Ubiquiti Networks EdgeRouter Lite (edgerouter) Do pracy z innymi platformami sprzętowymi potrzebne są dodatkowe warstwy Yocto (co najmniej BPS). Yocto
Warstwy Poky System Poky posiada trzy katalogi przechowujące metadane: meta: metadane -Core; wsparcie dla architektur ARM, x86, x86-64, PowerPC, MIPS imips64 oraz dla wirtualnej maszyny QEMU meta-yocto: metadane dystrybucji Poky meta-yocto-bsp: metadane dla wybranych platform sprzętowych Poky posiada również warstwę meta-skeleton, będącą wzorcem (schematem) dla nowych warstw. Yocto
Katalog roboczy Poky (build directory) uruchomienie skryptu (sourcing) oe-init-build-env: ustawia zmienne środowiskowe, tworzy pliki konfiguracyjne (można je modyfikować) sprawdza, czy spełnione są minimalne wymagania systemowe dla skrypt woła scripts/oe-setup-builddir script, który tworzy katalog roboczy. w momencie utworzenia katalog ten zawiera trzy pliki: bblayers.conf: lista warstw służących do budowy dystrybucji OS local.conf: konfiguracja parametrów procesu budowy dystrybucji templateconf.cfg: wzorcowe pliki konfiguracyjne. Yocto
System Poky analizuje konfigurację obrazu (m.in. pliki: bblayers.bb, local.conf) poszukując dodatkowych warstw, klas, przepisów i zadań i budując łańcuch zależności między nimi (i standardowymi elementami OE-core). Tak powstaje mapa ważonych priorytetów zadań (weighted task priority map). korzysta z tej mapy podczas ustalania kolejności budowy poszczególnych pakietów. Zadania wymagane przez większość innych zadań oceniane są wyżej, a więc będą wykonane wcześniej podczas procesu budowy dystrybucji OS wykonuje kolejkę zadań rozdzielając je między wątki (maksymalna liczba wątków zdefiniowana jest przez zmienną BB_NUMBER_THREADS w pliku conf/local.conf) Yocto
System Poky ZADANIE OPIS FUNKCJA Fetch pobranie danych (źródeł) do_fetch() Unpack rozpakowanie danych do_unpack() Patch dodanie łatek (patch-ów) do_patch() Configure konfiguracja drzewa źrodeł do_configure() Compile kompilacja drzewa źródeł do_compile() Stage instalacja w przestrzeni stage do_stage() Install instalacja do_install() Package utworzenie pakietu do_package() Skompilowane źródło jest rozdzielane na pakiety; tworzona jest inforamcja dla debuggera (debug package information). Rozdzielone pakiety pakowane są do odpowiedniego formatu (rpm, ipk lub deb). Bitbake wykorzystuje je do budowy plików. Yocto
System Poky Każdy aspekt procesu budowania jest kontrolowany przez metadane. mogą być luźno pogrupowane w: przepisy (package recipes) zbiór niewykonywalnych metadanych, wykorzystywany do ustawienia zmiennych lub zdefiniowania dodatkowych zadań, pola: recipe description, the recipe version, the license of the package i upstream source repository, mogą definiować dodatkowe zadania, pliki konfiguracyjne (configuration files) konfiguracja i (w ogólności) całego procesu budowania, konfiguracja warstw wykorzystywanych przez Poky do różnych obrazów docelowych. Yocto
Warstwy w systemie Poky Warstwa (layer) - grupa medanych definiujących określoną funkcjonalność: BSP - warstwy definiujące urządzenia, warstwy definiujące typy obrazów, warstwy definiujące dodatkowe oprogramowanie. meta-yocto - rdzenna warstwa. Warstwy bitbake - przykład Yocto Figure: http://www.aosabook.org/en/yocto.html
Outline Yocto Yocto
- interfejsy użytkownika Interfejs użytkownika umożliwia: prezentowanie wyników, statusie i postępach procesu budowania, przechwytywanie zdarzeń od zadań (build tasks). knotty - domyślny interfejs użytkownika; linia poleceń. hob - graficzny interfejs użytkownika; umożliwia modyfikowanie plików konfiguracyjnych, dodawanie warstw i pakietów. Yocto
- Hob Yocto
Podstawowy plik wykonawczy to bitbake/bin/bake Uruchomienie oznacza rozpoczęcie budowy infrastruktury potrzebnej do Kolejność uruchamiania modułów interfejs użytkownika (UI) serwer procesów (IPC) Cooker DataSmart parsowanie plików konfiguracyjnych obiekt Runqueue Scheduler Yocto
Moduł IPC Moduł IPC (Interprocess Communication) Umożliwia uruchomienie wielu procesów podczas budowy obrazu Architektura klient-serwer Domyślny serwer (i najczęściej używany z poziomu knotty) to serwer procesów Interfejs użytkownika potrafi wysyłać polecenia do modułu serwera Yocto
Cooker Zarządza parsowaniem metadanych Inicjalizuje generowanie drzewa zależności i zadań Zarządza procesem budowania. Yocto
DataSmart Moduł DataSmart przechowuje dane z plików konfiguracyjnych jako obiekty. Jeśli przepis (recipe) zmieni się podczas procesu budowy, obiekty danych nie są uaktualniane w całości, lecz zapisywane są jedynie różnice między stanem przed i po zmianie (oszczędność pamięci!). Słownik copy-on-write (COW) zmienne mogą zawierać kod pythona (DataSmart sprawdza poprawność kodu i obecność odwołań cyklicznych). Yocto
Runqueue i Scheduler Budowa obrazu - setki przepisów, każdy zawierający wiele pakietów i zadań powiązanych zależnościami. Zadaniem jest uporządkowanie ich. Cooker buduje mapę zadań z wagami, nazywaną runqueue pełna lista pakietów potrzebnych do łańcuch zależności między nimi Przepis (recipe) sprawdzenie PREFERRED_PROVIDER lub wybór dostawcy pakietu sprawdzenie DEPENDS i RDEPENDS wybór dostawców pakietów z zależności lista pakietów potrzebnych do zbudowana obrazu oraz ich dostawców Yocto
Scheduler - zależności Zależności (dependencies): DEPENDS - zależności (pakiety) potrzebne w procesie budowania. DEPENDS = "b" w przepisie "a" zostanie przetłumaczone na zadanie do_configure a, które zależy od zadania do_populate_sysroot task w b. Wszystko co b dodaje do plików, jest dostępne kiedy a jest konfigurowane. RDEPENDS - zależności (pakiety) potrzebne w procesie wykonywania. RDEPENDS_${PN} = "b" w przepisie "a" zostanie przetłumaczone na zadanie do_build task a, zależne od zadania b : do_package_write. Pakiet b będzie dostępny, kiedy a zostanie zbudowane Yocto
Scheduler - budowa Runqueue pierwszy znaleziony pakiet A lista zadań potrzebnych do budowy pakietu A przypisanie wag odpowiadających liczbie pakietów potrzebnych do zrealizowania zadania (zadania z wyższą wagą mają więcej zależności, zostaną wykonane wcześniej) Yocto Na podstawie mapy Runqueue rozdziela kolejne zadania między swoimi wątkami
- schemat Yocto
Outline Yocto Yocto
Obrazy w projekcie Poky Lista domyślnych obrazów projektu Poky: $ cd /opt/yocto/poky $ ls meta /recipes /images/.bb Najbardziej popularne to: core-image-minimal: najmniejszy obraz (tylko konsola) zawierający: busybox - podstawowe narzędzia UNIX sysvinit - pierwszy program uruchamiany w systemach uniksowych (np. Linux) przez jądro w trakcie procesu uruchamiania operacyjnego udev - dynamiczna alokacja plików urządzeń core-image-full-cmdline: konsola, pełna obsługa sprzętu oraz bash core-image-lsb: obraz z konsolą oparty na kompilacji Linux Standard Base core-image-x11: obraz z graficznym UI (X11) core-image-sato: obraz z graficznym UI (X11) i pulpitem GNOME Mobile oraz motywem SATO core-image-weston: obraz z protokołem Wayland i Weston reference compositor-based image Yocto
Obrazy w projekcie Poky Nazwy obrazów mogą mieć następujące przyrostki: dev: obraz zawiera pliki nagłówkowe i biblioteki potrzebne do tworzenia oprogramowania sdk: zawiera kompletne SDK, które może być używane na maszynie docelowej initramfs: initial RAM file system Yocto
Budowa obrazu Maszynę docelową (MACHINE) można zdefiniować na trzy sposoby. Na przykład, jeśli platformą docelową jest emulator maszyn x86: 1. Zdefiniowanie zmiennej MACHINE wraz z uruchomieniem bitbake: $ MACHINE=qemux86 bitbake core image minimal 2. Wyeksportowanie zmiennej MACHINE do bieżącej powłoki shell: $ export MACHINE=qemux86 $ bitbake core image minimal Yocto 3. Sposób preferowany: edycja pliku conf/local.conf: # MACHINE?= "qemux86" A w linii poleceń: $ bitbake core image minimal
Budowa obrazu Bitbake w pierwszej kolejności analizuje pliki: conf/bblayers.conf: lista warstw conf/layer.conf: konfiguracja każdej warstwy meta/conf/bitbake.conf: konfiguracja bitbake conf/local.conf: konfiguracja procesu budowania obrazu conf/machine/<machine>.conf: konfiguracja maszyny docelowej (np. qemux86.conf) conf/distro/<distro>.conf: konfiguracja dystrybucji OS (domyślnie jest to poky.conf) Następnie parsuje przepisy i ich zależności. Then parses the target recipe that has been provided and its dependencies. The outcome is a set of interdependent tasks that will then execute in order. Yocto
Budowa obrazu Zwykle nie jesteśmy zainteresowani całą informacją generowaną podczas procesu budowania. Zaleca się taką konfigurację procesu budowania, w której informacja wyjściowa dla każdego pakietu (np. źródła czy logi) była usuwana po zbudowaniu obrazu. W pliku conf/local.conf file: INHERIT += "rm_work" Z drugiej jednak strony uniemożliwia się w ten sposób debugowanie (wstecz). Możliwe jest zdefiniowanie listy pakietów, które mają być wyłączone z procesu czyszczenia historii, np.: RM_WORK_EXCLUDE += "linux yocto u boot" Yocto
Budowa obrazu Plik wzorcowy local.conf.sample - domyślna konfiguracja Gotowe zbudowane obrazy znajdują się w katalogu: build/tmp/deploy/images/qemux86 Domyślnie obrazy nie są usuwane z katalogu deploy. Jeśli podczas budowy poprzednia wersja ma być usunięta, trzeba w pliku conf/local.conf ustawić zmienną: RM_OLD_IMAGE = "1" Testowanie obrazu w emulatorze QEMU: Yocto $ runqemu qemuarm core image minimal
Budowa Yocto Intel dostarcza pliki niezbędne do Linux Dokumentacja: Intel QuarkTM SoC X1000 Board Support Package (BSP) Build and Software User Guide https://downloadcenter.intel.com/download/23197/intel- Quark-BSP Omawiany przykład bazuje na wersji Release 1.1 (January 2015) Wymagania wobec hosta: komputer PC z systemem Linux (Intel zaleca system 64-bitowy) lub Windows 7 (x64). W omawianym przykładzie system hosta to 64-bitowy Debian 8.0 (Jessie). łącze internetowe co najmniej 30 GB wolnego miejsca na dysku interfejs szeregowy do komunikacji z Intel Galileo Yocto
Przygotowanie środowiska pracy Powiązane pakiety: Python 2.6 or 2.7 (ale nie Python 3.x ) GCC i G++ (wersje nie młodsze niż GCC 4.7). Domyślna wersja kompilatora w Debian 8.0 to GCC 4.9. Należy zainstalować również starszą wersję (na przykład z repozytoriów Wheezy) klient kontroli wersji (git) uuid-dev (uuid = Universally Unique Identifier) iasl (iasl = ACPI Source Language Compiler) Instalacja niezbędnych pakietów: $ sudo apt get install build essential p7zip ful Pobranie pliku Download Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z spod adresu: https://downloadcenter.intel.com/download/23197/intel- Quark-BSP Yocto
Przygotowanie środowiska pracy Rozpakowanie pobranego pliku: $ 7z x Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z Pobranie i instalacja EDKII $ tar xvf Quark_EDKII_.tar.gz $ cd Quark_EDKII $./svn_setup.py $ svn update Instalacja patch-a OpenSSL (opis w CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt) Budowa oprogramowania układowego EDKII: Yocto $./buildallconfigs.sh GCC46 QuarkPlatform
Instalacja starszych wersji kompilatorów GCC i G++ Dodanie repozytoriów starszej wersji OS (np. Debian Wheezy) do listy repozytoriów (plik /etc/apt/source.list) Instalacja kompilatora gcc-4.6 $ sudo apt get update $ sudo apt get install gcc 4.6 g++ 4.6 Menadżer pakietów może w tym miejscu wyświetlić informację o problemie z zależnymi pakietami. Wówczas należy zainstalować je każdy osobno, np.: Yocto $ sudo apt get install gcc 4.6 base=4.6.3 14 $ sudo apt get install cpp 4.6 $ sudo apt get install gcc 4.6 $ sudo apt get install g++ 4.6
Instalacja starszych wersji kompilatorów GCC i G++ Aby używać zamiennie starszej i nowszej wersji kompilatora, należy zainstalować wersję 4.6 jako alternatywną. W tym celu należy usunąć wszystkie istniejące alternatywy dla gcc i g++: $ sudo update alternatives remove all gcc $ sudo update alternatives remove all g++ A następnie dodać informację o wersji 4.6 i 4.9 (zaznaczenie g++ jako slave powoduje, że przełączanie wersji gcc będzie powodowało analogiczne przełączenie wersji g++) : Yocto $ sudo update alternatives install /usr/bin/gcc gcc /usr/bin/gcc 4.6 60 slave /usr/ $ sudo update alternatives install /usr/bin/gcc gcc /usr/bin/gcc 4.9 40 slave /usr/ Można teraz przełączać wersje kompilatorów za pomocą polecenia: $ sudo update alternatives config gcc Aktualną wersję kompilatora można sprawdzić za pomocą polecenia: $ gcc version
Budowa obrazu W nowej sesji terminala należy rozpakować warstwę Yocto (meta-clanton_v1.1.0-dirty) i uruchomić skrypt setup.sh, który pobierze z zewnętrznych źródeł pliki potrzebne do zbudowania plików: $ tar xvf meta clanton.tar.gz # cd meta clanton $./setup.sh Następnie należy wykonać skrypt iot-devkit-init-build-env, inicjalizujący proces budowania: $ source./iot devkit init build env my_build Yocto Pozostaje uruchomić narzędzie bitbake: $ bitbake image full i uzbroić się w cierpliowość...
Budowa obrazu Po zakończeniu procesu budowania plików, wyjściowe obrazy znajdują się w:./tmp/deploy/images/quark/ i są to: image-full-quark.ext3 (system plików) core-image-minimal-initramfs-quark.cpio.gz (system plików RAM) bzimage (jądro) grub.efi boot (katalog) Pliki można skopiować na pustą kartę SD lub pamięć USB (sformatowane jako ext3). Yocto
Nagranie obrazów na kartę SD Gotowe pliki obrazów w katalogu tmp/deploy/images/ directory to: jądro Linux: bzimage wersja-r0-clanton-yyyymmddhhmmss.bin początkowy system plików RAM: core-image-minimalinitramfs-clanton-yyyymmddhhmmss.rootfs.cpio.gz system plików: image-full-clanton-yyyymmddhhmmss.rootfs.ext3 moduły jądra: modules wersja-r0-clanton-yyyymmddhhmmss.tgz konfiguracja Grub: boot/grub/grub.conf Formatowanie karty SD: $ sudo dd if=/dev/zero of=/dev/sdd Yocto Nagranie plików jako: bzimage core-image-minimal-initramfs-clanton.cpio.gz image-full-clanton.ext3 boot/grub/grub.conf
Używanie historii budowania obrazu Historia budowania obrazu - umożliwia sprawdzenie zależności między pakietami, które weszły do plików. By umożliwić jej używanie, należy dodać do pliku conf/local.conf: INHERIT += "buildhistory" Włączenie gromadzenia informacji (m.in. grafu zależności) w lokalnym repozytorium Git: BUILDHISTORY_COMMIT = "1" Yocto Lokalizacja repozytorium Git może być ustawiona za pomocą zmiennej BUILDHISTORY_DIR (domyślnie: build/buildhistory)
Używanie historii budowania obrazu Domyślnie buildhistory śledzi wszelkie zmiany w pakietach, obrazach i SDK. Jeśli chcemy śledzić tylko obrazy, należy zmienić wartość zmiennej BUILDHISTORY_FEATURES (w conf/local.conf): BUILDHISTORY_FEATURES = "image" Można śledzić konkretne pliki, należy je wówczas dodać to buildhistory za pomocą zmiennej: BUILDHISTORY_IMAGE_FILES += "/path/to/file" Budowa z rejestracją historii jest wolniejsza a rozmiar katalogów wynikowych większy. Nie zaleca się więc używania historii przy każdej kompilacji obrazu (jedynie kiedy jest to niezbędne). Yocto
Używanie historii budowania obrazu Dla pakietów rejestrowane są następujące informacje: wersja pakietu i przepisu zależności rozmiar pakietu pliki Dla obrazu: konfiguracja budowania graf zależności lista plików związanych z prawami własności i dostępem (permissions) lista zainstalowanych pakietów Dla SDK: konfiguracja SDK lista plików hosta i maszyny docelowej grafy zależności lista zainstalowanych pakietów Yocto
Używanie historii budowania obrazu Przeglądanie historii budowania obrazu: 1. Za pomocą narzędzi Git (gitk lub git log). 2. Za pomocą komendy buildhistory-diff 3. Za pomocą interfejsu sieciowego Django-1.4-based 3.1 import historii budowania do bazy danych 3.2 więcej: http://git.yoctoproject.org/cgit/cgit.cgi/buildhistoryweb/tree/readme. Yocto
Statystyka procesu budowania Podczas budowania obrazu możliwe jest zbieranie informacji przydatnej w identyfikowaniu obszarów potencjalnej optymalizacji i tzw. wąskich gardeł (zwłaszcza gdy w systemie pojawia się nowy przepis). Do zbierania informacji statystycznej potrzebne jest dziedziczenie klasy buildstats: USER_CLASSES?= "buildstats" Zmienna BUILDSTATS_BASE określa lokalizację statystyki (domyślnie build/tmp/buildstats Katalog buildstats zawiera osobny katalog dla każdego budowanego obrazu a w nim - podkatalogi odpowiadające pakietom z plikami build_stats, zawierającymi informację o: systemie hosta lokalizacji i rozmiarze plików czasie trwania procesu budowania średnim użyciu CPU statystyce dysku Yocto
Statystyka procesu budowania Przykładowy plik statystyki może zawierać informacje: ReadsComp: całkowita liczba operacji odczytu TimeReads: całkowita liczba milisekund poświęconych na operacje odczytu WritesComp: całkowita liczba operacji zapisu TimeWrite: całkowita liczba milisekund poświęconych na operacje zapisu TimeIO: całkowita liczba milisekund poświęconych na obsługę I/O Yocto
Statystyka procesu budowania pybootchartgui.py tool - graficzna reprezentacja danych ze źrodeł Poky Generowanie pliku bootchart.png w katalogu /tmp: $../sources/poky/scripts/pybootchartgui/pybootchartgui.py tmp/buildstats/core image minimal/ o /tmp Yocto
Debugowanie Sprawdzenie, czy dany plik jest obecny w danej warstwie: $ find name " busybox " To polecenie spowoduje rekursywne wyszukiwanie we wszystkich warstwach wzorca busybox. Wyszukiwanie wśród przepisów: $ find name " busybox.bb " Wyszukiwanie pliku ze zmienną DISTRO_FEATURES: $ bitbake e grep w DISTRO_FEATURES Lokalizowanie ścieżki pliku przepisu: Yocto $ bitbake e busybox grep ^S= Lokalizowanie katalogu roboczego pakietu lub obrazu: $ bitbake e <target> grep ^WORKDIR=
Debugowanie dostarcza zadanie devshell, ktore rozpakowuje źródło i wykonuje patch-e, a następnie uruchamia nową sesję terminala z prawidłowo ustawionymi zmiennymi środowiskowymi. $ bitbake c devshell <target> Wewnątrz devshell można używać komend takich jak configure, make i run. Jeśli na maszynie hosta nie ma środowiska graficznego, w conf/local.conf trzeba ustawić ekran wyjściowy: Yocto OE_TERMINAL = "screen"
Debugowanie Wiadomość o błędach budowy pakietów drukowana jest w terminalu podczas procesu budowania. Lista zadań dla danego przepisu: $ bitbake c listtasks <target> Powtórzenie błędu (wymuszone uruchomienie procesu budowania): $ bitbake f <target> lub (wymuszone) uruchomienie konkretnego zadania: $ bitbake c compile f <target> Yocto Drukowanie wersji pakietów: $ bitbake show versions Lista zależności: $ bitbake v <target>
Debugowanie Zapis zależności do pliku DOT: $ bitbake g <target> do odczytu można użyć pakietu GraphViz Niektóre zależności mogą być usunięte z grafu, np. by pominąć zależności dla glibc: $ bitbake g <target> I glibc Po wydrukowaniu pliku z zależnościami w bieżącym katalogu znajdują się trzy pliki: package-depends.dot: zależności między pakietami pn-depends.dot: zależności między przepisami task-depends.dot: zależności między zadaniami Konwersja pliku.dot do formatu.ps: Yocto $ dot Tps filename.dot o outfile.ps Wyswietlenie danych o zależności za pomocą eksplorera: $ bitbake g u depexp <target>
Raportowanie błędów Centralna baza danych o błędach zgłaszanych przez użytkowników: http://errors.yoctoproject.org. Zgłoszenie błędu do bazy - za pomocą klasy report-error: INHERIT += "report-error" Domyślnie informacja o błędach przechowywana jest w katalogu: build/tmp/log/error-report Można zmienić tą ścieżkę za pomocą zmiennej ERR_REPORT_DIR. Yocto
Elizabeth Flanagan, The Architecture of Open Source Applications, www.aosabook.org P. Raghavan, Amol Lad, Sriram Neelakandan, Embedded Linux system design and development, Auerbach Publications, 2005 http://patg.net/containers,virtualization,docker/2014/06/05/dockerintro/ http://osworld.pl/qemu-emulator-procesora/ Yocto