danisahne-mod ..::Developer::..

[kübel67]

Hallo,
erstmal danke für die Antwort
Habe die erste Antwort wohl übersehen, tut mir leid.

Was soll nicht GPL konform sein?

Na, ohne die zugehörigen hw-docs können selbst die selber ihre Programme nicht verstehen- Wie denn erst außenstehende? Das wiederspricht doch dem Sinn der GPL.
Du hast übrigens meine Frage nicht beantwortet, ob ihr mod-developer docs für den Chipsatz, die Chipsätze habt.

Zitat von kübel67
Wäre toll wenn ihr wissenden einfach mal den Weg skizziert, mit dem ihr zu eurem Wissen gekommen seid, anhand von Dokumenten meine ich.
Zitat von danisahne
Das kommt davon, weil wir uns schon lange mit der Box beschäftigen. Es gibt eine Wiki, die ein paar Sachen zusammengetragen hat:

Das Wiki kannte schon. Nur um mal zu veranschaulichen, was ich wil:
Also ich habe mal vor Jahren mir den 2.4er Kernel genommen, die Sourcen auf die Festplatte gezogen und mit Hilfe der hw-docs, Intelprozessorbeschreibungen 1-3, einem Buch über Pc-architektur, und ewtl einigen Howtos zum Thema den Initialisierungsprozess studiert. ging ok.
aber hier?
- Gibt es hw-docs?
- Wie komme ich zu den gepatchten Sourcen der von dir und avm modifizierten binaries, um sie zu lesen -und um sie schließlich selbst zu verändern?
Ich interessiere mich auch dafür, wie ihre die mods herstellt?

Zitat von kübel67
Ja und dann noch eine Frage, die beweist wie sehr ich nicht nur bzgl der Speicherbelegung im Dunkeln tappe:
Ist es etwa so, daß fb/ds02 sich Apps von externen hosts herunterlädt? Huch.
Zitat von
Nein, der danisahne-mod baut die Änderungen in das read-only Squashfs ein, das was df als 100% voll anzeigt.

Das beantwortet nicht meine Frage.
MfG
Thomas

 

[danisahne]

Na, ohne die zugehörigen hw-docs können selbst die selber ihre Programme nicht verstehen- Wie denn erst außenstehende? Das wiederspricht doch dem Sinn der GPL.

Sowas deckt doch nicht die GPL Lizenz. Ich weiß auch nicht, was du mit hw-docs meinst. Der Befehlssatz des Prozessors dürfte bekannt sein, sonst würde er von Linux nicht unterstützt werden. Es ist ein mipsel Prozessor (find den Namen der Prozessoren nicht mehr). Viele weitere verwendete Chipsätze haben Closed Source Treiber, die nicht unter der GPL Lizenz veröffentlicht sind. Für diese Chipsätze gibt es daher auch keine/kaum Dokumentation, denke ich.

Nur warum mußt du das zum Programmieren wissen? Ein großer Teil des Linux Kernels ist Architektur unabhängig und den Architektur abhängigen Teil liefert AVM mit seinen Kernel Sourcen aus. Im Userspace muss man gerade noch wissen, wie groß die Wortbreite ist und vielleicht ob er big oder little endian ist.

- Gibt es hw-docs?

Die Doku, die du suchst habe ich nicht, wenn ich dich richtig verstehe.

- Wie komme ich zu den gepatchten Sourcen der von dir und avm modifizierten binaries, um sie zu lesen -und um sie schließlich selbst zu verändern?
Ich interessiere mich auch dafür, wie ihre die mods herstellt?

Mit `make sources' werden alle Sourcen, die für den Mod verwendet werden ins Verzeichnis ./source/ entpackt. Wenn es dir nur um die Sourcen von AVM geht, die gibt es auf dem FTP Server: ftp://ftp.avm.de/develper/opensrc

EDIT: Willst du im Kernelspace oder im Userland programmieren? Für den Userspace nimm einfach die Toolchain, die du z.B. mit dem Mod durch `make toolchain' erstellen kannst (das produziert genaugenommen 2 Toolchains: glibc Toolchain für den Kernel (älterer Compiler) und uClibc Toolchain für den Userspace (gcc 4.1.0)). Auf der Box ist nicht die ganze Standard libc, sondern nur die für den Embedded Bereich hervorragend geeignete uClibc.

Mfg,
danisahne

 

[krafte]

Es ist ein mipsel Prozessor (find den Namen der Prozessoren nicht mehr).

Versuchs mal mit:

cat /proc/cpuinfo

:wink:

Naja ich hab seit gestern eine FB, und das hier war das erste was mir Google ausgespuckt hat. Ich hatte ja keine Ahnung was ich mir da angeschaft habe. Naja wenn ich dann mal Zeit hab werd ich auch ein bisschen modden, falls es dann noch was zu modden gibt (ihr seid ja schon fleisig) und vielleicht etwas sinnvollere posten als das hier. :wink:

Bye, Andy.

 

[meimi039]

@ danisahne:
Ich würde mir gerne mehr RAM freischaufeln, da die Box doch manchmal rebootet, wenn´s ihr zu eng wird. Vielleicht bietet sich da der USB-Stick einer 7170 an. Wäre es nicht möglich /var/tmp auf den Stick zu mounten. Dann wäre da schonmal mehr Platz und soviel passiert da ja auch nicht, daß man sich den Stick kaputt schreibt. Das wäre möglicherweise auch eine Möglichkeit für /var/tmp/flash (is eigentlich ja das gleiche). Vielleicht kann man irgendwo ein "Flag" setzen, welche Links vorher angelegt werden sollen, bevor die Scripts ihre tar-files auspacken? Was wäre noch denkbar?

 

[danisahne]

Kannst du das nicht einfach mal testen? An sich mußt du den Stick ja nur vor dem Entpacken der var.tar in der rc.S mounten (finde erst heraus, ob der Stick zu dem Zeitpunkt schon gemounted ist, dann könntest du ein Verzeichnis auf dem Stick mit "mount -o bind /path/to/usb/stick/tmp /var/tmp" mounten). Ich hab keine Box mit USB Host, ich kanns nicht für dich austesten. Brauche also eine fertige Lösung.

Warum ist denn deine Ramdisk so voll? Eigentlich ist da fast nichts drinnen und von da her sollten damit nur ganz minimal gespart werden können. In meinen Augen ist das den Aufwand nicht wert. Wenn du von Webservern Zeug nachlädst, dann versuch das mal in deine Firmware einzubauen, bzw starte das vom USB Stick.

Wie groß ist dein /var/tmp/ Verzeichnis?

du -h /var/tmp/

Mfg,
danisahne

 

[meimi039]

Ich kann leider gerade nicht an meine Box, weil mir vor zwei Stunden jemand den Bürgersteig aufgegraben hat ... Natürlich ist jetzt alle Telekomikerei tot...
Normalerweise läuft bei mir openvpn und dann sehe ich, wie dieser Prozess (je nach Anzahl der Tunnel) mehr Speicher allokiert. Ein 'free' gibt dann Werte um die 700k an freiem RAM aus. Wenn ich jetzt noch mit sowas wie transmission komme issi wohl tot...
Also meine hypothetische Frage: Wo kann man alles sparen, um ein maximum an RAM freizubekommen?

Das mit der rc.S werde ich testen, sobald ich wieder an meine Box kann...

Wir hatten ja vor langer Zeit schonmal dieses Thema angeschnitten, ob man den Mod (wenn er denn weiter wächst) nicht auf einem Stick etc. unterbringen kann, falls dieser denn verfügbar ist. Das würde den Mod wohl in zwei Teile spalten: Zum einen die Veränderungen der Box (busybox, kernel, ...) und zum Anderen die Zusatzfunktionen wie WebGui, etherwake, vpn, bftp... , die man dann z.b. Intern oder auf einem Stick unterbringen könnte (sollte der User entscheiden dürfen). Die Box sollte natürlich ohne Stick dann noch laufen können...
Das ist aber nur ein Traum... Ich wage es garnicht dies einen Feature-Request zu nennen wenn ich sehe, welche Arbeit Du jetzt schon da drinnen hast, und zu welchen Zeiten Du auf threads reagierst ... :groesste:

 

[danisahne]

Du bekommst aber nicht mehr Arbeitsspeicher frei, wenn du Pakete auf den USB Stick auslagerst. Der Mod speichert sie ja in den Flash und läd nichts in die Ramdisk nach (da ist nur die Konfiguration). Du kannst also damit Flash aber nicht Arbeitsspeicher sparen.

 

[meimi039]

Das ist richtig. Das mit dem Stick bezieht sich auch nur auf die Größe des Mod selbst. Falls da irgendwann mal sooooo viele Pakete zur Wahl stehen, daß sie einfach nicht mehr im Flash unterzukriegen sind...
Das mit dem RAM ist eine andere Sache. Ich vermute einfach mal, daß die Ramdisk dynamisch mit dem Inhalt wächst. Es müsste dann also Platz schaffen, wenn man deren Inhalt möglichst klein hält, also das TelefonSparbuch etc eben auslagert...

 

[hsudek]

Signalhandling

Hallo.
Ich versuche gerade ein Programm mit Signalhandling zu schreiben. Wenn ich gegen die glibc linke funktioniert das untenstehende Programm fehlerfrei. Auf der Fritzbox bekomme ich einen "SIGSEGV" sobald ich dem Programm das Signal "SIGINT" sende.
Hat jemand eine Idee woran das liegen kann? Habe ich beim erstellen der Toolchain einen Fehler gemacht?

#include <signal.h>

int run=1;

void sigHandler( int signal ) { run=0; return; }

int main(){
	signal( SIGINT, sigHandler );
	
	while(run){ sleep(1); }
	
	return(0);
}

Meine Fritzbox ist übrigens nicht modifziert.

Update:
Das hier scheint das gleiche Problem zu beschreiben. Und es ist sogar schon gelöst.
http://busybox.net/bugs/view.php?id=480
Stellt sich nur die Frage wie man den mod mit dem aktuellen uClibc Snapshot kompilieren kann.

Update:
Der Fehler scheint nur aufzutreten wenn ich das Programm statisch linke. Mit diesem Befehl zum linken klappt alles wie erwartet

mipsel-linux-gcc signal-handler.c  -static-libgcc -o signal-handler

Aber nicht zu schnell freuen. Wenn ich Transmission so linke wirft das Programm ein SIGSEGV in der Funktion tr_torrentInit...

Update:
OK. DerFehler ist jetzt auch klar Transmission wird per default mit -D_LARGEFILE_SOURCE compiliert was die Fritzbox uClibc nicht unterstützt.

Update:
Das hier scheit eine unendliche Geschichte zu werden. Wenn man das obige Programm leicht abändert funktoniert es wieder nicht.

#include <signal.h>
#include <stdio.h>

volatile int run=1;

void sigHandler( int signal ) { fprintf(stderr, "sigHandler\n"); run=0; }

void dummy(){
	sleep(0);
	fprintf(stderr, "dummy done\n");
}

int main(){
	signal( SIGINT, sigHandler );
	dummy();
	while(run){ sleep(1); }
	fprintf(stderr, "done\n");
	return(0);
}

Dieses Programm beendet sich mit einem SIGSEGV, wenn es SIGINT gesendet bekommt. Entfernt man den Aufruf der Funktion dummy(); läuft es hingegen wie erwartet. Auch das hinzufügen von Code kann das Problem beheben. Das ganze scheint etwas mit der Position im Programm zu tun zu haben, an der das Programm sich befindet, wenn es das Signal bekommt. Daher ist es auch wichtig welche Compilerflags man benutzt. Dieser Aufruf produziert den Fehler:

mipsel-linux-gcc -static-libgcc  signal-handler.c -o signal-handler

Benutzt man jedoch -Os oder -O2 tritt der Fehler in diesem Programm nicht mehr auf. Aber man kann auch für diese Fälle Programme finden, die nicht funktionieren.

Da es ohne Signalhandling schwer ist vernünftige Programme zu schreiben, wäre es schön wenn jemand das testen könnte.

mfg henner

 

[olistudent]

Wir brauchen ja nicht die neue uClibc. Es reicht wenn Daniel den Patch in die uClibc integriert...

diff -ur uClibc-0.9.28/libc/sysdeps/linux/mips/sigaction.c uClibc-0.9.28.openwrt/libc/sysdeps/linux/mips/sigaction.c
--- uClibc-0.9.28/libc/sysdeps/linux/mips/sigaction.c 2005-08-18 00:49:44.000000000 +0200
+++ uClibc-0.9.28.openwrt/libc/sysdeps/linux/mips/sigaction.c 2005-10-20 13:19:05.000000000 +0200
@@ -49,7 +49,8 @@
memcpy (&kact.sa_mask, &act->sa_mask, sizeof (kact.sa_mask));
kact.sa_flags = act->sa_flags;
 
- kact.sa_flags = act->sa_flags | SA_RESTORER;
+/* http://bugs.uclibc.org/view.php?id=480
+ kact.sa_flags = act->sa_flags | SA_RESTORER; */
#ifdef HAVE_SA_RESTORER
kact.sa_restorer = act->sa_restorer;
#endif

MfG Oliver

 

[danisahne]

In AVM's Version der uClibc sind nur

./libc/sysdeps/linux/arm/sigaction.c
./libc/sysdeps/linux/i386/sigaction.c
./libc/signal/sigaction.c

vorhanden, ich kann besagt Stelle aber nur in der libc/sysdeps/linux/i386/sigaction.c finden. Wird diese zum Kompilieren unserer mipsel Version verwendet? Das muss ich mal nächstes Wochenende ausprobieren. Den Code um das Problem zu reproduzieren hab ich ja schon von hsudek

Mfg,
danisahne

EDIT: Kann den Patch doch nicht anwenden.

 

[olistudent]

Hm, das wäre wohl auch zu einfach gewesen. Die sigaction.c für MIPS kam 3 Monate zu spät...

File: [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/?rev=8962#dirlist"][COLOR=#0000ff][svn][/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/?rev=8962#dirlist"][COLOR=#0000ff]trunk[/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/?rev=8962#dirlist"][COLOR=#ee6600][B]uClibc[/B][/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/?rev=8962#dirlist"][COLOR=#0000ff]libc[/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/?rev=8962#dirlist"][COLOR=#0000ff]sysdeps[/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/?rev=8962#dirlist"][COLOR=#0000ff]linux[/COLOR][/URL] / [URL="http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/mips/?rev=8962#dirlist"][COLOR=#0000ff]mips[/COLOR][/URL] / sigaction.c ([URL="http://uclibc.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/uClibc/libc/sysdeps/linux/mips/sigaction.c?rev=8962"][B][COLOR=#0000ff]download[/COLOR][/B][/URL]) ([URL="http://uclibc.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/uClibc/libc/sysdeps/linux/mips/sigaction.c?content-type=text%2Fplain&rev=8962"][B][COLOR=#0000ff]as text[/COLOR][/B][/URL]) 
Revision: [B]8962[/B], [I]Fri Jul 16 17:39:14 2004 PDT[/I] (20 months, 3 weeks ago) by [I]andersen[/I] 
File size: 3461 byte(s) 
Add sigaction for mips

MfG Oliver

 

[danisahne]

Ich habe jetzt mal einen Anfang gemacht, den ds-mod auch für Developer zu dokumentieren, Wen's interessiert, so sieht die [wiki=software:ds-mod:development:flash]Flash Partitionierung[/wiki] der Fritzboxen aus.

Mfg,
danisahne

 

[ptweety]

Das ist ein feines Stück Arbeit. Wenn du so weitermachst, dann verstehe ich das auch irgendwann mal alles

Ich habe jetzt aber mal ne Frage zur weiteren Strategie des ds-mod:

Bisher kann sich ja jeder sein einenes Image auf Basis der Originalfirmware zusammenbauen und dabei alle möglichen Pakete mit aufnehmen oder weglassen. (stimmts?)

Es gibt aber doch sicher Teile des ds-mods, welches man allgemein empfehlen könnte. Ich denke da an NFS & SAMBA Treiber, dropbear, firewall, web-frontend, ...

Man könnte doch dem etwas unbedarften Anwender (also z.B. mir ) eine geeignete Vorauswahl zusammenstellen, das ganze mit einem Paketmanager anreichern und dann vorkompilierte Packete erstellen, die sich jeder nach Bedarf auf einen externen Datenspeicher (per USB, NFS, Samba angebunden) nachladen kann.

Ich glaube, dass man bei entsprechender Vorarbeit vieles aus dem nslu2-linux Projekt übernehmen könnte. Insbesondere haben die schon viele Pakete für's crosscompile vorbereitet und unterstützen schon ein mipsel-Target mit dem WL500G.

MFG pTweety

PS: für die slug habe ich einige Paket bereitgestellt und könnte hier natürlich auch mithelfen (z.B. hätte ich Interesse an fetchmail, postfix, cyrus, cherokee, php, xmail, getmail, procmail, dovecot).

EDIT: hm, so was wurde weiter vorne schon von EvilDevil vorgeschlagen. Was ist daraus denn geworden?

 

[danisahne]

Es gibt aber doch sicher Teile des ds-mods, welches man allgemein empfehlen könnte. Ich denke da an NFS & SAMBA Treiber, dropbear, firewall, web-frontend, ...

Das sieht wohl jeder anders und da der Platz auf manchen Boxen sehr knapp ist, soll sich das bitte jeder selbst aussuchen.

[...] das ganze mit einem Paketmanager anreichern und dann vorkompilierte Packete erstellen, die sich jeder nach Bedarf auf einen externen Datenspeicher (per USB, NFS, Samba angebunden) nachladen kann.

Das wollte ich irgendwann noch machen, allerdings fehlt mir ne Box mit USB Host zum testen.

Ich glaube, dass man bei entsprechender Vorarbeit vieles aus dem nslu2-linux Projekt übernehmen könnte. Insbesondere haben die schon viele Pakete für's crosscompile vorbereitet und unterstützen schon ein mipsel-Target mit dem WL500G.

Ich schaue mir viel vom OpenWRT Projekt ab.

Ich kann den Fehler in der sigaction.c leider nicht finden und werde es daher jetzt nicht weiterverfolgen. Wenn jemand eine Lösung gefunden hat, dann soll er sie doch bitte hier posten.

mfg,
danisahne

 

[ptweety]

Das wollte ich irgendwann noch machen, allerdings fehlt mir ne Box mit USB Host zum testen.

Tja, wenn du 'nen Tester brauchst; ich habe eine 7170 und eine USB-Platte hier

EDIT: wenn ich jbd.o und ext3.o nachlade und per insmod lade, dann klappt das mounten schon mal. Wie kann ich aber nun diese Module fest in mein Image integrieren?

EDIT2: Ist das folgende diff (natürlich mit setzen der neuen Optionen) schon ausreichend?

diff -Nru ds-0.2.3-orig/.defconfig ds-0.2.3-ptweety/.defconfig
--- ds-0.2.3-orig/.defconfig    2006-04-03 17:34:04.000000000 +0200
+++ ds-0.2.3-ptweety/.defconfig 2006-04-15 22:27:00.000000000 +0200
@@ -91,7 +91,10 @@
 #
 # fs
 #
+# DS_KERNEL_MOD_ext2 is not set
+# DS_KERNEL_MOD_ext3 is not set
 # DS_KERNEL_MOD_fat is not set
+# DS_KERNEL_MOD_jbd is not set
 # DS_KERNEL_MOD_lockd is not set
 # DS_KERNEL_MOD_nfsd is not set
 # DS_KERNEL_MOD_nfs is not set
diff -Nru ds-0.2.3-orig/kernel/Config.in ds-0.2.3-ptweety/kernel/Config.in
--- ds-0.2.3-orig/kernel/Config.in      2006-04-03 00:44:51.000000000 +0200
+++ ds-0.2.3-ptweety/kernel/Config.in   2006-04-15 23:29:46.000000000 +0200
@@ -60,10 +60,23 @@

 comment "fs"

+config DS_KERNEL_MOD_ext2
+       bool "ext2.o"
+       default n
+
+config DS_KERNEL_MOD_ext3
+       bool "ext3.o"
+       select DS_KERNEL_MOD_jbd
+       default n
+
 config DS_KERNEL_MOD_fat
        bool "fat.o"
        default n

+config DS_KERNEL_MOD_jbd
+       bool "jbd.o"
+       default n
+
 config DS_KERNEL_MOD_lockd
        bool "lockd.o"
        select DS_KERNEL_MOD_sunrpc
diff -Nru ds-0.2.3-orig/make/linux/Config.ohio-8mb ds-0.2.3-ptweety/make/linux/Config.ohio-8mb
--- ds-0.2.3-orig/make/linux/Config.ohio-8mb    2006-04-03 01:05:54.000000000 +0200
+++ ds-0.2.3-ptweety/make/linux/Config.ohio-8mb 2006-04-15 22:26:21.000000000 +0200
@@ -780,7 +780,7 @@
 # CONFIG_QNX4FS_FS is not set
 # CONFIG_QNX4FS_RW is not set
 # CONFIG_ROMFS_FS is not set
-# CONFIG_EXT2_FS is not set
+CONFIG_EXT2_FS=m
 # CONFIG_SYSV_FS is not set
 # CONFIG_UDF_FS is not set
 # CONFIG_UDF_RW is not set

MFG pTweety