Hallo beisammen,
ich betreibe auf meiner ET9500 den MPD um Musik auf der Stereoanlage auszugeben.
Ich würde jetzt den MPD die Musik gerne über einen hochwertigen USB DAC (Audioquest Dragonfly) ausgeben lassen.
Ich habe den zwar noch nicht angeschafft, nehme aber an, dass ich dafür mindestens mal das snd-usb-audio Kernelmodul brauche.

Dieses ist wohl nicht aus dem Feed installierbar. (Oder gut versteckt, dann bitte Hinweis).

Um mir das Kernelmodul zu kompilieren brauche ich wohl 'ne Toolchain und die Kernelsourcen vom 3.8.7.
Im Web seh ich dazu den Wald vor lauter Bäumen nicht.

Es wäre super, wenn mit hier jemand kurz sagen könnte, was ich von wo benötige.

Auch wenn ich eigentlich Enigma selbst gar nicht kompilieren will, dennoch die Frage:
Ist das Build-Environment für OpenHDF eigentlich internes KnowHow oder kann man das irgendwo runterladen und nachlesen?

Vielen Dank!!

lg
eichhofener

Hi Koivo,

erstmal danke für Deine Antwort (hab mich vorher ja schon per Mausklick bedankt).
Ich habe demnächst ein bißchen Zeit dieses Projekt weiterzuverfolgen.

Bevor ich mir aber die Arbeit antu, das komplette HDF-Image zu übersetzen, von dem mich ja nur der Kernel interessiert vorab die Frage:

Wenn ich mit Bitbake usw. das Image baue, wird dabei denn auch der Kernel neu kompiliert?
Oder wird der einfach von irgendwoher (kernel.org?) kopiert?

Ich will ja nur ein kernel-modul kompilieren (evtl. auch kernel anpassen wg. support für kernel-modul.

Zusatzfrage: Wenn ich irgendwann einen passenden Kernel haben sollte, werde ich die Datei kernel.bin in einem vorhandenen HDF-Image ersetzen und flashen oder?
Laufe ich dabei Gefahr (wenn ich was falsch mache), mir den Bootloader zu zerschießen?

Vielen Dank vorab
~eichhofener

Hi Koivo,

danke nochmal.
Leider läuft es nicht ganz rund. Vielleicht hast Du eine Idee.

Ich verwende OpenSuse 13.1
Ich habe folgendermaßen begonnen:



Wenn Du zu Punkt 3 eine Idee hast, wärs super.
Oder habe ich mir evtl. die Daten aus dem git nicht richtig geholt ?!
(Evtl. alte Version ?)

Brauche ich evtl. (wg. Punkt 3) eine ganz bestimmte Version des gcc?
(Allerdings hatte ich den Eindruck, dass fürs Kompilieren eh' ein eigener gcc verwendet wird, und nicht der gcc
meiner OpenSuse Distro verwendet wird. Stimmt das?)

Vielen Dank für Deine Hilfe schonmal.
Liebe Grüße
eichhofener

PS: Ich habe das git https://github.com/henrylicious/enigma2 jetzt noch gar nicht verwendet, weil ich das so aufgefasst habe, dass es nur enigma2 umfasst und ich für die build-Umgebung erstmal das oe-alliance git brauche. Stimmt das?

Hallo Koivo (und alle anderen, die mir helfen mögen),

ich schreib mal ein Update meiner Bemühungen:

Ich bin nun schon viel weiter, nachdem ich mich einige Zeit in die Architektur des openembedded-builds und bitbake reingekniet habe.
Ich habe für alle bislang aufgelaufenen Probleme patches erstellt und in die bitbake recipes aufgenommen.
Unten habe ich mal alle notwendigen Fixes aufgelistet. Vielleicht hilft es jemandem, der den Build auch mit einer aktuellen Linux-Distro machen möchte.
(Bei Bedarf kann ich die Änderungen ja auch pushen).

"bitbake openhdf-image" läuft jetzt bis zum letzten task durch. Beim letzten Schritt "do_rootfs" kommt allerdings eine lange Latte von Fehlermeldungen.

Das Gute vorweg: Den Kernel konnte ich einwandfrei übersetzen und habe jetzt eine Version mit snd_usb_audio Support.
Ich werde den demnächst mal durch Austausch in einem fertigen Image testen.

Ich würde jetzt aber auch ganz gerne das komplette Image bauen können, und da habe ich noch Probleme.
Es ist mir schon klar, dass Du dich nicht um jeden Kram kümmern kannst, und ich knie mich schon selbst rein, aber ein Fingerzeig wäre schon klasse.

Ich verwende übrigens immer noch nur einen clone des oe-alliance git. Das enthält ja scheinbar auch schon enigma.
An welcher Stelle muss ich https://github.com/henrylicious/enigma2 verwenden?



Hier also mal ein Ausschnitte aus "build-enviroment/builds/openhdf/et9x00/tmp/work/et9x00-oe-linux/openhdf-image-531-20140120-r20140120172343/temp/log.do_rootfs":

erstmal kommen Warnings, die mir auch schon nicht koscher vorkommen...


dann kommts aber dicker:


Da schaue ich momentan noch nicht durch. Es wäre super, wenn Du mir einen Tipp geben könntest.
Vielen Dank,
eichhofener




PS:
Anbei eine Auflistung der Probleme, die bislang aufgetreten sind.
1. gettext
Das waren die stdio.h Probleme.
Ursache ist, dass einige GNU-libraries eigene Versionen der C Header-Files mitbringen, die nicht 100%ig zum gcc 4.8.1 passen.
-> per Patch des Headerfiles behoben

2. open-ssl
Enthält ein perl-skript, dass den shebang ("#!/bin/perl") in verschiedenen andern perl-Skripten auf einen eigenen Perl-Interpreter umbiegt.
Dieses initiale perl-Skript wird vom opensuse perl Interpreter ausgeführt. Dessen Version 5.18 kennt "find.pl" nicht mehr.
-> find.pl hinzugefügt, Verlinkung im recipe angepasst

3. open-ssl
Die pod-Files für die zugehörige perl-Dokumentation sind teilweise fehlerhaft. Die Übersetzung der pod-Files wird scheinbar auch von
opensuses perl Paket erledigt und dieses ist pingeliger als ältere Versionen. Ich hätte die Doku wohl auch ganz rausschmeißen können
-> per patch behoben

4. libav
Hier wird die Doku aus texi-Files erzeugt, die dann in pod-Files umgewandelt werden. Eines der texi-Files enthielt ein utf-8 Zeichen. Damit
kam der texi2pod Konverter nicht klar.
-> per patch behoben

5. openjade
Auch hier ein perl 5.18 Thema: Die getopts library gibt es nicht mehr und wurde durch das Modul Getopt::Std ersetz
-> per patch behoben

6. elfutils
gcc 4.8.1: Wohl ein Bug, den der Compiler erst jetzt anmeckert.
Es geht um eine Speicheranforderung per malloca.
sizeof(p) liefert jetzt tatsächlich den Platzbedarf des Pointers (4 Bytes) (früher evtl. Platzbedarf der Struktur?)
Der Kompiler meckert dies jedenfalls jetzt an. Gemeint war gewissermaßen sizeof(*p)
-> per patch behoben

7. gcc-4.6
Ein Fehler im Target-Compiler, der beim Übersetzen von libgcc2.c zuschlägt. Es geht um den Zugriff eines Iterators auf eine
Collection. Beim Test, bei dem herausgefunden wird, dass der Iterator über die Grenze der Collection hinausgeht, wird dennoch
auf das entsprechende Element zugegriffen. Das resultiert in einer Speicherverletzung, wegen der der Compiler dann abschmiert.
-> per patch behoben

vielen Dank schonmal für die Antwort.
Liest Henry hier mit?
Wie könnte ich ihn ggf. anfunken?

~eichhofener

Hi,
ich habe möglicherweise schon eine Erklärung gegoogled:

Zitat:


Also wieder eine OpenSuse Eigenart. Ich muss "tar --format=gnu" verwenden. Der tar Aufruf wird sich in irgendeiner bitbake *.bbclass Datei verstecken.
Ich lasse den build mal mit "-D -D -D" laufen. Vielleicht finde ich so heraus, welche Datei es ist.

~eichhofener

Sorry, ich gebe keine Ruhe.

Das Problem mit dem Bauen des Images wollte ich jetzt erstmal zurückstellen, und den Kernel, den ich kompiliert habe in ein
bestehendes OpenHDF Image reinkopieren.

Jetzt muss ich feststellen, dass mein Kernel unkomprimiert ist, der Kernel im Image muss aber komprimiert sein.
Scheinbar wird der Kernel erst beim Zusammenbauen des Image komprimiert ?!

Weiss jemand, wie der Befehl zum Komprimieren des Image lautet?

Vielen Dank
~eichhofener

Hi!

(wenns nervt, dass ich diesen Thread immer wieder nach vorne hole, bitte sagen, dann hör ich natürlich auf.)

Ich antworte mir einfach mal selbst:

1. Der Kernel wird einfach mit gzip -9 vmlinux gezippt. Ich hätte schwören können, dass da irgendein Entpacker-Stub davor muss. Ist aber nicht so.
   
2. Man kann den Kernel dann direkt von der Kommandozeile der Box flashen:
   flash_erase /dev/mtd1 0 0
   nandwrite -p /dev/mtd1 vmlinux.gz
   
3. Nach reboot kann man die Kernelmodule laden:
   insmod snd-hwdep.ko
   insmod snd-rawmidi.ko
   insmod snd-usbmidi-lib.ko
   insmod snd-usb-audio.ko
   
4. Eine angesteckte USB-Sound-Karte erscheint jetzt direkt unter /proc/asound als ALSA device. Um man kann es unmittelbar in der mpd.conf verwenden.
   Sehr cool.
   

Offener Punkt: Die USB-Soundkarte wird nur bis 44,1 kHz unterstützt (reicht mir allerdings).
Das ist aber kein Problem der Box, sondern ist auch unter Desktop Linux so. Offenbar ein allgemeines Problem des Linux Kernels.

Ich bin gegenwärtig sehr zufrieden.

lg
eichhofener