[SPARK] Buildsystem-CS mit YAFFS2

Fremd-Buildsysteme
martii
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

[SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von schufti »

Hallo martii!

das gibt generell mal ein :up: 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
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von martii »

Hi,
schufti hat geschrieben: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
Einsteiger
Einsteiger
Beiträge: 101
Registriert: Dienstag 6. März 2012, 13:24

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von Tann »

Jffs2 kann das auch gebaut werden? weil 4 sek Bootunterschied sind nicht wichtig
martii
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von martii »

Tann hat geschrieben: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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 362
Registriert: Mittwoch 14. Dezember 2005, 03:25

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 362
Registriert: Mittwoch 14. Dezember 2005, 03:25

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von martii »

schufti hat geschrieben: 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
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von martii »

mohousch hat geschrieben:
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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 217
Registriert: Donnerstag 14. Juni 2012, 09:39

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von martii »

seife hat geschrieben: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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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 ...
Zuletzt geändert von schufti am Dienstag 17. Juli 2012, 22:55, insgesamt 1-mal geändert.
schufti
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Interessierter
Interessierter
Beiträge: 67
Registriert: Dienstag 17. Juli 2012, 23:26

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von plux7887 »

Entspricht das dem Neutrino-HD2 aus dem EVO Triple Image?
Läüft das auf dem Edision Argus Pingulux?
schufti
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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: :up: super Arbeit!
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Einsteiger
Einsteiger
Beiträge: 352
Registriert: Freitag 20. August 2004, 23:33

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von 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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: [SPARK] Buildsystem-CS mit YAFFS2

Beitrag von seife »

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