Auf dem 8 poligen Flashbaustein steht nix drauf
Ich hätte mich besser nicht getraut, Display ist nun tot.
Im Windowstool kommt eine Meldung mit Hyroglyphen, auch [Winbond 25P16] rettet nix mehr.
Sonst noch eine Idee was ich ausprobieren könnte ?
Auf dem 8 poligen Flashbaustein steht nix drauf
Ich hätte mich besser nicht getraut, Display ist nun tot.
Im Windowstool kommt eine Meldung mit Hyroglyphen, auch [Winbond 25P16] rettet nix mehr.
Sonst noch eine Idee was ich ausprobieren könnte ?
Auf dem 8 poligen Flashbaustein steht nix drauf
Hab ich was davon gesagt, dass du den Flash angucken sollst? Das bing rein garnix da ProgSPI den Flash automatisch erkennt! Du solltest nur die eine Zeile in der FlashLib.ini ändern und sonst nix! Mach mal einen Screenshot von der Ausgabe des ProgSPI nachdem du "execute" gedrückt hast. Solange das Display noch erkannt wird (also das Kästchen in ProgSPI grün wird) sollte nix Schlimmes passiert sein.
Als Anhang dann eben doch mal die FlashLib.ini mit dem korrigierten Eintrag für den MX25L1605A....
Gruß
superelchi
Display lebt wieder.
Nachdem ich endlich den Akku weggenommen hatte, reagierte das Display wieder normal auf den Resetknopf.
Hab dann als normales Winbound 25P16 ein fertiges Bin (mit Debug und Schwarzbild) geflasht, das funktionierte.
Nachteil ist immer noch, das die Bilder nicht tauschbar sind, das CDrom kann nicht beschrieben werden.
Von weiteren Versuchen nehme ich erstmal Abstand, auch mit dem Hintergrund, das Pearl im Moment keine Displays anbietet.
Danke für die Hilfe.
Wens interessiert:
es gibt ne neue Version von hackfin - 0.2devel.
Das ist ne "echte" Firmware, d.h man muss nix mehr Patchen. Einfach die Firmware aufs Display und gut is.
Vielen Dank an hackfin!
Source: http://dpf-ax.svn.sourceforge.net/.
Fertige Firmware: http://tech.section5.ch/files/fw_pearl_landscape.bin.
Interessant ist, dass bei den Sourcen auch ein Bootload-Flasher dabei ist, d.h. eine Ersatz für ProgSPI unter Linux (restore.py im fw-Verzeichnis)!
Leider gibts damit die selben Probleme wie mit ProgSPI. Displays, die sich damit nicht flashen lassen gehen auch nicht mit restore.py.
Damit dürfte klar sein, dass es an den Displays und nicht am Flash-Programm liegt - leider.
Nachteil der neuen Version ist aus meiner Sicht, dass es keine hackit.py, etc. mehr gibt. Da die Original-Firmware komplett ersetzt wurde ist es auch nicht mehr möglich mit DPFMate oder sonstwie ein Einschalt-Bild aufs Display zu laden. Also wieder blauer Bildschirm.
Das Ganze zur Zeit nur fürs Pearl. Und das ja jetzt bekanntlich ausverkauft.
Gruß
superelchi
Hier noch ein paar "fastoff" Alternativen. Für die, denen es zu schnell geht.
Einfach die "fastoff2.ihx" beim Patchen durch eine der "fastoff_XXs.ihx" Dateien ersetzen, um eine Umschaltzeit von XX Sekunden zu kriegen.
Gruß
superelchi
Hi,
ist dir das aus einem der bösen Foren eigentlich eigentlich bekannt? Dort werden folgende Images released.
landscape = horizontal
fastoff = nach 2 Sekunden automatisch in den Debug
silent = unterdrückt den blauen Bildschirm und lässt das zuletzt angezeigte Bild im Display stehen
ohne Credit = keine Hinweis auf Debug
nowelcome = das häßliche drei Pinguinenbild wird nicht mehr gezeigt, es kommt das erste hochgeladene Bild
ohneBat = die Akku-Anzeige oben links ist nicht mehr dabei
Das ohneBat wäre noch so rein perfektionistisch toll. Das ohne Credit eigentlich auch, aber da magst du vermutlich nicht von weg?
Hm, die hackfin - 0.2devel, interessant. Aber irgendwelche Vorteile für den Nutzer gibts da momentan wohl nicht so wie ich das sehe? Weil die gepatchte original ist ja jetzt quasi ideal für den Display Zweck.
cu
Ja, das aus dem bösen Forum kannte ich schon.
Die "ohne Credit" ist die erste "silent" Variante, die ich gepostet hatte. In der Aktuellen hab ich noch ein bisschen was geändert und eben die Credits reingebaut. Ich find, hackfin hat es verdient hier genannt zu werden. Ohne ihn wäre das schließlich alles nicht ins Rollen gekommen. Und das ich da mit draufstehe, naja.
Das "ohneBat" hat jemand anderes gebastelt. Ist mit ehrlich gesagt noch garnicht aufgefallen, dass da oben links die Akkuanzeige steht. Wenn gesteigertes Interesse besteht, schau ichs mir mal an.
Was die neue hackfin Firmware angeht: tolle Leistung! Aber ich finde wegen des blauen Bildschirms, fehlendes Startbild, keine Möglichkeit der Serinennummer-Änderung, ... für uns momentan keine Alternative zum Patchen.
Gruß
superelchi
Interessant ist, dass bei den Sourcen auch ein Bootload-Flasher dabei ist, d.h. eine Ersatz für ProgSPI unter Linux (restore.py im fw-Verzeichnis)!
Leider gibts damit die selben Probleme wie mit ProgSPI. Displays, die sich damit nicht flashen lassen gehen auch nicht mit restore.py.
Damit dürfte klar sein, dass es an den Displays und nicht am Flash-Programm liegt - leider.
Hmm, ist es denn hier schon jemanden gelungen die 0.2 devel Firmware auf ein DPF zu bekommen ?
Habe folgendes Problem: ProgSPI und das alte hackit.py gehen ohne Probleme, ABER restore.py liefert eine Fehlermeldung - scheint also eher doch am Flasher zu liegen.
Found AX206 DPF (bootloader)
Error: Failed to claim usb device!
Possibly you have to 'sudo libhid-detach-device 1908:3318'
Ein Rechte Problem oder gleichzeitiger Zugriff durch eine andere Instanz kann nicht die Ursache sein, da der Fehler bei mir auch nach einem Reboot und mit root Rechten auftritt.
Mit ProgSPI lässt sich die 0.2 devel nicht flashen, da die 0.2devel Firmwaredatei nicht akzeptiert wird !
Vorteil dieser neuer Version wäre nämlich, dass man selbst die Firmware modifizieren könnte: fastoff und eigenes Bild ließen sich sicherlich einbauen ... man muss sich "nur mal" in die Sourcen einarbeiten .
Die Antwort hast du ja selbst gepostet - steht in der Meldung von restore.py.
ZitatPossibly you have to 'sudo libhid-detach-device 1908:3318'
Vorteil dieser neuer Version wäre nämlich, dass man selbst die Firmware modifizieren könnte: fastoff und eigenes Bild ließen sich sicherlich einbauen ... man muss sich "nur mal" in die Sourcen einarbeiten .
Da bin ich grad dabei.
Gruß
superelchi
Die Antwort hast du ja selbst gepostet - steht in der Meldung von restore.py.
Zitat
Possibly you have to 'sudo libhid-detach-device 1908:3318'
Damit kann ich aber leider nichts anfangen,was soll das für eine Befehl sein "libhid-detach-device" ???
Bitte um Aufklärung
Außerdem müsste doch erst was "attached" sein, bevor ich einen detach machen muss, der Fehler tritt aber auch wie bereits erwähnt , nach einem reboot auf !?
Läuft evtl. der VDR mit graphlcd?
Oder greift sich irgendwas anderes das Gerät? Evtl. mal das (die beiden Workarounds mit den IDs des Displays, da gehts zwar um ein anderes Gerät, aber das System sollte auch hier gehen) probieren http://code.google.com/p/yubik…lization/wiki/UsbhidIssue
cu
Damit kann ich aber leider nichts anfangen,was soll das für eine Befehl sein "libhid-detach-device" ???
Bitte um Aufklärung
Google ist dein Freund. "libhid-detach-device" ist im Paket "libhid" enthalten - wer hätte das gedacht bei dem Namen.
Für neuere Ubuntu-Versionen gibts allerdings kein fertiges Paket mehr. Also selbst ist der Mann - äh Kompilierer!
Außerdem müsste doch erst was "attached" sein, bevor ich einen detach machen muss, der Fehler tritt aber auch wie bereits erwähnt , nach einem reboot auf !?
Das Display wird im Bootloader-Modus von Linux als "Human Interface Device" erkannt und vom HID-Treiber gemanaged. Um zum Flashen dranzukommen muss man es eben erst dem HID-Treiber wegnehmen.
Gruß
superelchi
Läuft evtl. der VDR mit graphlcd?
Hat damit nix zu tun. Es geht hier um den Bootloader-Modus, also nach Drücken von MENÜ+RESET.
Das Display meldet sich dann anders, nämlich mit der ID 1908:3318 und als HID-Device. Das sieht graphlcd garnicht - dafür schnappt es sich der HID-Treiber.
Gruß
superelchi
Google ist dein Freund. "libhid-detach-device" ist im Paket "libhid" enthalten - wer hätte das gedacht bei dem Namen.
Für neuere Ubuntu-Versionen gibts allerdings kein fertiges Paket mehr. Also selbst ist der Mann - äh Kompilierer!
Das Display wird im Bootloader-Modus von Linux als "Human Interface Device" erkannt und vom HID-Treiber gemanaged. Um zum Flashen dranzukommen muss man es eben erst dem HID-Treiber wegnehmen.
Gruß
superelchi
Aah , danke für den Hinweis. Das erklärt auch warum bei
nichts gefunden wurde. Hätte ich doch gleich Google probieren sollen ...
Hat damit nix zu tun. Es geht hier um den Bootloader-Modus, also nach Drücken von MENÜ+RESET.
Das Display meldet sich dann anders, nämlich mit der ID 1908:3318 und als HID-Device. Das sieht graphlcd garnicht - dafür schnappt es sich der HID-Treiber.
Ah, danke war mir nicht so bewust.
"apt-cache search" durchsucht nur die installierten Pakete nach Dateinamen, mit "apt-file find" (apt-file muss extra installiert werden) kann man nach Dateien in allen vorhandenen Paketen (also alle Pakete in allen eingebundenen Repositories) suchen.
[wobei das "apt-file find libhid-detach-device" hier dann auch den genannten Gründen auch nicht geholfen hätte. Aber meist klappts ]
Nur so als Info weil mans öfter mal braucht. Z.B. um zu sehen in welchen dev Paket ein benötigtes Headerfile ist.
cu
OFF-TOPIC:
"apt-cache search" durchsucht nur die installierten Pakete nach Dateinamen, mit "apt-file find" (apt-file muss extra installiert werden) kann man nach Dateien in allen vorhandenen Paketen (also alle Pakete in allen eingebundenen Repositories) suchen.
Sorry, da muss ich leider widersprechen. Beispiel: "apt-cache search tomcat" findet diverse Pakete und von diesen Java Paketen habe ich garantiert nichts installiert, dagegen findet "apt-file find firefox" rein gar nichts, dabei benutze ich ihn gerade !
Außerdem habe ich in der Vergangenheit häufig fehlende Pakete mit apt-cache erfolgreich gefunden.
man apt-cache
[...]
search regex [ regex ... ]
search führt eine Volltextsuche in der Liste aller verfügbaren Pakete für das gegebene POSIX-regex-Muster durch
man apt-file
[...]
search Search in which package a file is included. A list of all packages containing the pattern pattern is returned.
apt-file will only search for filenames, not directory names. This is due to the format of the Contents files it searches.
find Alias for search
Alles anzeigen
Sorry, da muss ich leider widersprechen. Beispiel: "apt-cache search tomcat" findet diverse Pakete und von diesen Java Paketen habe ich garantiert nichts installiert, dagegen findet "apt-file find firefox" rein gar nichts, dabei benutze ich ihn gerade !
Da widerspreche ich dir doch gleich mal. Richtig benutzt findet apt-file sehr wohl etwas:
Gerald
Da widerspreche ich dir doch gleich mal. Richtig benutzt findet apt-file sehr wohl etwas:
$ apt-file search $(which firefox)
firefox: /usr/bin/firefox
Das ist aber nur die halbe Wahrheit !
apt-file funktioniert nur, wie ich inzwischen herausgefunden habe, wenn man mal ein "apt-file update" gemacht hat, ansonsten gabs bei mir kein output, auch nicht mit "apt-file search $(which firefox)".
Aber dann findet sogar ein "apt-file search libhid" etwas(das eigentliche Problem) , da mingw Pakete anscheinend eine statische libhid.a haben.
Habe ich doch heute mal wieder was nützliches gelernt ...
Das ist aber nur die halbe Wahrheit !
apt-file funktioniert nur, wie ich inzwischen herausgefunden habe, wenn man mal ein "apt-file update" gemacht hat
Das ist absolut nicht erwähnenswert, weil selbstverständlich. Auf diesen Umstand wird man ja recht deutlich hingewiesen beim Installieren von apt-file.
Gerald
Possibly you have to 'sudo libhid-detach-device 1908:3318'
So, das habe ich nun hinbekommen, aber leider gibt es immer noch Fehler, d.h. restore.py fängt an , den Flashspeicher zu löschen, steigt dabei leider aus:
sudo python ./fw/restore.py ./src/fw_pearl_landscape.bin
Found AX206 DPF (bootloader)
Erase full flash...
Reading USB: Resource temporarily unavailable
Traceback (most recent call last):
File "./fw/restore.py", line 37, in <module>
flash_restore(d, data)
File "./fw/restore.py", line 12, in flash_restore
d.eraseFlash() # erase full flash
SystemError: 145:(ffffff92): Unknown error
Eventuell ein Timing Problem ???
Zum Glück "lebt" anschließend wenigstens der Bootloader noch und ich kann mit ProgSPI den DPF wiederbeleben.
Also nochmal die Frage, gibt es hier jemanden der erfolgreich mit restore.py flashen konnte ?
Solange das nicht geht, macht die Modifizierung der Source FW auch keinen Sinn.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!