Gestern habe ich noch mein Leid geklagt, doch so langsam kommt Bewegung in meine Angstrom Installation.
Auf meiner SD-Karte ist inzwischen ein aktuelles Image aus dem unstable Zweig inkl. DSPLink Kernel Modul, GCC und den ALSA Utilities. Viel Zeit hatte ich noch nicht, um alles bis ins Detail auszuprobieren, aber meine Open-Embedded Umgebung sollte Pakete produzieren können, die sie dort nun installieren lassen.
Das Problem lag in den letzten Tagen insbesondere an zwei Problemen:
Der falschen Kombination aus X-Loader/U-Boot: Â Neuere U-Boot Versionen setzen einen aktualisieren X-Loader vorraus und der Updatevorgang ist wenig dokumentiert. Eine neue MLO-Datei auf der ersten Partiton wird derzeit noch ignoriert.
Texas Instruments X-loader 1.4.2 (Feb 19 2009 - 12:01:24) Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.03-rc1 (Apr 14 2010 - 12:28:02) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720MHz OMAP3 Beagle Board + LPDDR/NAND I2C: Â Â ready <aufgehangen>
Dies habe ich durch einen Downgrade der U-Boot Version in den Griff bekommen.
Evtl. davon ausgehend, verträgt sich der EHCI-Port nicht mit meinem aktiven USB-Hub (Kernel-Panic). Bei freiem Port oder nur einem einzigen angeschlossenen USB 2.0 Gerät klappt es aber. So habe ich z.B. einen funktionierenden Zugang zum Netzwerk (auch Internet) oder alternativ Speicherplatz auf einem USB-Stick. Meine Maus und Tastatur sind USB 1.0 und führen zu Fehlermeldungen, da sie ja eh nur über den aktiven HUB funktionieren sollten. Das ist entweder mit dem nächsten Kernel-Update behoben oder hängt mit dem veralteten U-Boot zusammen. Meine Interaktion mit dem X-Server ist bis dahin aber auf das Betrachten des X11-Logins beschränkt. 😉
Ein paar Logauszüge und Versionsnummern trage ich heute oder morgen noch nach, damit es nachvollziehbarer wird.
Meine (mit o.g. Einschränkungen lauffähige) Kombination:
Texas Instruments X-loader 1.4.2 (Feb 19 2009 – 12:01:24)
U-Boot 2009.11-rc1 (Jan 08 2010 – 21:19:52)
Angstrom/2.6.32/beagleboard
Angstrom 2010.4-test-20100423