[SPARK] Buildsystem-CS mit YAFFS2

[martii]

Ich habe mir mal die Freiheit genommen, vor ein paar Tagen die relevanten Repositories von Seife zu clonen und einige Änderungen und Ergänzungen einzubauen. Das meiste dürfte dem einen oder anderen vertraut erscheinen:

- Per Default wird ein YAFFS2-Image gebaut.
- Die 3D-Modi Side-by-Side/Top-Bottom/Tiled werden unterstützt
- Eine Handvoll Einstellmöglichkeiten für's OSD sind hinzugekommen
- Logos mit E2-Picon-Namen werden akzeptiert
- Infoviewer zeigt die korrekten Button-Bezeichnungen an
- Lautstärkeanhebung/-absenkung ist pro Audiokanal einstellbar
- GraphLCD (das Billig-LCD, das es bei Pearl gab) wird unterstützt
- HDMI-CEC ist ebenfalls integriert
- LED-Feedback beim Betätigen der Fernbedienung
- FreeSat und VIASat EPG werden unterstützt (auch MHWEPG, per Batchjob)
- AdZap (Werbezapper) ist mit drin
- OSD-Anzeige für PSI-Settings (Farbton, Kontrast, ...)

Plus diverse weitere Änderungen/Erweiterungen/Fehlerbehebungen/Kleinigkeiten, die nicht so offensichtlich sind (stm24_0210, anderes Input-Handling, yWeb, ...).

Das eine oder andere mag mainstream-geeignet sein. Einiges davon ist naturgemäß arg SPARK-spezifisch (z.B. das 3D-Handling) oder mangels anderer Testmöglichkeit eben nur auf SPARK getestet.

GIT-Links siehe "Personal Clones" bei Gitorious.

[schufti]

Hallo martii!

das gibt generell mal ein für deinen Einsatz!

Ich werde demnächst versuchen, mir daraus ein "Image" für Testzwecke zu bauen, auch wenn ich es nur auf USB testen werde (was bei pinkys evolux immer Patcherei bedeutet hat).

ist die alsa Geschichte für Spark kompat. Lautstärke auch drin?

btw: Im evolux - das ja auch aus seifes git gecloned wurde - hat das Menü-fading ja nie funktioniert; ist das in deinem jetzigen Clone auch so? Kann man das ev. fixen oder ist das ein Sideeffect der "Erweiterungen"?

nochmals vielen Dank!

P.S.: schon mal einen Richtwert für die Bootzeit (Knopfdruck bis erstes Bild)?

P.P.S.: es hat ja immer geheissen, dass BER-Anzeige bei den SH4 nicht möglich ist. Unlängst hatten wir hier ein Gewitter wo das Signal (fast) ganz weg war, da hat plötzlich die BER Anzeige doch Werte zwischen 100 und ca. 80000 angezeigt. Kann es sein, dass bloß das Format / die Skalierung nicht passt?

[martii]

Hi,

Ich werde demnächst versuchen, mir daraus ein "Image" für Testzwecke zu bauen, auch wenn ich es nur auf USB testen werde (was bei pinkys evolux immer Patcherei bedeutet hat).

Boot von USB sollte gehen. Dass der Boot bei YAFFS2 ohne Änderung der Bootargumente läuft, hat aber leider zur Konsequenz, dass der Kernel kein JFFS2 mehr bootet.

ist die alsa Geschichte für Spark kompat. Lautstärke auch drin?

Ja, ist ja "nur" der amixer-Aufruf. Aktuell fehlt, im Vergleich zu meine Anpassungen für Evolux, nur noch WLAN-Support (das ist wg. wpa_supplicant etwas aufwendig).

btw: Im evolux - das ja auch aus seifes git gecloned wurde - hat das Menü-fading ja nie funktioniert; ist das in deinem jetzigen Clone auch so? Kann man das ev. fixen oder ist das ein Sideeffect der "Erweiterungen"?

Echt? An dem Code habe auch bei Evo nichts bewusst geändert. Im aktuellen Clone tut's, eben getestet.

P.S.: schon mal einen Richtwert für die Bootzeit (Knopfdruck bis erstes Bild)?

39 Sekunden vom Deep Standby bis ARD HD. Kommt mir rein subjektiv zu lange vor, aber evtl. gibt es da ja noch Optimierungspotenzial. Der Kernel ist ziemlich flott da, die Module scheinen dann etwas zu dauern. Mal schauen.

P.P.S.: es hat ja immer geheissen, dass BER-Anzeige bei den SH4 nicht möglich ist. Unlängst hatten wir hier ein Gewitter wo das Signal (fast) ganz weg war, da hat plötzlich die BER Anzeige doch Werte zwischen 100 und ca. 80000 angezeigt. Kann es sein, dass bloß das Format / die Skalierung nicht passt?

War mir auch aufgefallen (aber ich hatte auch schon mal das Sat-Kabel gezogen, um zu sehen, ob sich da was tut). Die Werte werden vom Tuner gelesen, und die einzige Doku ich ich dazu gefunden habe, sind die Sourcen. Ohne Beschreibung der Register stochert man da im Dunkeln.

[Tann]

Jffs2 kann das auch gebaut werden? weil 4 sek Bootunterschied sind nicht wichtig

[martii]

Jffs2 kann das auch gebaut werden? weil 4 sek Bootunterschied sind nicht wichtig

Dachte ich mir dann gestern auch. Ja, in make/environment.mk ROOTFS_TYPE auf "default" setzen, oder beim make ROOTFS_TYPE=default mit angeben. Getestet hab ich das aber nicht.

[schufti]

ich denke, den Hauptanteil an der flotten Bootzeit beim evo war dem Umstand geschuldet, dass viels im rcS asynchron gelaufen ist, was dann auch schon mal unschöne Nebeneffekte hatte...

ich denke, mit entsprechenden Kerneloptionen für yaffs2/jffs2/etc Build ist das kein Problem.
man könnte den Bootparam rootfs ja nicht einfach nur rauslöschen sondern nach Buildtyp setzen. Beim aktuellen Kernelzweig ja sogar sauber per Kernelkonfig... (oder ist das jetzt eh sauberer gelöst)

Bei mir braucht altes evo (Neutrino-HD+E2) mit yaffs2 im flash 26s vom Druck auf Power in deep standby bis erstes Bild in Neutrino-HD 26sek, allerdings mit synchronem mount von nfs (statt automount in Neutrino-HD, da waren es ein paar s weniger).

[mohousch]

Der Unterschied in der Bootzeit zwischen Evolux (tdt basis) und Images aus dem seifes Repo liegt es auch noch in den Devices-Nodes und die das laden der Module:
- im seifes /dev ist tmpfs und die Nodes werden bei hoch fahren angelegt im gegensatz zu evolux die sind immer da ausser bei der ersten Boot.

- Depmod sucht erst mach den Modulen im gegensatz insmod lädet das Module wie es im Pfad gegeben ist und erstellt keine Module.conf

[schufti]

gegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)

Und auch nicht wirklich gegen insmod, die mögliche und sinnvolle HW ist ja relativ übersichtlich, wenn man nicht jeden billigst WLAN Stick unterstützen will, aber das ist natürlich Geschmacksache (und unerheblich solange WLAN sowieso aussen vor ist). Wobei ich da ja dann schon die UMTS Lösung bevorzuge; damit wäre das Ding optimal fürs Camping

wobei die Unübersichtlichkeit des evo Startup ist wohl ungeschlagen, da ist das Standardsystem (wie bei seife build) ja mustergültig; wenn auch ev. nen Ticken langsamer...

P.S.: falls es noch so Arme gibt, die wie ich oft durch proxy arbeiten müssen:
wesentlich besser als graphlcd-base-touchcol über git clone in einer bestimmten Version zu holen, wäre es per wget gleich das passende Archiv zu holen: http://projects.vdr-developer.org/git/g ... 02b.tar.gz

P.P.S.: im Makefile von CEC ist ein endif auskommentiert, das aber gebraucht wird. k.A. ob das von upstream kommt...

[mohousch]

gegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)

Und auch nicht wirklich gegen insmod

nein dagegen spricht ja nichts, sind nur schneller als das andere

[martii]

wesentlich besser als graphlcd-base-touchcol über git clone in einer bestimmten Version zu holen, wäre es per wget gleich das passende Archiv zu holen: http://projects.vdr-developer.org/git/g ... 02b.tar.gz

P.P.S.: im Makefile von CEC ist ein endif auskommentiert, das aber gebraucht wird. k.A. ob das von upstream kommt...

Beides angepasst, danke!

[martii]

gegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)

Und auch nicht wirklich gegen insmod

nein dagegen spricht ja nichts, sind nur schneller als das andere

Ich habe da mal ein bisschen experimentiert. Beim Boot ist nach grob 10 Sekunden der Kernel da, das Laden der Module dauert dann bis zu 20 Sekunden. Insmod statt modprobe hilft da leider auch nicht, das sind auch nur Sekundenbruchteile, die da potenziell gespart werden.

Ein vorgefertigtes /dev/ im Image wäre jedenfalls unschön. Man könnte das bestenfalls beim ersten Boot auf der Kiste selbst erzeugen. Beim Bauen ist das ungeschickt, da man dann als root auf dem Host die Devices erzeugen muss. Das passt so schon, wie Seife das handhabt.

Falls jemand eine funktionierende Idee zur Parallelisierung des Ladens der Kernel-Module hat, greife ich die freilich auch gerne auf.

[seife]

Das modulladen wird nicht schneller beim parallelisieren, weil der kernel immer nur ein Modul gleichzeitig einfügen kann.

Man müsste die Treiber fixen, dass sie schneller initialisieren bzw. asynchron im hintergrund (nach dem init_module() wieder beendet ist) die Hardware suchen und finden. Aber die bugs die man sich damit potenziell reinzieht will man eigentlich nicht haben. Einige Treiber machen das übrigens schon -- typischerweise welche die im mainline kernel sind, uinput z.B. IIRC -- deswegen muss man dann auch warten, bis das device da ist.

Und als ich das dynamische dev vs. statisches dev letztes mal benchmarked habe, hat es weniger als 1 Sekunde ausgemacht. Evtl. könnte man "richtiges" udev statt mdev nehmen, weil das eher weniger overhead hat, aber das ist halt auch wieder komplizierter und das dann für ein oder 2 Sekunden bootzeit? Das war's mir nicht wert.

Interessant ist das asynchrone laden der Firmware in die beiden ST40, wieviel macht das aus?

[martii]

Interessant ist das asynchrone laden der Firmware in die beiden ST40, wieviel macht das aus?

Leider auch nur ca. 2 Sekunden, also kaum der Rede wert.

[seife]

Das hatte ich befürchtet. Das problem ist, dass das alles sachen sind, die zentrale infrastruktur im chip (firmware laden) oder kernel (module einfügen) benötigen und deswegen schlecht parallelisierbar sind. Man müsste wirklich die Treiber auf delays untersuchen und unnötige rausmachen. Aber ohne genaue Hardwaredoku ist das halt sehr aufwändig. Und auch mit ist es viel Arbeit. Die dort investierte Zeit werden wir mit schneller booten niemals einsparen

[schufti]

aber ev. kann man die video/audio fw parallel zu den Modulen laden, das sollte sich nicht ins Gehege kommen. Und wenn parallel dazu das netzwerk gestartet werden kann, ist auch wieder was gespart.

habe aber jetzt nicht geschaut, wie weit das ev. schon geschieht ...

[seife]

Du kommst immer an einen Punkt, wo die haupt-cpu nichts anderes gleichzeitig machen kann, und das de-facto sowieso serialisiert ist. Ich vermute, sowas wie "firmware in den ST40 schieben" gehört in diese Abteilung. "Modul einfügen" genauso. Während "init_module()" läuft, läuft im Kernel nicht viel anderes. Zumindest nicht, wenn du nur eine CPU hast...

[schufti]

hmmm, ich hatte gehofft, dass die Warteschleifen in der Modulinitialisierung etwas "kooperativer" sind und dem fw-Loader etwas Luft lassen würden ... bei 20Sek für eine Handvoll Module ....

[seife]

init_module ist IIRC unter dem BKL, zumindest im relativ antiken 2.6.32er noch -> wärenddessen geht gar nichts.

Und wenn du dir die player2 etc. mal anschaust, dann wundert dich gar nichts mehr, schon gar nicht dass die lange laden...

[schufti]

habe gerade von nem jffs2 (+sumtool) user gelesen, dass dort von Netzschalter Ein bis Bild auch 39sec vergehen (38sec aus deep standby).
Waren die 39sek am Threadbeginn auf yaffs2 bezogen? Dann wäre es witzlos die Leute mit yaffs2 zu quälen...

P.S.: mit 40sec dauerts vom USB-Stick auch nicht viel länger ...

[schufti]

kann jetzt nicht sagen obs ein generelles oder nur ein martii Problem ist, aber wenn ich auf einen Sender zappe, der nur DD Ton hat, gibts meist nur Stille....

Bei einem mit mehreren Tonspuren (wo nur zuletzt DD verwendet wurde) hilft Tonkanal wechseln DD-stereo-DD und Ton ist wieder da ...

habe DD on HDMI force und DD on SPDIF on

[plux7887]

Entspricht das dem Neutrino-HD2 aus dem EVO Triple Image?
Läüft das auf dem Edision Argus Pingulux?

[schufti]

nein, das entspricht (basiert auf seifes git + martiis Änderungen für spark) dem Neutrino-HD aus dem triple.
ja, sollte laufen.

@martii:
ich denke, in packages.mk sollte es mtd-utils statt mtd-tools heissen?
irgendwo zickt es noch, da keine jfffs2 Dinge im img landen...
hat es seine Richtigkeit damit, dass die dropbear und xfs Sachen unter /opt/pkg... landen?

ansonsten: super Arbeit!

[seife]

Das /opt/pkg ist historisch so, weil es auch mal auf Boxen laufen sollte, die nicht soviel Flash haben (nur 32MB z.B.)
Deswegen habe ich damals die optionalen Pakete (oder besonders grosse...) nach /opt/pkg installiert, dorthin hätte man z.B. einen USB-Stick mounten können.
Ist mit heutigen Boxen eher nicht mehr notwendig.

[schufti]

im Prinzip wird ja auch der Pfad darauf erweitert, aber für libs sehe ich mit leerer ldso.conf schwarz

und andere Pakete (alsa, e2fs-tools) landen ja auch an "üblicher" Stelle

[seife]

die ld.so.conf wird ja bei mir auch erweitert. Wenn nicht ist das ein bug im jeweiligen postinst skript.