Folgende Veraussetzungen:
- GH board
- PSP LCD von Sharp + Hantouch Touchpanel
- AVR32 Buildroot 2.3.0 mit GH patch und extended-defconf
- Anpassungen im Kernel: fb console
Problembeschreibung:
Beim Booten erscheint wie eingestellt die Console bis 'freeing init
memory ...' auf dem lcd (inkl. Bootpinguin).
Wenn das System bis zum Prompt gestartet ist gebe ich dort z.b.
ts_calibrate ein um den Touchscreen zu kalibrieren (hier erscheinen
übrigens keine 'Touch-Targets' auf dem LCD, aber das ist wohl ein
anderes Thema).
Nach dem Beenden des Programms sollte die console wieder zurück in den
TEXT_MODE schalten und einen Refresh für den Inhalt durchführen.
Hierbei scheint sich in der Funktion fbdev_blank im fbcon Treiber ein
Fehler zu befinden, der die Ausgabe des LCD durcheinander bringt. Es
erscheint meist ein komplett weisses Bild auf dem LCD.
Nach nochmaligem Start und beenden von ts_calibrate kommt es oft vor,
dass die Ausgabe wieder korrekt erscheint. -> Also fast 1:1
alternierend.
Ein ähnliches Verhalten zeigt sich z.b. bei eingabe von 'reboot' um den
GH neu zu booten. Bei jedem zweiten mal kann ich somit nichts auf dem
LCD sehen.
Meine Untersuchungen gingen wie bereits erwähnt bis hin zur Methode
fbdev_blank im fbcon Treiber. Dort wird mit FB_ACTIVATE_FORCE ein
zurückholen und neu laden der Framebuffer Ausgabe erzwungen (auch wenn
ursprünglich nicht nötig). Wenn dort nur auf FB_ACTIVATE_NOW reduziert
wird, bleiben die Fehler beim starten einer FB-Anwendung und Beenden
jeniger aus. Allerdings das Problem beim Reboot bleibt weiterhin
bestehen.
Hat jemand bereits ähnliche Erfahrungen gemacht und gar eine Lösung
dafür gefunden?
Robert.
Hallo,
ich habe die gleichen Vorraussetzungen wie du, nur keinen Touchscreen.
Mein Problem ist ähnlich:
Sobald ich boote, erscheint der Pinguin und das AVR32 Logo (Wie bekomme
ich das weg?). Allerdings erscheint kein Consolentext, obwohl ich die
fb-console im Kernel aktiviert habe. (Es wäre nett wenn du mir erläutern
könntest, wie du es geschafft hast)
Wenn ich jetzt ein Programm wie fbplasma starte, funktioniert das
Display problemlos.
Aber wenn ich es etwa 5-10 Minuten ohne Aktivität laufen lasse, wird es
plötzlich schwarz. Danach reagiert es auf kein Programm mehr. Wenn ich
"reboot" eingebe, oder den Reset Taster drücke, wird es weiss, wie bei
dir. Damit es wieder etwas anzeigt, muss ich noch ein paar mal Resetten
oder den Strom ab/anstellen.
Aufgefallen ist mir auch noch, dass wenn ich den mPlayer mit einem Video
starte, der Screen schwarz bleibt und nicht mehr reagiert. (Genau so wie
oben wenn er 5 Minuten inaktiv bleibt).
Ob es mir dieser fbdev_blank-Funktion zusammenhängt kann ich nicht
beurteilen. Zumindest in meinem Fall scheint es mir eher
unwahrscheinlich.
Dan
Die Konsole auf dem TFT hatte ich damals deaktiviert, da sie bei mir nie
so richtig funktioniert hat.
Es kann sein, dass wenn sich die Konsole nach Zeit deaktiviert, dadurch
evtl. Fehler bei der Anzeige erzeugt.
Ich gehe immer mit putty über USB oder Netzwerk rein. Vorteil: es lassen
sich mehrere Konsolen öffnen.
Gruß
Udo
@ Dan:
Den Pinguin kannst du im config für den Kernel deaktiviern: Bootlogo
deaktivieren (hat nichts mit den Splashimages zu tun, die per fbv
während der rcinit geladen werden).
Die Console auf den fb zu leiten geschieht mithilfe von entsprechenden
Bootargs in uBoot: console=tty0 statt console=ttyS0. Dann kann man auch
z.B. durch anschliessen einer PS/2 Tastatur und vorheriger
entsprechender Konfiguration im Kernel bzw. setup.c die Konsole auf dem
framebuffer direkt bedienen. Dafür ist es evtl. sinnvoll in /etc/inittab
einen Eintrag für ein getty auf die console zu ergänzen oder einfach
analog zum Eintrag für die shell console auf ttyS0 eine für tty0 zu
ergänzen -> keine Anmeldung erforderlich.
Schliesslich versteht man hier dann auch das Problem mit dem 'Schwarz
werdenden' LCD. Das ist nichts anderes als ein sehr simpler
Bildschirmschoner, der auch bei x86 Systemen standardmässig aktiv ist,
nur hier weniger auffällt, da man meist direkt über die console am
Monitor arbeitet. Will heissen, wenn man nun über die shell auf der
console Programme startet, wird nicht abgedunkelt. Bzw. wenn man länger
wartet aktiviert sich der Bildschirmschoner und über einen Tastendruck
auf dem PS/2 Keyboard kann man den LCD wieder 'reaktivieren'. Wo man das
Verhalten umkonfiguriert müsst ich jetzt erst wieder nachforschen.
Im Betrieb mit mPlayer sollte aber zumindest ebenfalls die ersten 5
Minuten eine Anzeige erscheinen. War dem nicht so? Hast du fbdev2 als
video output genutzt?
Dein beschriebenes Problem beim Reboot deckt sich aber schliesslich
genau mit meinen Erfahrungen. Und hier denke ich ist noch an einer
anderen Stelle etwas faul, vlt. auch mit einem überzähligen
FB_ACTIVATE_FORCE. Bin noch nicht wirklich weiter gekommen. Oftmals ist
es so, dass bei komplett weissem LCD ein fbset -depth 24 hilft um die
Anzeige wieder zu korrigieren. Aber leider nicht prinzipiell -> also
nicht als Workaround geeignet.
@ Udo:
Leider hat das Problem mit der Nutzung der Console auf fb devices nichts
zu tun, da dann schliesslich das Problem spätestens beim reboot wieder
auftritt.
Habe übrigens herausgefunden warum mein Touchpanal bei QT Anwendungen
nicht funktionieren wollte: Man muss QWS_MOUSE_PROTO mit den
entsprechenden Einstellungen exportieren. In meinem konkreten Fall also:
1
exportQWS_MOUSE_PROTO=Tslib:/dev/input/event0
(man achte auf gross/KLEIN Schreibung)
Mit Hilfe von QT-Creator ist es anschliessend Kinderleicht eigene QT
Anwendungen zu stricken.
Robert.
Hallo,
Danke für den Tipp mit dem Bildschirmschoner. Da werde ich noch
recherchieren müssen.
Zum mPlayer: Nein, der zeigt leider nur einen schwarzen Bildschirm an.
Als Ausgabegerät hab ich fbdev.
Sehr auffällig ist, dass wenn ich den mPlayer mit [^C abbreche, hin und
wieder ein Frame des Videos angezeigt wird. Die Decodierung funktioniert
also. Der Frame bleibt dann auch im Framebuffer, bis was anderes
angezeigt wird.
Dieses LCD-Problem scheint mir darauf hinauszulaufen, dass es am LCD
selbst liegt. Denn bei einem Reset wird ja der LCD-Controller
zurückgesetzt, aber nicht das Display.
Vielleicht schickt der LCD-Controller irgendwie in machen Fällen die
Daten schlampig ans Display (H-Timing/V-Timing. usw..?) das sich
daraufhin eben verabschiedet.
Möglicherweise lässt sich da was an der Setup.c schrauben..
Noch schnell zum Splashscreen:
Die Frage mag lächerlich klingen...aber wo ist die rcinit beim
Grasshopper?
Soviel ich weiss/nachgelesen habe sollte es einen /etc/rc.d/ Ordner
geben wo das Zeug drinnen ist. Den habe ich aber nicht.
klingt jetzt etwas Oberlehrerhaft und ich denke die meisten wissen es
auch:
wenn irgend etwas in der Konfiguration geändert wird, sollte vor dem neu
builden ein make clean ausgeführt werden, oder die .o Dateien gelöscht
werden.
Gruß
Udo
Stimmt, zum Thema neu builden der Buildroot Umgebung. Ich habe mich auch
lange damit beschäftigt bei kürzlichen Änderungen nicht immer alles von
vorne durchcompilieren zu müssen.
Der einfachste Weg für änderungen am Kernel geht meiner Meinung nach
folgendermaßen:
Im Buildroot Hauptverzeichnis folgendes eingeben:
1
makelinux26-menuconfig
Alle Einstellungen / Änderungen vornehmen und bei Beenden speichern. Nun
werden bereits entsprechend nötige Dateien 'berührt' (Zeitstempel
aktualisiert) um mit einem anschliessenden
1
make
alles nötige übersetzt zu bekommen.
@ Dan: Bezüglich der Splashimages, entweder die jeweiligen Startscripte
(/etc/init.d/S03bootsplash bzw. /etc/ini.d/S99slpash) umbenennen (also
zumindest kein S mehr am Anfang) oder einfach löschen.
Versuch mal beim mPlayer nicht fbdev sondern fbdev2 als -vo.
Robert.
@Robert
Hast du mal ausprobiert ob deine Fehlerbeschreibung bzgl. des Displays
auch mit dem build von meiner Seite auftritt?
Leider kann ich es z.Z. hier nicht testen, da ich keine
AddOn-Leiterplatte mehr vorrätig habe.
Gruß
Udo
Oh...peinlich, dass ich die Bootsplash-Scripte übersehen hab..dabei war
ich so oft in dem Ordner.
Zum mPLayer: Bei -vo fbdev2 stürzt er leider einfach ab.
@ Udo:
Ja hatte ich getestet. Auch mit dem rootfs von dir hatte ich die LCD
Probleme.
@ Dan:
Achja dann liegts aber wahrscheinlich daran, dass dein fbdev nicht
genügend Speicher adressieren kann. Gib mal bei den bootargs in uBoot
zusätzlich 'fbmem=600k' an.
Robert.
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
