How To Survive Embedded Linux-Part 1 The Embedded Linux Development Process
The Embedded Linux Development Process
jądro Linuksa może działać na wielu różnych architekturach komputerowych, z których większość jest dość popularna w świecie wbudowanym. Wszystkie pakiety bazowe pozwalające na wykonywanie podstawowych zadań są odpowiednie do kompilacji krzyżowej, dlatego Linux może być tak wszechobecny jak mikrokontrolery i systemy na chipach (Soc).
dystrybucja Linuksa to system operacyjny stworzony z kolekcji oprogramowania, który opiera się na jądrze Linuksa i – często – systemie zarządzania pakietami. Dystrybucja może pochodzić jako wstępnie skompilowane pliki binarne i pakiety złożone razem
przez opiekunów dystrybucji, lub jako źródła połączone z instrukcjami jak (krzyżowo) je skompilować.
w domenie wbudowanej, ponieważ platforma sprzętowa jest zwykle szyta na miarę, projektant systemu operacyjnego zazwyczaj woli generować dystrybucję od zera, zaczynając od źródeł. Daje to projektantowi absolutną kontrolę nad tym, co kończy się w produkcie
. Ponadto inżynier Board Support Package (BSP) modyfikuje kod niskiego poziomu, aby podstawowa funkcjonalność systemu operacyjnego działała na konkretnym produkcie sprzętowym.
zebranie wszystkich niezbędnych komponentów oprogramowania do wygenerowania dystrybucji Linuksa dla konkretnego wbudowanego produktu było koszmarem, ale tak już nie jest.
wielu z nich dzieliło się ze społecznością open source źródłami systemów zdolnych do pobierania wszystkich składników oprogramowania z Internetu, kompilowania ich i łączenia ze sobą, aż do generowania obrazów instalacyjnych pełnoprawnych systemów operacyjnych. Kilka firm opracowuje i utrzymuje własny system kompilacji, inne kompilują tylko kilka podstawowych komponentów, a następnie pobierają wstępnie zbudowane pliki binarne, aby sfinalizować SYSTEM OPERACYJNY.
w 2010 roku grupa robocza z Linux Foundation zaczęła zajmować się narzędziami i procesami umożliwiającymi tworzenie dystrybucji Linuksa dla oprogramowania wbudowanego (znanego również jako Embedded Linux). Taka grupa robocza, znana jako projekt Yocto, dostosowała się do Open Embedded, frameworka o podobnych celach.
projekt Yocto jest projektem open source, którego celem jest usprawnienie procesu tworzenia oprogramowania dla Wbudowanych dystrybucji Linuksa. Projekt Yocto zapewnia interoperacyjne narzędzia, metadane i procesy, które umożliwiają szybki i powtarzalny rozwój systemów wbudowanych opartych na Linuksie.
projekt Yocto napędza obecnie najpopularniejsze dystrybucje Linuksa dla systemów wbudowanych, do tego stopnia, że czasami terminy ” Embedded Linux „i” Yocto Project ” są łatwo mylone jako synonimy. Yocto nie jest to osadzona dystrybucja Linuksa, tworzy dla Ciebie niestandardową.
układ meta-warstw Yocto
nowoczesna wersja architektury Yocto opiera się na meta-warstwach, które są katalogami zawierającymi pliki konfiguracyjne i reguły kompilacji i montażu dystrybucji Linuksa dla systemów wbudowanych.
zazwyczaj, ale nie zawsze, meta-warstwa żyje na własnym repozytorium git i zapewnia:
- własne pakiety (zdefiniowane przez recipes, pliki. bb),
- modyfikacje pakietów dostarczanych przez inne meta-warstwy (.bbappend files),
- machines (.pliki konfiguracyjne),
- pliki konfiguracyjne (.pliki conf),
- wspólny kod (.pliki bbclass),
- ,
- i inne drobne fragmenty.
pojedyncza meta-warstwa zwykle odnosi się do określonego celu. W związku z tym, aby uzyskać w pełni działający system, należy połączyć ze sobą więcej meta-warstw.
wybieranie i dopasowywanie wersji
składając różne komponenty oprogramowania, należy pamiętać o wersji każdego komponentu, ponieważ niewłaściwa wersja może nie działać dobrze z innymi komponentami lub nawet zepsuć system.
projekt Yocto zapewnia wydania komponentów, o których wiadomo, że dobrze ze sobą współpracują, ale to tylko punkt wyjścia dla Twojego produktu.
jądro Linuksa to duży kawałek kodu, który musi udostępnić odpowiednie interfejsy w przestrzeni użytkownika i musi zawierać odpowiednie sterowniki, aby system działał poprawnie. Dlatego rola dostawcy krzemu staje się coraz ważniejsza w dzisiejszych czasach, ponieważ zwykle mają własne repozytoria programistyczne dla jądra Linuksa i bootloadera, dlatego są najlepszymi ludźmi, którzy tworzą działający system bazowy oparty na ich technologii.
repo Google
pierwotnie opracowany, aby poradzić sobie z wieloma repozytoriami Git w projekcie Android, repo stał się dość popularny wśród programistów Yocto.
Repo to narzędzie zbudowane na bazie Gita; używa „pliku manifestu” do klonowania i ściągania zestawu repozytoriów Gita w tym samym czasie.
manifest repo todokument XML zawierający odniesienia do repozytoriów git (wraz z ich wersjami), repo może użyć manifestu do zapełnienia katalogu wszystkimi źródłami pochodzącymi z kilku repozytoriów Git wymaganych do zbudowania projektu.
ponadto, ten sam manifest może być używany przez repo do kontrolowania (synchronizacji) źródeł projektu, gdy upstream wprowadzi zmiany.
kilku dostawców krzemu dostarcza obecnie manifesty dla swoich oddziałów rozwoju i Wydania, dzięki czemu projektanci mogą łatwo sprawdzić punkt wyjścia dla własnych produktów.
rozwój produktu oparty na Yocto
inżynier BSP zwykle zaczyna od manifestu repo dostawcy krzemu, aby sprawdzić wersję oprogramowania dla projektu referencyjnego (czyli projektu dostarczonego przez samego dostawcę krzemu lub jednego z jego partnerów, zawierającego ten sam lub podobny SoC do tego, na którym opiera się nowy produkt). Inżynier wprowadza zmiany w bootloaderze i jądrze Linuksa, aby upewnić się, że sprzęt wybrany przez inżyniera elektronika ma odpowiednią obsługę oprogramowania niskiego poziomu (np. sterowniki urządzeń, drzewo urządzeń, konfiguracja jądra itp.).
celem produktu jest uruchomienie jednej lub więcej aplikacji, dlatego inżynier BSP/OS upewnia się, że wszystkie zależności aplikacji są budowane dla systemu. Inżynierowie tworzący aplikację potrzebują zestawu programistycznego (SDK), aby skompilować i połączyć aplikację, dlatego inżynier BSP/OS
dostarczy im taki zestaw, a dzięki Yocto stało się to dość proste.
Dobra Praktyka wbudowanego Linuksa
manifesty repo używane do programowania zwykle zawierają odniesienie do gałęzi programistycznych, co oznacza, że repo pobierze najnowszy commit dla tych gałęzi.
jeśli użyjesz tego samego manifestu do pobrania projektu w późniejszym terminie, możesz pobrać inną wersję kodu! Jest to całkowicie dobre dla rozwoju, ponieważ chcesz trzymać się najnowszej wersji projektu, ale jedna z Twoich wersji rozwojowych w końcu stanie się wydaniem, dlatego musisz „zrobić zdjęcie” tej precyzyjnej wersji źródeł używanych do generowania wydania oprogramowania, które idzie na projekt. Niezastosowanie się do tego może narazić Cię na problemy prawne, ponieważ nie będziesz w stanie zregenerować tej samej kompilacji, zaczynając od źródeł, dlatego nie będziesz w stanie wprowadzić zmian w konkretnej wersji, zmuszając klienta do ponownego przetestowania całego systemu, ponieważ będziesz zmuszony naprawić błąd lub dodać nową funkcję do najnowszej wersji oprogramowania.
Ponadto, jeśli nie wykonasz tych migawek, nie ma możliwości, abyś uruchomił bisekt na źródłach projektu, aby dowiedzieć się, który commit zepsuł funkcjonalność, której tak desperacko potrzebujesz. Podczas projektowania procesu tworzenia, znajdź sposób na automatyczne generowanie manifestów repo z dokładnymi zatwierdzeniami w nich, tak, że można zapisać je wraz z wydaniami, aby ponownie kasować te same źródła w późniejszym terminie i robić wszystko, za co płacą.
Kopiuj źródła w domu
Pamiętaj również, że 99,9% źródeł, które trafiają do Twojego produktu, pochodzi ze społeczności open source, co oznacza, że nie masz gwarancji, że te same źródła będą ponownie dostępne do pobrania. Jako projektant musisz chronić się przed zmianami i błędami popełnionymi na wcześniejszych etapach. Zachowaj kopię wszystkich istotnych źródeł w domu i znajdź sposób, aby podłączyć je z powrotem do systemu kompilacji. Ponadto, możesz chcieć skopiować niektóre repozytoria, z których najczęściej korzystasz, ponieważ czasami upstream Git serwery mogą nagle stać się niedostępne. Jeśli nie masz wewnętrznej kopii, utkniesz, dopóki serwery nie wrócą online.
w ByteSnap mamy w pełni zautomatyzowany sposób wydawania projektów opartych na Yocto, dzięki czemu możemy odzyskać źródła, które trafiają do wydania, a także ponownie zbudować to samo wydanie w późniejszym terminie. Przechowujemy kopie pakietów open source w sposób automatyczny, dzięki czemu nie doświadczamy przestojów spowodowanych wadliwymi serwerami na całym świecie. Co więcej, każdego dnia tworzymy kopie zapasowe, dzięki czemu możemy zagwarantować, że żadna praca nie zostanie utracona nawet w przypadku katastrofy na miejscu.
Fabrizio Castro
Fab jest starszym inżynierem oprogramowania. Tytuł licencjata i magistra uzyskał na Politecnico di Milano w Mediolanie we Włoszech. Posiada 20-letnie doświadczenie w wszechstronnym tworzeniu oprogramowania (usługi, bazy danych, aplikacje, oprogramowanie naukowe, firmware, RTOS, sterowniki urządzeń, jądro Linuksa itp.), spędził pracę w środowisku akademickim i przemysłowym. Fab jest współautorem prac naukowych i książek oraz pracował nad patentami. Oprócz badań i rozwoju, specjalizuje się w rozwoju systemu Embedded Linux – dostarczając najnowocześniejsze projekty zasilające udane produkty naukowe, przemysłowe, komercyjne i wojskowe. Fab jest również wykładowcą i wykładowcą na najbardziej prestiżowych Uniwersytetach w Europie. Więcej informacji na temat projektu ByteSnap można znaleźć na stronie http://www.bytesnap.co.uk.