[gelöst weil jetzt im kernel] block2mtd als modul im OE 2.0 ?

  • Hi !


    Nachdem es jetzt funktioniert mit rambo die root von einem nfi image beim booten direkt ins ram zu laden, aber die alten boxen nicht so viel RAM wie die 7020HD haben, würde ich gerne auch eine Variante bauen wo statt dem mtdram der block2mtd Treiber verwendet wird um Memory zu sparen.


    Wäre es daher möglich auch den im kernel config file im OE 2.0 als module aufzudrehen so das er gleich mitgebaut wird und am Softwarefeed liegt:


    CONFIG_MTD_BLOCK2MTD=m


    Dann habe ich fürs nächste Wochenende auch noch was zum Spielen und kann über rambo II nachdenken :winking_face:


    LG
    gutemine

    2 Mal editiert, zuletzt von Lost in Translation ()

  • Im Prinzip kannst du damit einfach auch fake mtd devices machen - mit mtdram benutzt du das Memory, beim block2mtd einfach ein file das du dem Treiber über einen Loop mount unterjubelst.


    Und nachdem nfi images nur etwas seltsam gepackte jffs2 files sind kannst du sie im Falle von mdtram 'fast' direkt auf das /dev/mtdblock4 schreiben und im Fall von block2mtd halt von eimem file laden das dir der Treiber dann als mtdblock4 vorspiegelt.


    Besser als zusätzliche Flashbausteien löten und ich wollte mit dem vielen RAM der 7020HD halt was 'sinvolles' anfangen :smiling_face:


    Wirklich brauchen tut man das nicht, aber z.B. auf der 7020HD bringt dir rambo eine Bootzeitverkürzung von 80 auf 63 sekunden, einen gähnend leeren Flash und ein merkbar agileres enigma2 nachdem dann fast alles vom RAM läuft. Und die 7020HD ist so schon relativ flott.


    Bei den boxen mit nur 256MB RAM geht der Trick zwar auch nur ist der Sweet Spot wo du die Vorteile des booten von RAM hast ohne das dir das Memory ausgeht relativ klein.


    Dort würde die block2mtd Variante besser funktionieren, und auch damit ist der Flash dann schlagartig leer - 5MB benutzt mit einem standard OE 2.0 image nach dem ersten boot.


    Im Prinzip ist rambo einfach ein umgekehrtes Freeze - statt das delta zum Flash auf ein anderes Device auszulagern lagerst du das nfi image aus und machst nur das Delta in den Flash.


    Nur gleich das nfi zu nehmen geht halt nur mit jffs2 Treibern die in der Lage sind den jffs2 Inhalt des nfi direkt zu verwenden. Sonst könnte man ja gleich das Image auf ext4 auspacken was für mich halt schon öde ist :smiling_face:


    PS: Wenn Du Lust hast kannst du uns aber gerne die block2mtd ipks backen im OE 2.0 dann kann ich gerne ein rambo II machen das sie auch verwendet, das geht deswegen recht schnell weil der Unterschied nur ein Dutzend codezeilen wären.


    PPS: Und mein rambo ist nicht wirklich böse, oder ?


    LG
    gutemine

  • Danke, wobei ich Sie wenn dann für alle boxen brauche - gerade auf der 7020HD geht das mtdram ja dank der 512MB schon ziemlich gut, selbst mit einem voll eingerichteten image hast du noch > 100MB frei und keine Performanceinbußen sondern Verbesserung :smiling_face:


    Im Prinzip ist das Ganze /dev/mtdblock4 ja nur eine Art riesiger Filesystemcache native mit jffs2. Mit hat halt auch interessiert ob die Mär mit dem jffs2 braucht lange beim mounten am Flash oder am jffs2 liegt. Und wen man sich das schnellere Booten mit Verbesserungen von fast 20 sekunden ansieht (weil ich brauche ja rund 2 sek um das /dev/mtdblock4 vom nfi zu befüllen) und jetztendlich ja weiterhin jffs2 verwendet wird dann ist das Filesystem besser als sein Ruf, auch wenn natürlich das ganze Bad Block handling, etc beim mtdram wegfällt. Rein so schnell online zu dekomprimieren ist schon eine Leistung.


    LG
    gutemine

  • Kernel ist nicht nötig, das module lädt problemlos in einem Image vom 12.05:


    modprobe block2mtd
    lsmod | grep block
    block2mtd 4644 0


    Ich würde aber wenigstens noch das ipk für die 8000er brauchen, weil die hat das größte Problem mit mdtram - auch nur 256MB Memory aber so große nfi images wie die 7020HD weil DMM dort alles genauso gleich reinpackt.


    Im Prinzip sind diese Treiber eh lächerlich simpel, ich habe sogar schon überlegt den block2mtd auf einen nfi2mtd umzuschreiben, weil das wären nur ganz wenig Code Anpassungen, aber Treiber debuggen ist mir zu mühsam und so gehts erstmal eh auch.


    Ich schaue dann halt mal am Abend ob ich einen zweiten Teil der 4 teiligen Rambo Triologie machen kann :smiling_face:



    LG
    gutemine

  • Das wird die Leute aber freuen, weil man dann auch problemos nfi images mit > 64MB machen kann die genauso einfach booten ohne das einem das Memory oder der Flash ausgeht.


    Aber lass Dir Zeit vor dem Abend komme ich nicht dazu neues Rambo zu machen, Wetter ist einfach zu schön und der Rasen muss auch mal gemäht werden.

    Einmal editiert, zuletzt von Lost in Translation ()

  • Rasen ist bei mir auch gemäht, also mache ich mich jetzt mal ans Werk.


    Von Hand geht es schon mal das root jffs2 aus dem nfi zu extrahieren mit losetup als blockdevice zu haben und dann mit dem block2mtd zu mounten, ich muss jetzt nur mehr den C code verbiegen.

  • Also kurzer Zwischenbericht - rambo 0.4 funktioniert jetzt bei mir sowohl mit mtdram als auch mit block2mtd Treibern. Ich habe doch gleich mehr Arbeit reingesteckt damit beides funktioniert aber ich denke es hat sich gelohnt.


    Du kannst jetzt auf jeder box ein OE 2.0 image mit rambo booten und hast nachher nur ca. 8-12MB BENUTZT im Flash, der Rest kommt vom nfi das man auf USB oder zur Not auch auf Harddisk legen kann. Damit reichen auch die 64 MB Flash der alten Boxen locker aus, zur Not sichert man halt wenn der Flash voll wird alles in ein nfi und bootet mit dem und dann wieder leerem Flash weiter.


    Insofern danke fürs Compilieren der Module und meine neuerliche Bitte auch den block2mtd Treiber im OE 2.0 gleich fix als modul mitbauen zu lassen - ist ja nur eine Zeile mehr in der defconfig.

  • Kein Problem.
    Kompiliert wird meistens auf einem Server auf der Arbeit.
    Der wird demnächst auf einen mit 2x Xeon Quadcore umgestellt, wenn ich das noch richtig in Erinnerung habe.
    Dann macht das kompilieren erst richtig Spaß. :thumbs_up:

  • Da kann ich nicht mithalten, mein Notebook hat nur 2 cores und 6GB Memory, aber es liegt nicht an der HW das ich das OE nicht gerne benutze :smiling_face:


    Hauptsache es funktioniert jetzt und das basteln am block2mtd support vom rambo hat mir einige böse Ideen geliefert. Theoretisch könne ich jetzt auch einen Ripper bauen und das image komplett aus einem File fahren das dann sogar im FAT liegen könnte wie beim LowFAT.


    rambo geht ja absichtlich den schwierigen Weg durch den Dschungel indem es das nfi File nur read only benutzt und alle Änderungen in den Flash macht.


    Aber mal sehen wo uns die Reise hinführt ...


    Wenn rambo so funktioniert wie ich mir das vorstelle dann ist es eh Idiotensicher, du machst einfach ein nfi file auf ein device (USB, zur not auch Harddisk) rebootest und schon ist das Image 'geflasht' und kann wie normal benutzt werden.

  • auf Grund der aktuellen Vorfälle habe ich entscheiden rambo II erstmal ohne unionfs zu implementieren.


    Ich würde daher bitten auch die block2mtd Treiber ins OE einzuchecken das diese immer gleich als modul mitgebaut werden.


    Bitte, Bitte Bitte.


    rambo II spendiert dafür dann auch ALLEN Boxen 256B Flash :winking_face:

  • Duch das am Feed vergessene unionfs sind den Leuten auf den gefreezten boxen reihenweise die Images zerbröselt.


    Aber Schwamm drüber, dadurch habe ich halt rambo II vorgezogen, hier das Ergebnis auf einer 500HD:


    df -h
    Filesystem Size Used Available Use% Mounted on
    /dev/root 59.0M 50.1M 8.9M 85% /media/realroot
    /dev/sda1 14.2G 10.3G 3.1G 77% /media/realroot/media/realroot
    /dev/mtdblock4 256.0M 51.2M 204.8M 20% /
    devtmpfs 155.1M 0 155.1M 0% /dev
    none 66.0M 524.0K 65.5M 1% /var/volatile
    /dev/mtdblock2 3.8M 3.7M 32.0K 99% /boot

  • Ja, und ich habe mich auch bedankt und es geht auch wieder.


    Nachdem es aber beim rambo I ja nur eine Spielereich war um zu sehen ob man die Welt auch umdrehen kann habe ich den größeren Flash im rambo II halt native im block2mtd Treiber implementiert, wenn man das loop gemountete file entsprechend groß macht ist es ja kein Problem und wenn man dann das rambo device absteckt bootet der Flash wie wenn nichts gewesen wäre.


    Genau deswegen hätte ich jetzt gerne das modul auf dem Feed dann kann man mit einem einzigen binary und indem man das nfi auf ein USB oder SATA device kopiert die box von dort booten.


    Wenn man den block2mtd (der ja winzig ist und kaum Platz wegnimmt) fix in den kernel machen würde könnte ich es sogar noch memorysparender und völlig transparent implementieren so dass /dev/mtdblck3 durch /dev/mtdblook4 ersetzt wird wenn die box beim booten ein nfi vorfindet und man z.B. root=block2mtd ins kernel command line schreibt.


    Ich muss mir das noch überlegen und mit den usern diskutieren, weil das schon einen gewissen Sex-appeal hätte wenn die box von alleine Ihren Flash erweitern kann ohne das man irgendwas installieren muss.

    2 Mal editiert, zuletzt von Lost in Translation ()