U-Boot updates

[rhabarber1848]

Im U-Boot git ist nach der Veröffentlichung der rc2 ein
Update für zlib von Version 0.95 auf Version 1.2.3
eingecheckt worden.
http://git.denx.de/?p=u-boot.git;a=comm ... 969f165d86

Da die allermeisten Tuxbox-Images mit zlib-komprimierten
Kernelimages arbeiten, wäre es wichtig, diesen
Code zu testen. Hier funktioniert er, nachdem ich den
Einbau von watchdog-reset-calls auf der U-Boot-Mailingliste
angestoßen habe, dies calls fehlten im ursprünglichen Patch.
http://git.denx.de/?p=u-boot.git;a=comm ... ded1096f44

Da der Watchdog der Dbox2 recht sensibel ist, würde
ich mich freuen, wenn er mit der git-Version von U-Boot
getestet wird.

Wie geht das? Ganz einfach, dieses Skript ausführen:

Code: Alles auswählen

#!/bin/sh
UBOOTDIR=$HOME/tuxbox/uboot.git

rm -rf $UBOOTDIR
mkdir -p $UBOOTDIR

cd $UBOOTDIR
git clone git://git.denx.de/u-boot.git
mv ./u-boot ./u-boot-2009.08-rc2

tar --exclude=.git --exclude=.gitignore -cf u-boot-2009.08-rc2.tar ./u-boot-2009.08-rc2
bzip2 -zv9 u-boot-2009.08-rc2.tar

Auf Debian Lenny heißt das git-Paket übrigens git-core.

Die Datei $HOME/tuxbox/uboot.git/u-boot-2009.08-rc2.tar.bz2
nach cdk/Archive kopieren und damit die vorhandene
Datei überschreiben.

Dann einfach ein Image bauen, egal ob Yadd oder Flash
(nicht flash-*-jffs2_lzma_klzma-*), booten und hier
eine Rückmeldung posten. Bei mir funktioniert das
Entpacken des Kernelimages auf einer normalen
66 MHz-Sagem-Kabelbox. Mehr habe ich bisher nicht
testen können.

[GetAway]

Bei mir funktioniert das Entpacken des Kernelimages auf einer Nokia-Kabelbox ebenfalls.

[maggou]

Yadd mit git-Version u-boot gebaut,Entpacken des Kernelimages hier auf Nokia Sat auch erfolgreich.

[rhabarber1848]

Danke fürs Testen!

[rhabarber1848]

U-Boot 2009.08-rc3 wurde veröffentlicht, einzige Tuxbox-Anpassung
ist im JFFS2-Code, wo einige neue Patches rückgängig gemacht
werden müssen. Ein JFFS2-only und ein Squashfs/JFFS2-Image
booten hier einwandfrei, bitte testen: EDIT: Patch ist im CVS

[GetAway]

Yadd / Squashfs mit U-Boot 2009.08-rc3 bootet auch bei mir.

[rhabarber1848]

Yadd / Squashfs mit U-Boot 2009.08-rc3 bootet auch bei mir.

committed, danke für das Testen!

[rhabarber1848]

U-Boot 2009.08 ist fertig und wird im Tuxbox CVS genutzt:
http://article.gmane.org/gmane.comp.vid ... x.scm/1035

Abgesehen vom Booten per HDD ist das auf absehbare Zeit die
letzte Änderung, die U-Boot im Tuxbox CVS betreffen wird.
Von meiner Seite sind keine neuen Features mehr geplant.

[seife]

booten von hdd (mit auswahlmenü) ist dank meiner Dummheit / Unvorsichtigkeit bis auf weiteres "postponed", bis Martin meine IDE-64mb-nokia wieder zum Leben erweckt (wozu ich sie ihm erst mal schicken muss... )g

[mb405]

ui was haste denn gemacht ?
böser fehler ?

[seife]

"saveenv" getippt

[mb405]

wenn du nen tester brauchst, bin ich gerne dafür da

[rhabarber1848]

U-Boot 2009.11-rc1 ist da, bitte testen: uboot-2009.11-rc1.diff

Kernel 2.4: Yadd & jffs2_lzma_klzma positiv getestet

[GetAway]

3x YaDD gebootet. 2x gabs Probleme mit den Logo's.

Code: Alles auswählen

U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 21:43:53)

CPU:   PPC823ZTnnA at 67.200 MHz: 2 kB I-Cache 1 kB D-Cache
         *** Warning: CPU Core has Silicon Bugs -- Check the Errata ***
Board: DBOX2, Nokia, BMon V1.0
       Watchdog enabled
I2C:   ready
DRAM:  32 MB
FLASH:  8 MB
FB:    ready
In:    serial
Out:   serial
Err:   serial
Net:   SCC ETHERNET
BOOTP broadcast 1
DHCP client bound to address 192.168.178.5
Using SCC ETHERNET device
File transfer via NFS from server 192.168.178.24; our IP address is 192.168.178.5
Filename '/home/getaway/tuxbox/dbox2-2.4_pers/cdkroot/var/tuxbox/boot/boot.conf'.
Load address: 0x200000
Loading: #
done
Bytes transferred = 72 (48 hex)
env: found console with value ttyS0
env: found baudrate with value 9600
env: found dbox_duplex with value 0
env: found lcd_inverse with value 0
env: found lcd_contrast with value 15
LCD:   ready
BOOTP broadcast 1
DHCP client bound to address 192.168.178.5
Using SCC ETHERNET device
File transfer via NFS from server 192.168.178.24; our IP address is 192.168.178.5
Filename '/home/getaway/tuxbox/dbox2-2.4_pers/cdkroot/var/tuxbox/boot/logo-lcd'.
Load address: 0x200000
Loading: Timeout
can't find LCD logo
BOOTP broadcast 1
DHCP client bound to address 192.168.178.96
Using SCC ETHERNET device
File transfer via NFS from server 192.168.178.1; our IP address is 192.168.178.96
Filename '/home/getaway/tuxbox/dbox2-2.4_pers/cdkroot/var/tuxbox/boot/logo-fb'.
Load address: 0x200000
Loading: Timeout
can't find FB logo

[rhabarber1848]

2x gabs Probleme mit den Logo's.

File transfer via NFS from server 192.168.178.24; our IP address is 192.168.178.5
Filename '/home/getaway/tuxbox/dbox2-2.4_pers/cdkroot/var/tuxbox/boot/logo-lcd'.
Load address: 0x200000
Loading: Timeout
can't find LCD logo

Tritt das Problem mit U-Boot 2009.08 nie auf?

[GetAway]

Das Problem gab es schon beim 2009.08, bis Du einen weiteren Patch,
wegen des Timeouts, eingespielt hattest. Oder hattest Du ihn rausgenommen.

[rhabarber1848]

Seitens der U-Boot-Entwickler wurde der Vorschlag geäußert, die Dbox2-Unterstützung in die offizielle U-Boot-Distribution aufzunehmen:

http://article.gmane.org/gmane.comp.boo ... boot/70980

the code was written by other people and is maintained out-of-uboot-tree in our public CVS.

So why not move mainline? Usually it's pretty fun to get other peoples
code into mainline *lol*

http://article.gmane.org/gmane.comp.boo ... boot/70983

After unpacking U-Boot 2009.08 these files are copied into the source
tree: http://cvs.tuxbox-cvs.sourceforge.net/t ... ot-tuxbox/

Ah uh, I would even offer some help in the process (like adding a branch
in the u-boot-testing repository), but this instruction is somewhat
unspecific, i.e. I see three boards being supported. If we want to get
the support mainline, we should start with only one of them - including
only the neccessary changes, i.e. cpu/ppc4xx/serial_sicc.c is very
likely not relevant for the dbox

the Dreambox files are not used atm, they were added 5 years ago, I never
cared about them.

The IPBox stuff is used with U-Boot 1.2.0, I do not have plans to upgrade
to a more recent U-Boot version because I do not have the hardware for
testing.

So only the Dbox is left, and yes, merging it will be fun;)

Our code includes functions to read files (config, logos) from a JFFS2
partition, display LCD and framebuffer logos during boot, some unfinished
support for booting from HDD and loading kernels from Squashfs
partitions.

The Squashfs code is based on Squashfs 3.0, it can not be upgrade to 3.3
or 4.x because we use Linux 2.4.37.6, where Squashfs > 3.0 is not
available.

Squashfs support in U-Boot also includes optional LZMA support, but not
the LZMA 4.65-based code from U-Boot, but LZMA 4.40 included in fs/
squashfs/. It is therefore not possible to link both LZMA libs into U-
Boot at compile time. This is not needed for us because the root
filesystem is either Squashfs/LZMA-4.40 or JFFS2/LZMA-4.65.

As hinted before, I do not have much C skills to do necessary cleanups
nor do I want to be mentioned as official maintainer

But the code is in use for many years by lots of users so technically
there should not be many problems.

Was denkt ihr darüber? Immerhin stammen die ersten Versionen aus
dem Jahre 2002, ich kenne die Hintergründe der Programmierung nicht
und möchte, ehrlich gesagt, mögliche Probleme nicht rechtfertigen
müssen. Dazu fehlen mir auf jeden Fall die Programmierkenntnisse.

Zudem sind noch einige Inkompatiblitäten vorhanden, die lokal
gepatcht werden, neben dem besagten NFS-Problem wird auch
eine ältere Version des JFFS2-Codes genutzt.

[Liontamer]

Ich weiß aus eigener leidiger Erfahrung, dass die U-Boot Custodians und vor allem Wolfgang sehr pingelich sind, was coding style, strukturierung etc. betrifft. Wenn ich mir den Umfang des dbox2 U-Boots so anschaue, wird das sicher nie von denen akzeptiert.
Und wenn doch, ist vorher noch ne menge Arbeit reinzustecken...

Btw. ich hab eure Unterhaltung gestern schon mitverfolgt und mich köstlich amüsiert. Vor allem über Wolfgangs statement

> U-Boot 2009.11 (Tuxbox) (Nov 03 2009 - 08:59:24)
>
> CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache
> Board: DBOX2, Sagem, BMon V1.0

This does not seem to be any of the boards supported in mainline. It
does not even show a correct version id, so I'm not surprised that
more bugs are present in this code.

Best regards,

Wolfgang Denk

[seife]

Ich bin dafür, das mainline zu bringen.

Ich würde auch den "offiziellen Maintainer" machen, denn ich muss jetzt sowieso U-Boot lernen

Ich melde mich gleich mal auf der Liste an (das wollte ich sowieso, hatte es aber vergessen).

[rhabarber1848]

Obwohl ich nicht als maintainer dienen werde, möchte ich hier
einige Infos weitergeben, die ich mir bei der Implementierung
des LZMA-Supports in U-Boot und Kernel-JFFS2 angeeignet habe.

Auf der Dbox2 werden Kernel 2.4.37.6 und 2.6.26.8 ( > 2.6.26
geht nicht, da arch/ppc nicht mehr existiert) verwendet.

U-Boot fungiert als second-stage-Bootloader, der vom Dbox-
Bootloader aufgerufen wird. Für den s-s-Bootloader sind 128 KB
im Flash reserviert, diese Partition beinhaltet nur U-Boot, muss
aber mit mkflfs erstellt werden, da der Dbox-Bootloader dieses
spezielle Format erwartet. Imho sollte mkflfs ebenfalls in Mainline
U-Boot integriert werden.

Für beide Kernel wird Squashfs 3.0 mit optionalem LZMA 4.40
verwendet. Neuere LZMA-Versionen für Squashfs 3.0 sind mir
nicht bekannt. Neuere Squashfs-Versionen sind für Kernel 2.4
nicht verfügbar, deshalb wird auch bei Kernel 2.6 Squashfs 3.0
eingesetzt, damit U-Boot Kernel-unabhängig booten kann.[1]
Mainline U-Boot beinhaltet keinen Squashfs-Support, im Tuxbox-
CVS gibt es den passenden Squashfs 3.0-LZMA 4.40-Support.

Für JFFS2 wird LZMA 4.65 in beiden Kernel-Versionen verwendet.

In der Praxis kann ein JFFS2-only-Image mit LZMA-Kompression
oder ein Squashfs-LZMA-Image mit JFFS2 (ohne LZMA)-/var-
Partition genutzt werden. Theoretisch kann in einem Squashfs-
LZMA-Image auch /var LZMA-komprimiert sein, dazu müsste
U-Boot beide LZMA-Bibliotheken (4.40 für Squashfs zum Laden
des Kernels von der Root-Partition, 4.65 für JFFS2 zum Laden der
Logos und boot.conf) beinhalten. Das ist praktisch nicht möglich,
da für U-Boot nur 128 KB Platz im Flash reserviert sind, allerdings
LZO-komprimiert. Wenn beide LZMA-Bibliotheken, Squashfs
und JFFS2 in U-Boot integriert sein sollen, wird U-Boot zu groß.

Für den praktischen Betrieb gibt es drei verschiedene Varianten
von U-Boot in Abhängigkeit des verwendeten Root-Dateisystems.

JFFS2, immer mit LZMA-Unterstützung
Squashfs, ohne LZMA
Squashfs, mit LZMA

Ein JFFS2-U-Boot beinhaltet immer LZMA-Unterstützung, einmal
zum Entpacken LZMA-komprimierter Kernel-Images (sind nur für
JFFS2-Images verfügbar, nicht in Squashfs-Images wegen des o.g.
Platzproblems). Die LZMA-Unterstützung für JFFS2 wird von U-Boot
selbst zur Verfügung gestellt, es handelt sich um Version 4.65.
Möglich ist die permanente LZMA-Unterstützung durch die Tatsache,
dass U-Boot und der Kernel erkennen können, ob ein JFFS2-Datei-
systemblock zlib- oder LZMA-komprimiert ist, indem LZMA als
neue JFFS2-Kompressionsmethode deklariert wird, die parallel
zu anderen Methoden existieren kann:
linux/include/linux/jffs2.h

Code: Alles auswählen

#define JFFS2_COMPR_LZMA       0x15

Das ist für den LZMA-Support in Squashfs 3.0 leider nicht möglich,
da LZMA 4.40 mit

Code: Alles auswählen

#ifdef CONFIG_SQUASHFS_LZMA
[neuer LZMA-Code]
#else
[alter zlib-Code]
#endif

arbeitet und somit zwei Squashfs-Versionen von U-Boot (und Kernel)
notwendig macht, einmal mit und einmal ohne LZMA-Unterstützung.

[1] Auf der Dbox2 können beim Flashupdate nur bestimmte Partitionen
aktualisiert werden, d.h. U-Boot muss mit Kernel 2.4 und 2.6
zurechtkommen, da ein Image-Update nur für die root-Partition
möglich ist.

[seife]

man könnte natürlich auch einfach dem Kernel eine eigene Partition im flash zugestehen, dann müsste der u-boot überhaupt kein Filesystem lesen / dekomprimieren können und LZMA (das ist wegen der Kotqualität praktisch immer kontrovers ) bliebe erstmal aussen vor.

[rhabarber1848]

man könnte natürlich auch einfach dem Kernel eine eigene Partition im flash zugestehen

Das ist in meinen Augen Platzverschwendung, da für
die Partition immer mehr Platz als wirklich nötig
vorgehalten werden muss.

[seife]

IIUC sind d es maximal (128k - 1 byte) wenn man es richtig macht.

Wenn wir den Code upstream haben wollen gibt es genügend Baustellen, da würde ich nur ungern mit alten Squashfs und mit LZMA auf der U-Boot-Liste ankommen.

Funktionieren tut es ohne

[rhabarber1848]

IIUC sind d es maximal (128k - 1 byte) wenn man es richtig macht.

Du meinst dynamische Kernel-Partitionsgröße in Abhängigkeit
von der Größe des Kernelimages?

Welches Dateisystem schwebt Dir für die Kernel-Partition vor, JFFS2?
Wenn ja, da gab es schon mal was:
http://forum.tuxbox-cvs.sourceforge.net ... 96#p359496

[seife]

Mir schwebt eine rohe Partition für den Kernel vor, gar kein Filesystem. Und die Grösse der anderen Partitionen (root / var) als Kommandozeile übergeben. Die U-Boot-Config auch in einem flash-block speichern, statt in boot.conf, (ja, das "verschwendet" nochmal 128k), dann braucht u-Boot überhaupt keine FS-Unterstützung, und gleichzeitig kann dann jeder u-Boot jedes beliebige Image / Partitionslayout booten (man könnte die Partitionslayouts anhand der Magic numbers noch automatisch erkennen).

Und booten von Platte wäre dann auch, unabhängig vom verwendeten Partitionslayout im Flash, trivial.

Momentan ist es so, dass der U-Boot genau zum Partitionslayout im FLASH passen muss. Das finde ich unelegant.
Auch ist es schwer, ein bootmenü (im U-Boot) zu machen, das erlaubt, von der Platte zu booten (und sich diese Einstellung auch zu merken, denn dazu müsste man momentan im jffs2 schreiben).

...und gleichzeitig kann ich die kontroversen Sachen upstream erstmal weglassen