Gedimmtes LCD bleibt dunkel nach Telnet halt

[rhabarber1848]

Hi,

Neutrino, LCD-Dimmtimeout != 0, LCD ist dunkel
Telnet-Login, dort den Befehl halt ausgeführt.
Beim Neustart der Box bleibt das LCD-Display dunkel,
bis Neutrino geladen ist, sogar die Debug- und Uboot-
Meldungen werden nicht angezeigt.

Folgender Patch implementiert in Neutrino Signal-
Handler, welche das LCD-Display wieder aufwachen
lassen, obiges Problem ist damit gelöst.

neutrino_lcdwakeup.diff

Irgendwelche Einwände?

The system is going down NOW!
Sending SIGTERM to all processes
[yhttpd] !!! SIGNAL !!! :15!
[yhttpd] No special SIGNAL-Handler:15!
[yhttpd] stop requested......
[neutrino] received signal, waking-up LCD...
[neutrino] received signal, waking-up LCD...
[neutrino] received signal, waking-up LCD...
Sending SIGKILL to all processes
Requesting system halt

[rhabarber1848]

PS: Nein, ich hatte keine Lust, switch/case zu coden, damit der Signaltyp angezeigt wird

[seife]

Würde man nicht besser dem U-Boot beibringen, das LCD einzuschalten?

Das funktioniert zwar, aber kommt mir irgendwie vor als wäre es an der falschen Stelle...

[rhabarber1848]

Würde man nicht besser dem U-Boot beibringen, das LCD einzuschalten?

Das funktioniert zwar, aber kommt mir irgendwie vor als wäre es an der falschen Stelle...

Dann würde man aber immer noch nicht die Debugmeldungen
der Dbox sehen können. Neutrino schaltet das Display ab und
sollte es beim Beenden wieder einschalten, soweit mein Gedanke.

Ich habe auch versucht, den Kerneltreiber beim Entladen das
Display wieder einschalten zu lassen, leider scheint das Modul
beim Herunterfahren nicht entladen zu werden.

[seife]

Dann würde ich es in die exit-routine einbauen. Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.

Wer per "halt" runterfährt, sollte wissen, was er tut

[rhabarber1848]

Dann würde ich es in die exit-routine einbauen.

Wenn ich das richtig sehe, wird CNeutrinoApp::ExitRun nicht
aufgerufen, wenn die Box per halt heruntergefahren wird.

Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.

Sie werden in tuxcald, tuxmaild, timerd, yhttpd, controld und zapit
bereits genutzt, hast Du dort Probleme feststellen können?

Wer per "halt" runterfährt, sollte wissen, was er tut

Ich habe nicht immer die FB zur Hand, wenn ich die Box herunterfahre,
um ein Yadd zu testen. Die Sagem-Dbox sendet keinen Bootp-Request
beim Warmstart. Während die Box per halt herunterfährt, suche ich
die FB zum Wiedereinschalten, nur bleibt dabei halt oft das LCD dunkel.

Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.

[seife]

Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.

Sie werden in tuxcald, tuxmaild, timerd, yhttpd, controld und zapit
bereits genutzt, hast Du dort Probleme feststellen können?

Nein, aber die führen z.B. keine skript-plugins aus. Das müsste man halt ausführlich testen. Aber du hast natürlich recht, einen Versuch ists wert.

Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.

Dort gehört's IMHO eigentlich hin (weil der bootloader sollte die Hardware so initialisieren, dass sie in einem definierten Ausgangszustand ist). Andererseits sollten wir keinen unnötigen Stress deswegen Veranstalten

[Liontamer]

Ein Workaround wäre, statt 'halt' ein 'rcsim KEY_POWER' zu benutzen. (evtl. auch über ein script)

[racker]

Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.

Hi,
das ist eigentlich das Interessante an diesem Verhalten,
u-boot resettet das Display, schaltet es ein und initialisiert es.

Btw sollte ein Programm die Hardware nicht in einem undefinierten Zustand hinterlassen.
=> Die Lösung mit Signalhandler gefällt mir ganz gut.

Gruß

[seife]

dann geht es aber mit "reboot -f" immer noch nicht

[racker]

dann geht es aber mit "reboot -f" immer noch nicht

Was beweist, dass wir 2 Baustellen haben

Gruß

[rhabarber1848]

u-boot resettet das Display, schaltet es ein und initialisiert es.

Punkt 2 geschieht bei mir eben nicht. Kann eigentlich jemand
anderes das von mir geschilderte Verhalten reproduzieren?

[seife]

reicht das evtl. schon?

Code: Alles auswählen

Index: lcd.c
===================================================================
RCS file: /cvs/tuxbox/boot/u-boot-tuxbox/board/dbox2/lcd.c,v
retrieving revision 1.3
diff -u -p -r1.3 lcd.c
--- lcd.c       14 Feb 2005 16:35:32 -0000      1.3
+++ lcd.c       10 Mar 2009 10:48:30 -0000
@@ -276,7 +276,7 @@ static void lcd_reset_init (void)

        lcd_send_cmd (LCD_CMD_ON, 1);
        lcd_send_cmd (LCD_CMD_RES, 7);
-       lcd_send_cmd (LCD_CMD_SRV, 1);
+       lcd_send_cmd (LCD_CMD_SRV, 0);
        lcd_send_cmd (0x00, lcd_contrast);

        switch (hwi[0])

Das ist auf die schnelle der grösste unterschied zwischen der linux-treiber initialisierung und der im u-boot.
Interessant wäre auch, ob das LCD an geht, wenn der treiber geladen wird, oder wenn neutrino startet.
Test-boote doch evtl. mal ohne neutrino-autostart (oder mach ein "sleep 10" in die start_neutrino), damit du das feststellen kannst.

[rhabarber1848]

reicht das evtl. schon?

Nein.

Interessant wäre auch, ob das LCD an geht, wenn der treiber geladen wird, oder wenn neutrino startet.

Erst Neutrino aktiviert das Display.

Ich habe auch den Fall "reboot -f" getestet. Wenn das LCD aus war
startet "reboot -f" die Box neu und das LCD-Display ist aktiv. Die
Debug-Meldungen werden angezeigt, aber kein Bootp-Request
abgesetzt, die Box bootet also aus dem Flash.

Hier der Vergleich dessen, wie sich meine Sagem-Box verhält:

reboot -f: kein Bootp-Request, LCD wird wieder eingeschaltet
halt/Einschalten über FB: Bootp-Request, LCD bleibt dunkel, sofern es ausgeschaltet war

Interessant wäre das Verhalten der Nokia- und Philips-Boxen.

Hier scheint also der Dbox-interne Code einige Defizite zu haben,
die vom Tuxbox-Code nicht behoben werden.

Weder Dein U-Boot-Patch, noch das LCD-Kernel-Modul sind in der
Lage, ein ausgeschaltetes LCD-Display wieder einzuschalten, nur
Neutrino (Enigma nicht getestet) macht das.

Ich schau noch mal weiter...

[rhabarber1848]

Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.

Du hast Recht, ich hatte jetzt schon mehrfach die Situation,
dass ich Neutrino mit kill nicht beenden konnte, es erschien
mehrfach die Logmeldung meines Patches

received signal, waking-up LCD...

aber Neutrino lief weiter. Dabei war es egal, ob ich die
Haupt-PID, alle PIDs (kill w x y z) oder "killall neutrino"
aufgerufen habe. Nur kill -9 funktionierte noch...

Ich habe den Patch daher aus dem ULC entfernt und poste
ihn hier zu Dokumentationszwecken. Für mich ist das
Thema erstmal erledigt.

Code: Alles auswählen

--- ../cvs/apps/tuxbox/neutrino/src/neutrino.cpp        2009-02-22 19:45:44.000000000 +0100
+++ ./apps/tuxbox/neutrino/src/neutrino.cpp     2009-03-04 20:52:47.000000000 +0100
@@ -1935,6 +1935,13 @@
        }
 }

+static void signalHandler(int /*signum*/)
+{
+       // turn on LCD display
+       dprintf(DEBUG_NORMAL, "received signal, waking-up LCD...\n");
+       CLCD::getInstance()->wake_up();
+}
+
 int CNeutrinoApp::run(int argc, char **argv)
 {
        CmdParser(argc, argv);
@@ -2241,6 +2248,12 @@

        execute_start_file(NEUTRINO_INIT_END_SCRIPT, false);

+        //catch all signals
+        signal(SIGHUP, signalHandler);
+        signal(SIGINT, signalHandler);
+        signal(SIGQUIT, signalHandler);
+        signal(SIGTERM, signalHandler);
+
        RealRun(mainMenu);

        ExitRun(true);

[seife]

Wir könnten ein "aufräum-Binary", das das Frontend in standby schickt, das LCD wieder anmacht etc. basteln, was dann beim shutdown aufgerufen wird.
Schreib's mal jemand auf meine Liste

[Barf]

Habe den Thread erst neulich entdeckt,...

Das das System nach einem unsauberes "runterfahren" (wie z.B. halt) in einem "komischen" Zustand sich befindet finde ich (normalerweise) nicht ein Problem, dass eine Lösung erfordert. Insbesonderes kein Hack.

Unabhängig davon halte ich eine vernünftige signal handling in Neutrino für sehr wünschenswert. Dabei soll, bei den normalen, "beende-dich"-Typ Signale, Neutrino so sich verhalten wie man es erwartet, d.h., nach Aufräumarbeiten sich beenden. Wegen

Code: Alles auswählen

until neutrino -f -u ; do

(start_neutrino) sogar mit (am mindestens für ein Signal) exitstatus 0. (In rhabarber1848s Signalhandler sollte also ExitRun aufgerufen werden.)

Danach könnte man ein einfaches shutdown Kommando implementiern z.B. als

Code: Alles auswählen

#!/bin/sh

if [ $1 = "s" ] ; then
    touch /tmp/.nohalt
elif [ $1 = "-r" ] ; then
    touch /tmp/.reboot
fi

killall -HUP neutrino

um ein sauberes Runterfahren von der Shell zu implementieren. Dies haben wir z.Z.nicht!!!

[rhabarber1848]

Durch lcdcmd (Quelle) bin ich wieder auf das Thema gestoßen.

Wenn in einem Yadd "lcdcmd -on" vor lcdmenu in /etc/init.d/start steht,
wird das LCD-Display korrekt wiedereingeschaltet. lcdcmd sendet dazu
zwei Befehle, LCD_IOCTL_ON an /dev/dbox/lcd0 und FP_IOCTL_LCD_DIMM
an den Frontprozessor /dev/dbox/fp0. Das ist wahrscheinlich die Erklärung,
warum U-Boot alleine mit Befehlen an das LCD nicht funktionierte, das
Display war mittels Frontprozessor gedimmt.

Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?
Falls nicht, dann reicht dieser positiv getestete Patch im FP-Kernelmodul,
der den Dimm-Modus deaktiviert: fp_lcd_init.diff
Der Wert 150 stammt aus lcdcmd.c, der Befehl ist aus "case FP_IOCTL_LCD_DIMM"
in dbox2_fp_core.c entnommen.

Eine andere Methode im Userspace wäre mittels liblcddisplay: lcd_poweron.diff

[rhabarber1848]

Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?

Kann das jemand beantworten? Falls das möglich wäre,
könnte man dann auch die Tasten am Gerät auslesen,
um z.B. den Bootvorgang wahlweise von HDD oder aus
dem Flash auszuführen?

Falls nicht, dann reicht dieser positiv getestete Patch im FP-Kernelmodul,
der den Dimm-Modus deaktiviert: fp_lcd_init.diff

Das gleiche, positiv getestet, für Kernel 2.6: fp_lcd_init26.diff

[seife]

Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?

Kann das jemand beantworten?

Der u-boot kann das (noch) nicht, es gibt keinen Frontprozessor-Treiber.

Falls das möglich wäre,
könnte man dann auch die Tasten am Gerät auslesen,
um z.B. den Bootvorgang wahlweise von HDD oder aus
dem Flash auszuführen?

Ja, das hätte ich auch gern, das schau ich mir auch mal an, ich weiss nur noch nicht, wann.

[rhabarber1848]

und FP_IOCTL_LCD_DIMM
an den Frontprozessor /dev/dbox/fp0. Das ist wahrscheinlich die Erklärung,
warum U-Boot alleine mit Befehlen an das LCD nicht funktionierte, das
Display war mittels Frontprozessor gedimmt.

Patches für Kernel 2.4 und 2.6 committed:
http://article.gmane.org/gmane.comp.vid ... ox.scm/732
http://article.gmane.org/gmane.comp.vid ... ox.scm/733