MPD und Buildroot

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich versuche über Buildroot (aktuelle Version) ein schlankes System zu bauen, das nur eine Aufgabe hat: einen MPD Server zu starten, der dann Internet-Radiostreams abspielt.
    Das Bauen des Systems funktioniert gut. Sowohl die Grundkonfiguration mit make raspberrypi_defconfig als auch die Netzeinbindung mit DHCP-Client, Root-Passwort und SSHD (allerdings nur openssh hat und nicht dropbear) funktioniert.

    Probleme bereitet mir mpd. Die generierte Version aus den aktuellen 0.19.9 sourcen zeigt nach einem mpd -V nur einen Bruchteil der Encoder, Decoder, Protokolle und PlugIns an. Selbst wenn ich alles im Buildroot Untermenü von mpd auswähle bleibt es bei einer Minimalinstallation. Die Kompilation erfolgt ohne Fehlermeldungen außer ich versuche die alsa-utils zu installieren. Unabhängig von dem alsa-utils Thema zeigt die Help-Übersicht zu mpd in Buildroot immer das Fehelen der Bibliothek br2_package_libiconv an, das sich laut Suchergebnis in Target packages > Libraries > Text and terminal handling befinden soll. Selbst wenn ich alle librariers aus text and terminal handling installiere, wird die libiconv immer noch als fehlend angezeigt. MPD startet nicht und gneriert auch kein log file. Ich komme nicht mehr weiter.

    Hat jemand hier Erfahrung mit Buildroot, Toolchain, Busybox usw. und kann mir helfen? Dann poste ich gerne weitere Konfigurationsangaben und Informationen.
    Jörg

  • Servus,
    ich kenne zwar das buildroot-Tool nicht, glaube aber, dass es an der Kernel-Konfiguration liegen könnte. Vermutlich muss da mehr an Schnittstellen resp. Adaptern aktiviert werden, als Du es durchgeführt hast. Ausserdem bin ich nicht sicher, ob dieses buildroot da das richtige Tool ist ...

    Was ich Dir empfehlen könnte wäre der -> ua-netinst <- ... mit dem kannst Du ganz einfach ein individuelles System aufsetzen und das, allein durch die Sicherung der Konfigurationsdatei, jederzeit reproduzierbar machen.

    Schau's Dir einfach mal an ... vielleicht bringt's Dir ja was ...

    cu,
    -ds-

  • Danke für den Hinweis auf die Alternative. Es ist mir nun mit meinen Werkzeugen gelungen:
    Es empfiehlt sich offensichtlich bei der Arbeit mit Buildroot nach ein paar Konfigurationsänderungen zunächst ein make clean vor einem erneuten make durchzuführen. Das verlängert zwar den Prozess der Erstellung eines neuen Kernels und Rootfilesystems deutlich, weil alle Paket neu geschrieben werden. Aber auf einem I7 als cross-compiler kann man damit leben.

    Im Ergebnis habe ich nun ein System, dass mir nach dem Einschalten bei einer DHCP-Konfiguration nach 8 Sekunden den ersten Ton liefert und bei einer festen IP sogar bereits nach 4,8 Sekunden. Das ist besser als erwartet!
    Noch zu lösende Probleme (für die Buildroot -Interessierten (und -Kenner):

    1) das Kernelmodul für snd_bcm2835 (der Soundchip) wird nicht automatisch geladen. Ich habe nun im MPD-Startskript /etc/init.d/S95mpd eine Zeile eingefügt, die das Modul mit modprobe snd_bcm2835 als erstes lädt.
    2) Wenn ich eine feste IP vergebe, kann ich mit MPD nicht mehr auf Internetstreams zugreifen, obwohl Gateway und Nameserver definiert sind. Merkwürdig...
    Das erste hängt vermutlich mit Buildroot zusammen das Zweite vielleicht eher mit der mpd.conf.
    Was das Eingangsproblem betriift, markiere ich diesen Thread mal als gelöst.
    Jörg

    Einmal editiert, zuletzt von JoergZ (12. August 2015 um 10:00)

  • Nachtrag 1:
    Problem 2 ist insofern gelöst, dass Buildroot auch bei Deaktivierung von dhcp einen Link /etc/resolv.conf -> /tmp/resolv.conf stehen lässt. Die /tmp/resolv.conf ist aber leer, weil dhcp abgeschaltet ist. Zur Zeit habe ich eine feste /etc/resolv.conf angelegt mit der Adresse meines Gateways. Innerhalb von Buildroot gibt es aber wohl die Skeleton Funktion, mit der ein rootfs angelegt wird, das vor der Übertragung auf die SD-Karte bearbeitet werden kann. Damit wird sich vermutlich auch mein Problem 1) lösen lassen.

  • Hallo JoergZ,

    Ich arbeite gerade an einem ähnlichen Projekt.
    Das Problem mit der snd-bcm2835 hab ich mit der init.d datei siehe unten gelöst. Dazu musste ich nur noch im inittab das script mit "::sysinit:/etc/init.d/S50snd-bcm2835 start" starten.

    Mein Problem ist gerade, dass der mdp server sich nicht starten lässt. "mpd socket: Failed to bind to '/var/lib/mpd/socket': No such file or directory"
    Hattest du das selbe Problem?

    lg

    Sebi

    #!/bin/sh
    #
    # Start audio driver

    case "$1" in
    start)
    echo -n "Starting audio driver snd-bcm2835: "
    modprobe snd-bcm2835
    echo "OK"
    ;;
    stop)
    echo -n "Stopping snd-bcm2835: "
    rmmod snd-bcm2835
    echo "OK"
    ;;
    restart|reload)
    ;;
    *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
    esac

    exit $?


    Nachtrag 1:
    Problem 2 ist insofern gelöst, dass Buildroot auch bei Deaktivierung von dhcp einen Link /etc/resolv.conf -> /tmp/resolv.conf stehen lässt. Die /tmp/resolv.conf ist aber leer, weil dhcp abgeschaltet ist. Zur Zeit habe ich eine feste /etc/resolv.conf angelegt mit der Adresse meines Gateways. Innerhalb von Buildroot gibt es aber wohl die Skeleton Funktion, mit der ein rootfs angelegt wird, das vor der Übertragung auf die SD-Karte bearbeitet werden kann. Damit wird sich vermutlich auch mein Problem 1) lösen lassen.

  • Bei mir gibt es keinen neuen Stand, wobei ich das Projekt nicht weiter verfolgt habe. Vor ein paar Wochen habe ich versucht, einen Kernel bzw. System für einen Raspberry Pi 3 zu bauen. Das lief aber aus nicht näher ermittelten Gründen weder besonders schnell und vor allem leider nicht stabil. Inzwischen habe ich ein Radio mit einer aktuellen Jessie lite Version auf einem Raspberry Pi 3 aufgesetzt. Der Vorteil ist, dass alles, was man braucht vorhanden ist bzw. in den entsprechenden Installationspaketen bereit gestellt wird. Der Nachteil: es wird auch jede Menge mit installiert (und gestartet) , was man nicht braucht. Das System ist dann aus dem Stand relativ flott, wobei ich mit fester IP für WLAN0 arbeite und das gesamte Netzwerk über systemd-Methoden starte. Gute Beschreibung dazu (Variante 5!) hier: http://www.elektronik-kompendium.de/sites/raspberry-pi/1912151.htm. Da mein Ausgangsziel nach wie vor ist, ein möglichst schnell startendes Radio zu haben, werde ich versuche, das weiter zu optimieren. Allerdings scheint es Aspekte zu geben, die man nicht steuern kann. So habe ich z. B. festgestellt, dass die Kernel-Ladezeiten um bis zu 3 Sekunden schwanken (zwischen 2,555 und 6,549 Sekunden). Das allein bedeutet eine entsprechend lange Verzögerung für das Abspielen des ersten Tones. Auch gibt es manchmal das Problem, dass MPD schon läuft, während das ALSA-Subsystem noch nicht bereit ist. Ich konzentriere mich zur Zeit eher auf diese Fehlerbeseitigung und Optimierungen.

  • Hallo tatoosh, wie lange dauert es denn bis zum login Prompt, bzw. bis der SSH-Server läuft nach dem Einschalten des Stroms? Im DietPi-Forum habe ich eine Vergleichstabelle mit Jessie Lite gefunden, laut der ein Pi 2 14,1 Sekunden braucht bis zum login Prompt. Dauert es wirklich so lang?

  • Hi JoergZ,
    es dauert wirklich ca. 30 Sekunden, bis aus meinem MPD ein ton kommt. Allerdings habe ich auch noch nicht alle performance Einstellungen gesetzt (hdmi off, cpu max etc - hier bin ich noch im Standard).
    Ich nutze zudem auch ein Pi ZeroW.
    Du nutzt aktuell Jessie light - schwanken hier deine Boot Werte immer noch?

    Ich hatte auf einem PiB mal http://www.runeaudio.com/ laufen. Unter Arch ist die Bootzeit deutlich besser gewesen, als Debian - aber ich kannte mich in der Umgebung zu wenig aus, zudem gibt es für das Projekt kaum noch Updates.

    Hast du ggf. noch andere Tipps?
    War das Basteln der Buildroot Umgebung zeitaufwendig?

    Gruß TaToosh

  • Hallo TaToosh,
    hab Karfreitag und heute mal mit Buildroot ein neues System mit mpd gebaut. Auf einem Pi 3 dauert es nun nach dem Einschalten 12,6 Sekunden bis der erste Ton kommt, bei einem reboot sind es sogar nur 8,8 Sekunden - ein paar Sekunden dauert es offensichtlich nach dem Einschalten des Stroms bis die Stromversorgung stabil ist und dann erst der Kernel geladen wird. Deshalb geht der reboot vermutlich fixer vonstatten.
    Das System ist noch nicht weiter optimiert, es nutzt zur Zeit noch DHCP für die IP-Numernvergabe. Mit fester IP lässt sich sicher noch einmal ein Sekündchen einsparen. Muss ich erst noch testen.
    Der Pi Zero wird vermutlich nicht so flott sein können, weil sein Prozessor nicht so leistungsfähig ist wie der im Pi 3.

    Zu deinen Fragen

    Zitat

    Du nutzt aktuell Jessie light - schwanken hier deine Boot Werte immer noch?


    In den letzten Tagen nicht mehr so stark. Ich weiß allerdings nicht, woran es liegt. Habe den Eindruck, dass nach einem Update es ein paar Bootvorgänge braucht, bis sich das System selbst optimiert hat - aber vielleicht ist das nur Voodoo ;)

    Zitat

    Unter Arch ist die Bootzeit deutlich besser gewesen

    Das ist gut möglich. Archlinuxarm bzw. Archlinux ist schon interessant, vor allem aktueller als Debian/Raspbian. Gutes Wiki in deutsch und englisch. Habe auch ein paar Projekte mit Archlinuxarm gemacht, war aber von Jessie lite dann so angetan, dass ich alle laufende System (zwei Radios, ein Videorecorder) alle auf Jessie lite aufgebaut habe.

    Zitat

    War das Basteln der Buildroot Umgebung zeitaufwendig?


    Jein. Mein Hostsystem ist auf einem i7, 4700 irgendwas-Generation mit 16 GB Arbeitsspeicher und Ubuntu 16.04 LTS. Beim ersten Mal dauert es immer lang, weil alle erforderlichen Quellcodes aus dem Internet gezogen werden müssen. Ich wohne auf dem Land, da ist die Bandbreite schon ein Thema :( .
    Das reine Kompilieren braucht bei mir rund 20 Minuten. Hier können eben alle 8 (virtuellen) Kerne des Prozessors beschäftigt werden, der Prozessorlüfter rauscht dann ein wenig - und das ist gut so :) . Wenn der Prozessor auf deinem Host-System aus einer anderen Klasse ist, z. B. i3 oder Pentium, dauert auch das Kompilieren länger, weil weniger Kerne zur Verfügung stehen.

    Für den Systembau empfehle ich dir schrittweise vorzugehen. Mach als erstes eine Kompilation mit den integrierten Standard-Konfigurationen. Hier ist beschrieben, wie du an die Vorkonfigurationen kommst:
    http://ltekieli.com/buildroot-with…-where-and-how/
    und
    https://www.raspberrypi.org/forums/viewtopic.php?f=75&t=89518

    In der Standardkonfiguration ist der SSH-Server bereits integriert. Du musst allerdings im Buildroot-Konfigurationssystem auch bei einer Standardkonfiguration ein root-Passwort setzen, sonst kommst du nicht rein.
    Wenn das System im Grundsatz läuft, kannst du anfangen, weitere Software-Packages (z. B. MPD und MPC, Alsa-Subsystem und -Tools, etc.) durch neue Buildroot-Konfigurationen nachzuinstallieren.

    Wichtig: Mach nach jedem (außer beim allerersten Mal) "make menuconfig" zunächst erst einmal ein "make clean" und dann erst wieder ein neues ein "make" (Den Parameter -j, der irgendwo zur Benutzung empfohlen wird. lass' besser weg.) Das "make clean" schreddert zwar alle bisherigen Kompilationen und alles muss neu kompiliert werden. Aber meine Erfahrung ist es, dass ein neues make ohne vorheriges make clean in der Regel nicht (stabil) läuft.
    Hier noch ein paar Links zu Buildroot:
    http://cellux.github.io/articles/diy-l…ildroot-part-1/

    und http://cellux.github.io/articles/diy-l…ildroot-part-2/ sowie http://www.elektronikpraxis.vogel.de/themen/embedde…rticles/173855/

    Versuch's einfach mal. Good luck!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!