yaffs2-Image

[Joker7]

...sehe grad bei Spark ein e2yaffs2.img...hats schon jemand getestet/ausprobiert ?

...und vorallen wie wird das geflasht?.... brauchts dafür ein Telnet-Script wie z.B. fürs "Evo-Image"....

[bonkel]

die befehle findest du im duckbox git ...unter flash/spark/extras/

[thomas]

wer nicht weiß was er da tut Finger weg von Yaffs - es gab genug kaputte Receiver durch evolux

jffs2 mit sumtool ist genauso schnell

[neipe]

sumtool ?

lass uns net im dunkeln sterben :cool:

[neipe]

aha google is dein freund

link (http://www.embedded-linux.co.uk/tutorial/jffs2-summary)

[karlchen1963]

genauso schnell nicht aber schneller wie normale gepackt.

Und ich meine du braucht beim yaffs jetzt keine scripte mehr wenn du es ähnlich wie Pinky machen würdes denn der macht es doch jetzt auch so wie bei der Sparksoft das erst ein ramdiskimage geladen wird. Hier mal die erklärung von schufti evtl. könnt ihr was damit anfangen.


warum ist eigentlich noch keiner auf die Idee gekommen, es so wie im Original zu machen?
(obwohl ich ja schon gehört habe, dass Fulan meint, das sei unmöglich)

sieht man sich das original Spark image an und die div startups, so sieht man folgendes:

1) das mImage ist ein extended uBootimage (Kernel+Ramdisk)
Code:
Image Name: Kernel-Ramdisk-Image
Image Type: SuperH Linux Multi-File Image (gzip compressed)

2) in der Ramdisk wird ein Minilinux gebootet, dass schaut ob es sich um einen "regulären Boot" oder eine "update session" handelt.
3) ist es ein regulärer Boot, wird das yaffs2 als root gemounted und normal gestartet
4) ist es ein Update, so wird das Image ins Flash kopiert und dann gestartet

(aus dem Gedächtnis, ist schon ne Zeit her, dass ich das angeschaut habe)

Vorteil: das ist voll transparent (keinerlei Bootargsfummelei nötig) zum flashen über Reci-Buttons, da uImage und user_esjffs.img in den gewohnten Formaten vorliegen. Ist es ein uImage mit Ramdisk, so wird im 1st stage Linux der jffs2 Inhalt als yaffs2 ins flash kopiert andernfalls liegt er als jffs2 dort für "normale" kernel-images.

aber auch pinkys image könnte ohne Bootargsfummelei auskommen, wenn auc h weiter über orig. Spark geflasht werden müßte (btw. Amiko uBoot kann yaffs2 Partition flashen) indem er "den" Bootparameter (rootfstype=yaffs2) einfach in Kernel-setup fix (quasi als override) einkompiliert ...

just my 2¢

P.S.: nandwrite sollte - wenn es korrekt implementiert ist - korrekt mit den .oob umgehen. Aber natürlich können Zweifler die yaffs2 Partition einfach mounten, das (ja auch jffs2) image über loop mounten und einfach 'umkopieren', dauert kaum länger.

P.P.S.: und als ÜberDrüberFeature könnte so ein Minilinux auch gleich gucken, ob eine mountbare root-Partition am Stick ist und die booten, dann kann man neue Images im "Stickumdrehen" testen (solange der Kernel gleich bleibt)

[thomas]

Sumtool schreibt ans Ende von jedem Flashblock eine Art Zusammenfassung. Beim mounten muss dadurch nur noch diese Zusammenfassung eingelesen werden und nicht der komplette Block. Das bringt bis zu 500% Geschwindigkeitsvorteil beim mounten. Je größer das Image desto größer ist der Vorteil.
Striper
Spark stm24_209 mit Enigma2-Pli
45 Sekunden bis zum Bild.

[bonkel]

das image wird dank schischus script ja schon mit sumtool bearbeitet.....