Hallo, vorgeschichte: da ich für ein projekt die Samsung S3C2410 und/oder S3C2440 einsetzen werde, musste ich ein paar dev boards besorgen. Irgendwan haben festgestellt das eine NAND flash kopie nicht einfach ohne weiteres wieder restored werden kann. Der grund dafür sind die OOB blocks (spare area) die z.b von dem YAFFS/YAFFS2 filesystem mitbenutzt werden. Solange es nur ein bootloader oder irgendwelche bin codes sind in dem Flash ist ein backup/restore mit den üblichen tools (h-jtag, sjf2410, sjf2440, sjf2440_rs232, Ulink) möglich und funktionsfähig, sobald aber informationen in dem OOB stehen wird schon der flash fs driver die blocks als "bad markieren" da der inhalt nicht zum OOB passt. Man kann natürlich auch u-boot benutzen oder supervivi und einen backup/restore über USB machen. Leider in meinem projekt muss ich einen custom bootloader benutzen, so wäre für mich eine programmierung von mehrere geräten sehr umständlich. Auch für private zwecke wird man nicht immer supervivi benutzen dürfen (da es closed source ist und nicht alle boards damit lauffähig sind) oder können (da z.zt nur S3C2440 supported) die treiber: Am ende habe ich mich entscheiden den H-Jtag USB zu kaufen und die driver so zu modifizieren das auch die OOB blocks mitgelesen werden und mitbeschrieben beim restore. Natürlich funktionieren diese treiber auch mit LPT wiggler, 64MB backup dauert zwar 3 stunden (mit h-jtag usb 6min), ist aber unter umständen schneller als mkyaffsimage falls man z.b. root fs angepasst hat (je nach dem wie fit man ist mit linux tools). In dem anhang befinden sich fertig compilierten treiber : Driver10020 - für S3C2410 und K9F1208 Driver11020 - für S3C2440 und K9F1208 ( die müssen ins C:\H-JTAG\FDevice\NAND-FLASH\Drivers\) und die jeweiligen config dateien : S3C2410+K9F1208+OOB S3C2440+K9F1208+OOB (die müssen ins C:\H-JTAG\FDevice\NAND-FLASH\) Nach dem H-jtag/h-flasher neu gestartet wird erscheinen die in dem NAND-FLASH menu (dabei bleiben die evt. originalen immer noch vorhanden) Die treiber sind für H-Jtag/H-Flasher 1.0, sollten aber mit v09.2 funktionieren. Bei der version preview_v1.0 ist zwar die LPT unterstüzung abgeschaltet, ich habe eine internal version freundlicherweise von dem developer bekommen - die kann LPT und USB (falls jemand sucht bitte um PN). Für andere flash groessen müssen entsprechend die configs und flash.c / flash.h angepasst werden (grossere NANDs haben OOB von64byte statt 16byte wie der K9F1208). Ich der zip file befinden sich die original und modifizierte sources, so kann jeder schnell verstehen wie h-jtag/h-flasher arbeitet und wo die änderungen vorgenommen werden müsen. Ich benutze nur die K9F1208 daher habe keine anderen compiliert. Übrigens, für besitzer von OpenJTAG (von 100ask.net) - entsprechende änderungen um OOB zu supporten werden die tage eingepflegt in den oflasher (weiterentwicklung von sjf24x0_rs232 - für linux und windows). Und natürlich, ein NAND flash dump erstellt mit den modifizierten treibern kann auch über supervivi restored werden. gruss Thomas EDIT: da S3C2410 oder S3C2440 weniger aussagekräftig ist, habe den Beitrag umbennant auf etwas mehr generic name. So kann ich auch weitere triebr, die inzwischen fertig und geetestet sind im selben Beitrag anhängen.
Ein weiterer treiber, diesmal für HY27UF082G2B (256MB flash) Den habe von hier ausgebaut [Beitrag "Re: Übersicht über preisgünstige elektronische Geräte für reverse-engineering"] um den inhalt zu dumpen/bearbeiten. Es war schneller auszubauen und in dem FriendlyArm mini2440 einzubauen (habe da ein TSSOP48/56 sockel drin) als sich mit dem seltsamen debug port des Tchibo-bilderrahmen zu beschäftigen. Treiber 11040 ist für mit OOB Treiber 11041 ohne OOB blocks
Moin moin Thomas, ich stehe vor einem ganz ähnlichen Problem: ich habe bei einen mini2440 (64MB NAND) einen neuen Kernel aufgespielt und auch das root-Dateisystem deutlich geändert und an die Bedürfnisse meiner Software angepasst. Nun muss ich das Image sichern und mit möglichst wenig Arbeit und Zeitaufwand auf mehrere minis verteilen. Ich habe zunächst mit den von FriendlyArm mitgelieferten Tools versucht, das gesamte NAND, also Kernel und Dateisystem in einem Zug zu ersetzten: Backup über USB von vivi (Option u) auf dnw.exe in Windows. Das sah auch zunächst ganz gut aus. Das Restore auch über dnw.exe und vivi (Option r) hat dann aber nicht geklappt. Kann das überhaupt gehen? Nun schreibst Du, dass Du das NAND mit H-JTAG und den modifizierten Treibern gesichert und zurückgeladen bekommst. Wie sind da die Einstellung bei H-JTAG zu machen? Noch 'ne Frage: ich habe nun ein Board, das sich nach so einer missglückten Restore-Aktion vom vivi nicht mehr formatieren lässt und jede menge "bad blocks" anzeigt. Könnte der von Dir beschriebene Effekt der überschriebenen OOBs sein. Wie bekommt man das wieder hin? Würde es reichen, ein sauberes Image mit dem J-Tag draufzuspielen? Gruß Joachim
Joachim K. schrieb: > Moin moin Thomas, > ich stehe vor einem ganz ähnlichen Problem: ich habe bei einen mini2440 > (64MB NAND) einen neuen Kernel aufgespielt und auch das root-Dateisystem > deutlich geändert und an die Bedürfnisse meiner Software angepasst. > Nun muss ich das Image sichern und mit möglichst wenig Arbeit und > Zeitaufwand auf mehrere minis verteilen. genau, dafür habe letztendlich den h-jtag usb gekauft und die treiber angepasst (muss sagen der h-jtag developer war auch sehr hilfreich). > Ich habe zunächst mit den von FriendlyArm mitgelieferten Tools versucht, > das gesamte NAND, also Kernel und Dateisystem in einem Zug zu ersetzten: > Backup über USB von vivi (Option u) auf dnw.exe in Windows. Das sah > auch zunächst ganz gut aus. Das Restore auch über dnw.exe und vivi > (Option r) hat dann aber nicht geklappt. Kann das überhaupt gehen? per software - backup/restore gehen nur mit supervivi, restore angeblich auch mit spezielen u-boot version. Problematisch ist beim unterschiedlichen boards und verschiedenen supervivi versionen. Mir war persönlich zu unsicher, daher mache ich full backups/restore nur über h-jtag - da der keine probleme hat mit partition einstellungen, kaputten oob's oder unterscheidlichen NANDs. > Nun schreibst Du, dass Du das NAND mit H-JTAG und den modifizierten > Treibern gesichert und zurückgeladen bekommst. Wie sind da die > Einstellung bei H-JTAG zu machen? Im prinzip h-jtga/h-flasher starten, im h-flasher eine config laden, z.b. "S3C2440+K9F1208.hfc" - damit die init scripts vorhanden sind. Dann im flash selection "S3C2440+K9F1208+OOB" wählen und das war schon. Jetzt zum backup im "4. Programming" auf den ic symbol neben Read clicken "also read all" - dann bekommst du eine file mit OOB blocks. Zum restoren im selben dialog die selbe file als src wählen und ab block-0000/page-0000 programmieren. > Noch 'ne Frage: ich habe nun ein Board, das sich nach so einer > missglückten Restore-Aktion vom vivi nicht mehr formatieren lässt und > jede menge "bad blocks" anzeigt. Könnte der von Dir beschriebene Effekt > der überschriebenen OOBs sein. Wie bekommt man das wieder hin? Würde es > reichen, ein sauberes Image mit dem J-Tag draufzuspielen? ja, dann sind die OOBs mit was auch immer beschrieben, im j-flash im "4. Programming" auf Erase - Entire chip" klicken. Evt, falls irgendwelche blocks wirklich kaputt sind, in "5. PGM Options - NAND Flash" die funktion relocate benutzen. Wenn die blocks wirklich kaputt sind wird j-flasher beim formatieren es melden, die muss man sich dann merken und verschieben. Übrigens, wenn man mehrere NANDs auf die art programmiert, kann schon vorkommen das manche kaputte blocks haben, allerdigns erkennt es h-flasher und bricht dann ab - also braucht man sich keine sorgen machen das ein restore in kaputten blocks landet und nichit funktionsfähig wird.
Moin moin Thomas. Erst mal besten Dank für Deine ausführliche Antwort. Ich habe bis zum 6.3. kaum Zeit, an dem Projekt weiter zu machen, daher die späte Antwort. Immerhin habe ich die aktuelle Version von h-jtag gezogen, Deine Treiber eingespielt und den Download des aktuellen Flash gestartet. Das klappt auch alles prinzipiell, nur die von Dir gemessene Downloadzeit von 3 Stunden mit dem LPT-Dongle kommt bei mir gar nicht hin. Ich musste nach etwa 6 Stunden abbrechen, da war gerade mal 1/3 der 64MB gesichert. Vermutlich liegt es daran, dass ich ein Linux-System habe und h-jtag in einer VMWare-Maschine mit Windows starte. Es geht aber auch nur darum, festzustellen, ob der Weg grundsätzlich für mich funktioniert. Wenn das klar ist, ist es auch kein Problem, den USB-Adapter zu kaufen, mit dem es ja wohl erheblich schneller geht. >per software - backup/restore gehen nur mit supervivi, restore angeblich >auch mit spezielen u-boot version. Problematisch ist beim >unterschiedlichen boards und verschiedenen supervivi versionen. Mir war >persönlich zu unsicher, daher mache ich full backups/restore nur über >h-jtag - da der keine probleme hat mit partition einstellungen, kaputten >oob's oder unterscheidlichen NANDs. Ich habe es mit supervivi probiert. Keines meiner Boards hat noch funktioniert, nachdem ich ein zuvor gesichertes Image zurückgespielt habe. Entweder mache ich was falsch, oder es geht grundsätzlich nicht. Ich werde das nicht weiter verfolgen. Die J-Tag - Methode scheint mir auch aus den von Dir genannten Gründen sicherer und problemloser. Besten Dank noch mal. Gruß Joachim
Joachim K. schrieb: > Vermutlich liegt es daran, dass ich ein Linux-System habe und h-jtag in > einer VMWare-Maschine mit Windows starte. ja so ist das, native zugriff auf H-JTAG->LPT eht mit max 6KB/s, in der vmware natürlich viel langsamer. > Methode scheint mir auch aus den von Dir genannten Gründen > sicherer und problemloser. > Besten Dank noch mal. > eigentlich die einzige methode wenn für klein-serien / viel benutzer bereich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.