Meta Layer für Openembedded/Yocto für STLinux basierende Box

[graugans]

Die Letzten Monate habe ich sporadisch damit zugebracht einen BSP Layer für die STLinux basierenden Set-Top-Boxen zu erstellen. Im Moment liegt der Fokus sehr stark auf den Spark (Fulan) Boxen, da ich selbst eine GM 990 besitze. Es gibt bereits eine Definition für die Spark 7162 dies ist allerdings ungetestet. Andere Boxen dürften allerdings kein allzu großer Aufwand sein.

Motivation
Da ich ich mich schon seit einiger Zeit mit dem Thema Openembedded Core / Yocto beschäftigen wollte dachte ich mir ich schaue mal wieviel Aufwand so ein STLinux Port wäre. Mir ist vollkommen klar, dass es bereits das TDT, OpenWRT und Seife's Buildsystem gibt. Diese haben für mich jedes seine Vorteile und Nachteile. Bis jetzt hat mir von allen Möglichkeiten das Buildsystem von Seife am Besten gefallen. Das ist klar strukturiert und bietet ein Paketmanagment out of the Box. Für mich bietet Yocto noch ein bisschen mehr als das System von Seife, da es etwas besser dokumentiert ist und eine größere Community dahinter steht. Des Weiteren ist es sobald man das System verstanden hat leichter Pakete hinzuzufügen. Für mich ist das erstellen einer Toolchain welche auch extern zur Entwicklung 3. Party Tools genutzt werden kann einfach Gold wert. Ich finde Layer Konzept mittlerweile echt super praktisch.

Aktueller Zustand
Auf meiner Golden Media 990 bootet das core-image-minimal aus dem Yocto Projekt. Die TDT Treiber werden geladen und die Tools wie fp_control und ustslave sind vorhanden. Die Funktionalität der Treiber ist noch nicht getestet, da ich noch keine GUI übersetzt habe. Es handelt sich ja im Moment auch nur um einen BSP Layer. Yocto verwendet UDEV als Hotplug Dienst aus diesem Grund mussten noch ein paar UDEV Rules für Tools wie ustslave erstellt werden. Das und die Verwendung der modutils sollte es deutlich einfacher machen W-LAN Treiber oder andere USB-Gadget Treiber vom Desktop auf die Boxen zu Portieren. Das habt mich im Falle der Compat-Wireless Treiber für das Pinky TDT fast wahnsinnig gemacht.

Die meiste Zeit hat mich die Toolchain gekostet. Insbesondere die glibc, da Yocto eigentlich die eglibc verwendet. Eine zeitlang wollte ich mit einer externen Toolchain arbeiten, was aber auch irgendwie unschön ist. Dann habe ich mich daran gewagt die glibc einzubauen. Das war dann doch einfacher als gedacht. Ich verwende die glibc direkt aus dem stlinux git. Beim GCC verwende ich den GCC welcher im denzil Branch von Yocto eingesetzt wird. Im Falle der Toolchain kann es ganz gut sein das noch der ein oder andere Patch für das Optimum an Performance fehlt. Mir war ein bootendes System erstmal wichtiger. Ob das Closed Source PTI funktioniert habe ich auch noch nicht getestet, da keine GUI vorhanden.

Lirc funktioniert bei meiner GM 990 zu mindestens mittels "irw" getestet. Die Ansteuerung des Front Panel Prozessors inkl. Erstellung des "/dev/vfd" scheint auch zu funktionieren. Ob alles Devices korrekt von UDEV erstellt wurden kann ich auch erst sagen sobald die erste GUI bzw. irgendwelche Tools wie w_scan etc. gelaufen sind.

Weitere Schritte
Neben dem weiteren Ausbau des BSP-Layers werde ich einen Applikations Layer anfangen. In diesen werden dann die GUIS wie Neutrino, VDR und enigma gepackt. Wobei der Fokus im Moment auf Neutrino liegt. Dawird noch genügend Arbeit auf mich warten bis alle Bibliotheken kompilieren und funktionieren.


Quellen
Das ganze finden interessierte hier bei github unter dem Namen project magpie und das Repository heißt meta-stlinux
- https://github.com/project-magpie/meta-stlinux -
- https://github.com/project-magpie/meta-stlinux/wiki -

Über Patches, Merge Requests, Anregungen und Hinweise freue ich mich immer.

[seife]

Hallo,

ich finde das ziemlich cool. Ich hatte mir auch schon mal openembedded angeschaut, aber die Lernkurve war eher steil. Buildroot war zwar etwas besser, aber nicht sooo viel.

Mein buildsystem funktioniert zwar, und ein paar features finde ich persönlich besser als bei OE (speziell das automatische hochzählen der Buildnummer wenn das Paket sich unterscheidet, anstatt die manuell einzutragen), andere sachen zeigen jedoch die einschränkungen auf (die meisten Patches in letzter Zeit waren z.B. um abhängigkeiten zum Hostsystem -- welche es eigentlich nicht geben sollte -- zu vermeiden / fixen etc, siehe die letzten glib-fixes oder der allerletzte giflib-"fix").

Ich werde das gleich mal anwerfen und anschauen.

Zu deiner wiki-seite: das neutrino-hd ist inzwischen obsolet und wird von mir nicht mehr maintained, sondern wenn dann nur von martii. Der Grund ist, dass das neutrino-mp auch auf singletuner-Boxen gut läuft und sogar eher weniger Speicher belegt. (Nur damit sich niemand wundert, warum an der "maintainten" Software keine Änderungen mehr gemacht werden).

Ciao,
seife

[graugans]

Hi,

Danke, ja ich bin immer noch am Lernen. Ich glaube nach dem ersten Booten muss man immer noch ein update-modules ausführen...
Ja das mit dem Autoinkrement ist eine praktische Sache. In die Falle bin ich bei OE schon ein paar Mal reingelaufen.

Zum Thema Doku (Wiki). Die muss ich noch anpassen. Das kostet halt alles seine Zeit.

Das mit Neutrino-MP hatte ich so schon fast vermutet.


P.S: Ich hoffe das Image baut durch ;-)

[graugans]

!!! ACHTUNG !!!
Aktuelle Informationen zum Buildsystem sind im Wiki zu finden.Yocto basiertes Buildsystem

[AudioSlyer]

OE ist halt blöde für Patcher und die, die mal fix den Source umschreiben bzw fixen / testen wollen

[graugans]

Da muss ich doch gleich mein Veto einlegen. Das traf glaube ich auch das alte OpenEmbedded zu, das war meiner Meinung nach auch ziemlicher Müll.

Keine Ahnung ob das für oe-core auch alles zutrifft im Falle von yocto sind die von Dir beschrieben Use-Cases wunderbar umsetzbar.

Mit der DEVSHELL kann man ganz easy an den sourcen rumschrauben und hat die Compiler usw schon direkt im Zugriff
http://www.yoctoproject.org/docs/1.2/po ... v-devshell

Dieses Feature hat kein anderes mir bekanntes Buildsystem ;-)

Oder Du entwickelst direkt mit Bitbake:
http://www.yoctoproject.org/docs/1.2/po ... dev-insitu

Liegen die Sourcen als git repo vor kann man ganz easy mittels git format-patch Patches erstellen. Diese können Dann auch im recipe wiederverwendet werden. Willst Du nicht das Original recipe ändern kannst Du Dir nen lokalen Layer anlegen und für das recipe Deiner Wahl nen .bbappend anlegen und damit Änderungen am source wie z.B Patches einspielen.

Patches kann man auch wie folgt generieren:
http://www.yoctoproject.org/docs/1.2/de ... t-workflow

Und da alles schön aus den sourcen gebaut wird kann man sogar nativ entwickeln. Oder man entwickelt nativ im Qemu ;-)

Das schönste daran ist es ist sogar ganz akzeptabel dokumentiert.

[mad bullet]

Hallo erstmal in die Runde,
ich versuche mich auch gerade am project-magpie und habe vor 3 Tagen schonmal erfolgreich damit durchgebaut.
Da seither wieder Änderungen eingeflossen sind, habe ich in meta-stlinux ein einfaches git pull eingegeben, erhalte jedoch diese Meldung.

Code: Alles auswählen

sh4@SH4:~/meta-stlinux$ git pull
error: Couldn't resolve host 'github.com' while accessing https://github.com/project-magpie/meta-stlinux.git/info/refs

fatal: HTTP request failed
sh4@SH4:~/meta-stlinux$

Ebenso beim Versuch neu zu Clonen. Was mache ich als Neuling falsch?

[Houdini]

Deine Büchse kommt nicht ins internet / deine Namensauflösung geht nicht

[graugans]

Hi,

@Houdini das wäre ja zu einfach ;-)

nachdem mir gestern meine Platte das zeitliche gesegnet hatte musste ich eh frisch ausschecken...

Code: Alles auswählen

git clone https://github.com/project-magpie/setup-scripts.git
cd setup-scripts/
MACHINE=spark ./oebb.sh config spark
./oebb.sh update

Hat er alles wunderbar ausgechekt.... Ich weiß das auf der yocto Mailingliste Probleme mit github gemeldet wurden ich checke das nochmal.

Du könntest mal versuchen auf das git Protokoll umzustellen falls möglich:
https://help.github.com/articles/changi ... mote-s-url

[graugans]

Ich habe mal im 3. Beitrag eine kleine Anleitung geschrieben. Leider konnte ich den ersten Beitrag nicht mehr editieren.

http://www.tuxbox.org/forum/viewt ... 24#p385324

[mad bullet]

Danke für die Antworten, ich habe gerade nochmals neu ausgecheckt und es geht wieder, allerdings die ursprüngliche Methode aus dem Readme.
Build baut.

edit: und hat anstandslos durchgebaut

[graugans]

Hi,

Ich baue gerade den support für die spark7162 Modell (Triplex) ein. Die Box bootet soweit Lirc geht Neutrino habe ich noch nicht getetstet.

@ mad bullet
mann muss halt beachten, dass in der Methode aus dem README kein Neutrinio gebaut wird. Das kann man ändern in dem man den Layer hinzufügt.

[dbt]

Ich habe mal im 3. Beitrag eine kleine Anleitung geschrieben. Leider konnte ich den ersten Beitrag nicht mehr editieren.

http://www.tuxbox.org/forum/viewt ... 24#p385324

Kleiner Anmerkung an der Stelle, für sowas haben wir ja eigentlich das Wiki. Dann reicht ein Link dorthin und es ist auch pflegeleichter. zB. dahin: Alternative_Buildumgebungen oder so

[mad bullet]

@ mad bullet
mann muss halt beachten, dass in der Methode aus dem README kein Neutrinio gebaut wird. Das kann man ändern in dem man den Layer hinzufügt.

Ja danke, dass hatte ich schon verstanden, mir ging es als Neuling darum,erstmal anzutesten wie ich damit umgehe, um ein Gefühl dafür zu bekommen.
Ich hatte bisher aus dem tdt gebaut.
Ich dachte mir auch dass es für dich als Rückmeldung so ok ist, quasi positives Feedback.
An den reinen Imagebau denke ich derzeit noch nicht, da kommt ja noch einiges rein, zumal ein Image für den Flash gerade bei Spark eh interessanter wird.
Bis dahin ist ja noch ein Weg.

[graugans]

@mad bullet
Danke für Dein Feedback. Alles klar, ja es fehlen noch ein paar Punkte. Das wird aber mit der Zeit.

@dbt
Danke, manchmal sehe ich den Wald vor lauter Bäumen nicht. Ich habe das ganze mal ins Wiki gestellt Alternative Buildumgebung Ich habe mir erlaubt eine separate Seite anzulegen und diese auf der Seite Alternative Buildumgebung zu verlinken.

[plux7887]

Wollte das jetzt auch nochmal ausprobieren.
Hab frisch geklont und bin nach der Wiki vorgegangen.
Jetzt hänge ich hier:

Code: Alles auswählen

*/spark-build$ bitbake core-image-minimal
Pseudo is not present but is required, building this first before the main build
WARNING: Host distribution "Ubuntu 12.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Parsing recipes: 100% |###############################################################################################| Time: 00:00:35
Parsing of 841 .bb files complete (0 cached, 841 parsed). 1117 targets, 44 skipped, 15 masked, 0 errors.
ERROR: No recipes available for:
  */meta-stlinux/recipes-multimedia/libdvbsi++/libdvbsi++_0.3.6.bbappend
  */meta-stlinux/recipes-multimedia/neutrino-mp/neutrino-mp_git.bbappend
ERROR: Command execution failed: Exited with 1

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

[graugans]

Ich schau mir das mal an. Da scheint der bsp layer Abhängigkeiten zum magpie layer zu haben. Ich muss eh noch ein paar Fixes pushen.

Gesendet von meinem Nexus 4 mit Tapatalk 2

[graugans]

@plux7887
Sorry für die späte Antwort. Aktuell bin ich etwas im Stress, leider nicht mit diesem Projekt. Falls Du ein komplettes Image bauen möchtest empfehle ich Dir die Verwendung des setup-scriptes. Wobei der build für die spark7162 gerade etwas instable ist ;(.

https://github.com/project-magpie/setup-scripts

Der von Dir beschriebene Fehler kann wie folgt behoben werden:

Code: Alles auswählen

rm   /meta-stlinux/recipes-multimedia/libdvbsi++/libdvbsi++_0.3.6.bbappend
rm /meta-stlinux/recipes-multimedia/neutrino-mp/neutrino-mp_git.bbappend

Die bbappends referenzieren auf den Layer mit den Paketen für Neutrino und die Restlichen nicht BSP relevanten Pakete wie ath9k etc...

Ich werde den Fix in den nächsten Tagen in die Layer pushen.

cu

[mohousch]

falls Jemand interessiert für das openpli OE es gibt Patche für den stlinux layer für die Kathrein Boxen, die Patche stammen vom scp.

[graugans]

falls Jemand interessiert für das openpli OE es gibt Patche für den stlinux layer für die Kathrein Boxen, die Patche stammen vom scp.

Hallo mohousch,
kannst Du mir mal bitte die Links schicken?

Gruß
Christian

[graugans]

Es scheint noch ein Fork von skl zu geben. Dieser implementiert wohl auch eine OpnelPLI Integration:

https://github.com/sklnet/meta-stlinux

[mohousch]

Hallo mohousch,
kannst Du mir mal bitte die Links schicken?

habe ihm ein PN geschickt.

EDIT:
Sorry, das ist der gleich Link.

[graugans]

Danke,

P.S: Ich bin gerade dabei Dein Neutrino-HD2 zu integrieren.

Gesendet von meinem Nexus 4 mit Tapatalk 2

[plux7887]

Ich versuche gerade hiermit Neutrino-HD2 zu bauen.
bekomme beim configure 2 Arten von Fehlern:

Code: Alles auswählen

| Thread model: posix
| gcc version 4.7.2 (GCC)
| configure:3491: $? = 0
| configure:3480: sh4-magpie-linux-gcc  -ml -m4 --sysroot=/media/tux/c30e53dd-e861-47d8-897b-c02f88787a97/setup-scripts/build/tmp-magpie/sysroots/spark -V >&5
| sh4-magpie-linux-gcc: error: unrecognized command line option '-V'
| sh4-magpie-linux-gcc: fatal error: no input files
| compilation terminated.
| configure:3491: $? = 1

Code: Alles auswählen

| checking for package id3tag... yes
| configure: error: could not find package id3tag

Bin auf Ubuntu 13.10
meta-yocto = "dora:8c102dba491927745d34b15176f9e4ba6c3c07c6"
meta-magpie = "master:5a681c8ec59f62c5312ee4d9ccea4dd22b3f6687"
meta-stlinux = "dora:91abbcebd0ac3fe0c6e479cd0cb7bc49f93dede1"
meta-local = "master:f96d93f078e14f3c46313a5549cb57e5f1b6aec0"

Das komische ist, Neutrino-MP läßt sich mit id3tag Problemlos bauen. Kann mir jemand einen Tip geben, woran es liegt?

[mohousch]

@plux7887

kannst Du neutrino neu auschecken dürfte jetzt gefixt sein (mad/id3tag check kopiert von Neutrino-MP ;( )