Nein Danke, das bringt mir leider im Moment nichts, wenn muss ich das ins initramfs machen und dann muss ich mir den kernel sowieso solange bauen bis beides zusammen geht.

Außerdem muss DMM eh schon aufpassen auf der 500HD ist es mit dem aktuellen Kernel schon SEHR knapp im /boot gerade wnen ich noch die 64k vom initramfs dazu mache.

Kann übrigens durchaus sein, dass sie bald /boot 1MB größer machen müssen auf 500HD und 800se, weil ob im /root jetzt 8 oder 9MB frei sind nach dem Flashen wäre auch schon sowas von egal.

ich weis dass block2mtd ist genauso wie der mtdram ja nur ein paar codeseiten, das wären Peanuts im Kernel.

Das initramfs ist rund 64k weil ich das ja gegen die klibc linken muss. Für das was es kann ist das immer noch lächerlich klein, aber ich muss beim bootlogo von rambo schon sehr aufpassen das es nicht zu groß wird auch noch ohne initramfs.

Nein, im Moment nicht, aber es ist dafür vorbereitet

Außerdem ist das Logo mit dem rambo tux im Dschungel recht hübsch geworden, bis jetzt hat sich jedenfalls keiner beschwert.

Na ja rambo ist nur ein binary ohne plugin, insofern ist das Logo die einzige Möglichkeit zu erkennen ob rambo im Dschungel ist

rambo gibts jetzt schon als release candidate 0.9 und soweit scheint er auch schon recht brauchbar zu funktionieren.

Insofern nochmals Danke für das Bauen der block2mtd Treiber zu bauen, weil ohne die gäbe es kein rambo.

LG
gutemine

Aus DMM Sicht und für DMM Images mag das schon stimmen, und der tar ball ist auch schnell auf ein USB device in ext3/4 entpackt, aber in der Community werden von den Imageteams halt nur nfi images verteilt, und jeder will auch solche Files als backup haben, also ist es naheliegender die so zu verwenden wie sie sind und besser nicht zu diskutieren

Mir reicht schon derzeit das Jammern der Benutzer das durch die größeren Images im OE 2.0 das mkfs.jjfs schon zu viel Memory frißt für das was wir in den Boxen an memory haben und die backups dadurch schon ewig dauern, nicht umsonst war ich böse und habe dem dFlash beigebracht sich das jffs2 mit nanddump direkt aus dem Flash zu holen, statt es mühsam wieder neu zu machen und dabei die boxen in die knie zu zwingen (außer die 7020HD die hat noch genug Memory) - und ja dFlash kann diese Jumbo nfi die halt immer so groß sind wie der Flash mit nandwrite auch wieder flashen.

Ich habe mir ja auch nicht umsonst das nfidump geschrieben damit man nfi images mit einem einzigen binary in einem Arbeitsgang entpacken kann, Dumbo verwendet das ja auch um so von USB zu booten.

Aber in dem Fall wenn man nur das jffs2 extrahiert und direkt verwendet (egal ob man es ins mtdram oder in den block2mtd Treiber reinlädt) ist es halt wesentlich anwenderfreundlich, du brauchst bei rambo nichtmal ein Plugin dafür, ist ein simples binary das statt dem /sbin/init läuft und das ich eben auch in ein initramfs packen könnte damit es gleich mit dem kernel mitkommt.

Zum 'Flashen' kopierst du beim rambo nur das nfi in die root irgend eines USB oder SATA devices, bei ersten boot wird das root jffs 'befreit' und ab dann bootest du das einfach und benutzt es wie gewohnt und merkst keinen Unterschied, ausser dass der Flash halt /dev/mtdblock4 heißt und dann 128MB groß ist was auf 500HD und 800se derzeit auch bei OE 2.0 mehr als ausreicht.

Würde ich es ins initramfs machen dann würde /dev/mtdblock3 gar nicht mehr benutzt - außer du bootest ohne das device wo das nfi drauf ist. Damit liegt die ganze Komplexität im rambo binary und aus Sicht der Benutzer ist es praktisch idiotensicher.

LG

gutemine

Danke, ich lade die neuen module auch im rambo thread hoch.

Letztendlich werden wir aber wohl nicht darum herum kommen DMM zu bitten sie über die defconfig immer gleich als Module im OE 2.0 mit zu bauen damit sie bei jedem kernel update auch mitaktualisiert werden können.

Im OE 2.0 haben die meisten boxen ausser der 7020HD zu wenig Memory um das mtdram wirklich voll ausfahren zu können. Man müsste sich dann auch überlegen ob man nicht gleich das nandsim modul nimmt, das kann glaube ich beides (also in einem file oder im ram ein mtd device simulieren).

Und wenn wir den block2mtd in den Kernel machen würde es wie schon gesagt mehr Sinn machen das rambo sterben zu lassen und die Funktionalität gleich ins initramfs zu moven, weil du dir dann das chroot/pivot_root sparst und die Flashroot gar nicht mehr mounten musst.

Sobald ich es aber ins initramfs mache ist es sowieso wieder egal weil man dann eigenen kernel bauen muss.

Andererseits gibt es auch gleich wieder Leute die rambo einen Bootmanager verpassen wollen um mehrere images booten zu können.

Aber jetzt warten wir auf jeden Fall mal auf die Anga ...

gut das ich noch selber entscheide was/wo hinkommt

Im BA macht das aber keine Sinn, im LowFAT schon eher, aber wie schon gesagt jetzt warte ich mal ab und dann wird entschieden.

Normal warte ich nicht gerne, und sitze untätig herum, wenn dir fade wäre könntest du ja mal schauen ob man nicht auch das nandsim und nandflash Module bauen könnte

http://wiki.freebsd.org/NAND

nandsim.c und nandflash.c sind auf jeden Fall im OE drinnen wenn mein find recht hat

Ob man damit aber Mehrwert generieren kann zu dem was schon jetzt geht ist eine andere Frage.