Kernel bauen

[saltlake]

Hallo!

Im Juni hat AVM ja endlich mal wieder neue Kernel-Quellen online gestellt. Im Gegensatz zu der Version vom Dezember erledigt das Skript make-kernel.sh jetzt ja alles - vom Erstellen der Dummy-Verzeichnisse bis zum Extrahieren des Modul-SquashFS direkt aus einer Firmware. Allerdings hatte ich keinen mipsel-glibc-Crosscompiler und habe im Makefile.GPL einfach mipsel-linux eingestellt (ich denke das ist ein uclib-Compiler).

Nun habe ich aber das Problem, dass mein Kernel am Schluss ca. 30kB zu groß wird. Woran könnte das liegen? Ich habe sonst nichts geändert, nichtmal die Config.4mb angepasst. Macht make-kernel.sh vielleicht doch irgendwo was falsch, z.B. bei der Kernel-Kompression? Oder brauche ich diesen mipsel-glibc-Compiler, weil der kleineren Code erzeugt? Oder hat AVM im Config-File zu viel drin?

Danke für eure Erfahrungen!

 

[owb]

Hallo,

ich hab grad selbst einmal probiert einen eigenen Kernel zu erstellen.
Einen Compiler habe ich mir mit folgendem Script erstellt: crosstool (gcc-3.3.2-glibc-2.3.2)
Allerdings ist auch hier das resultierende Image deutlich groesser als das Original. Ich habe auch nichts an der Konfiguration geaendert.

 

[danisahne]

Bei mir ist er auch um ca 30 KB zu goß. Habe auch crosstool 0.38 (gcc-3.3.2-glibc-2.3.2) verwendet. Hat schon jemand bei avm nachgefragt?

 

[saltlake]

Bei AVM fragen hab ich mir auch gedacht. Werd ich in den nächsten Wochen auch mal machen. Was vielleicht auf helfen könnte, ist ein Vergleich mit den Makefiles von Dezember.

 

[danisahne]

Hab schon mal die .config Dateien verglichen und da ist schon einiges anders. Der AVM Support sollte mir morgen antworten. Bin jetzt allerdings nicht mehr zu Hause, so dass ich da erst nächstes Wochenende weitermachen werde. Lass euch wissen, was AVM dazu sagt.

 

[danisahne]

Also AVM hat sich bei mir noch nicht gemeldet. Das bin ich von dem Support garnicht gewohnt. Vielleicht könnten ja noch mehrere interessierte die Frage an AVM richten. An sich müßen die Sourcen des von AVM verwendeten Kernels doch offen sein. Nach der GPL sind sie doch dazu verpflichtet oder sehe ich das falsch?

 

[spblinux]

SCSI entfernen und CFLAGS_KERNEL = - Os

1) gefahrlos, aber jeder auf seine eigene Verantwortung:
Man kann bei der 7050 wohl genauso wie bei der 5050 den scsi support ausschalten
(make menuconfig), denn die 5050/7050 haben nur einen USB-Slave Chip,
aber keinen USB-Host Chip (scsi braucht es um an den usb host eine Platte hängen
zu können); damit wird der kernel ein gutes Stück kleiner, obwohl scsi als
modul konfiguriert ist; könnten genau die 30kB sein; (printer support braucht es aus demselben Grund nicht, aber dadurch wird der kernel wohl kaum kleiner)

2) man sollte mit recover.exe/recover.pl arbeiten können
(vorher testen ...)
Habe eine 5050 mit selbstgebautem Kernel und -Os zum bauen verwendet
(Makefile im linux-2.4.17... Verzeichnis: CFLAGS_KERNEL = -Os)
Das sollte den Kernel ein ganzes Stück verkleinern. - Läuft seit ein paar Tagen
ohne Fehler zu zeigen.

 

[danisahne]

Ich habe jetzt eine Reaktion von AVM erhalten:

Sehr geehrter Herr ********,

bitte haben Sie Verständnis dafür, dass wir über die Bereitstellung der
Quellen hinaus keine technische Unterstützung auf Entwicklerebene geben
können.

Mit freundlichen Grüßen

******** (AVM Support)

Da sie GPL Code benutzen müßen sie doch sehr wohl den Quellcode in einer Art und Weise bereitstellen, so dass man den Kernel reproduzieren kann. Oder liege ich da falsch?

 

[danisahne]

Sehr geehrter Herr ********,

vielleicht verwenden wir aber auch eine andere Umgebung oder einen anderen Computer,
oder andere libraries? Die Quellen entsprechen den von uns verwendeten und sind
sogar unlängst aktualisiert worden um zu den neusten Versionen zu passen.

Mit freundlichen Grüßen

******** (AVM Support)

Also angeblich seien die Sourcen korrekt, nur in welcher Umgebung sie den Kernel bauen, das kann mir AVM nicht sagen. Ich persönlich finde das schwach. Nun gut, wenn ich mal wieder Zeit habe, werde ich mal andere gcc und libc Versionen testen.

 

[olistudent]

Hi.
Falls du etwas Zeit hast, kannst du dich mal mit dem Inhalt dieses Archivs versuchen...

Hallo.
Beim durchstöbern der Sourcen von openwrt.org ist mir aufgefallen,
dass die den Kernel und das Filesystem mit LZMA komprimieren.
In den neuesten AVM Sourcen ist der LZMA Loader für den Kernel auch schon
dabei, ich hab ihn aber nicht auf Anhieb zum Laufen gekriegt.

Ergebnis: Der Kernel ist 200kb und das Filesystem 900kb kleiner!
Ich hab mal alles in ein Archiv gepackt, falls jemand was damit anfangen
kann.

Der Inhalt von inflater.tar.gz muss nach
buildroot/build_mipsel/linux-2.4.17_mvl21/arch/mips/mips-boards/ti-avalanche/inflater.
Das ist der „loader“, der den Kernel dekomprimiert und lädt. Nicht vergessen die Kernelconfig anzupassen. (CONFIG_KERNEL_COMPRESS_7ZIP=y)

Das Komprimieren dauert sehr viel länger als vorher. Ob das beim
Dekomprimieren auch so ist, kann ich nicht beurteilen.
Mir sind jedoch im Betrieb keine negative Veränderungen aufgefallen.

MfG Oliver

 

[voipmustbe]

According to this site
http://lists.gpl-violations.org/pipermail/legal/2005-June/000291.html
can you download the tarball and make use of the included compiler tool to compile your own kernel image. The wag54g uses the same AR7 CPU board like AVM. The GPL can download as followed
ftp://ftp.linksys.com/opensourcecode/wag54g/germany_only/

 

[danisahne]

Mit crosstool 0.38 (gcc-3.3.2-glibc-2.3.2) und -Os statt -O2 bekomme ich einen um wenige 100 Bytes größeren Kernel wie der aus der aktuellen Firmware. Habe ihn allerdings noch nicht ausprobiert. SCSI Support ausschalten macht ihn bei mir lediglich um ca 400 Byte kleiner. Ich glaube SCSI Support ist im Zusammenhang mit der ominösen Datei /lib/modules/cdrom.iso. Kann das sein? Für was ist denn das cdrom image?

Mit dem Compiler aus wag54g bekomme Fehler beim kompilieren. Irgendwas sei kein Prototype und er kennt auch einige Optionen nicht. Das sieht für mich mit den AVM Sourcen hoffnungslos aus.

Zu LZMA: Wie muss ich dann das Dateisystem komprimieren? Wird mir der Kernel gleich automatisch damit komprimiert? Da hab ich echt noch wenig Ahnung. Wie muss ich mir das vorstellen? Ersetzt mir LZMA das squashfs oder an welcher Stelle greift es.

 

[olistudent]

Du kannst den Kernel mit lzma komprimieren, ohne was am Dateisystem zu ändern, dazu änderst du einfach die Kernel-Config und kopierst die inflater.tar.gz an besagte Stelle.
Wenn du das Dateisystem auch mit lzma komprimieren willst musst du dir ein mksquashfs mit lzma support bauen.
Das läuft dann natürlich nur, wenn du den squashfs-support im Kernel mit lzma erweitert hast.
Das mit dem Kernel musst du selbst machen, das mksquashfs könnte ich dir schicken...

MfG Oliver

 

[danisahne]

Ah jetzt verstehe ich. Sollte ich generell lieber mit -O2 kompilieren oder macht das in der Laufzeit nicht so viel? Alle anderen Programme im Userspace hab ich auch mit -Os optimiert. Wie sind die Binaries z.B. im mod-57 optimiert?

mksquashfs brauch ich dann ja nur für meine Host Plattform. Hast du es für x86 schon kompiliert? Das darfste mir gerne an wieder@entfernt schicken.

Sobald ich das also im Kernel drinnen hab, kann ich das Dateisystem sowohl mit als auch ohne LZMA packen. Läuft bei dir auch schon LZMA?

gruß,
Daniel

EDIT:
Ich habe den inflater an die richtige Stelle kopiert (ich habe das ganze Verzeichnis inflater ersetzt oder muss ich das Zeug in das bestehende Verzeichnis entpacken). Da ich nicht das buildroot benutze ein paar Fragen. Reicht der im Patch enthaltene Patch package/avm-gpl/patches/040_squashfs_lzma.patch für die AVM Sourcen aus? Im Buildroot sind noch 3 weitere Patches an der Stelle für den Kernel (010_contiguous-squashfs.patch, 020_dont_build_binary_modules.patch und 030_squash2.1-r2.patch). Benötige ich die auch?

Habe bis jetzt immer mit mksquasfs aus mod-0.57 mein Dateisystem gemacht ohne dass ich den Kernel verändert hätte. Für mich sieht es aber aus, als ob im Buildroot (und in mod-0.57) eine neuere Version des squashfs verwendet wird. Bis jetzt hatte ich damit aber noch keine Probleme.

EDIT2:
Die Kerneloption CONFIG_KERNEL_COMPRESS_GZIP muss ich aber schon entfernen, wenn ich CONFIG_KERNEL_COMPRESS_7ZIP setze, oder verstehe ich das falsch?

 

[olistudent]

Ich hab da beim Kernel nie zwischen O2 und Os probiert.
Dachte das passt so, die Binaries werden mit Os kompiliert.

Bei mir läuft LZMA und ich hab damit keine Probleme.
Du kannst danach aber keine Filesystem ohne lzma mit diesem Kernel benutzen!

MfG Oliver

 

[danisahne]

Den Kernel hätte ich jetzt soweit fertig (hoffentlich). ram_zimage.bin (das ist doch der komprimierte Kernel) ist bei mir 451717 Bytes groß. Damit die Box mit dem Kernel läuft brauch ich also noch mksquashfs-lzma, richtig? Kannst du mir bitte das Binary an wieder@entfernt schicken. Vielen Dank!

Werd mich jetzt erst noch mit dem Recovery beschäftigen, damit ich der Box schnell wieder Leben einhauchen kann, falls was schief geht.

mfg,
Daniel

 

[olistudent]

Zum Recovern kannst du meinen FritzBoxEditor benutzen.
Oder das Perl-Skript von Enrik...
Mail ist unterwegs.

MfG Oliver

 

[danisahne]

Wow, super. Läuft soweit alles bestens. Vielen Dank olistudent!

Der Vollständigkeit halber:
- crosstool 0.38 (gcc-3.3.2-glibc-2.3.2)
- LZMA Patch für den Kernel
- Dateisystem mit LZMA (mksquashfs-lzma braucht um einiges länger zum komprimieren, aber das dekomprimieren sollte nicht unwesentlich länger als gzip brauchen)

Jetzt ist erstmal wieder einiges mehr Platz auf der Box. Ich bin begeistert!

 

[fritzchen]

@ danisahne

es interessiet mich, was Du hier machst... Leider verstehe ich es nicht ganz. Kannst Du kurz den Nutzen deines eigenen Kernels erklären???

Besten Dank!

 

[danisahne]

Hi fritzchen,

angefangen hat alles, da wollte ich iptables nutzen und mußte leider feststellen, dass es im AVM Kernel nicht aktiviert ist. Also hab ich mir die Sourcen von AVM geholt und kompiliert, aber der Kernel, der dabei rauskommt ist leider zu groß (das haben auch schon andere festgestellt).

Nachdem vor ein paar Wochen ein LZMA Patch die Runde machte, wollte ich das auch im Kernel haben. Vorteil: Kernel wird um einiges kleiner und das Dateisystem läßt sich damit auch um einiges runterkomprimieren. Mein Dateisystem Image ist jetzt komprimiert gerade mal 2,7 MB groß (vorher waren es über 3 MB), obwohl ich schon eine größere Busybox reingepackt hab.

Ich will von meinem neuen Kernel erstmal die 2 Sachen:
* iptables (müßte ich jetzt dank LZMA sogar in den Kernel einkompilieren können, ohne Modul)
* Um einiges mehr Platz im Dateisystem dank besserer Kompression

Man könnte sich aber auch Unterstützung für Netzwerkdateisysteme wie NFS oder so vorstellen, alles, was halt in den Kernel mitrein muss.