To jest stara wersja strony!
Opis
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
08.03.04
Wybór kompilatora prologa (SWI, GNU), analiza jakości działania obu kompilatorów - pod względem zużycia zasobów systemu, stabilności oraz możliwych mechanizmów komunikacji z innymi składnikami systemu.
Sposób integracji z systemem - np. jako moduł jądra - wysoka wydajność i uproszczona komunikacja między składnikami systemu, duża podatność na awarie, niska portowalność na inne architektury; w przestrzeni użytkownika - większa stabilność kosztem potencjalnie bardziej złożonej komunikacji i mniejszej wydajności, konieczność opracowania rozbudowanej warstwy komunikacyjnej umożliwiającej integrację z systemem
Analiza alternatywnych środowisk uruchomieniowych - porównanie dostępnych platform bazujących na systemie GNU/Linux z innymi dostępnymi, jak np. NetBSD; należy zwrócić uwagę na wymagania sprzętowe, trudności związane z konfiguracją systemu oraz odtwarzaniem tej konfiguracji w nowych warunkach a także jakość dokumentacji i perspektywy rozwoju danej implementacji. Licencje i dostępność.
Rozważenie wykorzystania istniejącego już oprogramowania (D-Bus, PolicyKit, HAL) do realizacji zadań związanych z dostępem do sterowników oraz zarządzaniem zdarzeniami. Ewentualnie wykorzystanie pewnych wzorców dostępnych w wymienionych implementacjach.
Na podstawie powyższych punktów, określenie minimalnych wymagań sprzętowych umożliwiających działanie w czasie rzeczywistym.
080318
080408
080415
spis środowisk + ew. ewalucja: OpenMoko, Android → argumenty
ew. zasadzki w kompilacji prologu na w.w
080422
Projekt
Sprawozdanie
08.03.18
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.
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.
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.
08.04.08
Kross-kompilacja:
cd [binutils-build]
[binutils-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
make all install
export PATH=„$PATH:[toolchain-prefix]/bin”
cd [gcc-build]
[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
- make all-gcc install-gcc
- cd [newlib-build]
- [newlib-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib
- make all install
- cd [gcc-build]
- make all install
- cd [gdb-build]
- [gdb-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib
- 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:
- rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja
- [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]
- 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.
===== 08.04.15 =====
Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB.
=== Android ===
== Zalety ==
* Stabilny rozwój architektury.
* Dobry zestaw narzędzi pozwalających na tworzenie oprogramowania.
* Dobrej jakości dokumentacja.
== Wady ==
* Ograniczenia licencyjne (Google zastrzega sobie pewne zasadnicze [[http://en.wikipedia.org/wiki/Android_%28mobile_phone_platform%29 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.
=== OpenMoko ===
== Zalety ==
* Całkowita otwartość kodu.
* Jasna koncepcja rozwoju.
* Dostępność wirtualizatora (w najbliższej przyszłości, p. wyżej)
== Wady ==
* Aktualnie brak dobrego środowiska do emulacji platformy.
* Duży koszt ew. urządzenia.
=== Versatile PB ===
http://www.arm.com/products/DevTools/VPB926EJ-S.html
== Zalety ==
* 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.
== Wady ==
* Przeciętnej jakości dokumentacja.
==== Próba instalacji systemu GNU/Linux (Debian) na wirtalizatorze ====
Emulowana platforma to płyta ewaluacyjna Versatile PB. Instalacja odbyła się zgodnie z intrukcjami podanymi na stronie: http://www.aurel32.net/info/debian_arm_qemu.php. Jedyna modyfikacja polegała na dodaniu flagi „clock=pit” do parametrów jądra.
Po instalacji systemu oraz pakietów make, gcc, g, g77 oraz libc6 odbyła się próba kompilacji i uruchomienia kompilatora Yap (wersja 5.1.2). Próba ta zakończyła się sukcesem. Jedyną niezbędną modyfikacją, było usunięcie flag odpowiadających za obsługę wyjątków zmiennoprzecinkowych z pliku config.h. Skrypt konfiguracyjny prawdopodobnie niewłaściwie rozpoznał dostępną w systemie implementację wyjątków.
Próba kompilacji kompilatora SWI niestety nie powiodła się. Proces kompilacji w tym wypadku konsumował olbrzymie ilości zasobów i z powodu długiego czasu trwania został przerwany.
Materiały