Probleme mit Entwicklungsumgebung

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
224
Punkte für Reaktionen
4
Punkte
18
Hallo,

ich wollte jetzt auch einen Einstieg in das eigene Firmware-Brutzeln und v.a. in das Bauen von eigenen Moduln/Programmen für meine FBF wagen und habe mir dazu Enrik's Build-Umgebung heruntergeladen.
Dann auf meiner SuSE 9.2 ausgepackt und ein "make" durchgeführt.

Das läuft auch erst einmal eine ganze Weile und bricht dann (ich glaube beim bauen des gdb) irgendwann mit der Fehlermeldung ab, dass der "trap"-Befehl in falscher Syntax verwendet würde.

Ist das ein bekannter Fehler oder eine Unzulänglichkeit meiner SuSE-Distribution?
Und wie kann ich den umgehen (ich sehe ja noch nicht einmal genau, in welcher Zeile des configure-Scripts das ganze auftritt)?

Ich habe bis jetzt Enrik's Original-Umgebung verwendet.
Sollte ich die besser mit HaveANiceDay's patch aufpeppen?

Fragen über Fragen :?:
(und hoffentlich bald jede Menger hilfreicher Antworten :wink: )
 
Hallo Massa,

mein "Patch" bereinigt diesen Fehler. ( Habe auch SuSE 9.2 )
Das Problem kannst du auch von Hand lösen:
Falls ...gcc-3.3.3/configure über ein "trap" stolpert: alle "trap 0" durch "trap '' 0" ersetzen.
Bei meinem Template sind 2 Templates ( gcc 3.3.3 => Kernel compile, gcc 3.4. => "normale binaries" ) dabei.

Wer den Grund für den "trap" Fehler liefert ist mir nicht ganz klar. Vielleicht sind
neuere Tools strikter mit der Syntax.

Viele Grüße,

Haveaniceday.
 
Hallo haveaniceday,

Super :D
Wenn ich jetzt nachträglich Deinen Patch anwende, sollte ich dann besser ein "make clean" machen oder kann ich einfach nochmals "make" sagen und er macht weiter?

haveaniceday schrieb:
Bei meinem Template sind 2 Templates ( gcc 3.3.3 => Kernel compile, gcc 3.4. => "normale binaries" ) dabei.
In Deinem ReadMe steht ja drin, dass sich der "alte" Kernel nicht mit dem neueren gcc 3.4 verträgt.
Was heisst das genau? Lässt er sich nicht übersetzen oder gibt es Fehler mit dem übersetzten Kernel?
Lädt Deine geänderte Build-Umgebung dann beide gcc-Sourcen (und binutils-Versionen) und übersetzt diese?
Oder wie läuft das?
 
Hallo Massa,
mach bitte kein "make clean". Ich meine make clean setzt irgendetwas anderes noch zurück.

Ich würde folgendes vorschlagen:
- Enriks buildroot auspacken
- patch rein
- passendes .config aktivieren
- Verzeichnis "dl" erstellen und füllen. ( geht schneller als jedesmal Downloaden )
=> das ganze in 2 Verzeichnissen. Einmal für Kernel und Module, Einmal für binaries.

Unter "http://www.wehavemorefun.de/fritzbox/Main_Page" gibt es (ziemlich unten ) eine Mailingliste. Im Archiv davon stehen auch ein paar Hinweise.

Der GCC 3.4 mag den alten Kernel nicht.
gcc 3.4.? kann anscheinend nicht auflösen: => mtdblock.c:435: panic(__FUNCTION__""
Davon gibt es viele Stellen im Kernel.

Haveaniceday.

Wichtiges ! Edit :
- Die Buildumgebung von Enrik ist hervorragend !
- Habe nur:
- lufs + dropbear mit reingebracht
- Kernel und gcc 3.3.3 korrigiert. ( kann sein, das dieses ausserhalb SuSE 9.2 schon vorher ging )
- busybox mehr in die Richtung meiner gewünschten Änderungen gepatcht

Die Grundarbeit kommt von Enrik ! :rock:
 
Danke nochmals,

ich schau' mir das heute abend mal an (sofern ich Zeit habe :D )

Übrigens wollte ich mich für die Mailingliste vor ein paar Tagen auch anmelden.
Dann kam die Bestätigungsmail, die habe ich wie üblich einfach zurückgeschickt.
Tja, und dann kam eine Mail zurück:
Code:
Ihr Anliegen wurde mit der Bitte um Bestätigung an den Listenmoderator weitergeleitet
Seitdem hat sich nichts getan (und es kommen auch keine Nachrichten der Mailingliste zu mir rein).
Bei einem erneuten Anmeldeversuch kommt dann "Sie sind bereits Mitglied der Gruppe" - seltsam :?

Achja, mein Plan ist übrigens, lufs wieder rauszuschmeissen und stattdessen einen kleinen ftp-Server aufzunehmen :)
 
Manchmal ist der Mailserver von der Liste etwas langsam. ( nur der Mailliste, nicht der Moderator ;-) )

lufs hatte für mich einen Reiz, weil damit z.B. ein paar 100 MB Webspace
ruckzuck als Softwarearchiv für die Box greifbar sind.

Mal sehen ob das ganze mit der Christmas Edition ein bischen konfigurierbare wird..

Haveaniceday.
 
So, jetzt habe ich versucht, mit Deinem Patch etwas weiterzukommen.

"Etwas" komme ich auch weiter - aber nicht wirklich viel :(
Ich habe jetzt, so wie Du vorgeschlagen hast, zwei buildroot-Verzeichnisse aufgebaut eines fuer den Kernel und eines für die "Applikationen".

In beiden Umgebungen scheiterte der erste Versuch an den Snapshot Version (einmal busybox, einmal uclibc).
Als flugs die Konfiguration angepasst (busybox habe ich das release genommen, bei uclibc die Version vom 10.12.)
Das lief dann etwas weiter...
Bis dann in beiden Zweigen das mounten mit squashfs fehlschlägt, weil das Modul nicht im Kernel vorhanden ist.
Du hast das doch auch mit SuSE 9.2 gemacht, wie ging das bei Dir?
Ich habe kein installierbares Modul gefunden.
Muss ich jetzt erstmal noch einen neuen SuSE-Kernel übersetzen, damit das ganze funktioniert?

Und wo gebe ich eigentlich an, welche Fritz!Box ich habe?
Und was mache ich nach dem erfolgreichen Build in den beiden Zweigen?
Kommt bei dem einen nur der Kernel bei raus und beim anderen die Applikationen?
Oder muss ich mir das entsprechende zusammenkopieren?

Irgendwie blicke ich bei dem ganzen Build-System noch nicht richtig durch :oops:
 
Hi.
Enrik hat auf seiner Seite das Tool dumpsquashfs. Damit kann man auch ohne Kernelunterstützung ein squashfs-Image auspacken.

Die Optionen für die FritzBox stehen in der Datei buildroot/target/fritz/fritzroot.mk.
Dort müsstest du die Zeile "sudo mount -o loop ..." ersetzen, durch:
Code:
dumpsquashfs -C $(BUILD_DIR)/fboxmnt -x -f $(FBOXFW_DIR)/var/tmp/filesystem.image
Ist aber ungetestet, also keine Garantie ob's funktioniert. Mein Suse-Kernel hat squashfs-2.0-Support. :)

In der fritzroot.mk, Zeile 10-12, kannst du übrigens den Typ deiner FritzBox ändern...

Und wenn's make fertig ist kommt immer ein filesystem.image raus. Ist also kein komplettes Firmwareimage. Das kann man z.B. über ftp flashen (Achtung: ftpflash funktioniert aber bei meiner wlan nicht!!!)
Das zweite buildroot wird benötigt um Kernelmodule zu erstellen. Einen kompletten Kernel kann man mangels tffs-Support noch nicht erstellen, oder???
Also probier erst mal das buildroot für die Applikationen hinzubekommen. Solange du kein filesystem.image bauen kannst, brauchst du auch keine Kernelmodule. ;-)

MfG Oliver
 
haveaniceday schrieb:
Die Grundarbeit kommt von Enrik!

Da muss ich jetzt doch auch mal richtig stellen:

Die Grundarbeit kommt von den Entwicklern der uClibc und der busybox und sowieso der ganzen Linux und drumrum Community. Ich habe ja nur deren buildroot verwendet und etwas an die fbox angepasst.

Gruß,
Enrik
 
olistudent schrieb:
Das zweite buildroot wird benötigt um Kernelmodule zu erstellen. Einen kompletten Kernel kann man mangels tffs-Support noch nicht erstellen, oder???

Man hört, dass die Sourcen mit dem xmas-Release der Firmware zugänglich gemacht werden sollen.

@haveaniceday: Wenn du Zeit hast, bastel doch schonmal ein Skript, das in etwa folgendes macht:

- freien Platz in der Kernelpartition ermittlen (also 0xb0000 - Kernelgröße)
- mittels trial and error oder wie auch immer ein squashfs bauen, dass so viele Kernelmodule wie möglich enthält aber noch in diese Größe passt
- das squashfs an den Kernel hinten dran klatscht (aligned auf 256 byte)

Gruß,
Enrik
 
@Massa,
habe mein selbstkompiliertes Squashfsmodul mal hochgeladen.

@Enrik,
bin sowieso gerade an Skripten. Ich bereite schon mal vor...

Edit: @Enrik, arbeitet die Box/Der Bootloader eigentlich mit initrd ?

Viele Grüße,

Haveaniceday.
 

Anhänge

  • squashfs.suse.9.2.-2.6.8.24.5.tgz
    14 KB · Aufrufe: 4
haveaniceday schrieb:
arbeitet die Box/Der Bootloader eigentlich mit initrd?

Könnte sein, dass der Bootloader eine initrd unterstützt, die hinten am Kernel dranhängt. Weiss ich aber nicht genau, da das im Moment offensichtlich nicht verwendet wird.

Wäre aber sehr nützlich für einen über direkt über FTP gebooteten "Reparaturkernel" und ähnliches, gell?

Gruß,
Enrik
 
@haveaniceday:
Danke, ich werde mir das squashfs-Modul mal holen (wobei ich erstmal enrik's Tool ausprobieren werde :wink: )
Ich habe übrigens keine Option für das squashfs in den Kernel-Optionen (2.6.8) gefunden. Unter welchem Unterbaum liegt das?

@olistudent:
Ebenfalls Danke, das werde ich alles bei nächster Gelegenheit ausprobieren.

@alle:
soweit ich die recover-Funktion verstanden habe, ist da ja wohl ein ftp-Server auf der Box enthalten, der aber vor dem eigentlichen Booten wieder deaktiviert wird.
Kann man den nicht dauerhaft aktivieren?
Oder würde das nichts bringen, weil es nur auf die mtd-Devices kommt?
 
Massa schrieb:
Ich habe übrigens keine Option für das squashfs in den Kernel-Optionen (2.6.8) gefunden. Unter welchem Unterbaum liegt das?

Ist ein externes Paket: http://squashfs.sourceforge.net/

Massa schrieb:
soweit ich die recover-Funktion verstanden habe, ist da ja wohl ein ftp-Server auf der Box enthalten, der aber vor dem eigentlichen Booten wieder deaktiviert wird.
Kann man den nicht dauerhaft aktivieren?

Dieser "ftp"-Server ist erstens kein richtiger, sondern ein rudimentärer und zweitens ist er Teil des Bootloaders (Urladers), der nach dem Starten des Kernels gar nicht mehr laufen kann.

Gruß,
Enrik
 
So, der Build im Applikation-Verzeichnis ist jetzt erfolgreich durchgelaufen :) (mit dumpsquashfs und ein paar kleinere Aenderungen im frtzbox.mk - Mein Kernel mit squashfs-patch ist noch am compilieren :wink: )
Jetzt habe ich angefangen, ein neues Paket hinzuzufügen; folgendes habe ich bisher vorbereitet:
  • BR_PACKAGE_<NAME>-Option in .config hinzugefügt
    ein neues Verzeichnis package/<name> erzeugt
    das Verzeichnis in .config.cmd eingetragen
    eine Datei package/<name>/Config.in angelegt und editiert
    eine Datei package/<name>/<name>.mk erstellt

Jezt habe ich angefangen, package/<name>/<name>.mk zu editieren.
Als Ausgangsbasis habe ich mir das Makefile aus dem Verzeichnis lufs kopiert.
Ganz schön Arbeit, das richtig anzulegen :)

Was mir aber noch nicht so klar ist: ich muss ja jetzt irgendwie die passenden Konfigurationsoptionen für's configure-Script des Tools finden um sie ins Makefile einzutragen.
Aber wie kann ich die jetzt testen?
Irgendwie muss ich doch in die Build-Umgebung "reinkommen" und mit den übersetzten Tools (wie z.B. den gcc) arbeiten können.
Wenn ich aber z.B. einfach das bin-Verzeichnis aus der Build-Umgebung an den Anfang der PATH-Variablen setze, funktioniert das configure-Skript nicht mehr.
(er versucht direkt den C-Compiler dadurch zu testen, dass er ein Programm übersetzt und ausführt - was natürlich nicht funktioniert...)

Muss ich da jetzt das configure-Script patchen oder ist es die falsche Vorgehensweise?
Wie geht ihr vor, wenn ihr eine neue Applikation hinzufügt?
@olistudent: wie hast Du z.B. so schnell den vsftpd bei Dir hinzugefügt?

Gruß,
Matthias

P.S.: wenn ich Euch mit meinen Anfängerfragen nerve, sagt es bitte :oops: !
 
Hi, Matthias.
Jeder hat mal klein angefangen. ;-) (ich vor 2 Monaten)
Ich füge die Programme nicht in den buildroot ein.
Ich lade mir den Source runter und compiliere dann in einem anderen Verzeichnis.

Tips:
1.buildroot/build_mipsel/staging_dir/bin in Pfad aufnehmen
2. ./configure --host=mipsel-linux --build=i386
3. mit mipsel-linux-strip kann man die Dateien strippen
4. mit file kann man sich den Dateityp anschauen
5. mit ldd.host kann man sich die shared libs angucken (erst in Pfad aufnehmen)

Das configure funktioniert nicht immer. Cross-Compiling ist wohl nicht so populär. Nach einem geglückten configure kannst du das Makefile auch von Hand editieren.

MfG Oliver
 
Hallo Oliver,
olistudent schrieb:
Jeder hat mal klein angefangen. ;-) (ich vor 2 Monaten)
Na dann ist habe ich ja noch Hoffnung - meine Box ist erst seit ein paar Tagen in Betrieb und mit dem bauen der Umgebung befasse ich mich intensiv erst seit gestern :wink:

olistudent schrieb:
Ich füge die Programme nicht in den buildroot ein.
Ich lade mir den Source runter und compiliere dann in einem anderen Verzeichnis.
Das war auch mein Gedanke, um es erstmal einfacher zu machen - danach kann man das immer noch ins buildroot reinpfriemeln :)

olistudent schrieb:
Tips:
1.buildroot/build_mipsel/staging_dir/bin in Pfad aufnehmen
Das hatte ich bereits gemacht, hat aber zu einem Fehler geführt...

olistudent schrieb:
2. ./configure --host=mipsel-linux --build=i386
... das sieht mit diesen Optionen schon viel besser aus :)
(bisher hatte ich --build=mipsel )

Das configure des wu-ftpd läuft jetzt problemlos durch.
Allerdings hat er beim compilieren Probleme mit dem bison von SuSE - das liegt aber nicht an der Crosscompiler Build-Umgebung,
das kommt auch, wenn ich es native für SuSE übersetzen will :(

Hmm, muss mal das Source-Paket von SuSE raussuchen und was man da wieder patchen muss :twisted:

MfG,
Matthias
 
olistudent schrieb:
Was für ein Fehler kommt bei export=$path:/...???
Der kam wegen der falschen Optionen bei --host,
ist mit Deinen Optionen weg :lol:

olistudent schrieb:
Du bist der Beste!
Das war's - jetzt lässt er sich problemlos übersetzen.
Allerdings bekomme ich ihn (gestripped) trotz aller Tricks und ausblenden aller nicht benötigter Features nicht unter 200KB :(

Da warst Du mit dem vsftpd oder dem pure-ftpd erfolgreicher...
Wie gross darf das Image denn sein?
 
Die Partitionstabelle sieht so aus:
Code:
0x000c0000-0x003c0000 : "mtd0"
0x00010000-0x000c0000 : "mtd1"
0x00000000-0x00010000 : "mtd2"
0x003c0000-0x003e0000 : "mtd3"
0x003e0000-0x00400000 : "mtd4"

Du musst (in Hex) die 2 Zahlen voneinander abziehen, z.B. 3c0000-c0000=3072kb für mtd0.

MfG Oliver
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.