hur man överlever Embedded Linux-Del 1 Den inbäddade Linux-utvecklingsprocessen
den inbäddade Linux-utvecklingsprocessen
Linux-kärnan kan köras på många olika datorarkitekturer, varav de flesta är ganska populära i den inbäddade världen. Alla baspaket som tillåter operativsystemet att utföra de grundläggande uppgifterna är lämpliga för korssamling, därför kan Linux vara lika genomgripande som mikrokontroller och system på Chip (SoCs).
en Linux – distribution är ett operativsystem tillverkat av en mjukvarusamling, som är baserad på Linux – kärnan och-ofta-ett pakethanteringssystem. Distributionen kan komma som förkompilerade binärer och paket som sammanställts
av distributionsansvariga, eller som källor ihopkopplade med instruktioner om hur man (cross-) kompilerar dem.
i den inbäddade domänen, eftersom hårdvaruplattformen vanligtvis är skräddarsydd, föredrar OS-designern i allmänhet att generera distributionen från början, från källor. Detta ger designern absolut kontroll över vad som hamnar i produkten
. Dessutom ändrar Board Support Package (BSP) engineer lågnivåkoden för att få kärnfunktionaliteten i operativsystemet att fungera på den specifika hårdvaruprodukten.
att få alla nödvändiga programvarukomponenter tillsammans för att generera Linux-distributionen för en viss inbäddad produkt brukade vara en mardröm, mentackfully är det inte längre fallet.
många har delat med open source-communityn källorna till byggsystem som kan hämta alla programvarukomponenter från Internet, kompilera dem och länka dem tillsammans, fram till generering av installationsbilder av fullfjädrade operativsystem. Några företag utvecklar och underhåller sitt eget byggsystem, andra sammanställer bara några av kärnkomponenterna och tar sedan förbyggda binärer för att slutföra operativsystemet.
under 2010 började en arbetsgrupp från Linux Foundation ta itu med verktyg och processer för att möjliggöra skapandet av Linux-distributioner för inbäddad programvara (aka Embedded Linux). En sådan arbetsgrupp, känd som Yocto-projektet, anpassade sig till Open Embedded, ett ramverk med liknande mål.
Yocto-projektet är ett open source-projekt vars fokus ligger på att förbättra mjukvaruutvecklingsprocessen för inbäddade Linux-distributioner. Yocto-projektet tillhandahåller interoperabla verktyg, metadata och processer som möjliggör
snabb, repeterbar utveckling av Linux-baserade inbäddade system.
Yocto-projektet driver för närvarande de mest populära Linux-distributionerna för embedded system, till en punkt där ibland termerna ”Embedded Linux” och ”Yocto Project” lätt förväxlas som synonymer. Yocto det är inte en inbäddad Linux-distribution, det skapar en anpassad för dig.
yoctos meta-layers layout
den moderna versionen av Yoctos arkitektur är baserad på metalager, som är kataloger som innehåller konfigurationsfiler och regler för hur man kompilerar och monterar Linux-distributioner för inbyggda system.
vanligtvis, men inte alltid, lever ett metalager på sitt eget git-arkiv och tillhandahåller:
- egna paket (definierade av recipes, .bb-filer),
- ändringar av paket som tillhandahålls av andra metalager (.bbappend filer),
- maskiner (.conf-filer),
- konfigurationsfiler (.conf-filer),
- gemensam kod (.bbclass-filer),
- licenser,
- och andra mindre bitar.
ett enda metalager adresserar normalt ett specifikt syfte. Därför måste fler metalager kombineras för att uppnå ett fullt fungerande system.
versioner plocka och matcha
när du sätter olika programvarukomponenter tillsammans, måste man vara uppmärksam på den version av varje komponent, som fel version kanske inte fungerar bra tillsammans med de andra komponenterna eller ens bryta systemet.
Yocto-projektet ger utgåvor av komponenter som är kända för att fungera bra tillsammans, men det är bara utgångspunkten för din produkt.
Linux-kärnan är en stor bit kod som måste exponera rätt gränssnitt för användarutrymme och måste innehålla rätt drivrutiner för att systemet ska fungera korrekt. Därför har kiselleverantörens Roll blivit allt viktigare idag, eftersom de vanligtvis har sina egna utvecklingsförvar för Linux-kärnan och bootloader, därför är de de bästa människorna att sätta ihop ett fungerande bassystem baserat på deras teknik.
Googles repo
ursprungligen utvecklad för att klara av de många Git-repositories i ett Android-projekt, har repo blivit ganska populärt bland Yocto-utvecklare också.
Repo är ett verktyg byggt ovanpå Git; den använder en ”manifest-fil” för att klona och dra en uppsättning Git-repositorier samtidigt.
en repo manifest är en .xml-dokument som innehåller referenser till git-repositories (tillsammans med deras versioner), repo kan använda manifestet för att fylla i en katalog med alla källor som kommer från de flera Git-repositories som krävs för att bygga ett projekt.
samma manifest kan också användas av repo för att hålla kontroll (synkronisera) projektkällorna när uppströms gör ändringar.
några kiselleverantörer ger manifest för deras utveckling och släpp grenar idag, så att designers enkelt kan kolla utgångspunkten för sina egna produkter.
Yocto-baserad produktutveckling
BSP-ingenjören börjar vanligtvis från kiselleverantörens repo-manifest för att kolla versionen av programvaran för referensdesignen (som är en design som tillhandahålls av kiselleverantören själv eller en av dess partners, innehållande samma eller liknande SoC som den nya produkten är baserad på). Ingenjören gör ändringar i bootloader och Linux-kärnan för att se till att hårdvaran som valts av elektronikingenjören har korrekt programstöd på låg nivå (t.ex. drivrutiner, enhetsträd, kärnkonfiguration etc.).
syftet med produkten är att köra en eller flera applikationer, därför ser BSP/OS-ingenjören till att alla beroenden för applikationen / applikationerna byggs för systemet. Ingenjörerna som utvecklar applikationen behöver ett mjukvaruutvecklingssats (SDK) för att korskompilera och länka applikationen, därför kommer BSP/OS-ingenjören
att förse dem med ett sådant kit, och tack vare Yocto har detta blivit ganska enkelt.
Embedded Linux good practice
de repo-manifest som används för utveckling innehåller vanligtvis hänvisning till utvecklingsgrenar, vilket innebär att repo hämtar det senaste åtagandet för dessa grenar.
om du använder samma manifest för att hämta projektet vid ett senare tillfälle kan du hämta en annan version av koden! Det här är helt bra för utveckling eftersom du vill hålla fast vid den senaste versionen av ditt projekt, men en av dina utvecklingsversioner kommer så småningom att bli en release, och därför måste du ”ta en bild” av den exakta versionen av källorna som används för att generera programvaruversionen som går på projektet. Om du inte gör det kan du utsättas för juridiska problem eftersom du inte kommer att kunna regenerera samma byggnad från källor, därför kommer du inte att kunna göra en ändring ovanpå en specifik utgåva, vilket tvingar kunden att testa hela systemet igen eftersom du kommer att tvingas fixa felet eller lägga till den nya funktionen ovanpå den senaste versionen av programvaran.
om du inte tar dessa ögonblicksbilder finns det inget sätt att köra en bisect på projektkällorna för att ta reda på vilket åtagande som har brutit den funktionalitet du så desperat behöver. När du utformar din utvecklingsprocess, hitta ett sätt att automatiskt generera repo-manifest med exakta åtaganden i dem, så att du kan spara dem tillsammans med utgåvor för att checka ut samma källor igen vid ett senare tillfälle och göra vad du får betalt för att göra.
kopiera källor i huset
Tänk också på att 99,9% av källorna som går in i din produkt kommer från Open source-communityn, vilket innebär att du inte har någon garanti för att samma källor kommer att vara tillgängliga för nedladdning igen. Som designer måste du skydda dig mot förändringar och misstag som görs uppströms. Håll en kopia av alla relevanta källor i huset och hitta ett sätt att ansluta dem tillbaka till ditt byggsystem. Du kanske också vill spegla några av de förvar du använder mest, eftersom ibland uppströms git-servrar plötsligt kan bli otillgängliga. Om du inte har en intern kopia kommer du att fastna tills servrarna kommer tillbaka online.
på ByteSnap har vi ett helt automatiserat sätt att släppa Yocto-baserade projekt, så att vi kan återställa källorna som går in i en release, och även bygga om samma release vid ett senare tillfälle. Vi håller kopior av Open source-paket på ett automatiskt sätt, så att vi inte upplever någon stilleståndstid orsakad av felaktiga servrar runt om i världen. Dessutom backar vi upp allt varje dag så att vi kan garantera att inget arbete går förlorat även i händelse av katastrof på plats.
Fabrizio Castro
Fab är en senior software engineer. Han fick sin kandidatexamen och magisterexamen vid Politecnico di Milano, i Milano, Italien. Han har 20 års erfarenhet av allsidig mjukvaruutveckling (tjänster, databaser, applikationer, vetenskaplig programvara, firmware, RTOS, drivrutiner, Linux-kärna, etc.), tillbringade arbete i akademi och industri. Fab har medförfattare vetenskapliga artiklar och böcker, och arbetat med patent. Förutom forskning och utveckling specialiserar han sig på inbäddad Linux-utveckling-levererar toppmoderna mönster som driver framgångsrika vetenskapliga, industriella, kommersiella och militära produkter. Fab har också varit föreläsare och har undervisat studenter vid några av de mest prestigefyllda universiteten i Europa. För mer information om ByteSnap Design besök http://www.bytesnap.co.uk.