U-Boot updates

[rhabarber1848]

Hier meine Probs mit Kernel 2.6 mit dem Patch von heute morgen.

Habe heute abend noch 2.6er-Images gebaut, ging immer
ohne Probleme, auch in den letzten Tagen.

cmd_fs.c:59:7: invalid suffix "x" on integer constant
cmd_fs.c:59: error: initializer element is not constant
cmd_fs.c:59: error: (near initialization for `part_info[1].offset')

Ein solcher Fehler ist hier noch nie aufgetreten.

Welche configure-Parameter nutzt Du?

[GetAway]

ich habe gerade mal --enable-lzma rausgeschmissen und Rootpartitionsize geändert.
Wahrscheinlich hatte ich dort nen Typo, denn jetzt läuft es weiter. Mal schauen.

[rhabarber1848]

ich habe gerade mal --enable-lzma rausgeschmissen

Bei cdk/configure? Diese Option ist obsolet: http://forum.tuxbox-cvs.sourceforge.net ... 44#p368644

[GetAway]

Kernel 2.6 uboot 2009.06 YaDD-booting positiv getestet.

[rhabarber1848]

Mittels das Patches konnte ich erstmals einen LZMA-komprimierten Kernel von U-Boot
entpacken lassen, leider ging es so weiter:

ERROR: Failed to allocate 0x200 bytes below 0x800000.
ERROR with allocation of cmdline

Da habe ich doch glatt einen Bug in U-Boot gefunden und behoben:
http://article.gmane.org/gmane.comp.boo ... boot/63778

Ich werde unseren U-Boot-Patch später aktualisieren.

[rhabarber1848]

- CONFIG_LZMA in u-boot.dbox2.h.m4 für alle U-Boot-builds aktiviert

Patch aktualisiert.

Die Fähigkeit von U-Boot, einen LZMA-komprimierten Kernel zu entpacken,
behindert nicht den normalen Betrieb. Es macht daher keinen Sinn, zwischen
CONFIG_LZMA ja/nein beim U-Boot-build zu unterscheiden. U-Boot selbst wird
dadurch 9 kb größer, was kein Problem darstellen dürfte. Dennoch möchte ich
Euch bitten, den aktuellen Patch nochmals auf Herz und Nieren zu prüfen.
Langsam nähert er sich der Vollendung und CVS-Reife.

Ein LZMA-komprimierter Kernel macht nur Sinn in einem JFFS2-only-Image,
das im Moment nur mit zlib gepackt werden kann. Wie groß die Speicher-
ersparnis durch einen LZMA-komprimierten Kernel ist, kann ich noch nicht
sagen, da ich es bis jetzt noch nicht getestet habe. Bisher habe ich einen
LZMA-komprimierten Kernel nur im Yadd gebootet, hier der Größenunterschied
bei Kernel 2.4 zu einem gzip-komprimierten Kernel:

Code: Alles auswählen

-rw-r--r-- 1 root root 589888 14. Jul 14:38 kernel-cdk
-rw-r--r-- 1 root root 748691 15. Jul 12:21 kernel-cdk-gzip

Patches, welche die Erstellung eines JFFS2-only-Images mit einem LZMA-
komprimierten Kernel ermöglichen, werde ich noch erstellen.

Bis dahin ist es das wichtigste, den neuen U-Boot auf Herz und Nieren zu prüfen.

[GetAway]

K24, YaDD ok, Flash bringt diesen Fehler:

Code: Alles auswählen

debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: WATCHDOG RESET
debug: BMon V1.0  mID 01
debug: feID 7a    gtxID 0b
debug: fpID 5a     dsID .....
debug: HWrev X5  SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

Found Flash-FS superblock version 3.1
Found file /root/platform/nokia-dbox2/kernel/os in Flash-FS
flboot: block not found, empty file ?
will verify ELF image, start= 0x800000, size= 0
verify sig: 261
Branching to 0x40000

[rhabarber1848]

flboot: block not found, empty file ?
will verify ELF image, start= 0x800000, size= 0

Da war U-Boot wohl durch den Kernel-LZMA-Support zu groß...
Ich habe den Patch aktualisiert und dabei die aktivierten
Dateisysteme in U-Boot aufgeräumt.

In Yadd-U-Boot ist nun weder JFFS2 noch Squashfs drin,
dafür aber permanenter Kernel-LZMA-Support, um den
Test LZMA-komprimierter Kernel zu vereinfachen.

In JFFS2-only-U-Boot ist kein Squashfs-Support mehr
drin, dafür wird optional Kernel-LZMA-Support enthalten
sein, nachdem ich die passenden make targets für die
Images erstellt habe.

Im Squashfs-U-Boot gibt es keinen Kernel-LZMA-Support
mehr. Entweder ist das Squashfs-Image mit LZMA
komprimiert oder es wird explizit kein LZMA gewünscht,
das wird dann auch für den Kernel zu gelten haben.

[GetAway]

Folgendes positiv getestet:

- Dbox2: Yadd Kernel 2.4 getestet
- Dbox2: Yadd Kernel 2.6 getestet
- Dbox2: flash-$gui-squashfs-2x Kernel 2.4 getestet
- Dbox2: flash-$gui-squashfs-2x Kernel 2.6 getestet

logo-lcd und logo-fb werden ebenfalls geladen und angezeigt.

[rhabarber1848]

Patches, welche die Erstellung eines JFFS2-only-Images mit einem LZMA-
komprimierten Kernel ermöglichen, werde ich noch erstellen.

Vorschlag für make target: flash-$gui-jffs2_klzma-all

Ein LZMA-komprimierter Kernel belässt hier 196kb mehr freien Speicher
in einem JFFS2-only-Image. Die Bootzeit erhöht sich um die 10 Sekunden,
die das Entpacken eines LZMA-komprimierten Kernels länger dauert als
bei Verwendung des gzip-komprimierten Pendant.

Die Anzahl der make targets erhöht sich leider, hat jemand eine Idee,
das zu umgehen oder logischer zu gestalten?

flash-$gui-squashfs-all (Squashfs+LZMA-Dateisystem)
flash-$gui-squashfs_nolzma-all (Squashfs-Dateisystem, ohne LZMA)

nun noch
flash-$gui-jffs2-all (jffs2+zlib-Dateisystem)
flash-$gui-jffs2_klzma-all (jffs2+zlib-Dateisystem + LZMA-komprimierter Kernel)

und evtl. demnächst
flash-$gui-jffs2_lzma-all, was ein jffs2-Dateisystem wäre, welches
vollständig mit LZMA komprimiert wurde, der Kernel wäre mit gzip
komprimiert.

[mrvica]

nur mal als Beispiel, Enigma binary mit "upx -9 enigma" gepackt wird 950k gross (original CVS 2,7 MB), das Image bootet gleich schnell wie ungepackt (weil ja Einlesen einer kleineren Datei in den Speicher schneller vonstatten geht), enigma mit "upx --lzma enigma" wird 750k gross, Booten dauert 7-8 Sekunden länger, wenn man den Kernel mit upx -9 packt, wird der Bootvorgang gleich schnell (vermute ich mal), es wird auf jeden Fall besser geshrinkt als gzip

mrvica

[rhabarber1848]

wenn man den Kernel mit upx -9 packt, wird der Bootvorgang gleich schnell (vermute ich mal), es wird auf jeden Fall besser geshrinkt als gzip

Du kannst den Kernel nicht einfach so mit UPX packen, U-Boot
muss in der Lage sein, ihn zu entpacken. Ich habe hier bereits
LZMA-komprimierte Kernel am Laufen, das dürfte vom Platz
keinen Unterschied zu upx machen.

Ich lasse noch einige Tests laufen und dann werde ich den
hoffentlich letzten U-Boot 2009.06-Patch und den ersten
LZMA-Kernel-Patch für jffs2-only-Images veröffentlichen.

[rhabarber1848]

Patches, welche die Erstellung eines JFFS2-only-Images mit einem LZMA-
komprimierten Kernel ermöglichen, werde ich noch erstellen.

Hier erstmal der aktuelle U-Boot 2009.06-Patch: EDIT: Patch ist im CVS

Darauf aufbauend: jffs2_klzma.diff
Die neuen make targets:
make flash-neutrino-jffs2_klzma-all
make flash-enigma-jffs2_klzma-all

Damit wird ein jffs2-only-Image gebaut, dessen Kernel LZMA-komprimiert ist.
Kernel 2.6 wird noch nicht unterstützt - ist aber möglich,
Kernel 2.4 habe ich positiv getestet:

### FS (jffs2) loading 'vmlinuz' to 0x200000
### FS load complete: 501554 bytes loaded to 0x200000
## Booting kernel from Legacy Image at 00200000 ...
Image Name: Linux-2.4.37.2-dbox2
Image Type: PowerPC Linux Kernel Image (lzma compressed)
Data Size: 501490 Bytes = 489.7 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.4.37.2-dbox2 (root@dbox) (gcc version 3.4.6) #4 Fr 17. Jul 13:36:09 CEST 2009

[fran]

Im Squashfs-U-Boot gibt es keinen Kernel-LZMA-Support
mehr. Entweder ist das Squashfs-Image mit LZMA
komprimiert oder es wird explizit kein LZMA gewünscht,
das wird dann auch für den Kernel zu gelten haben.

Vielleicht ist es schon diskutiert worden, ich frag trotzdem. Würde nicht auch kernel-lzma-Support im Squashfs-LZMA-FS Sinn machen? Schließlich kann der Kernel dann komplett in einem lzma-komprimiert werden und nicht wie im FS nur in 64k-Blöcken. Die LzmaDecode-Routinen wären ja eh schon drin.

[rhabarber1848]

Vielleicht ist es schon diskutiert worden, ich frag trotzdem.

Nein, es ist noch nicht diskutiert worden.

Würde nicht auch kernel-lzma-Support im Squashfs-LZMA-FS Sinn machen? Schließlich kann der Kernel dann komplett in einem lzma-komprimiert werden und nicht wie im FS nur in 64k-Blöcken.

Getestet habe ich es nicht, technisch dürfte es möglich sein, einen
Zugewinn an freiem Speicherplatz erwarte ich allerdings nicht.

Die LzmaDecode-Routinen wären ja eh schon drin.

Jein. U-Boot unterstützt von Hause aus kein Squashfs.
Der Squashfs-Support in U-Boot kommt aus dem Tuxbox CVS, dort wird
mit LZMA 4.40 gearbeitet.
Der LZMA-Support in U-Boot dient nur dazu, ein Kernel-Image zu entpacken,
hier nutze ich in meinem Patch LZMA 4.65. Damit das funktioniert, musste
ich die LZMA-Funktionen, die mit U-Boot-Squashfs kommen, umbennen.
Eine Anpassung wäre vielleicht möglich, übersteigt meine Kenntnisse.

[fran]

... einen Zugewinn an freiem Speicherplatz erwarte ich allerdings nicht.

hmm, werde ich mal ausprobieren.

Die LzmaDecode-Routinen wären ja eh schon drin.

Jein. U-Boot unterstützt von Hause aus kein Squashfs.

Ist mir schon klar. ich meinte beim Squashfs-Lzma im CVS wird ja in uncompress.c die LzmaDecode.c des gleichen Verzeichnisses eingebunden. Statt auf diese zurückzugreifen, kann man auch die codegleiche unter lib_generic/lzma/ nehmen, halt die aus LzmaKernelSupport. Zumindest ging's das mit den lzma-Änderungen im U-Boot im Sep/Okt des letzten Jahres. War letztendlich nicht wesentlich mehr Code. Weiß natürlich nicht, ob das jetzt noch mit dem Update Anfang Juli auf lzma 4.65 geht.

[rhabarber1848]

Hier erstmal der aktuelle U-Boot 2009.06-Patch: uboot-2009.06.diff

Aufgrund eines CVS commits habe ich den Patch aktualisiert.

[rhabarber1848]

@fran: Ich suche noch nach Code, der es dem JFFS2-Modul von U-Boot ermöglicht,
von einer LZMA-komprimierten JFFS2-Partition den Kernel zu laden. Ich meine damit
nicht ein LZMA-komprimiertes Kernel-Image, sondern eine komplett mit LZMA
komprimierte JFFS2-Rootpartition. Entsprechenden Kernelcode habe ich bereits
hier, mkfs.jffs2 kann bereits mit LZMA komprimieren und ein Squashfs-Image mit
JFFS2-LZMA-komprimiertem /var läuft hier bereits. Nur für U-Boot habe ich noch
keinen Code in der Richtung gefunden, selber coden übersteigt meine Kenntnisse.

[fran]

hab leider nichts parat. Der Kernel-Code läßt sich nicht übertragen? Wo gibt's den?

Komprimieren geht aber noch nicht im jffs-lzma-Rootfs?

[rhabarber1848]

hab leider nichts parat. Der Kernel-Code läßt sich nicht übertragen? Wo gibt's den?

Komprimieren geht aber noch nicht im jffs-lzma-Rootfs?

http://forum.tuxbox-cvs.sourceforge.net ... 82#p368682

[mb405]

mhhh. irgendwas stimmt bei mir nicht

Code: Alles auswählen

make[2]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/tools'
make -C examples all
make[2]: Entering directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/examples'
powerpc-tuxbox-linux-gnu-gcc -g  -Os   -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0x40000 -I/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include -fno-builtin -ffreestanding -nostdinc -isystem /home/mb405/image/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/include -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes  -c -o hello_world.o hello_world.c
In file included from /home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include/common.h:111,
                 from hello_world.c:24:
/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include/flash.h:36: error: `CONFIG_SYS_MAX_FLASH_SECT' undeclared here (not in a function)
make[2]: *** [hello_world.o] Fehler 1
make[2]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/examples'
make[1]: *** [examples] Fehler 2
make[1]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06'
make: *** [.deps/u-boot] Fehler 2

[rhabarber1848]

mhhh. irgendwas stimmt bei mir nicht

Hast Du ein ungepatchtes CVS, welches nur mit uboot-2009.06.diff
aktualisiert wurde, genommen? In der neuen config/u-boot.dbox2.h.m4
ist CONFIG_SYS_MAX_FLASH_SECT definiert.

[mb405]

mist. geht immer noch nich

Code: Alles auswählen

make[3]: Entering directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/board/dbox2'
powerpc-tuxbox-linux-gnu-gcc -g  -Os   -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0x40000 -I/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include -fno-builtin -ffreestanding -nostdinc -isystem /home/mb405/image/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/include -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes  -c -o dbox2.o dbox2.c
dbox2.c:108: error: conflicting types for 'initdram'
/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include/common.h:210: error: previous declaration of 'initdram' was here
dbox2.c:108: error: conflicting types for 'initdram'
/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/include/common.h:210: error: previous declaration of 'initdram' was here
make[3]: *** [dbox2.o] Fehler 1
make[3]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/board/dbox2'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06/board/dbox2'
make[1]: *** [board/dbox2/libdbox2.a] Fehler 2
make[1]: Leaving directory `/home/mb405/image/tuxbox-cvs/cdk/u-boot-2009.06'
make: *** [.deps/u-boot] Fehler 2

[rhabarber1848]

dbox2.c:108: error: conflicting types for 'initdram'

Hast Du wirklich meinen aktuellen Patch genommen?
Da muss das hier für boot/u-boot-tuxbox/board/dbox2/dbox2.c drin sein:

Code: Alles auswählen

-#define phys_size_t long int
+//#define phys_size_t long int

[mb405]

hehe jo ich trottel hab doch glatt nen cvs abgleich vergessen

kanns sein das ausgabe auf den framebuffer nimmer geht ?
ich glaube schon seit 1.3.x nimmer