Projekt zakończony

Konrad Rybacki, konrad.rybacki@wp.pl

Embedded Prolog Runtime (EPR) – Running Prolog on Embedded Platforms, programming Prolog-C Interfaces, evaluation, refinment, testing, improvement; C and Prolog Programming is required

spotkania

• Próba utworzenia wirtualnego środowiska uruchomieniowego emulującego system oparty o procesor z rodziny ARM.

Wykorzystano: Pakiet QEMU, wersja 0.9.1_2, system uruchomieniowy (host) FreeBSD 7.0, procesor klasy i686. Uruchomienie dystrybucji ARM systemu NetBSD nie powiodło się. Emulator albo zupełnie odmawia współpracy, nie rozpoznając właściwie obrazu jądra, albo sygnalizuje błędy w uruchamianym kodzie. Należy dokładnie sprawdzić wsparcie dla architektury opartej o ARM w tym systemie w konfrontacji z możliwościami QEMU. Niestety, brak jest dokumentacji opisującej bezpośrednio przykłady uruchomienia NetBSD na tym symulatorze.

Próba uruchomienia systemu Linux na wspomnianym emulatorze, zgodnie z opisem http://www.aurel32.net/info/debian_arm_qemu.php zakończyła się połowicznym sukcesem. System wprawdzie uruchamia się, ale przy próbie zapisu na dysk dochodzi do błędu segmentacji. Najprawdopodobniej jest to spowodowane jakimiś zależnościami FreeBSD - QEMU. Niestety, nie miałem możliwości przetestowania QEMU na innym systemie - do zrobienia w najbliższym czasie.

• Analiza wymagań implementacji Prologa:

W związku z wymienionymi wcześniej problemami, trudno podejmować próby oceny wymagań dostępnych środowisk. SWI Prolog posiada wygodną w użyciu bibliotekę, pozwalającą w pewnym stopniu analizować zużycie zasobów http://gollem.science.uva.nl/SWI-Prolog/Manual/profile.html. Niestety, nie udało mi się znaleźć odpowiednika dla YAP, bez czego właściwie trudno o wykonanie sensownych porównań. Do wykorzystania zestaw testów sprawdzających wydajność Prologa: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/code/bench/0.html. Interesująca może być również strona: http://www.david-reitter.com/compling/prolog/compare.html.

• Próba cross-kompilacji Prologa na architekturę ARM:

W ramach próby wykorzystałem toolchain arm-elf-linux. Niestety, kompilator sygnalizuje błędy w kodzie (zarówno w przypadku YAP jak i SWI) - może być to spowodowane niezgodnością wersji. Należy przetestować inne dostępne wersje oraz, po rozwiązaniu problemów zasygnalizowanych powyżej (QEMU), sprawdzić, czy możliwa będzie kompilacja w natywnym środowisku.

Kompilacja CxProlog nie powiodła się zarówno przy środowisku docelowym arm-linux jak i FreeBSD. Brak skryptów umożliwiających konfigurację budowy tego oprogramowania prawdopodobnie poważnie utrudni możliwość jego uruchomienia w systemie innym niż GNU/Linux.

Kross-kompilacja:

• Przygotowanie środowiska. Należy pobrać archiwa zawierające pakiety binutils, newlib oraz gcc i umieścić w odpowiednio dobranej strukturze katalogów.

1. cd [binutils-build]
2. [binutils-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
3. make all install
4. export PATH=„$PATH:[toolchain-prefix]/bin”
5. cd [gcc-build]
6. [gcc-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib –enable-languages=„c,c++” –with-newlib –with-headers=[newlib-source]/newlib/libc/include
7. make all-gcc install-gcc
8. cd [newlib-build]
9. [newlib-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
10. make all install
11. cd [gcc-build]
12. make all install
13. cd [gdb-build]
14. [gdb-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
15. make all install

• Jeżeli ma się odbyć pełny proces kompilacji, to należy również wyposażyć się w pliki nagłówkowe oraz wymagane biblioteki z przyszłego środowiska uruchomieniowego.
• Kompilacja oprogramowania odbywa się zgodnie z np. następującymi regułami:

1. rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja
2. [sciezka_do_zrodel]/configure –target=arm-elf –host=i386-unknown-freebsd CC=[toolchain-prefix]/bin/arm-elf-gcc CPP=[toolchain-prefix]/bin/arm-elf-cpp RANLIB=[toolchain-prefix]/bin/arm-elf-ranlib CPPFLAGS=„-I[sciezka_do_naglowkow]” LDFLAGS=„-L[sciezka_do_bibliotek] –prefix=[prefiks]
3. użycie CPPFLAGS i LDFLAGS jest w pewnych warunkach opcjonalne

• YAP przechodzi taki proces pomyślnie do momentu linkowania. Niestety, ze względu na ciągłe trudności ze znalezieniem właściwego środowiska, brak odpowiednich bibliotek umożliwiających końcowe zbudowanie pakietu.
• W przypadku SWI problemem jest brak odpowiednich plików nagłówkowych - należy to rozwiązać tak samo jak problem powyższy.

• Udało się znaleźć ciekawe wydanie systemu linuks uruchamialne na wirtualizatorze qemu:

http://free-electrons.com/community/demos/qemu-arm-directfb Samo wydanie nie odpowiada dokładnie oczekiwaniom ale zawiera zestaw skryptów oraz opis pozwalający na budowę własnej dystrybucji - co wobec problemów ze znalezieniem jakiejkolwiej innej, działającej, może być dobrym rozwiązaniem.

• Platforma Neo1973 wymagana do uruchomienia dystrybucji OpenMoko nie jest oficjalnie wspierana przez Qemu. Wsparcie dla tej architektury jest aktualnie przedmiotem aktywnego rozwoju - instnieje możliwość wyposażenia Qemu w taką funkcjonalność, ale nie jest to rozwiązanie w pełni stabilne i przewidywalne.

Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB.

• Stabilny rozwój architektury.
• Dobry zestaw narzędzi pozwalających na tworzenie oprogramowania.
• Dobrej jakości dokumentacja.

• Ograniczenia licencyjne (Google zastrzega sobie pewne zasadnicze prawa co do projektu)
• Częściowo zamknięty kod
• Ograniczenie dostępności pewnych funkcji hardware'u dla oprogramowania.
• Duży koszt ew. urządzenia.

• Całkowita otwartość kodu.
• Jasna koncepcja rozwoju.
• Dostępność wirtualizatora (w najbliższej przyszłości, p. wyżej)

• Aktualnie brak dobrego środowiska do emulacji platformy.
• Duży koszt ew. urządzenia.

http://www.arm.com/products/DevTools/VPB926EJ-S.html

• Jest to architektura o względnie uniwersalnym charakterze.
• Obecna od dłuższego czasu na rynku - dobra dostępność oprogramowania.
• Możliwość rozbudowy o dodatkowe komponenty.

• Przeciętnej jakości dokumentacja.

• Całkowicie otwarty kod.
• Dobrej jakości SDK.
• Pełen zestaw mogących się przydać bibliotek i oprogramowania: D-Bus, Hal, X Windows, itp.
• Z przyczyn finansowych brak możliwości przetestowania poza środowiskiem emulowanym.

• Każda z tych platform jest związana z konkretnym rozwiązaniem sprzętowym - trudność migracji, brak możliwości uruchomienia poza środowiskiem emulowanym. Przeciwnie, środowisko oparte o własnoręcznie dostosowany system prawdopodobnie byłoby łatwiej dostosować do nowego rozwiązania sprzętowego.
• Ograniczona dostępność oprogramowania w binarnych pakietach w porównaniu np. do standardowej dystrybucji Debiana.
• Konieczność stosowania określonych rozwiązań, częściowa zamkniętość/ograniczenia w użyciu kodu/narzędzi.

Brak wsparcia ze strony dostępnych wirtualizatorów.

Wsparcie dla środowiska Linuksa: http://www.vollmann.ch/en/colibri/info.html, http://wiki.toradex.com/index.php?title=Linux. Niestety są to rozwiązania komercyjne.

http://rybacki.rootnode.net/debian.pdf

http://wiki.debian.org/Embedded_Debian

http://www.emdebian.org/

http://wiki.debian.org/EmdebianQuickStart

http://wiki.debian.org/EmdebianGuide

Jako platformy uruchomieniowej wydałoby się zasadne użycie systemu GNU/Linux wyposażonego w pakiety: D-Bus, PolicyKit oraz Hal. Pakiety te umożliwiają realizację zagadnień takich jak: komunikacja międzyprocesowa, zarządzanie uprawnieniami oraz interakcja z warstwą sprzętową. Dzięki wysokiemu poziomowi abstrakcji oraz łatwej konfigurowalności mogłby by stanowić wystarczające środowisko - teoretycznie, możliwe do przeniesienia na inne platformy.

Środowisko to pozwala na imitację częściowo natywnej kompilacji oprogramowania oraz kompilację skrośną. Wykorzystywany jest emulator QEMU dla architektury ARMEL.

SDK maemo pozwala na stworzenie środowiska uruchomieniowego na bazie architektury x86 opartej o system GNU/Linux. Nie jest to emulacja, lecz kompilacja i użycie natywnego dla tej architektury kodu ale z użyciem elemetów dostępnych tylko dla maemo:

http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#development

Takie rozwiązanie znacznie zwiększa wygodę testowania i obsługi aplikacji, jednocześnie nie ograniczając możliwości uruchomienia w środowisku emulatora (QEMU).

Ostatecznie, do dalszych prac, zostały uwzględnione trzy różne rozwiązania sprzętowe oparte o procesor architektury arm/armel. Dwa z nich to klasyczne urządzenia typu smartphone/pda, natomiast w przypadku trzecim jest to płyta ewaluacyjna o szerokim zakresie zastosowań. Właściwości tych urządzeń zostaną rozpatrzone w poniższych punktach:

Jest to telefon pracujący w standardzie GSM , wyposażony w zestaw funkcji pozwalających zaliczyć go do klasy urządzeń smartphone. W finalnej wersji (aktualnie jest to sprzęt będący obiektem ciągłego rozwoju) mają się znaleźć:

• Procesor: Samsung S3C2442 B54 SoC @ 400Mhz
• Interfejs WiFi: Atheros 802.11 b/g
• Akcelerator graficzny: SMedia Glamo3362
• Dwa czujniki przyspieszeń (3D)
• 256MB pamięci Flash
• 128MB pamięci SDRAM
• 2MB pamięci Flash NOR
• Bateria 1200mAh
• Podświetlanie LED
• Odbiornik GPS u-blox/Atmel ATR0635
• Interfejs Bluetooth
• Host USB z zasilaniem
• Czytnik kart microSD
• Interfejs JTAG

Oprogramowanie na tę architekturę powstaje w środowisku OpenMoko, które zostanie opisane w dalszych akapitach.

Platforma ta może być emulowana przez wirtualizator QEMU, jednak wsparcie dla niej jest ciągle w fazie rozwoju (konieczności modyfikacji źródeł QEMU na podstawie odpowiedniego repozytorium).

Jest to seria urządzeń o funkcjonalności zbliżonej do klasycznych rozwiązań typu PDA (wbrew błędnie powielanym opiniom, urządzenia te nie posiadają funkcji telefonu). Najnowszym modelem z tej serii jest N810:

• Procesor: 400 MHz TI OMAP 2420
• 2GB pamięci Flash
• 128MB pamięci SDRAM
• Klawiatura, ekran dotykowy
• Wyświetlacz 800×400 pikseli, 16 bitowa głębia kolorów
• Intefejs IEEE 802.11 b/g
• Bateria 1500mAh
• Czytnik kart miniSD
• Interfejs Bluetooth
• Interfejs USB
• Odbiornik GPS
• Kamera
• Czujnik światła

Platforma rozwojowa - maemo.

Architektura ta jest wspierana (częściowo) przez wirtualizator QEMU.

Platforma ta, spośród wybranych, zawiera najszerszy zestaw komponentów - jest to rozwiązanie przeznaczone do w pełni profesjonalnych zastosowań. Istnieje wiele odmian tego urządzenia; jako przykład może zostać przedstawiona płyta:

• Procesor ARM926EJ-S
• Akcelerator Java Jazelle®, dodatki DSP
• Koprocesor MOVE™, sprzętowy akcelerator kompresji MPEG
• Koprocesor zmiennoprzecinkowy
• Kontroler DMA, kontroler przerwań
• Interfejs JTAG
• 64MB pamięci Flash
• 128MB 32 bitowej pamięci SDRAM
• 2MB pamięci SRAM
• Interfejs ethernet
• LCD i ekran dotykowy
• Wyjście VGA
• 4 porty szeregowe
• 1 synchroniczny port szeregowy
• 32 zewnętrznych wyprowadzeń i/o
• 1 interfejs USB, 2 hosty USB
• 2 czytniki SmartCard
• Interfejs klawiatury i myszy
• Wyjście/wejście audio stereo
• Wyświetlacz alfanumeryczny 2×16 LCD
• Kontroler PCI

Platforma wspierana przez wirtualizator QEMU.

Jest to projekt w stu procentach społecznościowy, a zatem i otwarty/niezależny (GPL). Dystrybucja ta powstaje w oparciu o platformę http://oe.linuxtogo.org/.

Struktura zawartego oprogramowania została przedstawiona na poniższym schemacie:

• Za komunikację międzyprocesową odpowiedzialny jest demon D-Bus.
• Obsługa zdarzeń systemowych (np. zmiana stanu baterii, itp.) jest zapewniona przez demona neod; jest to rozwiązanie dość nietypowe i wyłamujące się z konwencji (w środowiskach opartych o system Linux tę rolę pełni najczęściej HAL), dodatkowo, prawdopodobnie jest to rozwiązanie tymczasowe: http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/daemons/neod/README?view=auto

Środowisko to powstało w oparciu o dystrybucję linuksa Debian. Ciekawą własnością SDK należącego do tego środowiska jest możliwość stworzenia platformy uruchomieniowej na bazie architektury x86 z wykorzystaniem kompilacji skrośnej oraz częsciowej tylko emulacji (QEMU). To rozwiązanie jest możliwe dzięki zastosowaniu pakietu http://www.scratchbox.org/:

http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#development

Struktura oprogramowania została przedstawiona poniżej:

Środowisko bazuje na klasycznych rozwiązaniach: warto tu szczególną uwagę zwrócić na wykorzystanie takich pakietów, jak D-Bus oraz HAL (szczególnie interesujące w kontekście sterowania/obsługi zdarzeń). Szczególnie cenna może być również wirtualizacja systemu plików (GnomeVFS), umożliwiająca wykorzystanie wielu dostępnych źródeł danych; narzędzia do obsługi XML; G-Conf (globalne zarządzanie danymi konfiguracyjnymi).

Nie jest to właściwie pełne środowisko jak w przypadkach wyżej opisanych a raczej wydanie samego systemu możliwe do uruchomienia na wybranych paltformach sprzętowych. Szczególnym przypadkiem zastosowania tej dystrybucji, może być wspominana wcześniej płyta ewaluacyjna Versatile PB.

Z faktem, iż nie jest to w pełni funkcjonalne środowisko wiąże się konieczność samodzielnego wyposażenia go w odpowiednie oprogramowanie. Problem ten częściowo da się rozwiązać przez wykorzystanie dostępnych wraz z dystrybucją pakietów i/lub kompilacji skrośnej/w środowisku wirtualizatora. Sytuacja taka daje jednak niewątpliwą korzyść w postaci możliwości niemal dowolnej ingerencji w ostateczny kształt rozwiązania.

Przykład uruchomienia tej dystrybucji na wirtualizatorze, został przedstawiony tutaj: http://www.aurel32.net/info/debian_arm_qemu.php.

Kwestię przenaszalności, w rozważanym tutaj przypadku, można sprowadzić do problemu, czy na danej architekturze da się uruchomić system GNU/Linux. Ewentualne ograniczenia mogą wynikać z wyboru dodatkowego oprogramowania. Zastosowanie popularnych rozwiązań, wymienionych wcześniej (HAL, D-Bus, GnomeVFS, PolicyKit, itd.) daje możliwość oddzielenia warstwy sprzętowej/systemowej od samego środowiska uruchomieniowego prologu. W praktyce oznacza to, że np. migracja między wymienionymi tu platformami będzie ograniczała się najwyżej do instalacji i/lub odpowiedniej konfiguracji wymaganego oprogramowania.

Kompilację przeprowadzono w środowisku: http://www.aurel32.net/info/debian_arm_qemu.php uruchomionym na wirtualizatorze QEMU. Komputer, na którym uruchomiono wirtualizator wyposażony był w procesor Core 2 Duo T5500, 2GB pamięci RAM, system operacyjny FreeBSD. Kompilacja Yap zajęła w sumie ok. 40 min. W przypadku SWI, proces ten przeciągnął się nieomal do 3 godzin.

Po uruchomieniu (zajmowanej pamięci rzeczywistej): 2968kB.

Po uruchomieniu (zajmowanej pamięci rzeczywistej): 3328kB.

Nie udało się dokładnie zbadać zapotrzebowania na czas procesora w przypadku wymienionych kompilatorów, jednak, zauważono, w środowisku wirtualizatora wyraźnie mniejszą responsywność kompilatora SWI.

• Określenie na jakim poziomie ma przebiegać interakcja prologu z pozostałymi składnikami systemu; na tej podstawie wybór właściwego oprogramowania otaczającego.
• Wybór platformy lub wykorzystanie uniwersalnych, przenaszalnych rozwiązań.
• Stworzenie środowiska ułatwiającego analizę wymagań/działania kompilatorów prologu pod względem wydajności i niezawodności.

Do sprawdzenia:

• http://www.ubuntu.com/products/mobile
• http://www.moblin.org/index.php
• https://wiki.ubuntu.com/MobileAndEmbedded
• http://www.linuxdevices.com/news/NS9978560959.html
• http://osnews.pl/ubuntu-mid-edition-804-pierwsza-wersja-deweloperska/
• http://www.linuxdevices.com/news/NS9978560959.html
• http://www.osnews.com/story/19906/Nokia_Now_Controls_Symbian;_Empowers_Symbian_Foundation
• http://lwn.net/Articles/287330/

:pl:miw:gjn-mixdes2006-final.pdf

http://www.toradex.com/e/colibri_evalboard.php