[gelöst] nfiwrite

  • Hi !


    Wie in dem Thread zu den ubifs Problemen erklärt erleben wir derzeit die Grenzen des Bios und damit auch von DreamUP sowie dem writenfi beim Flashen.


    Da es ein malloc macht um die Daten zu buffern bevor es schreibt geht das nur bis der Box das Memory ausgeht.


    Damit hat die 8000 bereits das Problem das der Flash größer ist als das was man eigentlich flashen kann, und auf der 7020HD sieht es nicht viel besser aus.


    Das nandwrite aus den mtd-utils hat diese Limitierung nicht, weil es einfach sequentiell das file ausliest und aufs mtd device rauschreibt.


    Das aktuelle dFlash kann daher auch jetzt schon mit nandwrite flashen, um diese Limitierung zu umgehen.


    Dabei wird allerdings das nfi file vom dFlash mit nfidump zuerst in boot und root file zerlegt und bewusst der secondstage loader gar nicht geflasht obwohl das mit writenfi natürlich auch ginge.


    Was ich jetzt machen könnte und auch der Grund für diesen Thread ist, wäre statt das mit 3 verschiedenen Binaries zu machen das in ein einziges nandnfiwrite binary zu mergen und das auch mit der klibc zu compilieren und linken so das es ein relativ kleines binary ist, das man auch ganz ohne ein root Filesystem benutzen kann.


    Die ganzen Codeteile dafür habe ich mehr oder weniger fertig rumliegen, insofern wäre das für mich relativ leicht zusammenbaubar.


    Die Frage ist allerdings ob das Sinn macht, von DMM und/oder den Usern gewünscht ist, etc...


    Daher diskutieren wir das einfach mal ... ein bisschen.


    Und bitte nicht vergessen nandwrite ist mehr oder weniger Industriestandard um NAND Flash zu schreiben.


    LG
    gutemine

    4 Mal editiert, zuletzt von Lost in Translation ()


  • Wie gewuenscht hier weiter.


    Ich wollte NICHT vorschlagen, die eierlegende Wollmilchsau zu implementieren, sondern
    EINEN Weg, mit dem man auch ohne Image im Flash von einem "externen" Geraet ein
    Image booten kann und NICHT auf WEITERE externe Tools angewiesen ist.
    Z.B. also nur von einem USB-Stick (meinetwegen auch nur in EINEM der USB-Slots).
    Egal wie einfach es auch mit externen Tools sein kann; der "gemeine" User an sich, ist
    haeufig damit ueberfordert, selbst die einfachsten Dinge fehlerfrei hinzubekommen.
    Stick rein und genau das machen, was man auch mit dem Flash beim Aufspielen eines
    neuen Images macht, sollte das Ziel sein. Keinen zweitern/dritten... Weg das Image auf
    die Box zu bekommen, sondern nur EINEN und den ab Werk ohne Nachruestung/Plugins.


    So halt mein Vorschlag/Wunsch/Gehirnfurz/Bloedsinn ....

    DM900 SS, DM8000SSSS
    Kein Support per PN! Nutzt das Forum zum Fragen, dann haben auch andere etwas davon.

  • Sagen wir mal so, mir wäre es absolut egal in nan(nfi)write die root auf den stick und den Rest in den Flash zu schreiben, allerdings vergisst du das du auf einem USB stick oder CF oder SD obwohl da Flashchips drinnen sind nicht so einfach ein echtes Flashfilesytem drauf machen kannst weil sie sich als Blockdevices darstellen (wie Harddisken).


    DAS geht NUR mit dem block2mtd device Treiber oder evt. dem nandsim Treiber und beide gibt es nur bei laufenden Linux im/vom Kernel aus.


    Außerdem kann das BIOS nur jffs2 und FAT und eine Liux root in FAT geht nicht praktikabel weil FAT nicht alle nötigen Sachen Dinge die ein Linux benötigt supportet.


    Das einzige was du machen kannst ist in FAT ein containerfile abzulegen und von dort mit block2mtd zu booten, das ist aber genau das war rambo macht. Die Variante gleich auch zu konvertieren und ext4 im container zu verwenden heisst LowFAT.


    Ich weis schon was du möchtest, nur wie schon gesagt die Funktionailtität die die dann im Bios brauchst ufert dann aus bis es nicht mehr praktikabel ist.


    Insofern sind auch Wünsche für die Zukunft da wenig sinnvoll, weil wenn dann eher Dinge wie uboot & Co eingesetzt würden, weil die können schon all diese Dinge wie partitionieren, Filesystemsupport,... NUR sind die Open Source und ich glaube nicht das DMM da Treiber für all Ihre devices dazu machen werden die dann auf Grund der Lizenz OpenSource sein müssten.


    Das nand(nfi)write zielt einfach ab die aktuellen Probleme mit writenfi zu fixen, und das schnell und ordentlich, weil wie gesagt du hängst dafür nur vorhandenen code zusammen um ein binary zu bekommen das Flashen kann (und eben auch auf andere devices falls gewünscht)

  • ...
    Ich weis schon was du möchtest, nur wie schon gesagt die Funktionailtität die die dann im Bios brauchst ufert dann aus bis es nicht mehr praktikabel ist.
    ...


    Ich will es nochmal festhalten: KEINE Loesung, die mit allem tut und mit allem zurecht
    kommt, sondern eine Loesung, die genau EINEN Weg fuer genau EIN Device mit genau
    EINEM Format so unterstuetzt, dass es wie internes Flash aussieht bzw. sich so verhaelt.
    Meinetwegen soll das Device/Stick so vergewaltigt werden, dass nur die Box damit etwas
    anfangen kann. Hauptsache ich kann irgendetwas verwenden, was das interne Flash so
    substituiert, dass die Box sich "normal" verhaelt, falls das Flash mal den Geist aufgibt
    (oder zu klein geworden ist).
    Nicht mehr, aber auch nicht weniger.

    DM900 SS, DM8000SSSS
    Kein Support per PN! Nutzt das Forum zum Fragen, dann haben auch andere etwas davon.

  • Lies nochmals was ich dir geschrieben hat - KEIN normales Flashdevice sieht ohne entsprechede treiber wie echter NAND Flash aus.


    Und auf ein Filesystem welches das bios nicht verstehst ist nicht so einfach 'Flashen' bzw. mit Image befüllen.


    Es gäbe noch einen Ausweg aus dem Dilemma den ich gerade getestet habe - du kannst auf ein rawdevice schreiben und das dann mit block2mtd beim booten mit dem Kernel mounten.


    Ich war nicht umsonst so lästig bis alle dafür nötigen Patches im OE waren.


    Aber selbst dann musst du entweder die kernel Parameter entsprechend umsetzen oder einen initramfs patch haben der schnell alle Partitionen abchecked, um zu sehen ob wo ubifs drauf ist und dann davon statt vom Flash zu booten.


    Beim ubifs geht das relativ simpel weil auf den ersten 3 bytes steht da immer UBI :smiling_face:


    Den code bringst du halbwesg realistisch noch im Bios unter, womit wir aber wieder bei dem Punkt wären das es nicht im Bios sein muss.


    Weil kein Mensch sagt das die Dreambox unbedingt mit dem WebIF flashen gehen muss und den stick mit so einer ubifs root am rawdevice zu beschreiben kannst du am PC genauso.


    Aber auch da gilt wahrscheinlich das man es erst glaubt wenn man es sieht :smiling_face:


    Ich mach jetzt mal rambo fertig fürs ubifs, weil das ist ein prima Test ob der block2mtd wirklich stabil mit ubifs läuft, wenn es im Filesystem mit container geht ist das rawdevice zu verwenden dann nur ein kleiner Schritt, vor allem geht es dort auch nur native mit dem was im kernel ist, weil wirklich was bringen tut das nur wenn du /dev/mtdblock3 gar nicht mehr mountest, was bei rambo aber der Fall ist da dort ja das binary als init ersatz agiert.


    Also eines nach dem anderen ...

    2 Mal editiert, zuletzt von Lost in Translation ()

  • Und wieder hast Du da eine "intelligente" Loesung vorgeschlagen, die mit allem
    Moeglichen (und Unmoeglichem) zurecht kommen soll.
    Ich habe nie gesagt, dass der Stick genau wie NAND angesprochen werden soll, nur
    dass der Weg, wie man ein Image darauf bekommt, der gleiche wie mit NAND Flash
    sein sollte. Dabei sind keine Tools ala dFlash oder Konsorten gemeint, sondern der
    Dummy-0815-Weg ueber booten, Knopf druecken, Web-Interface aufrufen, Image
    waehlen, Button klicken. Meinetwegen wird halt etwas emuliert (ist aber nicht das
    Entscheidende).
    Keine X Partitionen auf Y Devices, wo erst das richtige erkannt werden muss oder
    sonstigen "Luxus".
    Einfach etwas festlegen, was erfuellt sein muss, damit es tut und nicht versuchen,
    mit jedem Exoten zurecht zu kommen.
    Nicht falsch verstehen; ich habe nichts gegen die Wollmilchloesungen, aber eine
    Loesung, die auch OHNE PC tut, waere halt der Bringer fuer alle nicht PC Affinen.

    DM900 SS, DM8000SSSS
    Kein Support per PN! Nutzt das Forum zum Fragen, dann haben auch andere etwas davon.

  • Eines der Dinge die ich gelernt habe ist das die besten Lösungen oft nicht so sind wie die Benutzer sie haben wollen, also schränkt Euch nicht unnötig ein.


    Außerdem kann das Bios das jetzt schon was du willst - also was anderes booten beim Knopfdrücken. Du kannst von einem LowFAT stick zum Flashen booten indem du die down oder bei den boxen die nur die Power taste haben diese gedrückt hältst wenn der stick drann ist - ganz ohne irgendwas im Bios umstellen.


    'besser' können es die mitbewerber auch nicht und da macht das blöde bios auch nur mit nandwrite files vom FAT in den Flash, wenn ich statt einzelnen files pro Partition das auf einmal kann ist das bereits eine Verbesserung.


    Sonst bin ich böse und bringe den Dreamboxen bei ala Vunderbox geflasht zu werden - das wäre sogar ziemlich simpel weil 90% davon geht mit LowFAT ja jetzt schon :smiling_face:

  • immer wieder was neues und anderes überfordert die meisten "Normaluser" schon, dabei ist es egal wie das heißt. :smiling_face:

    mfG
    Amelie


    DM8000 | DM 7020HD | DM500 HD | DM 7025 | DM 600 |

  • @gutemine:
    So langsam verstehe ich, was ich falsch zum Ausdruck gebracht habe.
    Es ist nicht immer leicht, wenn es schon Loesungen gibt, den Unterschied
    zum eigenen Vorschlag so auf den Punkt zu bringen, dass jemand, der
    die Loesungen gebaut hat versteht, was dabei anders sein soll.
    Mir geht es nicht ums Flashen an sich, sondern um den Betrieb eines
    Images OHNE den internen Flash zu verwenden (fuer den Fall eines
    nicht behebbaren Defekts (z.B. zu viele Bloecke kaputt) oder wegen
    Groessenproblemen). Dabei soll auch keine Super-Duper-fuer-jeden-DAU-
    geht-immer-Loesung rauskommen.
    Die "BIOS-Loesung" soll "nur" ermoeglichen, dass ich, per einzelnem Schalter
    im BIOS (und nicht durch Druecken von Tasten beim Booten oder blosses
    Einstecken von Devices oder Aenderung der Kernelparameterleiste), eine
    andere Bootquelle bestimme, die dann fuer den Benutzer so eingebunden
    wird, dass es sich wie internes Flash "anfuehlt". Dabei soll/muss keine immer
    und in jedem Fall und fuer jedes Device funktionierende Loesung zur
    Verfuegung gestellt werden, sondern nur das Device angesteckt und der
    Schalter im BIOS umgelegt werden, in den Flashmodus gebootet werden
    und ein Image mit dem WebInterface auf das Device gebracht werden.


    Kurzanleitung:
    Schalter im BIOS auf Flash -> Kiste bootet vom Flash, egal ob ein Device
    da ist oder nicht.
    Schalter im BIOS auf Device -> Kiste bootet vom Device; ist da kein Image
    -> Kiste stoppt mit Fehlermeldung (KEIN Booten vom Flash) und laesst
    nur noch ein Flashen via WebInterface zu.


    KEINE Vorbereitung mit dem PC; Device rein, BIOS umschalten und gut ist es.
    Keine Ruecksicht auf Daten auf dem Device oder Lesbarkeit am PC.
    Halt eine gute, alte proprietaere Loesung, wie anno dunnemals in der guten
    alten Steinzeit der IT. :winking_face:
    Denke ich zu kompliziert, oder habe ich es mir zu einfach gemacht?


    P.S.: Als damals LowFat rauskam, habe ich es mit Begeisterung genutzt.
    Es ist also nicht so, dass ich nicht wuesste, wie es von Dir schon ansatzweise
    so implementiert wurde; mir waere es aber auch Recht, wenn DMM da eine
    "offizielle" Loesung anbietet, bei der man sich dann nicht mehr anhoeren
    muss, dass man doch erstmal das Image ins Flash schreiben soll, wenn man
    Support bei einem Problem haben will.Passiert zwar seit OE 2.0 kaum noch,
    aber wer weiss was noch kommt?

    DM900 SS, DM8000SSSS
    Kein Support per PN! Nutzt das Forum zum Fragen, dann haben auch andere etwas davon.

  • Was Ihr immer mit Euren offiziellen Lösungen habt, ich warte nur bis mal wer vorbeikommt und von DMM einen offiziellen Camambert haben will der sein ganzen Kartenspiel versteht.


    Egal, sobald du Bios umstellen musst hast du trotzdem wieder deinen Inhibitor. Und DMM/das Bios kann nicht ohne Rücksicht auf Verluste auf USB devices images machen.


    Und die Bios Einstellung gibt es ja längst wo du von Flash auf USB umstellen kannst ... nur dorthin 'Flashen' kann das Bios halt nicht, was aber bei einem device das du abstecken kannst sowieso nur begrenzt Sinn macht.


    Aber wir drehen uns im Kreis, wie ich schon geschreiben habe mache ich wenn das rambo fertig getestet ist auch eine rawdevice variante und dann sehen wir weiter.


    LG
    gutemine

  • Apropos offizielle Lösung, DMM verwendet das writenfi ja jetzt auch nicht mehr für das SSL schreiben, das dreambox-secondstage macht das jetzt auch mit nandwrite.


    Insofern ist writenfi wahrscheinlich sowieso tot und man könnte sagen nandwrite ist jetzt 'offiziell' :smiling_face:

    Einmal editiert, zuletzt von Lost in Translation ()

  • Kurzer Zwischenbericht: Ich habe jetzt die ganzen nötigen Binaries in ein einziges nfiwrite zusammengeschruabt und mit klibc statisch gelinkt so das es auch im Single user modus und ganz ohen weitere libs und binaries funktioniert.


    Im Moment habe ich erstmal implementiert das ein simple nfiwrite imagename.nfi das gesamt nfi in den Flash schreibt. Mit --loader --boot --root kann man steuern ob man nur loader, boot oder die root flashen will.


    Die Frage ist jetzt ob ich mir noch die Arbeit machen soll das man bei -boot und -root auch noch Partitionen angeben können soll, wobei /boot dann in FAT formatiert sein müsste (damit es bootbar ist) und /root als rawpartition das man mit block2mtd und ubifs booten kann (jffs2 macht bei den üblichen USB/SATA Stickgrößen einfach keinen Sinn). Wobei zur Not kann ich auch noch das mkdosfs ins nfiwrite integrieren, darauf kommt es dann auch nicht mehr an.


    Und falls gewünscht könnte ich auch noch ein --single reinmachen das die box in den Single user modus bringt und / auf read-only remountet und ein -force das anschließend einen sofortigen Reboot erzwingt. Dann kann das binary praktisch alles was das dFlash heute beim Flashen macht, allerdings mit einer Menge Binaries und Python und Shellcode.


    LG
    gutemine

  • Also das klingt wirklich sehr interessant!


    Was ist der Vorteil von ubifs auf USB - oder wäre das eher für SATA vorbehalten? ext3/ext4 auf USB/SATA macht keinen Sinn?


    Hat der "Single User Modus" auch Performance Vorteile gegenüber Dflash?

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • Sobald du ubifs auf USB machst musst du halt warten bis das device online ist - mit dem rootdelay kernel parameter kein problem, nur benutzen musst du den halt.


    Von SATA ist das halt nicht nötig womit es sofort weiter bootet.


    Und bei der heitigen Größe von Sticks ist das dann halt ein recht großes UBIFS, und z.B. wenn du nur eine 1GB Partition machst entsprechend flott.


    Ich habs auf meiner 500hd sogar mal testweise auf der sata Harddisk in die swappartition gemacht, geht auch wunderbar, nur sollte man dann halt keinen Filesystemcheck mehr machen, oder eigene parition dafür verwenden :winking_face:


    Aber Ihr müsst für das booten eigentlich nicht auf das nfiwrite warten, wie man ein ubifs aufs rawdevice schreibt und bootet ist oft genug beschrieben und mit der Freundlichen Suchmaschine aus der Nachbarschaft auch ganz leicht zu finden, ich habe das ja nicht erfunden :smiling_face:


    Und schaut dir das dflash.sh script an mit dem dFlash flasht - das bringt die box auch nur in den single user modus, remountet die root read only damit das was du ins Flashdevice schreibst nicht durch den filesystemsync beim anschließenden reboot wieder runiiert wird und scheibt dann einfach das nfi in den Flash (nur halt im Moment nur mit writenfi oder nachwrite). Genau deswegen habe ich es auch noch nicht eingebaut, weil um es im dFlash zu testen reicht das script auch. Nachdem das aber nur eine Handvoll codezeilen sind mache ich das halt auch nicht rein, dann kann es jeder der will direkt verwenden, auch ganz ohne Plugin.


    LG
    gutemine

  • Wieder mal Zeit für einen kleinen Zwischenbericht:


    Derzeit wird der SSL in einem Dreambox image ja auf ziemlich perverse Weise gemacht, das rohe bin steckt im ipk, daraus wird dann mit buildimage ein rawimage ohne dem üblichen NFI header gemacht unter Verwendung von mtd_debug um die Geometrie auszulesen, dann wird mit mtd_debug erased wobei auch dafür mit md_debug die Größe ausgelesen wird und dann wir mit nandwrite geschlashed.


    Also eigentlich 3 binaries und ziemlich viele implizite Aufrufe vom mdt_debug mit showinfo.


    Ich enhalte mich mal einfach eines Kommentars wie elegant diese Lösung ist :smiling_face:



    Dafür passiert auch nichts wenn man bad blocks im /dev/mtd1 hat - habs selber ausprobiert indem ich so viel ich konnte als bad markiert habe. leider hatte ich keinen echten bad block in diesem Flashbereich den ich als gut markierten hätte können um zu testen ob das sauber geandhabt wird, aber nachdem das in /dev/mtd3 problemlos geht nehme ich mal an das nandwrite auch das schaffen wird. Insofern ist das eine ziemlich saubere Lösung.



    Mein All-in-1 nfiwrite benötigt allerdings kein buildimage, weil es den loader aus jedem nfi rausstrippen kann (egal ob reines loader nfi oder komplettes image) und das showinfo und das erase vom dmt_info sowie nandwrite sind alles als routinen im binary drinnen. Wenn gewünscht kann ich aber auch das Flashen von secondstage*-.bin files noch ins nfiwrite reinmachen, das ist ja nur padden des Files.


    Das mit klibc gelinkte nfiwrite binary is jetzt 60k groß und kann mit einem einzigen Aufrufe den loader bei laufendem Betrieb schreiben. Im Prinzip macht es also genau das selbe wie das dreambox-seconstage ipk nur eben in einem einzigen binary.


    Insofern denke ich das es Euch gefallen wird.


    root und boot kann man damit auch schreiben, aber root halt auch nur im single user so wie derzeit beim writenfi modus weil sonst das filesystem korrupt würde.


    ABER beim Testen habe ich mir auch angeschaut was im ubifs so möglich ist - solange man den Flash nur zur Hälfte benutzt, also auf 8000 halt 128MB und bei der 7020hd halt 500MB könnte man das ubifs auch live ohne single user modus flashen indem man das neue volume als zusätzliches volume reinpackt, dann beim ersten boot die neue root auf rootfs umbenennt und die alte löscht bevor man die neue attached und weiterbootet. Nur dieses switchen müssten man in einem initramfs machen bevor die root attached wird.


    Die Frage ist halt ob an so einem on-the-fly Flashing Interesse bestünde?


    Und ja das jffs2 von /boot stört bei der Sache nicht weil es im laufenden betrieb sowieso nicht benutzt wird und man es ziemlich problemlos unmounten und neuschreiben kann.

    3 Mal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Hi,


    nur als info.. also das voodoo beim 2nd schreiben ist eigentlich nur nötig, weil es bei der 7020hd halt verschiedene nand flashes gibt... also 7020hd vs 7020hdv2.. also das nfi selber ist flash abhängig.. aber die feeds der 7020hd und 7020hdv2 sind halt identisch...


    Andere Lösung wäre gewesen dass wir für die 7020hd dann im secondstage ipk beide rein gepackt hätten.. aber naja.. das war auch nicht schön :winking_face:


    cu

  • Das verstehe ich natürlich, dann mache ich halt die Möglichkeit secondstage*.bin damit zu flashen auch noch rein, damit auch das funktioniert.


    Im Moment kämpfe ich ja eher noch mit dem Flashen der root im laufenden Betrieb, weil das ist eigentlich das interessante für die User.


    Mit dem read only remount von / im single user modues mit anschließendem reboot geht das zwar genauso wie im dFlash aber vielleicht fällt mir noch was besseres ein.


    Für mich ist das ja eher ein Forschungsbinary um die Möglichkeiten auszuloten, das Zusammenhängen der nötigen binaries war dazu halt ein notwendiges übel.


    Die ganzen main() auf routinen umzubauen mit den nötigen Parametern ist je relativ simpel, und den C code um die nfi beliebig zu zerstückel habe ich ja aus meinen anderen Projekten.


    Interessant wird es eigentlich erst jetzt wo es funktioniert damit zu flashen, weil jetzt kann man schauen was möglich ist.

    Einmal editiert, zuletzt von Lost in Translation ()

  • Jetzt habe ich allerdings noch eine Frage an die Devs:


    Wie schreibt das Bios den Freiplatz für boot und root. Beim Flashen läuft der Balken da ja sehr rasch durch.


    Beim Loader wird im postinst vom secondstage ipk ja erst /dev/mtd1 formatiert und dann nur das loader file geschrieben was nachdem es ja vom rawdevice geladen wird auch Sinn macht.


    Ich habe im nfiwrite das jetzt auch so implementiert, aber auch die variante die daten aus dem nfi bis zu größe von /dev/mtd2 und /dev/mtd3 auszuppolstern und auch diese zu schreiben. Dauert kaum länger und dadurch werden auch dort die Bad Blocks sozusagen bei jedem Flashen neu bestimmt. Wenn ich nur Erase mache kann es ja sein das trotzdem ein bad Block erst beim benutzen als bad erkannt wird und dann erst vom Betriebsystem markiert, in der Padding Variante würde das schon beim Flashen passieren.


    Welche Variante verwendet Ihr, bzw. das bios, weil ich würde die dann zum Default machen und die andere nur als Option.


    Soweit ist das binary nämlich fertig, ich bastle jetzt nur mehr an den command line options, derzeit sieht es so aus:


    --l loader flashen
    --b boot flashen
    --r root flashen
    --s single user mode
    --f force reboot after flashing
    -- k keep image files
    --p pad images


    Man kann also falls gewünscht jeden Flashbereich einzeln schreiben.


    Wenn man gar keine Option angibt entspricht das einen nfiwrite --l ---b --r --s --f imagename


    Und wenn der imagename *.bin ist statt einem *.nfi dann entspricht es einen nfiwrite --l secondstage.bin


    Fällt noch jemandem ein was man als Option dazu machen könnte, ich überlege noch ob ich ein --v für verbose mache, weil im Moment rufe ich das eingebettete nandwrite mit quiet auf.


    LG
    gutemine

    2 Mal editiert, zuletzt von Lost in Translation ()

  • Na gut, ich stehe auf Monologe :smiling_face:


    Dann ist das padding jetzt erstmal nur optional und --verbose habe ich auch eingebaut.


    Ich denke wir werden das jetzt so erstmal am Wochenende zum Flashen testen.


    Eigentlich braucht man jetzt gar kein dFlash mehr, ein simples nfiwrite imagename.nfi oder nfiwrite secondstage.bin reicht, aber ich packs halt als zusätzliches Flashtool ins dFlash Plugin und wenn es sich bewährt hat ersetze ich mit dem nfiwrite sowohl das writenfi als auch das nackte nandwrite und nfiwrite kann aus meiner Sicht in Pension gehen.


    PS: Das flashen aufs rawdevice mit --root /dev/sdb1 ist auch schon eingebaut aber erstmal disabelt, damit testen wir dann wenn der Rest funktioniert das booten mit ubifs über block2mtd treiber vom rawdevice, aber das kommt dann frühestens nächstes Wochenende dran wenn der code zum Flashen auf allen Boxen 100%ig funktioniert.

    Einmal editiert, zuletzt von Lost in Translation ()