Pearl DPF "fastoff" Firmware

  • 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


    Habe mal selber reingeschaut, eigentlich muss man kein großer C-Programmierer sein, um den BSOH zu modifizieren, bzw. sogar eine Grafik reinzupasten:
    In main.c / Funktion umain() gibt es u.a. die Aufrufe:


    Wenn man eine Grafik in den BSOH reinpasten will, muss man nur schauen wie clrscreen() funktioniert:
    Anstelle von einzelnen col Wertes könnte man ein array nehmen, welches die Bilddaten im RGB16/RGB565 Format enthält zB const unsigned short g_splashgfx[] = {...}


    Das sollte es gewesen sein, jetzt muss man "nur noch" (haha, siehe meinen vorhergehenden Eintrag) die modifizerte FW flashen können ...

  • Also nochmal die Frage, gibt es hier jemanden der erfolgreich mit restore.py flashen konnte ?

    Ja. Ich.


    Habe mal selber reingeschaut, eigentlich muss man kein großer C-Programmierer sein, um den BSOH zu modifizieren, bzw. sogar eine Grafik reinzupasten:

    Na dann viel Vergnügen. Dann sind wir wieder bei den Pinguinen. Was machst du, wenn jemand gern ein anderes Bild hätte? Soll der das dann auch - ganz easy - "reinpasten"? Oder machst du einen Änderungsdienst auf?


    BTW: schon mal 8051 Assembler programmiert? Schon mit den diversen 8051 Memory Models, Adressierungsarten, Bank-Switching, AX206 Speicheraufbau, SDCC Eigenheiten, etc. beschäftigt? Code, den man modifizieren will, sollte man nämlich erst mal verstehen. :]


    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

  • Na dann viel Vergnügen. Dann sind wir wieder bei den Pinguinen. Was machst du, wenn jemand gern ein anderes Bild hätte? Soll der das dann auch - ganz easy - "reinpasten"? Oder machst du einen Änderungsdienst auf?


    Zugegeben, eine Lösung bei der ich ein default Image im USB flash drive definiere, welches ich jederzeit austauschen ist natürlich schöner, aber wie du schon schreibst ist das nicht trivial und mal eben schnell gemacht.


    Aber als erste einfache Lösung, wenn jemand unbedingt sein eigenens Image haben will , muss man halt selber compilieren, selbst die FW flashen muss man eh.
    Mir persönlich reicht das, die saubere Lösung ist aber klar vorzuziehen !


    BTW: Ja, verdammt ist schon bald 20 Jahre her, dass ich mit dem 8051 gearbeitet habe

  • Mir persönlich reicht das, die saubere Lösung ist aber klar vorzuziehen !

    Okay, hast recht. Doch wo ist dabei der Vorteil gegenüber der vorhandenen, gepatchten Version? Ist doch eher ein Rückschritt.
    Deshalb bin ich dran das etwas umfangreicher zu machen. Hab schon eine zusätzliche Schrift eingebaut (die ich ohne Lupe lesen kann) und sitze momentan an einem schöneren Menü. Dann ist der Grundstock da um so Sachen wie eigener Splash-Screen, Änderung der USB-Serial, etc. einzubauen.


    BTW: Ja, verdammt ist schon bald 20 Jahre her, dass ich mit dem 8051 gearbeitet habe

    Jetzt wo ich so drüber nachdenke- ist bei mir noch ein bisschen länger. Und war nur der 8048. 8o


    BTW: dein Problem mit der restore.py: ich mach das immer direkt im fw-Verzeichnis, also

    Code
    1. cd fw
    2. sudo libhid-detach-device 1908:3318
    3. sudo python restore.py ../src/current.bin -f


    Vielleicht liegt es daran?


    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

  • Hallo superelchi,


    das klingt ja höchst interessant mit deinen Änderungen und bin gespannt was du da noch aufbohrst. Mir fehlt leider momentan Zeit und Muße da so tief einzusteigen, bis auf meinen Quick & Dirty Vorschlag.


    Vielen Dank auch für den Tipp es mal so zu versuchen, aber leider ;( kein Unterschied und gleiche Fehlermeldung,
    Habe es übrigens auf 2 verschiedenen Ubuntu Systemen versucht, unterschiedlich HW - einmal 32bit und ein 64bit System.


    Könntest du eventuell einen fulldump der neuen Firmware zur Verfügung stellen ?
    Diese ließe sich dann vielleicht mit ProgSPI flashen und man kann eventuell Rückschlüsse daraus ziehen, wie man gleich ein solchen bin File erzeugt, das von ProSPI akzeptiert wird !?


    Nicht schön aber dann kriege ich die FW hoffentlich auf mein DPF., Könnte mir vorstellen, dass viele das Problem haben .... ?


    Grüße,
    irimi

  • Vielen Dank auch für den Tipp es mal so zu versuchen, aber leider kein Unterschied und gleiche Fehlermeldung,
    Habe es übrigens auf 2 verschiedenen Ubuntu Systemen versucht, unterschiedlich HW - einmal 32bit und ein 64bit System.

    Beim mir läufts auf zwei Ubuntus. 1 x 10.04 (da ist sogar noch libhid in den Repos) und 1 x 11.04. Mal ganz vorsichtig gefragt: du verwendest hoffentlich nicht das Schrott USB-Kabel, das bei dem Display dabei ist?
    Funktioniert libhid-detach-device auch einwandfrei?
    Zieh mal das Display ab und mach ein

    Code
    1. ls /dev/hidraw*

    Dann Display dran und in Bootloader-Mode versetzen. Paar Sekunden warten (der HID-Treiber braucht ein bisschen). Nochmal den Befehl von oben. Jetzt sollte da ein "hidraw" mehr sein (bei mit "/dev/hidraw5"). Jetzt

    Code
    1. sudo libhid-detach-device 1908:3318

    dann sollte das neue "hidraw" wieder weg sein.


    Könntest du eventuell einen fulldump der neuen Firmware zur Verfügung stellen ?
    Diese ließe sich dann vielleicht mit ProgSPI flashen und man kann eventuell Rückschlüsse daraus ziehen, wie man gleich ein solchen bin File erzeugt, das von ProSPI akzeptiert wird !?

    Fulldump.py bringt da leider nix. Da kommt die selbe Datei raus wie die, die du programmiert hast. Nur mit ganz vielen 0FFH auf 2 MB aufgeblasen. :D Ich nehme an, dass ProgSPI sich den Header anschaut und was bestimmtes erwartet. Kriegen wir schon noch raus.


    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

  • Ne,ne , Kabel, Hub usw. kommen nicht in Frage, habe es jetzt nochmal mit meinem Notebook mit USB3.0 versucht - wieder dieses "Temporary Unavailable " Problem. Schon komisch , bisher nie Probleme gehabt , auch nicht mit dem alten hackit.py.
    Auch mit dem detachen wie erwartet, hidraw komt und geht wie erwartet. Allerdings: alle meine Rechner haben Ubuntu 11.10 ! Aber selbst hackfin/Strubi schreibt

    Quote

    For some reason, there are sometimes too many timeouts on the pearl DPFs.

    Habe da noch eine Idee - ist aber etwas aufwendiger.


    Das mit dem Fulldump habe ich befürchtet :( . Ja, dürfte sich herausfinden lassen, wie man das macht.


    Ach, noch zu meiner "Quick & Dirty" Funktion: habe mal ein kleines Konverter Script geschrieben, was ein entsprechendes C-Array erzeugt.
    Solch ein Array kann je nach Auflösung recht groß werden, was vielleicht mein Compilieren/Linken der FW Probleme machen könnte.


    Zusätzlich kann man den DPF direkt per USB mit Bildern befüllen (alles unter Python), wenn man mal eben schnell eine Grafik auf dem DPF testen will.
    Zu finden unter:
    dpflib.py

  • Zusätzlich kann man den DPF direkt per USB mit Bildern befüllen (alles unter Python), wenn man mal eben schnell eine Grafik auf dem DPF testen will.
    Zu finden unter:
    dpflib.py

    Kannte ich noch garnicht. Cool. :tup
    Hatte schon überlegt, wie ich das Startbild am einfachsten auf das Display kriege. Ein Programm, das die libpdf.a von hackfin benutzt ist meine Meinung nach nicht so das Gelbe vom Ei für einen "normalen" Anwender. So mit Kompilieren und so...
    Wenn ich das richtig verstehe, brauchts nur die dpflib.py für den Zugriff aufs Display? Wenn ich nen neuen Befehle wie "set splashimage" in die Firmware reinbaue, könnte man dann doch ein einfaches Download-Programm mit der dpflib.py basteln, oder?


    Auch mit dem detachen wie erwartet, hidraw komt und geht wie erwartet. Allerdings: alle meine Rechner haben Ubuntu 11.10 ! Aber selbst hackfin/Strubi schreibt
    Zitat
    For some reason, there are sometimes too many timeouts on the pearl DPFs.

    Nur komisch, dass es mit hackit.py, ProgSPI und wohl auch dpflib.py geht? Okay - Bootloader-Modus gibts nur in der neuen libdpf von hackfin oder ProgSPI - aber beide laden dieselbe Lib aufs Display für die Übertragung. [Am Kopf kratz].
    Bin zwar momentan tief in der Menüerstellung der Firmware, aber ich glaube, das Problem mit ProgSPI ist wirklich wichtig. Mal sehn ob ich nicht erst mal versuche das zu Fixen. Hab ja von hackfin Developer-Zugriff auf das dpf-ax Projekt bekommen.Wenn ich was rausfinde, stell ichs direkt im Projekt bei sourceforge ein. Mit meinen Erweiterungen (Font/Menü/etc.) dauerts noch etwas (ja, ja, die Zeit...).


    Ach, noch zu meiner "Quick & Dirty" Funktion: habe mal ein kleines Konverter Script geschrieben, was ein entsprechendes C-Array erzeugt.
    Solch ein Array kann je nach Auflösung recht groß werden, was vielleicht mein Compilieren/Linken der FW Probleme machen könnte.

    Das Bild würde ich als Resource in die Firmware einbinden. Schau mal in die Makefile und compile.py, wie die "font4x8.bin" eingebunden wird. Dafür bräuchte es eine Datei, die schon die richtige Orientierung/Auflösung hat und im RGB565 Format vorliegt. Also für die momentan unterstützten Displays wären das drei Dateien: 128x128 Pixel, 240x320 Pixel (Portait) und 320x240 Pixel (Landscape). Dann ne einfache Routine, die die Resource aus dem SPI-Flash ließt und direkt aufs Display haut - das wäre wirklich Quick&Dirty. :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

  • Hatte schon überlegt, wie ich das Startbild am einfachsten auf das Display kriege. Ein Programm, das die libpdf.a von hackfin benutzt ist meine Meinung nach nicht so das Gelbe vom Ei für einen "normalen" Anwender. So mit Kompilieren und so...
    Wenn ich das richtig verstehe, brauchts nur die dpflib.py für den Zugriff aufs Display? Wenn ich nen neuen Befehle wie "set splashimage" in die Firmware reinbaue, könnte man dann doch ein einfaches Download-Programm mit der dpflib.py basteln, oder?


    Hat auch Nachteile: es muss noch die Python Image Library (PIL) und pyusb 0.4 nachinstalliert werden. Außerdem ist die notwendige Wandlung nach rgb565 rechenintensiv, was auf kleinen System schon im Sekundenbereich liegen kann - auf meinem Router an dem ich das Display ebenfalls verwende geht es gerade so.
    Vorteil ist aber, dass man von dieser libdpf.a unabhängig ist.
    Der Download mit dpflib.py geht übrigens schon zB

    Code
    1. python ./dpflib.py [Grafikdatei.png|jpg]

    .


    Die Grafik kann kann größer als 320x240 sein - wird dann runterskaliert (allerdings noch absolut)


    Quote

    Hab ja von hackfin Developer-Zugriff auf das dpf-ax Projekt bekommen


    Cool - da kommen noch spannende Zeiten :]


    Quote

    Das Bild würde ich als Resource in die Firmware einbinden.


    Wenn du stattdessen ein bin File erzeugen willst, die Zeile 396-414 ändern in

    Code
    1. [(r565.append((p[0] & 0xf8) |((p[1] & 0xe0) >> 5 )),r565.append(((p[1] & 0x1c) << 3)|((p[2] & 0xf8) >> 3)) ) for p in rgbdata]
    2. import struct
    3. f = open("./RGB565.bin", "wb")
    4. for short in r565:
    5. bindata = struct.pack("h",short)
    6. f.write(bindata)
    7. f.close()


    Ergänzung: die Skalierung kann man bereits als Parameter übergeben ("dpflib.py help") zeigt wie.

  • Hat auch Nachteile: es muss noch die Python Image Library (PIL) und pyusb 0.4 nachinstalliert werden

    Rechne das mal gegen die Nachteile von dpflib.a auf. :D
    Ist mir allemal lieber, einem Otto-Normalnutzer zuzumuten ein paar Standard-Libs nachzuinstallieren, statt ihn die dpflib.a kompilieren zu lassen.


    Die Grafik kann kann größer als 320x240 sein - wird dann runterskaliert (allerdings noch absolut)

    Könne man da nicht was mit ImageMagick machen?


    BTW: hab schon rausgefunden warum ProgSPI die Firmware nicht mag. Das Programm ist zwar so doof, dass es eine Firmware mit falschen CRCs programmiert (die dann auf dem Display natürlich nicht läuft) aber wenn sich der Header der Jumptable nicht an der richtigen Stelle befindet weigert es sich. :rolleyes:


    Gruß
    superelchi



    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

  • Könne man da nicht was mit ImageMagick machen?


    Nicht notwenig, kann alles die PIL, läßt sich schnell ändern, wen man es relativ oder anderes haben will.
    Und wie bereits oben noch ergänzt, kann man die Skalierung bereits als Parameter übergeben - einfach mal "dpflib.py help" eingeben.

  • Alles klar.
    Mit Python hab ich nur cut&paste Erfahrung. :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

  • So, programmieren der 0.2er Version mit ProgSPI geht jetzt.
    Änderungen sind in http://dpf-ax.svn.sourceforge.net/ drin.
    Im Anhang fertige FW-Versionen fürs Pearl.


    Gruß
    superelchi

    Files

    • fw_pearl.zip

      (51.28 kB, downloaded 239 times, last: )

    #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 was für die, bei denen es kein libhid gibt.


    Das Skript ist ein Ersatz für libhid-detach-device.
    Ab dem nächsten commit auch in die Projekt-Sourcen zu finden.


    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

  • So, programmieren der 0.2er Version mit ProgSPI geht jetzt.
    Änderungen sind in http://dpf-ax.svn.sourceforge.net/ drin.


    Gruß
    superelchi


    Bin erst jetzt dazu gekommen, funktioniert super, auch der libhid Ersatz :tup .
    Habe festgestellt dass mein dpflib.py Script nicht kompatibel zur neuen Firmware ist - Ursache ist klar, muss es aber noch modifizieren.


    Außerdem habe ich ein wenig was beim Flash-Problem unter Linux/Python herausgefunden:
    - Problem tritt bei mir nur beim flashen per Bootloader auf
    - Timeouts in der dpflib hochsetzen bringt nichts
    - mit der neuen FW ist leicht zu erkennen, dass gleich nach dem ersten Befehl der Full Erase Flash Sequence "fllash_cmd(h, SPM_RES, 1, 0);" das Display offensichtlich einen Reset durchführt.


    Leider kann ich es nicht genau sehen da wireshark plötzlich keine Bulk Messages mehr mittraced :rolleyes: (ging aber schonmal) . Jedenfalls wird die FW gestartet, damit das Flash nicht gelöscht ! Wenn man das nicht mitgekommt und nochmal das Script startet, begeht die FW Selbstmord und löscht sich selbst 8o .
    Mein Verdacht: eventuell sind unterschiedliche Bootloaderversionen drauf, die ihre Eigenarten haben. Man müsste mal den Flashspeicher an der Stelle auslesen und vergleichen.


    Grüße, irimi

  • - mit der neuen FW ist leicht zu erkennen, dass gleich nach dem ersten Befehl der Full Erase Flash Sequence "fllash_cmd(h, SPM_RES, 1, 0);" das Display offensichtlich einen Reset durchführt.

    Was für einen Flash-Chip hast du denn im Display? Vielleicht passen die Erase, etc. Befehle einfach nicht zu deinem Flash?


    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

  • Was für einen Flash-Chip hast du denn im Display? Vielleicht passen die Erase, etc. Befehle einfach nicht zu deinem Flash?


    Hab zu hause nicht so einen kleinen Schraubendreher zur Hand, aber würde zur BL Theorie passen.


    Meine letzten genannten Analysen kann man vergessen, da war irgendwie der Wurm drin, keine Ahnung warum es immer einen Reset gab.
    Bin jetzt mal mit dem Debugger + Wireshark dran gegangen und es verhält sich so:

    Code
    1. flash_cmd(h, SPM_RES, 1, 0);
    2. flash_cmd(h, SPM_WRSR, 2, 0); // clr status
    3. flash_cmd(h, SPM_WREN, 1, 0);
    4. flash_cmd(h, SPM_FLASH_BE, 1, 0);


    werden erfolgreich ausgeführt und vom DPF immer mit OK quittiert.


    Aber anschließend gibs Probleme bei Abfrage des Flashstatus - über bootloader.c / flash_status_hid() / spilib_process() wird aufgerufen:

    Code
    1. error = transmit(h, umsg);
    2. if (umsg->u.spi.rnum > 0 && error >= 0) {
    3. error = usb_rawread(h->dev.udev, out, 64);
    4. }
    5. if (error < 0) perror("Reading USB");
    6. else error = 0;
    7. return error;


    Der Transmit ist noch erfolgreich, aber beim usb_rawread() gibt es nach 4s eine Fehlermeldung, hierzu der Trace:



    Das interessante: diesen Vorgang kann ich beliebig oft wiederholen, ohne einen weiteren detach machen zu müssen - ABER der Flashspeicher bleibt ungerührt, nichts wird gelöscht.


    Muss ich wohl doch mal den Flashbaustein anschauen - aber erst nach Ostern, fahre ein paar Tage weg.