Samstag, 23. November 2013
Crawlee OS
Intel bietet zwei verschiedene Linux Varianten für das Galileo Board an, die beide Arduino kompatibel sind.

Das eine Linux firmiert unter clanton-tiny und läuft direkt auf dem Board. Die knapp 8MB große Distribution bietet jedoch so gut wie keine Möglichkeiten zur Interaktion.

Als Alternative gibt es eine clanton-full Distribution, die bereits deutlich mehr Tools zur Verfügung stellt. Insbesondere ist dadurch dann auch möglich sich bei angeschlossenem Netzwerkkabel via

ssh root@galileo

mit dem Board verbinden und erhält eine bash Shell. Die clanton Distribution wird mit Hilfe des yocto-Projektes erstellt. Um clanton-full zu installieren genügt es die zur Verfügung gestellten Files

bzImage - Der Linux Kernel
core-image-nimimal-initramfs-clanton.cpio.gz - Das RAM-Linux, das das Hauptlinux bootet
image-full-clanton.ext3 - Ein Image File, das das gesamte Dateisystem enthält
boot/grub/grub.conf - Die Bootconfiguration, die festlegt welches Dateisystem gestartet werden soll

auf die SD-Karte zu kopieren. Auch das "volle" Linux bietet aber nicht besonders viele Optionen, so dass ich dazu übergegangen bin ein eigenes Linux zu kompilieren. Die entsprechenden recipes kann man sich von Intel unter

https://communities.intel.com/community/makers/software/drivers

herunterladen. Man benötigt die "Board Support Package Sources for Intel Quark".

Für meinen ersten Build meiner SDK-Distribution habe ich mich sklavisch an die von Sergey Kiselev veröffentlichte Anleitung gehalten:

http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage

Die wichtigsten Schritte im Schnelldurchlauf:

- In meta-clanton_v0.7.5 das Setup Script ./setup.sh ausführen
- In das Build Directory wechseln über source poky/oe-init-build-env yocto_build
- In conf/local.conf die clanton-full Disitribution auswählen
- uClibc patch in v4l2apps auskommentieren
- Rezept für image-sdk erstellen auf Basis des image-full.bb Files
- Die Pakete packagegroup-core-basic packagegroup-core-lsb kernel-dev unter IMAGE_INSTALL zur Installation auswählen
- Die Tools tools-sdk dev-pkgs tools-debug eclipse-debug tools-profile tools-testapps debug-tweaks zu den IMAGE_FEATURES hinzufügen
- Speichergröße um z.B. Faktor 10 auf 3072000 kByte erhöhen (Achtung: Mein Image hatte hinterher knapp 1.5GB benötigt!)
- Den CY8C9540A-Patch hinzufügen
- Das Image über bitbake image-sdk erstellen
- Warten ...

Mit ein bisschen Glück, sollte das Ganze dann durchlaufen, und am Ende findet man die benötigten Files (die man am einfachsten noch umbenennt, so dass sie genauso wie die weiter oben erwähnten Dateien heißen) in dem yocto_build/tmp/deploy/images Verzeichnis.

Das hat natürlich überhaupt nicht funktioniert… Wie man das bei Linux ja schon mal hat…

Zunächst einmal fehlten einige Pakete auf meinem Ubuntu-EeePC, der meine Build-Plattform werden sollte, obwohl ich das build-essential Paket installiert hatte. Immerhin bekommt man in der Fehlermeldung genau mitgeteilt, welche Pakete erwartet werden, so dass man sie über ein entsprechendes

sudo apt-get install <paket-name>

nachinstallieren konnte.

Als nächstes musste ich dann feststellen, dass mein EeePC, der leider mein einziger Linux Rechner im Hause war, keine besonders gute Build-Plattform abgibt. Die komplette 1.5GB Distribution zu kompilieren hat (ungelogen) an die 30 Stunden gedauert.

Wenn es denn dann wenigstens fehlerfrei durchlaufen würde, was mir leider auch nicht vergönnt gewesen ist.

Das OpenCV Paket habe ich nicht gelinkt bekommen. Ich habe immer einen relocation Fehler bekommen. Im Internet wird immer auf die Option -fPIC als Lösung verwiesen. OpenCV selbst wurde aber mit -fPIC erstellt. Ich vermute, dass es am Ende an der Python Library lag. Ich werde mich des Problems ein anderes Mal wieder annehmen, und habe OpenCV schließlich aus dem Image-Recipe entfernt. Dazu einfach die Einträge in der image-sdk.bb Datei unter IMAGE_INSTALL entfernen oder auskommentieren.

Ein weiteres Problem beim Verlinken gab es, weil der Befehl einer Library zu lang geworden ist. Die Parameterlänge ist durch die Stackgröße begrenzt. Ich habe den Stack verdoppelt, aber auf Grund des langen Pfadnamens hatte auch das nicht genügt. Dementsprechend musste ich alles in einen Pfad verschieben, der deutlich weniger lang ist, was (natürlich) einen kompletten Rebuild nach sich zog.

Eine Woche später, war es dann aber endlich geschafft und ich hatte das 3 GB große Image für mein Galileo Board in Händen :-)

Alles weitere kann ich jetzt direkt via ssh auf dem Board selbst kompilieren.

... comment