Razvoj softvera za embedded platforme

Slika 1. Pristup preko terminala

U prethodnom broju napravili smo uvod u svet embedded računara koji kao operativni sistem koriste Linux. Pre nego što se pozabavimo specifičnostima konfigurisanja i upotrebe Linuxa na takvim sistemima, treba pojasniti način razvoja softvera za njih.

Kros-kompajliranje

Neki embedded sistemi dolaze sa kompletnim Linux distribucijama koje sadrže sve potrebne alate, uključujući takozvani „toolchain” (kompajler, linker, dibager i programske biblioteke), tako da je softver moguće „bildovati” (kompajlirati i linkovati u izvršne fajlove) direktno na odredišnom uređaju. Mnogo češći slučaj je da uređaj koristi minimalističku Linux distribuciju veličine nekoliko desetina (eventualno stotina) megabajta, bez ikakvih razvojnih alatki. U tom slučaju, razvijanje se vrši na PC/Mac radnoj stanici (u daljem tekstu: host računar) koristeći takozvani kros-kompajler, najčešće baziran na GCC-u (GNU Compiler Collection), koji prevodi program razvijan na jednoj platformi (npr. x86) u mašinski kôd za neku drugu platformu (npr. ARMv7). Pored prevođenja aplikativnih programa, na isti način se prevode Linux kernel i odgovarajući bootloader koji će ga pokrenuti. Prednost kros-kompajliranja na host računaru, između ostalog, leži u brzini – bildovanje velikih projekata poput Linux kernela na embedded platformama trajalo bi satima, dok je host računar najčešće znatno brži, a pritom možete uključiti prevođenje u više paralelnih threadova i tako drastično ubrzati posao.

Slika 2. Šema povezivanja prilikom razvoja softvera

Primer popularnog kros-kompajlerskog toolchaina za ARM platforme je CodeSourcery, ali već nekoliko verzija unazad Ubuntu repozitorijumi sadrže paket „gcc-arm-linux-gnueabi” kao potpuno slobodnu alternativu. Takođe, izvorni kôd Androida stiže sa kros-kompajlerom u podfolderu opt/ndk/toolchains, kako bi eliminisao zavisnost od „spoljnog” kompajlera instaliranog na razvojnom sistemu (ako ništa, barem ste sigurni da će se izvorni kôd Androida ispravno bildovati, jer su i njegovi autori koristili isti kros-kompajler prilikom razvoja i testiranja).

Tačna upotreba toolchaina u zavisnosti od scenarija prevazilazi obim ovog teksta, ali je suština jednostavna: softver se bilduje na isti način kao i za host računar, pozivajući komandu „make” koja će procesirati odgovarajuću Makefile skriptu. Programi koji imaju ispravno napisane Makefile skripte, tako da se ne oslanjaju na fiksno ime kompajlera, pozvaće odgovarajući kros-kompajler ako se on nalazi u PATH putanji čak i ako je definisana vrednost shell promenljive CROSS_COMPILE. Na primer, program koji biste na PC radnoj stanici bildovali za PC pozivajući „make program”, bildovaćete za ARM preko kros-kompajlera pozivajući „make CROSS_COMPILE=arm-linux-gnueabi- program”. Vrednost CROSS_COMPILE predstavlja prefiks koji će se „nalepiti” na ime komande (npr. gcc), pa će tako „make” pozvati „arm-linux-gnueabi-gcc” umesto klasičnog gcc za host računar. Suštinski, kros-kompajleri zasnovani na GCC zadržavaju originalna imena svih alatki (GCC, LD, Strip itd.), uz dodavanje odgovarajućeg prefiksa u imenu fajla, kao u pomenutom primeru.

U slučaju bildovanja Linux jezgra ili nekog bootloadera kao što je U-Boot, pored promenljive CROSS_COMPILER potrebno je podesiti i vrednost ARCH (npr. ARCH=arm), s obzirom na to da će njihova Makefile skripta izvršiti još neka podešavanja u zavisnosti od ciljne platforme.

Deljene biblioteke

Nakon što ste rešili problem prevođenja programa na drugu procesorsku arhitekturu, ostaje problem linkovanja sa deljenim bibliotekama, kao što je standardna C biblioteka koja sadrži uobičajene funkcije poput „printf”, „malloc”, „memset” i slično. Zato je potrebno da kros-kompajler kojim prevodite aplikacije za odredišnu platformu bude isti (ili barem kompatibilan) kao onaj kojim je prevedeno Linux jezgro i osnovne sistemske biblioteke na uređaju. U suprotnom, narušava se ABI (application binary interface) kompatibilnost, pa vaša aplikacija neće uspeti ispravno da pozove funkcije iz deljene biblioteke, rezultujući neuspelim izvršavanjem programa. Ovaj problem je naročito izražen ako program prevodite za Android, koji ne koristi standardnu GNU C biblioteku već nekompatibilnu varijantu po imenu Bionic, pa je u ovom slučaju obavezno korišćenje kros-kompajlera koji stiže uz Androidov izvorni kôd. U krajnjem slučaju, program uvek možete linkovati statički tako da se ne oslanja ni na jednu deljenu biblioteku, što nije naročito dobra praksa iz razloga detaljno opisanih na forumu StackOverflow u temi pod brojem 1993390.

Kontrola sa host računara

Nakon što savladate način prevođenja softvera, postavlja se pitanje kako u fazi razvoja dobiti kontrolu nad Linuxom koji se izvršava na uređaju. Najjednostavniji način je pristup preko tekstualnog terminala koristeći serijsku liniju. Praktično svaki embedded sistem sa ARM ili MIPS procesorom ima izveden RS-232 port sa dve signalne linije: jednu za slanje i drugu za prijem podataka. Koristeći RS-232 kabl možete ga povezati na odgovarajući COM port na PC-u (ili u nedostatku istog, na RS-232/USB adapter, koji obezbeđuje virtuelni COM port). Pomoću aplikacija kao što su Putty i Minicom otvarate terminal na COM portu i tako imate kontrolu nad uređajem, izdavajući tekstualne komande i prateći dijagnostičke poruke (Slika 1). Alternativno, možete pristupiti i preko mreže ako je na uređaju instaliran SSH server, ali ste u ovom slučaju ograničeni na pristup tek kada se uređaj u potpunosti podigne, pošto u stadijumu podizanja bootloadera i Linux kernela ovaj server nije aktivan, što nije od koristi tokom debagovanja kernela i drajvera. Naposletku, tu je i namenski JTAG interfejs za debagovanje uređaja na najnižem nivou (Slika 2).

Embedded uređaji, odnosno procesori na njima, najčešće podržavaju podizanje sa raznih tipova „storidža”, uključujući fleš memorijske čipove na samom uređaju, zatim spoljne diskove preko raznih interfejsa (uključujući SD/MMC memorijske kartice), pa čak i kompletno podizanje preko mreže (na primer, učitavanje bootloadera i Linux kernela preko TFTP protokola, a zatim podizanje fajl sistema sa NFS-a). Od izabranog načina zavisi fleksibilnost razvoja i osvežavanja softvera na uređaju. U slučaju da ste ograničeni samo na SD karticu, svaki put kad rebildujete bootloader, Linux kernel ili aplikaciju/biblioteku, potrebno je isključiti uređaj, izvaditi karticu, ubaciti u računar i prekopirati nove fajlove. U slučaju korišćenja „sirovih” fleš memorija, kao što su NAND fleš čipovi povezani direktno na memorijski kontroler na procesoru, situacija je još gora jer je potrebno iznova napraviti „imidž” particije i potom ga „uflešovati” na odgovarajuću početnu adresu na čipu.

Najudobniji način za razvoj softvera je u slučaju podizanja embedded uređaja preko mreže. Ako NFS server podignete na host računaru, možete podesiti kompajler (određenim direktivama u Makefile skriptama) da novonapravljene izvršne fajlove ubacuje u foldere koje delite preko NFS-a, tako da će uređaj imati pristup najsvežijim fajlovima, bez potrebe da ručno ažurirate lokalni storidž na uređaju.

U sledećem broju pozabavićemo se specifičnostima pripreme fajl sistema za embedded platforme i najbitnijim razlikama u odnosu na fajl sisteme za „velike” računare.

Ivan TODOROVIĆ