X

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

Einklappen
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • graugans
    Neuer Benutzer
    • 06.02.2012
    • 6

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

    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.
  • Captain
    Erfahrene Benutzer
    • 29.06.2009
    • 7022

    #2
    Klasse Arbeit

    das OE-CORE Build system gehört auch zu meinen Favoriten, seit openAAF 2.0 Arbeiten wir ja auch mit den Layern und das ist sehr Praktisch auch das anbinden der submodule, dadurch immer saubere Trennung.

    Kann nur hoffen das du hier Unterstürzung bekommst da im alten Build System eigendlich jetzt schon alles verwoben ist und auch Einsteiger nicht mehr das System durchblicken.

    Kommentar

    • graugans
      Neuer Benutzer
      • 06.02.2012
      • 6

      #3
      Danke, jede Hilfe ist willkommen egal ob

      • Beta Tester mit anderen Boxen, Pingu, Amiko etc..
      • Hinweise auf fehlende Doku.
      • ...

      Gruß
      graugans

      Kommentar

      • obi
        obi
        SVN-.....
        • 04.01.2008
        • 24587

        #4
        was hat denn so eine umgebung für vorteile für die devs die sich mit der cvs umgebung auskennen ?

        Kommentar

        • graugans
          Neuer Benutzer
          • 06.02.2012
          • 6

          #5
          Hi,

          ich denke das hat viel mit persönlichen Vorlieben zu tun. Wenn sich jemand mit dem cvs Umgebung auskennt wird er sich vermutlich effizienter in dieser Umgebung bewegen können. Meine persönlichen Highlights von Yocto sind die folgenden:

          - Paket-Management out of the Box. Wahlweise opkg, deb oder rpm.
          - Trennung zwischen BSP Board Support Package und Applikationen. Das heißt man kann den selben Applikationslayer auf unterschiedlichen Boxen bauen. z.B sh4 und mips.
          - Bei Openembedded können neue Pakete sehr einfach hinzugefügt werden: z.B alsa
          - Unterschiedlich Plattformen können recht elegant definiert und angepasst werden.
          - Anwender können sich Ihren eigenen Layer erstellen ohne gleich das ganze Buildsystem zu patchen.
          - Es ist ganz einfach eine Toolchain zu erstellen mit welcher man auch ohne Buildsystem Applikationen compilieren kann, da sämtliche Header und libs integriert werden. Siehe
          - Crossdebugging mit eclipse funktioniert auch fast out of the box.


          Für mich sind Files wie diese fast zu heftig. ;-)

          Ich will keine Konkurrenz zu cvs TDT aufziehen. Ich finde die Arbeit an den Treibern absolut genial und unverzichtbar wertvoll. Ich persönlich komm halt mit der Openembedded Varinate besser zurecht.


          <ironie>
          P.S: Die Diskussion hat was von vi vs. emacs ;-)
          </ironie>

          cu

          Kommentar

          • obi
            obi
            SVN-.....
            • 04.01.2008
            • 24587

            #6
            ja das hauptproblem is das die main devs ehr keine lust hätten sich umzugewöhnen. (schätzungsweise)
            sicher hat alles vorteile es gab/gibts ja auch dieses openwrt sh4 usw... aber tdt hat das damals halt auf cvs umgesetzt.

            wenn ich das nun richtig verstanden habe baut dieses Openembedded jede lib/bin... als opkg und aujs den einzelnen packeten wird irgendwo das image zusammen gesetzt... also so wie es bei den dreambox kisten offizell is. Das hat schon vorteile wenn man alle bestandteile automatisch als opkg nach dem bauen hat. Und somit direkt anbieten kann.

            Würd mich an sich schon interessieren.

            Hab ich den part da richtig verstanden ?

            Kommentar

            • graugans
              Neuer Benutzer
              • 06.02.2012
              • 6

              #7
              Genau es wird immer ein opkg gebaut. Die dreamboxen haben teilweise noch das alte openembedded. Die neueren Versionen heißen dann glaube ich 2.0. Es werden standardmäßig auch immer dev,doc, und dbg Pakete gebaut. Das mit den Paketen ist echt praktisch. Damit lassen sich viel leichter Erweiterungen wie Vögel einbauen die im Dev Layer nix zu suchen haben.

              cu
              Zuletzt geändert von graugans; 12.01.2013, 10:03.

              Kommentar

              • graugans
                Neuer Benutzer
                • 06.02.2012
                • 6

                #8
                Hi,

                ich habe heute das erste Mal das Neutrino-MP welches ich mittels OpenEmbedded für die spark Box gebaut habe gestartet. Prinzipiell startet Neutrino viel mehr habe ich bis jetzt noch nicht getestet.
                Die ganzen Hardware unabhängigen Teile habe ich in einen eigenen Layer ausgelagert:
                https://github.com/project-magpie/meta-magpie

                Damit das Aufsetzen etwas einfacher wird habe ich die Angström setup-scripts angepasst.
                https://github.com/project-magpie/setup-scripts

                Damit ist die ganze Sache aber immer noch nichts für den unerfahrenen Nutzer. Wer ein bisschen damit experimentieren will kann sich ein Image zum spielen bauen.
                Code:
                bitbake vulture-image
                Das Neutrino wird noch nicht automatisch ins image integriert mann kann es aber leicht über einen lokalen feed nachinstallieren. Oder man ändert die image Konfiguration.

                Code:
                meta-magpie/recipes-core/images/vulture-image.bb
                Es muss nur neutrino-mp zur Variablen IMAGE_INSTALL hinzugefügt werden. Ich hoffe ich bekomme das Neutrino dann in den nächsten Tagen mit dem vollen Leistungsumfang und Startup Skript ans Laufen.

                Kommentar

                • Captain
                  Erfahrene Benutzer
                  • 29.06.2009
                  • 7022

                  #9
                  gibt ja schon aus unseren oe-a Team ein fork für oe-alliance

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

                  Kommentar

                  • graugans
                    Neuer Benutzer
                    • 06.02.2012
                    • 6

                    #10
                    Stimmt, habe ich schon gesehen. Mit dem fork muss ich bei Gelegenheit mergen ;-) und diesen auch mal testen.

                    Ihr konzentriert euch mehr auf enigma2 oder? Immerhin gibt es einen NHD2 Patch von SCP für oe-a.

                    Da Ihr sehr viel aus dem openpli verwendet wäre es kein act die Neutrino-mp recipes auf oe-a zu portieren. Wie interessant das ganze für die MIPS Boxen ist habe ich keine Ahnung ;-)

                    Kommentar

                    • Captain
                      Erfahrene Benutzer
                      • 29.06.2009
                      • 7022

                      #11
                      nur e2 , machen wir dafür aber eine große Anzahl von Boxen.

                      build ist ein gemischt pli, dmm, oe-core, oe-a , haben das sauber in den layern getrennt
                      wir sind da offen und nehmen für uns das optimale.

                      Da sif team ja auch für spark Boxen Images Baut sind sie gerade dabei die Builds zu vereinen.

                      Ich selber mache aber nur noch mipsel muss meine Freizeit auch Aufteilen
                      Bin auch gespannt wie weit es geht, für das openaaf und openpli e2 macht ja max den sh4 diff also eine Anpassung sollte möglich sein.

                      Kommentar

                      Nicht konfiguriertes PHP-Modul

                      Einklappen

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

                      Einklappen
                      Lädt...
                      X