Pingulux in die Knie zwingen

[dr.h8ball]

Guten Abend zusammen.

Ich habe das Problem dass bei meinem Pingulux der Flashspeicher defekt ist.
Das äußert sich dadurch dass sich neuere Enigma2 Images nicht mehr flashen lassen.
Ich habe Hyperion v1 über Spark geflasht, ging bei so vielen anderen Pinguluxen auch.
Hier lässt es sich auch flashen, aber nicht mehr booten.
Nehme ich nun ein altes Nebula v2 kann ich es problemlos flashen und auch booten, doch dann ohne jegliche Ankündigung stürzt der Receiver ab, kein GreenScreen, sondern einfach keine Reaktion mehr, dann hilft nur noch Hauptschalter aus und wieder ein.

Also gehe ich davon aus dass eine Zelle weiter hinten im Speicher kaputt ist.

Ich habe noch Garantie und würde den Receiver gerne einschicken. Enigma2 habe ich per Plugin gelöscht.
Leider ist jetzt so viel Speicher bei Spark frei dass ich es nicht schaffe ihn abzuschießen.

Und der Händler hätte gerne eine Anleitung wie man den Fehler hervorruft.

Daher jetzt meine Frage:
Wie schaffe ich es in Spark den Speicher so auszulasten dass er auf die tote Zelle/den Speicher voll schreibt?

Vielen Dank schon mal.

Mit freundlichen Grüßen.

Dr.H8Ball

 

[Daggi_Duck]

AW: Pingulux in die Knie zwingen

Spark und Enigma2 sind zwei vollkommen getrennte und festliegende Adressbereiche im Flash-Speicher. Wenn jetzt wieder Enigma2-Firmwares funktionieren ist doch alles gut.

Das Problem muss etwas anderes gewesen sein. Die NAND Flash-Chips sind extra so gemacht, dass sie defekte Bereiche (Bad Sector) haben können und ein Defektmanagment sort dafür, dass dies die Funktion nicht beeinträchtigt. Wichtig ist nur, dass man keine Komplett-Backups eines anderen Receivers vom gleichen Modell flasht, da jeder NAND-Chip an anderen Stellen defekte Sektoren haben kann. Insbesondere bei den PKT-Firmwares muss man da skeptisch sein, weil diese oftmals Komplett-Backups sind.

 

[dr.h8ball]

AW: Pingulux in die Knie zwingen

Wie bekomme ich dann PKT drauf ohne dass ich ein komplettes Backup einspielen muss? Und wieso fällt er in unregelmäßigen Abständen aus?

Vielen Dank schon mal für die sehr ausführliche Antwort.

 

[Alex]

AW: Pingulux in die Knie zwingen

Hab's hier hochgeladen: Link ist nicht mehr aktiv.

 

[Daggi_Duck]

AW: Pingulux in die Knie zwingen

... Und wieso fällt er in unregelmäßigen Abständen aus?

...

Weil schon bei der Herstellung der NAND-Chips praktisch alle Chips ein paar defekte Sectoren und das bei jedem Chip an unterschiedlichen Adressen haben. Das liegt an der hohen Speicher-Kapazität/Dichte dieser NAND-Chips und deshalb gibt es eben ein Defekt-Managment in den Chips selbst. Aber dieses Defekt-Management funktioniert nur dann richtig, wenn man eben kein direktes Backup eines anderen Flash-Chips 1:1 flasht. Sonst läuft man Gefahr, dass Teile der Firmware (ein paar Bytes) in defekten Sectoren landen, waseben Probleme bereiten kann, aber nicht muss. Hatte mal selber bei einem Pingulux mit einem PKT-Backup als "Image" den NAND Flash-Chip sehr durcheinder gebracht, so dass Sectoren als defekt markiert waren, die gar nicht defekt waren, und zum Schluss für defekte Sektoren gar keine Reserve-Sektoren mehr zur Verfügung standen. Kann man sich alles mit u-boot Konsolen-Befehlen genau anzeigen lassen und auch mit etwas Mut zum Risiko wieder reparieren (Flash-Chip komplett neuinitialisieren:

nand info - show available NAND devices
nand device [dev] - show or set current device
nand read[.jffs2] - addr off size
nand write[.jffs2] - addr off size - read/write `size' bytes starting
at offset `off' to/from memory address `addr'
nand erase [clean] [off size] - erase `size' bytes from
offset `off' (entire device if not specified)
nand bad - show bad blocks
nand dump[.oob] off - dump page
nand scrub - really clean NAND erasing bad blocks (UNSAFE)
nand markbad off - mark bad block at offset (UNSAFE)
nand biterr off - make a bit error at offset (UNSAFE)

 

[dr.h8ball]

AW: Pingulux in die Knie zwingen

Bist du zufällig Teil des PK Teams?

 

[Daggi_Duck]

AW: Pingulux in die Knie zwingen

Nö, hatte nur mal ein derartiges PKT-Image auf dem Pingulux. Es ist auch nicht so, dass alle PKT-Images Vollbackups sein müssen, kann gut sein, dass das, was ich mal versucht habe, nur eines war. Aber "das gebrannte Kind scheut das Feuer" und da es genügend andere, gut funktionierende Firmwares gibt, probiert man sowas nicht noch mal.

 

[dr.h8ball]

AW: Pingulux in die Knie zwingen

Vielen Dank schon mal für diese sehr ausführliche Antwort, im neuen Jahr habe ich die Zeit um mich mit dem Receiver zu beschäftigen.
Dann werde ich auch mal im Bootloader arbeiten.
Eine Frage noch, das Image ist über ein Jahr ohne Probleme gelaufen, und dann kam es schlagartig.
Vielleicht hast du dazu auch noch so eine gute Idee.

Mit freundlichen Grüßen.

Dr.H8Ball

 

[Daggi_Duck]

AW: Pingulux in die Knie zwingen

Ist vollkommen unerklärlich, warum die Spark-Receiver manchmal einfach den Flash-Speicherinhalt zermöllern. Ist aber auch bei anderen Receivern mit den ST40/SH4-Cores zu beobachten. Könnte an der Nutzung der Receiver und den Eigenschasften der verwendeten Firmwares liegen. Dann wahrscheinlich im Zusammenhang mit dem Yaffs2-Dateisystem und vermehrten Schreibvorgängen im Flash-Speicher. Nicht ohne Grund verwendet man heute vermehrt dass UBIFS Dateisystem insbesondere bei NAND-Flash Chips. Das wird den Eigenschaften der NAND-Flashs besser gerecht, ist aber für die Firmware-Programmierer komplizierter in der Handhabung.

 

[dr.h8ball]

AW: Pingulux in die Knie zwingen

Hab's hier hochgeladen: Link ist nicht mehr aktiv.

Was du da hochgeladen hast war Neutrino, hat er zwar problemlos gebootet, aber ich wollte doch Hyperion

 

[Alex]

AW: Pingulux in die Knie zwingen

Muss ich noch mal prüfen, wenn ich daheim bin. Das Hyperion müsste auch in der DB sein

Von meinem Telefonierknochen geschickt

 

[dr.h8ball]

AW: Pingulux in die Knie zwingen

Das in der Datenbank hat den gleichen Namen wie deine Datei, ist aber das richtige. Bin auch gerade schön am flashen über die Fronttasten.
Wenn jetzt noch VPN läuft ist alles gut.

Leider klappt es mit dem VPN noch nicht so wie es soll.

Mon Jan  6 17:04:58 2014 ROUTE default_gateway=192.168.88.1
Mon Jan  6 17:04:58 2014 Note: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Mon Jan  6 17:04:58 2014 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Mon Jan  6 17:04:58 2014 Cannot allocate TUN/TAP dev dynamically
Mon Jan  6 17:04:58 2014 Exiting

Die Datei ist da

spark:/etc/openvpn# ls -alF /dev/net/
drwxr-xr-x    2 root     root            60 Jan  1  2000 ./
drwxr-xr-x    8 root     root         12460 Jan  1  2000 ../
crwx------    1 root     root       10, 200 Jan  1  2000 tun
spark:/etc/openvpn#

Also wenn ich mir mit "more" den Inhalt der tun.ko anschaue, kann ich in dem lesbaren Text entnehmen dass die Kernel-Version die richtige ist. Leider kenne ich mich noch nicht gut genug in der Materie aus um zu sagen was da falsch ist.