Ni har tagit beslutet att starta ett nytt projekt. Ert första inbyggda Linux-system lämnar tankesmedjan. I det förra kapitlet beskrevs den första grundbulten, kompetensutvecklingen. Nu tittar vi på hur vi praktiskt går tillväga för att ta oss från ord till handling, Vi börjar med att välja CPU.
Idag kan ingen halvledartillverkare med självaktning säga nej till Linux. Verkligheten är att plattformar som x86, ARM, PowerPC, MIPS och SH3/SH4 alla har marknadsandelar på mer än 5 procent. ARM tar idag kring 30 procent av alla Embedded Linux-projekt. Valet av CPU styrs av faktorer som urval av verktyg, tillgängliga drivrutiner, dokumentation, minneskrav och prestanda. Listan kan göras lång men vi skall inte heller glömma betydelsen av rykte, vad andra säger om plattformen, vad ni själva vet och har hört. Ert mål är förstås att bygga ett stabilt, flexibelt och framtidssäkert system på kortast möjliga utvecklingstid.
Valet av CPU styr tillgängligheten av programkod som kan köras direkt eller som kan anpassas med små medel. Här är det är viktigt att ni tar hänsyn till att alla kombinationer av CPU, drivrutiner, kretsar och protokoll inte nödvändigtvis är fullt beprövade. Det kan mycket väl vara så att olika delar i Linux-systemet fungerar var för sig men att kombinationen du väljer visar sig vara otestad. Det finns mycket att vinna på att tidigt i projektet se på hårdvaran ur ett Linux-perspektiv. Se till att ni utnyttjar de möjligheter som ändå finns att prata med andra användare av samma kombination hård- och mjukvara. Vare sig ni väljer Internet eller att ringa till en erfaren Linux-konsult kommer tiden och kostnaderna ni spenderar för att välja rätt att vara en lönsam investering för projektet som helhet.
Med i bagaget har ni nu ha ett realistiskt CPU-val och förståelse för minnesbehoven. Ni har tagit hänsyn till om ert system skall ha MMU, realtidsstöd och ni vet ungefär hur mycket RAM och ROM som systemet kommer att behöva. Det finns en undre gräns där det inte är meningsfullt att använda Linux som plattform, det behövs normalt någon eller några Mbyte ROM för mjukvara och ungefär dubbelt så mycket RAM som ROM i ett fungerande Linux-system för inbyggnad. När det gäller realtidsprestanda så räcker normalt Linux inbyggda stöd för de flesta projekt. Behöver man svarstider som är i nivå med det som processorarkitekturen klarar av så finns det ett flertal olika implementationer, både kommersiella och med öppen källkod, som ger ert inbyggda Linux-system samma prestanda som andra realtids-OS ni kan hitta på marknaden.
För att bygga ett Linux-system behövs olika komponenter som boot-laddare, kärna, systemapplikationer, C-bibliotek och filsystem. Man behöver också verktyg som kompilatorer, länkare, debuggers och image builders. Alla komponenter och verktyg finns tillgängliga som öppen källkod och kan laddas ned från Internet. En snabbare och oftast billigare lösning är att köpa in utvecklingsmiljön med programvara från en leverantör av embedded Linux. På Enea har vi utvecklat ett alternativ som vi kallar QiTools som är en samlad utvecklingsmiljö, BSP och utbildning vilket ger en komplett verktygslåda för att utveckla Linuxprojekt.
Utveckla för Linux på Linux! Visst kan man ha Windows som utvecklingsvärd när man utvecklar mot ett inbyggt Linux-system. Men det blir oftast enklare, med snabbare kompileringar och kortare utvecklingstider, när man arbetar med Linux som utvecklingsvärd. Redan romarna, en Sankt Ambrose, lär ha gett rådet ”Si fueris Romae, Romano vivito more” till Sankt Augustine på trehundratalet, ”När du är i Rom, lev som Romarna”. Det är lika sant idag, nära två tusen år senare.
För att minimera utvecklingstiden är det ofta en bra metod att tidigt i projektet skaffa ett refe-renskort från CPU-leverantören. Här kan stora delar av Linux-systemet integreras och testköras. Dessutom finns då möjligheter att tidigt studera hur prestanda kommer att bli på den riktiga hårdvaran. Gör en förstudie på alla de krav som ni bedömer som kritiska och mät på referensplattformen. Med ett fungerande system på ett referenskort återstår nu att ta fram drivrutiner och anpassa för de skillnader som finns mellan referenskortet och den slutliga, egenutvecklade hårdvaran. Ta fram ett Board Support Packet (BSP), d v s en komplett mall för hur programvaran för er referensplattform och er slutliga hårdvara skall byggas. En välgjord BSP kräver ofta en djup Linux-kunskap och många företag väljer därför att lägga ut detta på specialister för att själva fokusera på sin egen kärnverksamhet.
Utveckling av applikationer för inbyggd Linux skiljer sig inte från utveckling för andra OS. Det finns stöd för en mängd olika språk, kommunikationsprotokoll finns i överflöd och grafiska miljöer likaså. Att föra över befintliga applikationer till Linux är i grunden en fråga om att systemanrop skall skrivas om eller emuleras. Beroende på vilket tidigare OS applikationen kommer ifrån och hur mycket av annan kod som skall förändras blir valet olika. Ofta hamnar ni i en hybridlösning med både omsystemering och emulering. Då är det bra att ha en erfaren Linuxperson i projektet för att värdera olika lösningar. En fördel är att Linux på samma sätt som andra OS är baserat standarder, bl.a. POSIX, och detta underlättar migrering. Det betyder att arbetet att överföra befintlig kod oftast är en mycket liten del av hela projektet.
När det slutligen kommer till förvaltningen av ert Linux är frågan: Vill ni vara er egen OS-leverantör? Skall ni förvalta produktens OS själva och upprätthålla nödvändig kunskap för det? Vill ni ta ansvar? Eneas rekommendation är att fokusera på produkten och låta en utom-stående Linux-leverantör stå för underhåll av Linux-plattformen. Köp det stöd och det underhåll som passar för produktens livscykel. Det kan vara lämpligt att börja med en garanterad mängd stöd, underhåll och kompetensutveckling per månad. När projektet mognat kan ni sedan eventuellt köpa punktvisa insatser i samband med andra systemuppgraderingar. Vanligtvis förändras inte Linux-plattformen efter att ni släppt er inbyggda Linux-produkt.
Linux bara går och går...
Flödet i ett embedded Linux-projekt