Lost in Translation

    This has nothing to do with this plugin and is explained also in the GP Wiki


    Add this to the kernel command line in bios :


    console=ttyS0,115200

    2 Mal editiert, zuletzt von gutemine ()

    @getemine how do I create the log of dFlash?




    Mittlerweile habe ich mich doch einmal mit den mtd-utils beschäftigt, so dass ich mich endlich an der ganzen Diskussion beteiligen kann.


    nandwirte stammt also aus diesen Tools und ist demnach völlig herstellerunabhängig. nfidump ist ein proprietäres Tools von DMM oder gutemine (?) und kann die Teile eines nfi-Images einzeln extrahieren und - habe ich das richtig verstanden? - auch mittels des Betriebssystems diese in den Flash schreiben. Hierbei wird wohl implizit das nandwrite von Linux verwendet?


    Demnach wäre writenfi einfach ein (von der jeweiligen Image-Struture abhängiges) Werkzeug, das lediglich ein komplettes nfi ohne bad block Vewaltung in den Flash schreibt. Und da sich die Image-Struktur derzeit jedoch im Wandel befindet, halte ich gutemine's Ansatz, die Teile eines solchen Images einzeln mittels nfidump zu handhaben, auf auf Dauer gesehen sogar als einzig sinnvolle Lösung. Wer wieiß, ob DMM noch Interesse hat, writenfi überhaupt anzupassen. Nicht nur, dass keine bad block Verwaltung vorhanden ist, schlimmer noch, das aktuelle writenfi kann mit der aktuell verwendeten JFFS-Struktur gar nicht umgehen.


    Mein Wunsch wäre: writenfie völlig abzulösen durch eine Kombination aus nfidump (Separieren aller Imageteile) + nandwrite (in den Flash schreiben) zu ersetzen, wobei gutemine uns alles Teile eines nfi mittels dFlash in den Flash schreiben lässt.


    viele Grüße
    wysiwyg

    Kernenergie, die todsichere Garantie für eine strahlende Zukunft. :rot:

    2 Mal editiert, zuletzt von wysiwyg ()

    >>> >detected old jffs2 sig.. disable hw ecc


    This means what I always said that current writenfi is not good for new jffs2 Drivers that DMM uses and just produces just a corrupt filesystem


    writenfi was written for loader writing (where jffs2 is not used) and writing of Dm8000 images (NFIFlash) and DMM supports them only for this - and since the latest driver changes it simply doesn't work for anything else anymore without problems, The 8k dodn't change drivers & Flash format - hence it is the only box where it still works.


    And this is the reason why I switched to use my own nfidump

    I used nfidump


    DM800


    dFlash with default parameters


    now I have started from usb "dumbo"


    restart


    and now also flash. no longer appears the message ###stop###


    how do I create the log of dFlash?

    if you have a valid autoexec* and kernel on the dumbo device it boots as long as the loader in Flash is alive.


    The problem is that flashing works only in single user modus where it is VERY hard to get output.


    Even if you change the dflash.sh shellscript to sh -x you might not see what you want to see.


    And if you try to switch images with old/new drivers and loaders you will fail with the nfidump approach as it doesn't change the loader or the filesystem of the flash as this is only emptied and re-filled and NOT re-written.


    Wünschen kann man vieles, wobei so ein hyprid Ansatz auch Fehleranfällig ist. Vor allem geht das auf meiner 8000 schwer zu testen weil die ja das jffs2 und das nfi file format nicht gewechselt hat.


    Die NP Tests von Benutzern auf 800 und 800se mit dem neuen format und nandwrite sind leider nicht sehr viel versprechend, aber mal sehen, ich sagte doch schon das ihr da Geduld haben müsst.


    Und das nfidump ist einfach ein binary um nfi files ins filesystem auszupacken, mehr mache ich damit im dFlash auch nicht, da wird kein Flashfilesystem geschrieben, sondern files ins vorhandene Flashfilesystem geschrieben statt dieses neu zu erstellen. nfidump benutzt eigentlich nur mehr den alten dump code von tmbinc um aus einem jffs2 file die files rauszuholen, den Rest habe ich drumherum geprogged damit es als Standalone binary funktioniert.


    LG
    gutemine

    3 Mal editiert, zuletzt von gutemine ()

    Zitat

    Original von gutemine
    ..i so ein hyprid Ansatz auch Fehleranfällig ist..
    .., ich sagte doch schon das ihr da Geduld haben müsst.


    Aber ist es nicht zu erwarten, dass das Dateiformat jffs2 demnächst auch auf der 8000 erneutert wird? Schließlich ist das jffs2 ja ebenfalls herstellerunabhängig und wird sich über kurz oder lang durchsetzen. Insofern wäre dieser von mir gewünschte hohe Mehraufwand nicht sinnlos. Aber der andere von dir angesprochene Punkt macht mir noch mehr Sorgen: Wenn du nur auf uns als Tester bei den Boxen 800, .. angewisen bist, .. :loudly_crying_face:


    Aber es sit Deine Zeit, die hierbei draufgeht. Ich für meinen Teil werde gerne mit Geduld abwarten.


    viele Grüße
    wysiwyg

    Kernenergie, die todsichere Garantie für eine strahlende Zukunft. :rot:

    Am jffs2 Format hat sich ja nichts geändert, an der Error correction in den Treibern schon. Deswegen funktionieren die Backups ja noch immer anstandslos.


    Insofern macht Ihr unnötig Stress was die Benutzer auch nur wieder unnötig verwirrt.


    Das man mit dFlash so bequem Flashen könnte war und ist immer etwas gewesen dass zwar erfreulich war das es funktioniert hat aber das immer auf sehr wackeligen Füßen gestanden ist, nicht umsonst war und wird immer der ganze Disclaimer im Plugin zu lesen sein.


    Das primäre Problem von nfidump ist ja nicht das extrahieren (das geht prima) sondern das während dem extrahieren das root.jffs2 und das boot.jffs2 ja auch wo hin müssen bevor man das Filesystem leermachen und die neuen Files schreiben kann und ziemlich viel Memory braucht das extrahieren auch. Ausserdem schreibt man ziemlich viel ins Filesystem und obwohl ich ein sync mache vor dem reboot kann es passieren das sachen nicht sauber in den Flash zurück geschrieben werden - und dann bootet es halt nachher nicht wie es sollte.


    LG
    gutemine

    2 Mal editiert, zuletzt von gutemine ()


    Could you also test if using a swapdevice makes any difference to improve the situation ?

    Look, there should not be a problem when you unpack a backup of the same image with the same loader
    (for example my lates OoZooN 3.2 backup with dFlash is nicely 'flashable' with dFlash


    BUT the r6 images are bigger because of the double enigma2 binary - hence it could be that nfidump runs out of memory while unpacking - hence a swapfile maybe could help.

    I've now Flashed Nemesis r6, backuped it with dFlash and restored/Flashed it with dFlash (usind nfidump). Works nicely on my 8k.


    And when I cann't reproduce it then it is hard to fix it. But as I said it could be caused by size problems due to the smaller Flash of the 8c or by Memory problems, or ...

    2 Mal editiert, zuletzt von gutemine ()

    Zitat

    Original von gutemine
    ..
    Insofern macht Ihr unnötig Stress was die Benutzer auch nur wieder unnötig verwirrt.
    ..


    Ich bitte dich! Damit wollte ich keinen Stress machen, sondern schlicht und einfach nur einen Beitrag für die von dir doch wohl gewünschte Diskussion liefern.


    Aber mir ist wohl bewusst, dass das Ganze sehr schnell auf beiden Seiten in Stress auszuarten droht, wenn einerseits du auf unsere Testbeiträge angewiesen bist und andererseits wir dafür oft zu wenig Mut und Ahnung haben, die Tests in die Tat umzusetzen.


    Wenn du künftig nfidump als Grundlage verwenden würdest, das ja wohl auf Linux basierend alle Ressource der Box verwenden kann, wäre doch eine Verwendung externer Speichermedien (HDD, USB, ..) eine Möglichkeit der Klemme Spiecherknappheit zu entkommen!?


    Insgesamt gesehen scheint mir nach wie vor für eine auf nicht so wackligen Beinen stehende Implementierung von dFlash die von dir vorgeschlagene - auf nfidump und nandwrite basierende - Lösung höchst sinnvoll.


    viele Grüße
    wysiwyg

    Kernenergie, die todsichere Garantie für eine strahlende Zukunft. :rot: