Dreamboard

Na ja mir würde im ersten run schon reichen wenn die Module mitgebaut würden und am Softwarefeed sind damit man sich beim Kernel Updaten keinen Probleme einhandeln kann.

Im Kernel wäre aber natürlich die schönere Lösung, weil wie gesagt dann könnte man es perfekt lösen und alles in den Kernel tun also auch die deviceerkennung und das ummounten.

Linus sieht das anders und zum debuggen ist es auch einfacher wenn du nicht ständig neuen kernel bauen musst.

Wobei als Kloneschutz ist etwas das fix im kernel verbaut ist schon ganz brauchbar, mein initramfs oder rambo prüft ja auch brav ob ein aktueller Originalloader verwendert wird und nicht was gepanschtes. Ich bin da auch eher der Meinung das man in den kernel nur packen sollte was man zum booten braucht und sonst nichts - wobei diese definition dann auf den block2mtd zutreffen würde wenn man größeren Flash braucht. Einer der Gründe das wir kein ubifs gekriegt haben ist ja auch dass der Freiplatz noch weiter runter gehen würde und dann ist es bei 64MB Flashboxen schon fast zu knapp.

Sachen die man sehr früh im booten braucht könnte man ja auch als module in ein initramfs packen - ich habe mir nicht umsonst in meinem kinit binary den support für externe initramfs.cpio.gz reingemacht.

Nur wird dafür der Platz in /boot AUCH schon recht knapp, aber das ist eine andere Geschichte.

LG
gutemine

http://www.linux-mtd.infradead.org/doc/ubifs.html

Da gibts reichlich Lesestoff dazu.

Im Prinzip hat jffs2 bei größerem Flash ein Problem performant zu bleiben, ubifs nicht.

Mit ein bisschen Handarbeit kann man es im OE 2.0 sogar für das root filesystem ausprobieren (/boot geht nicht weil unser bios derzeit kein ubifs kann, wobei dort stört jffs2 auf Grund der geringen Größe auch nicht wirklich)

Ghost hat gesagt wir werden ubifs schon kriegen aber nicht gleich zum Anfang der OE 2.0 ;-)

Alle nötigen Treiber und tools sind aber vorhanden, nur das bios kann halt (noch) nicht damit umgehen.

ich könnte ein kleines root2ubifs Plugin schreiben, aber dann werde ich wieder gesteinigt.

Mit dem neuen dFlash das auch naddump und nandwrite beherrscht könnte man solche ubifs images aber auch flashen, mit DreamUP und Bios halt nicht.

Insofern war das eher eine Spielerei um zu sehen ob es geht und wie rasch es damit bootet.

Weil dann die Leute schon wieder Sachen benutzen die sie nicht verstehen :-)

Und ja das mit dem block2mtd habe ich gesehen, ist nett von Ihnen. Ich muss aber erst das initramfs wieder 100% zum laufen bringen, aus irgendeinem Grund will das Labelmounten schon wieder nicht funktionieren. Ich habe gestern ja das Dumbo fürs OE 2.0 als Testkit fertig gemacht (bei OoZoon im Board zu finden) und da geht eigentlich schon wieder alles wie im OE 1.6 eben bis auf das Labelmounten.

Sobald ich rausgefunden habe warum das initramfs nicht per Label mounten will schaue ich mir wie versproochen mal an ob ich den Rambo code da drinnen zum Laufen kriege.

Na ja sagen wir mal so um ubifs zu simulieren wäre das nandsim sinvoller, aber wenn schon dann macht man es auf den echten Flash:

Wenn du die ubifs Beschreibung die ich dir gepostet habe ordenlich durchliest, mit Dumbo von einem stick bootest damit du /dev/mtdblock3 mit den mtd-utils formatieren und ubifs drauf machen kannst ist es eigentlich eh nur eine Handvoll Befehle abtippen, in den mtd utils findest du ja alles nötige und ubifs Treiber ist im Kernel schon drinnen.

Dann kopierst du vom Dumbo device die root wieder in den unifizierten Flash zurück (oder packst mit nfidump eine neue aus einem nfi drauf) passt die autoexec*.bat an und schon ist das Flashimage 'ubifiziert'

In Summe keine 10 min Arbeit, du kannst es ja ausprobieren und HowTo schreiben - dann fliegen die Steine mal in eine andere Richtung.

Wobei das jffs2 auf einem block2mtd device eh viele Nachteile des echten jffs2 auf NAND Flash nicht hat, schließlich brauchst du kein ECC und Weearlevel handling weil ja keine echten Flashbausteine drunter sind.

Auf jeden Fall habe ich den thread jetzt auf gelöst gesetzt und muss schnell neue rambo version bauen die die Treiber nicht mehr nachlädt (aber noch als standalone binary).

LG
gutemine

Kleiner update noch, das rambo 0.9.2 kommt jetzt auch mit dem neuen Kernel mit block2mtd Treiber im kernel zurecht, mal sehen ob es den Leuten gefällt.

wirklich gescheit ist das aber nicht, weil abgesehen von der Kernelgröße die auf der 7020HD nicht so das Problem ist wäre so ein genvminux mit allen devices auch entsprechend träge bis er das alles initialisiert hat. Da wäre ein Kenrel der auf allen Dreamboxen läuft schon eine lustigere Herausforderung :-)

Und nein, ich bin bekennender im Debian auf der Box compilierer, insofern bin ich fürs OE der denkbar schlechteste Ansprechpartner, ich war schon froh mir einen kernel mit meinem initramfs Patch selber bauen zu können.

Wenn dir fade ist dann mach lieber in den kernel auch die mtd devices für den restlichen Flash rein, weil über das /dev/mtd0 kann man den zwar benutzen, aber das bringt wenig wenn man jedesmal nachher den loader wieder flashen muss :-)

LG

gutemine

das mtdlayout ist in irgendeinem config file hinterlegt, das muss man nur finden und anpassen. Such mal nach maxvar für die enigma1 images da war das schön erklärt auch wenn es jetzt wahrscheinlich ganz anders funktioniert.

Und nur mit dem Tasklöschen wird es nicht getan sein, da baut dann zwar der kernel aber ob das alles funktioniert ist eine andere Frage ;-)

Wobei wenn man nicht spielt lernt man nichts, insofern bist du schon auf dem richtigen Weg.

na ja schau mal ins bootlog/dmesg was davon auch wirklich alles geladen wurde und devices anlegt, Vieles wie die Berge von Tunermodulen macht ja nur was wenn auch so ein device angesteckt ist.

Was mich daran erinnert das ich da auch einiges an USB devices herumliegen hätte was ich bis zum OE 2.0 beiseite gelegt hatte :-)

sound ist auch nur in den closed source broadcom Treibern drinnen glaube ich

Erst wenn die laufen kannst du die ganzen anderen devices wie alsa pulseaudio & co starten.