Archiv verlassen und diese Seite im Standarddesign anzeigen : Pingulux flashen bleibt bei Writing Flash hängen - spark und HDMU
Hallo,
das Update (per USB) gelingt seit 2 Tagen nicht mehr und wenn ich das Log ansehe bleibt er beim "Writing Flash" hängen.
Das gilt für Spark und auch für HDMU. Da ich beides versucht habe ist praktisch nichts lauffähiges mehr drauf.
Der Zugriff per HTerm und über die Tasten am Gerät funktioniert.
Kann jemand in den log Dateien das Problem erkennen und mir schreiben was ich zur Rettung tun kann?
Vielen Dank St. Renpez
kannst mal ein altes HDMU Image testen? (teste mit verschiedenen Sticks!)
Hallo,
super schnelle Antwort Danke.
Habe diverse HDMU getestet (zwischen 12069 und 12791) und auch das aktuelle Edision spark und NF-EOS Help Pack 1.1.29 .
Alle flash Vorgänge laufen ganz normal mit alle (3) probierten Stick`s erst das letze schnelle hochzählen kommt einfach nicht.
Es gibt kein 7 70 oder T TO
Alles scheint ganz normal U Ld - e 299 - succ - S 199 Ende.
Laut log hat er doch da schon alles vom Stick ausgepackt und in seinen kleinen Bauch geschaufelt?
Alles in den NAND geschrieben , den Flash entsperrt gelöscht und erst danach beim neu Beschreiben klemmt es.
Grüße St Renpez
.... ein wirklich komisches Phänomen .....zu dem mir auch fast nichts einfällt,außer bei "weiteren Flashversuchen" mal anhand der Logs Prüfen ob sich die Bad Blocks nicht verändern und gleich bleiben...
Hallo,
ja die bad Blöcke bleiben immer gleich. Im HTerm werden sie schon beim löschen angezeigt und alle Logs verschiedener Images haben die gleichen B-Blöcke.
Aber dennoch scheint trotz badBlocks ja bis dahin alles noch OK.
Log HTerm
NAND erase: device 0 offset 0x18800000, size 0x7700000
Skipping bad block at 0x1a1c0000
Skipping bad block at 0x1b920000
Skipping bad block at 0x1c460000
Skipping bad block at 0x1de20000
Skipping bad block at 0x1de40000
Skipping bad block at 0x1e2e0000
Skipping bad block at 0x1f1e0000
Erasing at 0x1fee0000 -- 100% complete.
OK
NAND write: device 0 offset 0x18800000, size 0x2920000
Bad block at 0x1a1c0000 in erase block from 0x1a1c0000 will be skipped
Writing data at 0x1b13f800 -- 100% complete.
43122688 bytes written: OK
Unprotecting Flash...
.. done
Un-Protected 2 sectors
Erasing Flash...
.. done
Erased 2 sectors
Writing to Flash...
Grüße St Renpez
rantanplan
08.09.2014, 17:10
mach es über e2-Upgrade-Tool von Spark aus.
..und wie soll er das bitte machen ?
...er schreibt doch "Das gilt für Spark und auch für HDMU. Da ich beides versucht habe ist praktisch nichts lauffähiges mehr drauf."
Genau so ist das.
Es läuft nix mehr da das Löschen des Flash im Laufe der Installation noch wunderbar funktionierte, das Beschreiben leider weniger.
Scheint ja kein bekanntes bzw. erklärbares Problem zu sein.
Grüße St Renpez
- - - Aktualisiert - - -
Genau so ist das.
Es läuft nix mehr da das Löschen des Flash im Laufe der Installation noch wunderbar funktionierte, das Beschreiben leider weniger.
Scheint ja kein bekanntes bzw. erklärbares Problem zu sein.
Mal ganz anders gefragt. Durch was werden die einzelnen Schritte der Installation den bestimmt?
Daran scheitert es doch scheinbar. Bis zum Update war doch alles OK.
Grüße St Renpez
Erzähl mal Schritt für Schritt was du gemacht hast.
Welches image war vorher drauf
Hallo,
es lief ein HDMU aus Juni 14 ( Nr ??), also Zeit mal für ein Update. 12791 auf den Stick Instll normal bis (S 199 bzw Writing to Flash) Stillstand. Habe diverse Images versucht auch spark, was nach einer Reparatur bei Edision nicht mehr drauf war, Hdmu ca 3 verschiedene, NF EOS E2, NF Eos Help pack spark und org. spark von Edision das aktuelle. Alle mit den gleichen Ergebniss. Writing to Flash (E2) bzw Copy to Flash (spark)- Stillstand. s.Anhang oben
Grüße St Renpez
Ist denn noch Garantie drauf, dann weg mit der Box und gut ist, ich bezweifle das du e2 zum Laufen bekommst wenn spark nicht läuft
Teilzitat:
"...auch spark, was nach einer Reparatur bei Edision nicht mehr drauf war"
...verstehe ich das richtig, Edision hat die Box repariert und ohne Betriebssystem ...also quasi leer...zurückgesandt ???
Hallo,
so genau kann ich das eigentlich gar nicht sagen da ich nie spark benutze. Nach dem misslungenen Update habe ich das erste mal auf spark umgestellt , er zählte in ca.1s (viel zu kurz) bis 199 danach load, das wars und das ist auch jetzt noch so . Danach habe ich diese diversen flash Versuche incl. Log unternommen.
Der Firma habe ich das Problem vorgestellt aber noch keine Antwort.
Ich würde mich unabhängig davon aber freuen das Problem mit Eurer Hilfe selbst zu lösen und die Experten dafür sind hier im Forum.
Einschicken kann ich die Box natürlich auch, mache ich auch wenn Ihr sagt das es so nicht zu ner Lösung kommen kann.
Grüße St Renpez
..wie hier schon erwähnt erstmal muß wieder das Spark zum Laufen gebracht werden....
....ich kenne mich damit nicht aus, aber ggf. kannst Dich ja selbst belesen und informieren ob mit der Google-Eingabe "rescue image pingulux" und was da so kommt was anfangen kannst und vorallem auch zutraust !!
...nicht das die Box dann wirklich noch jtag braucht !!!
Hallo,
das erschließt sich mir auf keinen Fall. Kein Images ist auf ein Anderes angewiesen weder beim PC und auch nicht bei der Box.
Die Auswahl erfolgt durch den Bootloader. Der funktioniert wie die Logs zeigen, ich habe seriell Zugriff und die Box reagiert auch auf alle Eigaben am Gerät (das war damals nicht der Fall und Grund für die Rep), die Install Vorgänge laufen scheinbar normal bis zum neu Beschreiben des Flash. Das macht er dann nicht.
Noch einmal meine Frage von oben, wo, von wem, womit wird der Install Vorgang geführt? Wo stehen die einzelnen Schritte die auszuführen sind uboot? bootargs? oder?und wer kennt sich damit aus?
Viele Grüße St Renpez
Hier mal die Bootargs für den Pingu und das e2upgrade-plugin für Spark.
In der .txt ist beschrieben wie es geht, drauf achten dass wirklich Zeile für Zeile komplett eingefügt wird.
Alternativ,
google bitte nach dem Rescue Image für Pingulux 1.2.65 und flashe das, da ist der Bootloader mit enthalten, es würden also auch die Bootargs neu geschrieben.
Die Version deshalb, weil nur mit dieser aktuelle Spark upgrades möglich sind, was mit älteren Rescue Images nicht mehr geht (sofern überhaupt Bedarf besteht bez. Spark).
Auch was das angehängte e2upgrade-plugin betrifft.
suchmich1983
09.09.2014, 12:25
google bitte nach dem Rescue Image für Pingulux 1.2.65 und flashe das, da ist der Bootloader mit enthalten, es würden also auch die Bootargs neu geschrieben.
genau damit solltest du es in Schritt 1 versuchen! Danach sehen wir weiter!
Hallo,
vielen Dank.
Kurze Nachfrage Rescue Image für Pingulux 1.2.65 > ganz normal flashen spark?
Grüße St Renpez
Hallo,
Rescue Image Pingulux 1.2.65, leider das gleiche Ergebniss wie immer. S199 - Copy to Flash.
Ca 30min gewartet.
Grüße St Renpez
Elfenbein_47
09.09.2014, 19:56
Ich hab mein Pingu ohne + auch schon die Bootargs geradebiegen müssen.
Ist aber schon 1,5 Jahre her.
Die Anleitung hab ich damals benutzt un hat funktioniert.
..tja,mein Ratschlag wenn die 2 Jahre noch nicht um sind,dann eben nochmals zur Rep. senden....und nach Rücksendung die Box erstmal Booten und schauen ob auch das Spark drauf ist...nicht das es wieder "evtl." ohne BS back kommt....was aber nur ne "Annahme" war...
ru2001edv
10.09.2014, 10:16
schon versucht über netzwerk neu zu flashen? so mache ich das immer weil meine usb sticks nicht mit dem pingukux zusammen arbeiten wollen.
wäre ja noch ein versuch
Hast du denn bisher mal versucht die Bootargs manuell einzurichten?
Ist ein Versuch wert, bevor du was hin und herschickst.
Hallo,
übers Netz habe ich noch nicht geflasht, da offensichtlich mit den versch. Sticks alles und immer eingelesen wird, so zumindest die Log-Meldungen.
An den Bottargs bin ich dran, vielen Dank dafür. Das wird ne Weile dauern, im Moment habe ich nicht viel Zeit. Auf den ersten Blick sehen Eure und meine aber gleich aus.
Werde aber noch genauer vergleichen.
Grüße St Renpez
Hallo,
habe Eure Bootargs mit meinen verglichen und es gibt kleine Differenzen.
bootargs=console hat andere IP Adr.
filesize und fuseburned fehlen
Habe die Veränderungen im MAT eingetragen.
Und schon gibt es ein neues Problem. MAdminTool schreibt zwar angeblich in die Box ( -Successfully written bootarg: bootargs - Saving environment via RS232... ) die Box startet sofort neu - boot - load wo sie natürlich nichts findet weil ja nichts drauf ist. Box - aus - an Bootargs unverändert die Alten. Werden auch diese nicht in die Box geschrieben oder mache ich was falsch dabei? Beim Auslesen der Bootargs im AdminTool steht allerdings am Ende im Debug Browser "Could net read version of library - aborting update process..." Was kann das bedeuten?
Grüße St Renpez
Das da mächtig was kaputt ist, nochmal, wenn noch Garantie dann weg damit
Hallo.
Werd mich wohl damit abfinden müssen !
Schade nur unbefriedigend gelernt.
Vielen Dank an Alle
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.