How To Survive Embedded Linux-Del 1 Den Innebygde Linux Utviklingsprosessen

Den Innebygde Linux Utviklingsprosessen

Linux-kjernen kan kjøre på mange forskjellige datamaskinarkitekturer, hvorav de fleste er ganske populære i den innebygde verden. Alle grunnpakker som gjør AT OPERATIVSYSTEMET kan utføre de grunnleggende oppgavene, er egnet for krysskompilering, Derfor Kan Linux være like gjennomgripende som mikrokontrollere og Systemer på Chip (SoCs).

En Linux-distribusjon er et operativsystem laget av en programvaresamling, som er basert På Linux-Kjernen og – ofte-et pakkehåndteringssystem. Distribusjonen kan komme som forhåndskompilerte binærfiler og pakker satt sammen
av distribusjonsholderne, eller som kilder parret med instruksjoner om hvordan man (kryss -) kompilerer dem.

i det innebygde domenet, siden maskinvareplattformen vanligvis er skreddersydd, FORETREKKER OS-designeren generelt å generere distribusjonen fra bunnen av, fra kilder. Dette gir designeren absolutt kontroll over hva som ender opp i
– produktet. Videre modifiserer Board Support Package (BSP) engineer lavnivåkoden for å få KJERNEFUNKSJONALITETEN TIL OPERATIVSYSTEMET til å fungere på det spesifikke maskinvareproduktet.

Å Få alle nødvendige programvarekomponenter sammen for å generere Linux-distribusjonen for et bestemt innebygd produkt pleide å være et mareritt, mentakkfullt er dette ikke lenger tilfelle.

Mange har delt med open source-samfunnet kildene til byggesystemer som er i stand til å hente Alle Programvarekomponentene fra Internett, kompilere dem og koble dem sammen, opp til generering av installasjonsbilder av fullverdige operativsystemer. Noen få selskaper utvikler og vedlikeholder sitt eget byggesystem, andre samler bare noen få av kjernekomponentene og tar deretter forhåndsbygde binærfiler for å fullføre OPERATIVSYSTEMET.

i 2010 begynte En arbeidsgruppe Fra Linux Foundation å adressere verktøy og prosesser for å tillate etablering Av Linux-distribusjoner for innebygd programvare (aka Embedded Linux). En slik arbeidsgruppe, Kjent Som Yocto-Prosjektet, justerte Seg Med Open Embedded, et rammeverk med lignende mål.

Yocto-Prosjektet Er et åpen kildekode-prosjekt som fokuserer på å forbedre programvareutviklingsprosessen for innebygde Linux-distribusjoner. Yocto-Prosjektet gir interoperable verktøy, metadata og prosesser som muliggjør
rask, repeterbar utvikling Av Linux-baserte innebygde systemer.

Yocto-prosjektet driver for tiden De mest populære Linux-distribusjonene for embedded system, til et punkt der noen ganger uttrykkene «Embedded Linux» og «Yocto Project» lett forveksles som synonymer. Yocto det er ikke En Innebygd Linux-distribusjon, det skaper en tilpasset for deg.

Yoctos metalagsoppsett

den moderne versjonen av yoctos arkitektur er basert på metalag, som er kataloger som inneholder konfigurasjonsfiler og regler for hvordan man kompilerer Og monterer Linux-distribusjoner for innebygde systemer.

vanligvis, men Ikke alltid, lever et meta-lag på sitt eget git-depot, og gir:

  • egne pakker (definert av oppskrifter, .bb-filer),
  • modifikasjoner av pakker levert av andre metalag (.bbappend filer),
  • maskiner (.conf-filer),
  • konfigurasjonsfiler (.conf-filer),
  • felles kode (.bbclass filer),
  • lisenser,
  • og andre mindre biter og stykker.

et enkelt metalag adresserer normalt et bestemt formål. For å oppnå et fullt fungerende system må flere metalag kombineres sammen.

Versjoner plukke og matche

når du setter forskjellige programvarekomponenter sammen, må man være oppmerksom på versjonen av hver komponent, da feil versjon kanskje ikke fungerer bra sammen med de andre komponentene eller til og med bryte systemet.

Yocto-prosjektet gir utgivelser av komponenter som er kjent for å fungere godt sammen, men det er bare utgangspunktet for produktet ditt.

Linux-kjernen er en stor del av koden som må avsløre de riktige grensesnittene til brukerplass, og må inneholde de riktige driverne for at systemet skal fungere skikkelig. Derfor har silisiumleverandørens rolle blitt stadig viktigere i disse dager, da de vanligvis har egne utviklingslager for Linux-kjernen og bootloaderen, derfor er de de beste menneskene å sette sammen et arbeidsbasesystem basert på deres teknologi.

Googles repo

opprinnelig utviklet For å takle mangfoldet Av Git-repositorier i Et Android-prosjekt, har repo blitt ganske populært blant yocto-utviklere også.

Repo er et verktøy bygget på Toppen Av Git; den bruker en «manifest-fil» for å klone Og trekke et sett Med Git-repositorier samtidig.
en repo manifest er en .xml-dokument som inneholder referanser til git-repositorier (sammen med deres versjoner), kan repo bruke manifestet til å fylle ut en katalog med alle kildene som kommer fra De flere Git-repositoriene som kreves for å bygge et prosjekt.

det samme manifestet kan også brukes av repo for å holde kontroll (synkronisere) prosjektkildene når oppstrøms gjør endringer.

noen silisiumleverandører gir manifester for deres utvikling og utgivelsesgrener i disse dager, slik at designere enkelt kan sjekke ut utgangspunktet for sine egne produkter.

Yocto-basert produktutvikling

bsp-ingeniøren starter vanligvis fra silicon vendor repo manifest for å sjekke ut versjonen av programvaren for referansedesignet (som er et design levert av silisiumleverandøren selv eller en av dets partnere, som inneholder samme Eller lignende SoC til den det nye produktet er basert på). Ingeniøren gjør endringer i oppstartslasteren og Linux-kjernen for å sikre at maskinvaren valgt av Elektronikkingeniøren har riktig programvarestøtte på lavt nivå (f.eks.).

formålet med produktet er å kjøre ett eller flere programmer, derfor bsp / OS ingeniør sørger for at alle avhengigheter av programmet (e) bygges for systemet. Ingeniørene som utvikler applikasjonen trenger Et Software Develpment Kit (SDK) for å krysskompilere og koble applikasjonen, derfor VIL bsp/OS engineer
gi dem et slikt sett, og Takket Være Yocto har dette blitt ganske greit.

Embedded Linux good practice

repo-manifestene som brukes til utvikling inneholder vanligvis referanse til utviklingsgrener, noe som betyr at repo vil hente den siste forpliktelsen for disse grenene.

hvis du bruker samme manifest for å hente prosjektet på et senere tidspunkt, kan du hente en annen versjon av koden! Dette er helt greit for utvikling fordi du vil holde fast i den nyeste versjonen av prosjektet ditt, men en av utviklingsversjonene dine vil etter hvert bli en utgivelse, og derfor må du «ta et bilde» av den nøyaktige versjonen av kildene som brukes til å generere programvareutgivelsen som går på prosjektet. Unnlatelse av å gjøre det kan utsette deg for juridiske problemer som du ikke vil være i stand til å regenerere den samme bygge fra kilder, derfor vil du ikke være i stand til å gjøre en endring på toppen av en bestemt utgivelse, og tvinger kunden til å re-teste hele systemet som du vil bli tvunget til å fikse feilen eller legge til den nye funksjonen på toppen av den nyeste versjonen av programvaren.

også, hvis du ikke tar disse øyeblikksbildene, er det ingen måte du kan kjøre en halvert på prosjektkildene for å finne ut hvilken commit har brutt funksjonaliteten du så desperat trenger. Når du utformer utviklingsprosessen, finne en måte å automatisk generere repo manifesterer med presise forpliktelser i dem, slik at du kan lagre dem sammen med utgivelser til kassen de samme kildene igjen på et senere tidspunkt, og gjøre hva du er betalt for å gjøre.

Kopier kilder i huset

Husk også at 99,9% av kildene som går inn i produktet kommer fra åpen kildekode-fellesskapet, noe som betyr at du ikke har noen garanti for at de samme kildene vil være tilgjengelige for nedlasting igjen. Som designer må du beskytte deg mot endringer og feil som gjøres oppstrøms. Hold en kopi av alle relevante kilder i huset, og finne en måte å koble dem tilbake til bygge systemet. Det kan også være lurt å speile noen av depotene du bruker mest, da noen ganger oppstrøms git-servere plutselig kan bli utilgjengelige. Hvis du ikke har en intern kopi, vil du bli sittende fast til serverne kommer tilbake på nettet.

På ByteSnap har Vi en helautomatisk måte Å slippe Yocto – baserte prosjekter på, slik at vi kan gjenopprette kildene som går inn i en utgivelse, og også bygge den samme utgivelsen på et senere tidspunkt. Vi beholder kopier av åpen kildekode-pakker på en automatisk måte, slik at vi ikke opplever nedetid forårsaket av feil servere rundt om i verden. Videre støtter vi alt opp hver eneste dag, slik at vi kan garantere at ingen arbeid vil gå tapt selv i tilfelle katastrofe på stedet.

Fabrizio Castro
Fab er en senior programvareingeniør. Han fikk sin bachelor og mastergrad ved Politecnico Di Milano, I Milano, Italia. Han har 20 års erfaring med allsidig programvareutvikling (tjenester, databaser, applikasjoner, vitenskapelig programvare, firmware, RTOS, enhetsdrivere, Linux-kjernen, etc.), jobbet i akademia og industri. Fab har vært medforfatter av vitenskapelige artikler og bøker, og jobbet med patenter. I tillegg til forskning og utvikling, spesialiserer Han Seg På Innebygd Linux-utvikling-og leverer toppmoderne design som driver vellykkede vitenskapelige, industrielle, kommersielle og militære produkter. Fab har også vært foreleser og har undervist studenter ved noen Av De mest prestisjetunge universitetene I Europa. For mer informasjon om ByteSnap Design besøk http://www.bytesnap.co.uk.

Leave a Reply

Din e-postadresse vil ikke bli publisert.