Pearl DPF "fastoff" Firmware

  • 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

    Dateien

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

  • 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! :respekt


    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. :D


    Das Ganze zur Zeit nur fürs Pearl. Und das ja jetzt bekanntlich ausverkauft. :(


    Gruß
    superelchi

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

  • Hier noch ein paar "fastoff" Alternativen. Für die, denen es zu schnell geht. :D
    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.

    Code
    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. ;D
    Das "ohneBat" hat jemand anderes gebastelt. Ist mit ehrlich gesagt noch garnicht aufgefallen, dass da oben links die Akkuanzeige steht. :wow 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

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

  • 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.

    Code
    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 ;D .

  • 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'


    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. :D



    Gruß
    superelchi

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

    Einmal editiert, zuletzt von 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. :D
    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

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

  • 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

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

  • Google ist dein Freund. :] "libhid-detach-device" ist im Paket "libhid" enthalten - wer hätte das gedacht bei dem Namen. :D
    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 :wand , danke für den Hinweis. Das erklärt auch warum bei

    Code
    apt-cache search libhid

    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.


    Aah :wand , danke für den Hinweis. Das erklärt auch warum bei

    Code
    apt-cache search libhid

    nichts gefunden wurde. Hätte ich doch gleich Google probieren sollen ...


    "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.


  • 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:

    Code
    $ apt-file search $(which firefox)
    firefox: /usr/bin/firefox


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • 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 :D !
    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


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • 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:

    Code
    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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!