hoe te overleven Embedded Linux-deel 1 Het Embedded Linux ontwikkelingsproces
het Embedded Linux ontwikkelingsproces
de Linux kernel kan draaien op veel verschillende computerarchitecturen, waarvan de meeste vrij populair zijn in de embedded wereld. Alle basispakketten waarmee het besturingssysteem de basistaken kan uitvoeren zijn geschikt voor cross-compilatie, daarom kan Linux net zo alomtegenwoordig zijn als microcontrollers en Systems on Chip (SoCs).
een Linux-distributie is een besturingssysteem gemaakt van een softwareverzameling, die gebaseerd is op de Linux – Kernel en – vaak-een pakketbeheersysteem. De distributie kan komen als voorgecompileerde binaries en pakketten die
zijn samengesteld door de beheerders van de distributie, of als bronnen gecombineerd met instructies over het (cross -) compileren ervan.
in het embedded domein, omdat het hardware platform meestal op maat is gemaakt, geeft de OS designer over het algemeen de voorkeur aan het genereren van de distributie vanuit de broncode. Dit geeft de ontwerper absolute controle over wat in het
product terechtkomt. Bovendien wijzigt de Board Support Package (BSP) engineer de low-level code om de kernfunctionaliteit van het besturingssysteem te laten werken op het specifieke hardwareproduct.
het samenbrengen van alle benodigde softwarecomponenten om de Linux-distributie voor een bepaald embedded product te genereren was een nachtmerrie, maar helaas is dit niet langer het geval.
velen hebben met de open source gemeenschap de bronnen gedeeld van bouwsystemen die in staat zijn om alle softwarecomponenten van het Internet te halen, te compileren en aan elkaar te koppelen, tot aan het genereren van installatiebeelden van volwaardige besturingssystemen. Een paar bedrijven zijn het ontwikkelen en onderhouden van hun eigen bouwsysteem, anderen compileren slechts enkele van de kerncomponenten en vervolgens vooraf gebouwde binaries om het besturingssysteem te voltooien.
in 2010 begon een werkgroep van de Linux Foundation tools en processen aan te pakken om de creatie van Linux-distributies voor embedded software (ook bekend als Embedded Linux) mogelijk te maken. Zo ‘ n werkgroep, bekend als het Yocto Project, sloot zich aan bij Open Embedded, een raamwerk met vergelijkbare doelen.
het Yocto-Project is een open source-project dat zich richt op het verbeteren van het softwareontwikkelingsproces voor embedded Linux-distributies. Het Yocto Project biedt interoperabele tools, metadata en processen die de
snelle, herhaalbare ontwikkeling van op Linux gebaseerde embedded systemen mogelijk maken.
het Yoctoproject voedt momenteel de meest populaire Linux-distributies voor embedded systeem, tot een punt waar soms de termen “Embedded Linux” en “Yoctoproject” gemakkelijk als synoniemen worden verward. Yocto het is geen Embedded Linux-distributie, het maakt een aangepaste een voor u.
Yocto ’s metalagen lay-out
de moderne versie van Yocto’ s architectuur is gebaseerd op Metalagen, dat zijn mappen met configuratiebestanden en regels over het compileren en assembleren van Linux distributies voor embedded systemen.
gewoonlijk, maar niet altijd, leeft een meta-laag op zijn eigen Git repository, en biedt:
- zijn eigen pakketten (gedefinieerd door recepten, .bb bestanden),
- wijzigingen aan pakketten geleverd door andere metalagen (.bbappend-bestanden),
- machines (.conf-bestanden),
- configuratiebestanden (.conf-bestanden),
- common code (.bbclass-bestanden),
- licenties,
- en andere kleine bits en stukken.
een enkele metalaag richt zich normaal gesproken op een specifiek doel. Om tot een volledig werkend systeem te komen, moeten meer metalagen worden gecombineerd.
versies picking en matching
bij het samenvoegen van verschillende softwarecomponenten moet men rekening houden met de versie van elk onderdeel, omdat de verkeerde versie mogelijk niet goed samen met de andere componenten werkt of zelfs het systeem breekt.
het Yocto project biedt releases van componenten waarvan bekend is dat ze goed samenwerken, maar dat is nog maar het beginpunt voor uw product.
de Linux kernel is een groot stuk code dat de juiste interfaces aan de gebruikersruimte moet blootstellen en de juiste drivers moet bevatten om het systeem goed te laten werken. Daarom is de rol van de silicon leverancier steeds belangrijker geworden deze dagen, omdat ze meestal hun eigen ontwikkeling repositories voor de Linux kernel en de bootloader, vandaar, ze zijn de beste mensen om samen te stellen een werkend basissysteem op basis van hun technologie.
Google ‘ s repo
oorspronkelijk ontwikkeld om te gaan met de veelheid van Git-repositories in een Android-project, is repo ook erg populair geworden onder Yocto-ontwikkelaars.
Repo is een tool gebouwd op Git; het gebruikt een” manifest bestand ” om tegelijkertijd een set Git repositories te klonen en te Pullen.
een repo-manifest is een .xml document met verwijzingen naar Git repositories (samen met hun versies), repo kan het manifest gebruiken om een directory te vullen met alle bronnen afkomstig van de verschillende Git repositories die nodig zijn om een project te bouwen.
ook kan hetzelfde manifest door repo worden gebruikt om de projectbronnen te controleren (synchroniseren) wanneer upstream wijzigingen aanbrengt.
een paar leveranciers van silicium bieden manifesten voor hun ontwikkeling en release branches deze dagen, zodat ontwerpers gemakkelijk kunnen controleren het uitgangspunt voor hun eigen producten.
productontwikkeling op basis van Yocto
de BSP-ingenieur vertrekt gewoonlijk van het repo-manifest van de siliconenverkoper om de versie van de software voor het referentieontwerp te controleren (dat is een ontwerp dat door de siliconenverkoper zelf of een van zijn partners wordt geleverd en dezelfde of soortgelijke SoC bevat als die waarop het nieuwe product is gebaseerd). De engineer maakt wijzigingen aan in de bootloader en de Linux kernel om er zeker van te zijn dat de hardware geselecteerd door de Electronics Engineer de juiste low-level software ondersteuning heeft (bijvoorbeeld apparaatstuurprogramma ‘ s, apparaatstructuur, kernelconfiguratie, enz.).
het doel van het product is om een of meer applicaties te draaien, daarom zorgt de BSP/OS engineer ervoor dat alle afhankelijkheden van de applicaties voor het systeem worden gebouwd. De engineers die de applicatie ontwikkelen hebben een Software Develpment Kit (SDK) nodig om de applicatie te compileren en te koppelen, daarom zal de BSP/OS engineer
hen van een dergelijke kit voorzien, en dankzij Yocto is dit vrij eenvoudig geworden.
Embedded Linux good practice
de repo manifesten die gebruikt worden voor ontwikkeling bevatten meestal een verwijzing naar ontwikkeltakken, wat betekent dat repo de laatste commit voor die branches zal ophalen.
als u hetzelfde manifest gebruikt om het project op een later tijdstip op te halen, kunt u een andere versie van de code ophalen! Dit is perfect prima voor ontwikkeling, omdat je wilt vasthouden aan de nieuwste versie van uw project, maar een van uw ontwikkeling versies zal uiteindelijk een release worden, en daarom moet je “neem een foto” van die precieze versie van de bronnen gebruikt om de software release die gaat op het project te genereren. Als u dit niet doet, kunt u juridische problemen ondervinden omdat u niet in staat zult zijn om dezelfde build te regenereren vanaf bronnen, daarom zult u niet in staat zijn om een wijziging aan te brengen bovenop een specifieke release, waardoor de klant wordt gedwongen om het hele systeem opnieuw te testen omdat u wordt gedwongen om de bug op te lossen of de nieuwe functie toe te voegen bovenop de nieuwste versie van de software.
ook, als je die snapshots niet maakt, is er geen manier om een bisect op de projectbronnen uit te voeren om erachter te komen welke commit de functionaliteit heeft verbroken die je zo hard nodig hebt. Als je je ontwikkelingsproces ontwerpt, zoek dan een manier om automatisch repo manifesten te genereren met precieze commits erin, zodat je ze naast releases kunt opslaan om dezelfde bronnen op een later tijdstip opnieuw uit te checken, en doe waar je voor betaald wordt.
kopieer bronnen in huis
Houd er ook rekening mee dat 99,9% van de bronnen in uw product afkomstig zijn van de open source gemeenschap, wat betekent dat u geen garantie hebt dat dezelfde bronnen opnieuw beschikbaar zullen zijn om te downloaden. Als ontwerper moet je jezelf beschermen tegen veranderingen en fouten die stroomopwaarts zijn gemaakt. Houd een kopie van alle relevante bronnen in huis,en vind een manier om ze weer in uw build-systeem. Ook wil je misschien een aantal van de repositories die je het meest gebruikt spiegelen, omdat soms upstream Git servers plotseling niet meer beschikbaar zijn. Als je geen interne kopie hebt, zit je vast totdat de servers weer online komen.
bij ByteSnap hebben we een volledig geautomatiseerde manier om op Yocto gebaseerde projecten vrij te geven, zodat we de bronnen die in een release gaan kunnen herstellen, en ook dezelfde release op een later tijdstip opnieuw kunnen bouwen. We bewaren kopieën van open source-pakketten op een automatische manier, zodat we geen downtime ervaren die wordt veroorzaakt door defecte servers over de hele wereld. Bovendien back-uppen we elke dag alles, zodat we kunnen garanderen dat er geen werk verloren gaat, zelfs niet in geval van een ramp op de site.
Fabrizio Castro
Fab is een senior Software engineer. Hij behaalde zijn bachelor – en masterdiploma ‘ s aan Politecnico di Milano, in Milaan, Italië. Hij heeft 20 jaar ervaring in allround softwareontwikkeling (diensten, databases, toepassingen, wetenschappelijke software, firmware, RTO ‘s, apparaatstuurprogramma’ s, Linux kernel, enz.), besteed aan het werken in de academische wereld en de industrie. Fab is medeauteur van wetenschappelijke artikelen en boeken, en werkte aan patenten. Naast onderzoek en ontwikkeling, is hij gespecialiseerd in Embedded Linux – ontwikkeling-het leveren van state-of-art ontwerpen aandrijven van succesvolle wetenschappelijke, industriële, commerciële en militaire producten. Fab is ook docent geweest en heeft studenten onderwezen aan enkele van de meest prestigieuze universiteiten in Europa. Ga voor meer informatie over ByteSnap Design naar http://www.bytesnap.co.uk.