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 | export QWS_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 | make linux26-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.
war mir hier in der Vergangenheit nicht aufgefallen. Mag aber daran gelegen haben, dass ich immer über putty rein gegangen bin. Gruß Udo
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.