neues Dateisystem UBIFS für Flashspeicher

[FlatTV]

Ich experimentiere gerade mit upx.
Die zu packenden Dateien (top als Beispiel) werden im customize-Skript ordentlich verarbeitet.

Code: Alles auswählen

                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2008   
UPX 3.03        Markus Oberhumer, Laszlo Molnar & John Reiser   Apr 27th 2008

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
     65920 ->     34080   51.70%  linux/ElfPPC   top                           

Packed 1 file.

Der Aufruf von top im Image endet mit "Killed"
Fehlt mir da noch irgend etwas?
make upx_host ist natürlich dabei

cu FlatTV

[rhabarber1848]

Scheinbar harmoniert top nicht mit upx, das trifft auf lcdmenu, mke2fs
und automount ebenso zu.

neutrino, sectionsd, zapit, enigma -> alles komprimierbar.

[mrvica]

Ich hatte das auch mit einigen binaries, oder mit binaries in Images mit älterem Kernel, bei mir gings dann mit upx 2.0, auf http://upx.sourceforge.net/ findest du ältere Versionen ("old versions") von upx, ein Versuch wert ist es

mrvica

[rhabarber1848]

The main news in version 3 are:
* optional LZMA compression

Ich glaube, mit upx 2 wird man nicht sehr glücklich

[FlatTV]

Da hab ich wohl noch ein Bock drin

Code: Alles auswählen

                       Ultimate Packer for eXecutables                                                                         
                          Copyright (C) 1996 - 2008                                                                            
UPX 3.03        Markus Oberhumer, Laszlo Molnar & John Reiser   Apr 27th 2008                                                  

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   1829146 ->    500568   27.37%  linux/ElfPPC   neutrino                      

Packed 1 file.

Code: Alles auswählen

BusyBox v1.14.2 (2009-07-11 20:35:36 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # neutrino -f -u
Killed
~ #

cu FlatTV

[rhabarber1848]

Neutrino hat bei mir definitiv mit UPX funktioniert.
Was für ein Image und welche UPX-Parameter nutzt Du?

[FlatTV]

Das Image ist ein jffs2-flash, die upx Parameter sind --best --lzma
Ich denke ja mir fehlt noch irgend etwas, keine gepackte Datei startet.

cu FlatTV

[rhabarber1848]

Das Image ist ein jffs2-flash

Selber kompiliert aus aktuellen CVS-Sourcen?

[FlatTV]

jepp, Stand: jetzt

cu FlatTV

[rhabarber1848]

Ich kann nur sagen: Bei mir funktioniert es.

[rhabarber1848]

LZMA-Support für JFFS2-Kernelmodul: linux24_jffs_lzma.diff (aktualisiert für LZMA 4.65)
LZMA-Support für mkfs.jffs2 (siehe oben): EDIT: Patch ist im CVS
Erstellen von /var als JFFS2/LZMA-Partition: mkjffs2_var_lzma.diff (aktualisiert)

Ich habe mit den Vorbereitungen für optionalen LZMA-Support
in JFFS2-Partitionen begonnen. mkfs.jffs2 kann diese Partitionen
nun erstellen, tut es allerdings im Moment noch nicht.

Wer in einem Squashfs-Image /var als LZMA-JFFS2-Partition haben möchte,
muss die beiden o.g. Patches nutzen, diese habe ich positiv getestet.

[rhabarber1848]

Mit den heutigen CVS commits sind U-Boot und Kernel 2.4 in
der Lage, von LZMA-komprimierten JFFS2-Partitionen lesen
zu können. Der neue Code ist momentan noch nicht aktiviert,
ich habe ihn vorab committed um die folgenden Patches klein
zu halten.

PS: Der Kernelcode stammt von Nikos Mavrogiannopoulos
https://lists.openwrt.org/pipermail/ope ... 03886.html

Diese Patches teste ich hier noch, es sieht aber schon gut aus.
Ein LZMA-komprimiertes JFFS2-only-Image läuft hier bereits
stabil. Wenn dazu noch ein LZMA-komprimiertes Kernelimage
und passende customization-Skripts dazukommen, funktioniert
sogar ein per "make flash-enigma+neutrino-jffs2_lzma_klzma-all"
erstelltes Image

Dazu noch eine Frage: Momentan existiert das target

flash-$gui-jffs2-all

Ich plane folgende neue targets:

flash-$gui-jffs2_lzma-all
- JFFS2-Partition LZMA-komprimiert, Kernel weiterhin gzip-komprimiert

flash-$gui-jffs2_lzma_klzma-all
- JFFS2-Partition und Kernel LZMA-komprimiert
Die Unterscheidung der Kernel-Komprimierung möchte ich machen, weil
die LZMA-Komprimierung 200kb mehr freien Speicher im Flash und eine
10s längere Bootzeit mitbringt.

Sind die Namen der make targets, obwohl ziemlich lang, in Ordnung?

[FlatTV]

Die Namen sind ja "sprechend", ist doch wichtiger als die Länge

cu FlatTV

[rhabarber1848]

LZMA-Unterstützung für JFFS2-Partitionen ist nun auch für Kernel 2.6 im CVS.

PS: Der Kernelcode stammt von Nikos Mavrogiannopoulos
https://lists.openwrt.org/pipermail/ope ... 03886.html

[FlatTV]

Code: Alles auswählen

disable LZMA compression for JFFS2 filesystems, it is too slow on Dbox2

Ist das Projekt damit erst einmal gestoppt ?

cu FlatTV

[mrvica]

>> disable LZMA compression for JFFS2 filesystems, it is too slow on Dbox2

was ist jetzt zu langsam, das Booten selbst, oder die Box wird im Betrieb lahm, ist die LZMA Compression auf das ganze Image oder auf die Dateien bezogen, kann man da beim Komprimieren was excluden, was auf keinen Fall komprimiert werden soll ist die busybox, die ist keine binary die einmal aufgerufen wird und im Speicher schlummert, die wird beim Booten zick mal aus rcS aufgerufen (und entpackt), beim Experimentieren mit upx habe ich mal busybox gepackt (war nicht mal mit --lzma Option), das Booten dauerte 20 Sek länger, jetzt würde ich gerne wissen was da langsamer wird, könnte jemand ein Image zur Verfügung stellen (dietmarw)

mrvica

[Houdini]

Beim Komprimieren von Dateien wurde der LZMA Algorithmus deaktiviert,
anstatt dessen wird nun was? benutzt, gzip wie default?

[rhabarber1848]

Es geht hier nur um die Komprimierung zur Laufzeit, d.h. welcher Algo
wird genutzt, wenn Dateien auf der Dbox neu ins Flash geschrieben
werden. Hier wird nun zlib genutzt. Bei der ursprünglichen Erstellung
des Images (mkfs.jffs2) auf dem Host wird weiterhin LZMA genutzt.
Der Linux-Kernel auf der DBox nutzt nun nicht mehr LZMA zur on-the-
fly-Komprimierung, weil das einfach zu langsam war,
hier geht es um den Faktor 5-6, d.h.

cp /vmlinux /vmlinux2

dauert nun mit zlib 12s, mit LZMA ~ 60s...

[bosmann]

>> disable LZMA compression for JFFS2 filesystems, it is too slow on Dbox2
könnte jemand ein Image zur Verfügung stellen (dietmarw)
mrvica

bin gerade am neu bauen und wenn du willst kann ich dir eines zur Verfügung stellen...

[rhabarber1848]

oder die Box wird im Betrieb lahm

Das ist der Fall.

ist die LZMA Compression auf das ganze Image oder auf die Dateien bezogen,

Auf das komplette Image zum Zeitpunkt der Erstellung.
On-the-fly-LZMA-Kompression für das JFFS2-Dateisystem ist auf der Dbox2
zu langsam, deshalb habe ich sie heute aus den LZMA-Patches entfernt.
Es ist halt nicht so angenehm, wenn in Neutrino das Speichern der
Einstellungen länger als 20s dauert...

kann man da beim Komprimieren was excluden

Soweit ich die Syntax von mkfs.jffs2 verstanden habe, nein.

Hier ist die Bootzeit eines JFFS2-only-Images 49s, mit aktivierter
LZMA-Komprimierung 62s, Zugewinn an freiem Speicherplatz 600 kb.

Im CVS ist momentan noch kein Code, der eine LZMA-komprimierte
JFFS2-Root-Partition zur Verfügung stellt. Dort befindet sich nur
vorbereitender Code, der erst durch zukünftige Patches aktiviert wird.
Die Absicht hinter bis jetzt eingechecktem Code ist die Kontrolle, dass
er den bestehenden Funktionsumfang nicht tangiert. Deshalb glaube ich
nicht, dass es schon Images zum Testen gibt.

Hier teste ich im Moment den Kernel 2.6-Betrieb, einen LZMA-
komprimierten 2.6er-Kernel habe ich heute erstmals erfolgreich booten
können. Ich denke, dass ich zum Wochenende den ersten JFFS2-LZMA-
Patch zum Testen veröffentlichen kann.

[seife]

was auf keinen Fall komprimiert werden soll ist die busybox, die ist keine binary die einmal aufgerufen wird und im Speicher schlummert, die wird beim Booten zick mal aus rcS aufgerufen (und entpackt),

Ist zwar OT, aber um die Bildung von Urban Legends zu verringern: das ist natürlich blödsinn. Wenn die busybox einmal geladen wurde, ist sie im Speicher und wird nicht nochmals dekomprimiert / geladen.

Mit den exe-packern ist das anders, deswegen sind die für embedded nicht wirklich brauchbar, aber das will ja keiner hören...

[rhabarber1848]

Dazu ein paar Zahlen:

~ # cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "FLFS (U-Boot)"
mtd2: 007c0000 00020000 "root (jffs2+lzma)"
mtd3: 007e0000 00020000 "Flash without bootloader"
mtd4: 00800000 00020000 "Complete Flash"
~ # time busybox
BusyBox v1.14.3 (2009-08-05 07:42:02 CEST) multi-call binary
[...]
real 0m 0.07s
user 0m 0.01s
sys 0m 0.06s

~ # cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00004000 "BR bootloader"
mtd1: 00020000 00020000 "FLFS (U-Boot)"
mtd2: 007c0000 00020000 "root (jffs2)"
mtd3: 007e0000 00020000 "Flash without bootloader"
mtd4: 00800000 00020000 "Complete Flash"
~ # time busybox
BusyBox v1.14.3 (2009-08-05 07:42:02 CEST) multi-call binary
[...]
real 0m 0.07s
user 0m 0.00s
sys 0m 0.06s

[rhabarber1848]

Nach einigen Tests halte ich den JFFS2-LZMA-Patch jetzt für testwürdig: EDIT: Patch ist im CVS

Inhalt des Patches:

• Partitionsnamen in Kleinbuchstaben (cdk/Patches/dbox2-flash.c*)
• Anzeige von "jffs2+lzma" bei entsprechenden Partitionen
• U-Boot für JFFS2-Images enthält nun immer LZMA. Es gibt damit kein Größenproblem, d.h. für JFFS2-only-Images ändert sich nichts. CONFIG_LZMA wird zum Entpacken von LZMA-komprimierten Kernelimages und zum Laden von Dateien von LZMA-komprimierten JFFS2-Partitionen genutzt - der LZMA-Support in Squashfs hat damit nichts zu tun und ich werde diesen nicht anfassen.
• Neue make targets
  
  LZMA-komprimiertes JFFS2-only-Image, Kernel weiterhin gzip-komprimiert
  flash-all-jffs2_lzma-all
  flash-neutrino-jffs2_lzma-all
  flash-enigma-jffs2_lzma-all
  flash-enigma+neutrino-jffs2_lzma-all
  flash-null-jffs2_lzma-all
  
  LZMA-komprimiertes JFFS2-only-Image, Kernel zusätzlich LZMA-komprimiert
  flash-all-jffs2_lzma_klzma-all
  flash-neutrino-jffs2_lzma_klzma-all
  flash-enigma-jffs2_lzma_klzma-all
  flash-enigma+neutrino-jffs2_lzma_klzma-all
  flash-null-jffs2_lzma_klzma-all
  
  und ein paar radiobox targets, die ich nicht extra aufführen möchte.
  Das target flash-enigma+neutrino-jffs2-all existiert nicht, da es mir
  nicht möglich war, ein solches Image zu erstellen. Für die anderen
  neuen enigma+neutrino targets ist trotz der Speicherersparnis durch
  LZMA die Anwendung von customization-Skripts[1] zur Reduzierung des
  Imageinhaltes nötig.

[1] Beispiel: nukegames, nukelanguages, in
share/tuxbox/neutrino/icons/ radiomode.*, scan.* und shutdown.* löschen
Plugins löschen:

Code: Alles auswählen

newroot=$1/`basename $0 | sed "s/-local.sh//"`
for i in games lcdcirc libfx2 outdoor satfind dvbsub tuxcom vnc ngrab dbswitch rss; do
          rm -v $newroot/lib/tuxbox/plugins/$i*
done

[dietmarw]

Nach einigen Tests halte ich den JFFS2-LZMA-Patch jetzt für testwürdig: jffs2_lzma.diff

ergebnisse hier http://tuxbox.trale.de/ unter div_tests

[mrvica]

Enigma kommt noch bestimmt? habe zwar Neutrino heruntergeladen um es mit NewTuxboxFlashTool anzuschauen, geht nicht, nich unterstütztes Kompressionsverfahren, @dietmarw, wenn du mal Zeit hast, wirf auch Enigma an

Gruss mrvica