[Gelöst] Fritz!Box 4040 make error (freetz-devel 14964)

[WileC]

@er13

Weil trac auf freetz.org derzeit nicht geht (502 bad gateway), muss ichs leider hier schreiben: beim make einer 4040 wird der make mit einem Fehler abgebrochen.

4040_make.log

PATH="/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/bin:/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0/arm-unknown-linux-gnueabi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" \
    make -j2 MAKEINFO=true -C /home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial \
    all-gcc \
    all-target-libgcc
make[1]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial“ wird betreten
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libiberty“ wird betreten
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/intl“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/intl“ wird verlassen
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libiberty/testsuite“ wird betreten
make[3]: Für das Ziel „all“ ist nichts zu tun.
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libiberty/testsuite“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libiberty“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libiberty“ wird betreten
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libiberty/testsuite“ wird betreten
make[3]: Für das Ziel „all“ ist nichts zu tun.
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libiberty/testsuite“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libiberty“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/zlib“ wird betreten
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-D_GNU_SOURCE -fno-stack-protector" "CXXFLAGS=-D_GNU_SOURCE -fno-stack-protector" "CFLAGS_FOR_BUILD=-D_GNU_SOURCE -fno-stack-protector" "CFLAGS_FOR_TARGET=-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp -marm -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc " "LIBCFLAGS=-D_GNU_SOURCE -fno-stack-protector" "LIBCFLAGS_FOR_TARGET=-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp -marm -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" "MAKE=make" "MAKEINFO=true --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr" "infodir=/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/share/info" "libdir=/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/lib" "prefix=/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr" "tooldir=/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=ld" "LIBCFLAGS=-D_GNU_SOURCE -fno-stack-protector" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/zlib“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libbacktrace“ wird betreten
make  all-am
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libbacktrace“ wird betreten
true  DO=all multi-do # make
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libbacktrace“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libbacktrace“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libdecnumber“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libdecnumber“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/lto-plugin“ wird betreten
make  all-am
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/fixincludes“ wird betreten
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/lto-plugin“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/fixincludes“ wird verlassen
make[3]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/lto-plugin“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/lto-plugin“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libcpp“ wird betreten
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/libcpp“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/fixincludes“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/fixincludes“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libcpp“ wird betreten
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/build-i386-pc-linux-gnu/libcpp“ wird verlassen
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/gcc“ wird betreten
make[2]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/gcc“ wird verlassen
Checking multilib configuration for libgcc...
Configuring in arm-linux-uclibcgnueabi/libgcc
configure: loading cache ./config.cache
checking build system type... i386-pc-linux-gnu
checking host system type... arm-unknown-linux-uclibcgnueabi
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for arm-linux-uclibcgnueabi-ar... /home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/bin/ar
checking for arm-linux-uclibcgnueabi-lipo... arm-linux-uclibcgnueabi-lipo
checking for arm-linux-uclibcgnueabi-nm... /home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/./gcc/nm
checking for arm-linux-uclibcgnueabi-ranlib... /home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/bin/ranlib
checking for arm-linux-uclibcgnueabi-strip... /home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/bin/strip
checking whether ln -s works... yes
checking for arm-linux-uclibcgnueabi-gcc...  /home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/./gcc/xgcc -B/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/./gcc/ -B/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/bin/ -B/home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/lib/ -isystem /home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/include -isystem /home/freetz/freetz-trunk/toolchain/build/arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/arm-linux-uclibcgnueabi/usr/arm-linux-uclibcgnueabi/sys-include  
checking for suffix of object files... configure: error: in `/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/arm-linux-uclibcgnueabi/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:10904: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Verzeichnis „/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial“ wird verlassen
toolchain/make/target/gcc/gcc.mk:131: recipe for target '/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/.compiled' failed
make: *** [/home/freetz/freetz-trunk/source/toolchain-arm_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-4.4/gcc-5.5.0-initial/.compiled] Error 2

Grüße

 

[er13]

Und welchen Punkten aus der Error-Message bist du inzwischen gefolgt? Welche Erkenntnisse hast du dabei gewonnen?

Auf Basis der von dir zur Verfügung gestellten Informationen wird dir keiner helfen können. Alles, was man sagen kann, ist - folge dem, was in der Error-Message steht. Aber wenn du die Error-Message nicht mal liest (irgendeine andere sinnvolle Erklärung, warum ich jetzt sagen muss, folge doch dem, was da steht, fällt mir nicht ein), dann sei mir nicht böse, wenn ich mich für die weitere Entwicklung dieses Threads nicht interessiere.

 

[Shirocco88]

4040_make.log

See `config.log' for more details.

ich kann die Datei config.log im ZIP-File #1 nicht finden;
Bitte auch das Logfile config.log dem Thread beifügen, dann sieht man ggf. mehr.

weitere nützliche Inputs:
Betriebssystem des Build-Hosts: "uname -m" bzw. "cat /etc/os-release", "gcc -v"
ist das evtl. ein RasPI ?

 

[WileC]

Hoppla, mein Fehler, sorry,

es ist die Freetz-Buildumgebung mit ubuntu 18.04.01 und freetz-devel-14964

ich selbst werde aus dem "log" nicht wirklich schlau, nur eben, dass irgendwas nicht kompiliert werden konnte...

 

[PeterPawn]

@WileC:
Die "toolchain.in" braucht noch den passenden Eintrag von FREETZ_TARGET_CFLAGS für die ARM-Modelle, weil die "trap"-Option für den Assembler bei ARM nicht bekannt ist (ist eine MIPS-Spezialität). Entweder die x86-Zeile wird ergänzt/geändert oder Du fügst eine weitere für FREETZ_TARGET_ARCH_ARM hinzu, in der die Übergabe von "trap" an den Assembler nicht enthalten ist (die sieht dann so aus, wie die für x86).

Andererseits kann man kaum deutlicher machen, daß das noch lange nicht fertig ist, als es mit dem "WORK-IN-PROGRESS" zum Ausdruck gebracht wurde ... warum versucht man (als jemand, der sich offenbar nicht so sehr gut mit der Materie auskennt) eigentlich mit einer so unvollständigen Umsetzung sein Glück? Die sollte zwar (nach meiner Überzeugung jedenfalls) der "Öffentlichkeit" ohnehin noch nicht zugänglich sein - dafür gibt es schließlich Branches -, aber so richtig trägt so ein Thread wie dieser auch nicht dazu bei, daß es "vorwärts" geht, weil auch das hier natürlich Zeit kostet.

Da fehlen jedenfalls (mit Ansage) noch weite Teile der Umsetzung ... also würde ich an Deiner Stelle besser noch die Finger davon lassen, bis das wenigstens den Status "EXPERIMENTAL" erreicht hat.

 

[WileC]

@PeterPawn
weil ichs im trunk gesehen habe, dass es nun wählbar ist, ich mir gedacht habe - "probiers mal aus" - festgestellt habe, dass es nicht geht und es dementsprechent hier kund getan. Es sollte nicht mehr sein, als Problem erkannt, Problem gemeldet.

Aber wie sollen Problemstellen herausgefunden werden, wenn keiner einen Test durchlaufen lässt?


Wenns keinen interessiert, braucht auch keiner auf den Thread zu antworten.

 

[PeterPawn]

Es ist eben noch nicht mal im Ansatz fertig ... und selbst wenn keiner antwortet, wird es ja trotzdem gelesen (siehe #2).

Ich habe Dir ja auch aufgezeigt, wie Du den konkreten Fehler erst einmal umgehen könntest, wenn Du tatsächlich weitermachen willst ... aber der nächste wartet vermutlich ohnehin schon an der Ecke. Die Frage, ob man bei WIP tatsächlich "Fehler melden" sollte, wird sicherlich auch sehr unterschiedlich beurteilt - denn mehr als die Feststellung des Offensichtlichen ist das dann auch nicht. Wenn es funktionieren sollte, wäre es ja nicht mehr WIP.

 

[Shirocco88]

bis das wenigstens den Status "EXPERIMENTAL" erreicht hat.

Hinweis: aktueller Stand gemäß menuconfig: "4040 - EXPERIMENTAL (status: unknown)"
siehe: https://github.com/Freetz/freetz/commit/3073f2cdfafcf45b9eb0a749be851a1f742ea71d

 

[er13]

Die "toolchain.in" braucht noch den passenden Eintrag von FREETZ_TARGET_CFLAGS für die ARM-Modelle, weil die "trap"-Option für den Assembler bei ARM nicht bekannt ist (ist eine MIPS-Spezialität).

Den Teil mit "fehlen" habe ich verstanden (und werde gleich ergänzen), den Teil mit "trap" dagegen nicht. Wozu die Anmerkung, die trap-Option wird doch für ARM gar nicht verwendet (s. die von dir verlinkte Stelle)?

Edit: die trap-Option könnte dann in der .config landen, wenn man von MIPS auf ARM umstellt, dann wird der alte (der MIPS-) Wert beibehalten.

Andererseits kann man kaum deutlicher machen, daß das noch lange nicht fertig ist, als es mit dem "WORK-IN-PROGRESS" zum Ausdruck gebracht wurde ... Da fehlen jedenfalls (mit Ansage) noch weite Teile der Umsetzung ...

Es ist zwar work-in-progress, aber das work-in-progress bezieht sich nicht mehr auf die Toolchain, zumindest meiner Hoffnung nach:

• es werden die richtigen Compiler/Binutils/uClibc-Versionen verwendet
• es sind die relevanten ARM-related Patches enthalten
• es werden die richtigen --with-arch/--with-cpu/--with-fpu/--with-float-abi/etc. Optionen und deren Counterparts -march/-mcpu/etc. gesetzt
• es werden die Binaries erzeugt, die bei einem Abgleich mittels "readelf -a, section eabi" mit den Binaries aus der Original-Firmware keine Unterschiede aufweisen
• die uClibc-Symbole der Freetz-uClibc passen zu denen aus der Original-Firmware

Es sollte nicht mehr sein, als Problem erkannt, Problem gemeldet.

Ja, aber auf die Art und Weise, dass man damit rein gar nichts anfangen kann.

Es ist übrigens immer noch die falsche config.log. Es wird die aus dem Unterverzeichnis gcc-5.5.0-initial/arm-linux-uclibcgnueabi/libgcc benötigt.

Das Problem, dass die MIPS spezifische assembler Option "--trap" bei einer Umstellung im menuconfig von einer MIPS-Box auf die Box einer anderen Architektur, beibehalten wurde, wurde in r14965 behoben.

### Zusammenführung Doppelpost by stoney ###

Damit das Problem entsteht, musste man wirklich erst eine MIPS-Box im menuconfig wählen und dieses verlassen. Und dann das menuconfig erneut aufrufen und umstellen. Oder alternativ einfach mit der alten .config einer anderen Box starten (was aber im Grunde das gleiche wie das erste Szenario ist).

@WileC: bitte mit einem frischen Checkout und ohne irgendeine alte .config von einer anderen Box testen.

 

[WileC]

@er13
So, anbei meine aktuelle config.log aus dem von Dir angegebenen Verzeichnis. Ich dachte eigentlich, die "alte" config.log wäre auch aus diesem Verzeichnis gewesen, aber manchmal unterläuft ein Fehler.

Auch habe ich nach einem svn up meine aktuelle, gänzlich neu erstellte .config (hier config_4040) mit beigefügt. Ich hoffe, ihr könnt damit etwas anfangen...

 

[er13]

In der config.log steht:

arm-linux-uclibcgnueabi/bin/as: unrecognized option '--trap'

Damit hattest du vermutlich zunächst die .config für eine MIPS-Box gespeichert und erst anschließend auf eine ARM-Box umgestellt oder alternativ mit der alten .config für eine MIPS-Box deinen Test gestartet. In jedem Fall ist dieses Szenario seit r14965 nicht mehr möglich, was auch deine neue .config belegt.

Bitte mit einem frischen Checkout starten, ohne irgendeine alte .config und dann die Ergebnisse hier posten. Danke!

 

[WileC]

@er13 : mit komplett neuem Checkout wurde das Image erstellt, werde es nachher mal auf der Box testen. Aber ich finde im "menuconfig" nicht mehr die Option fürs "in-memory-image" ?! oder bin ich blind ?

Würde bei meinem eigentlichen freetz-trunk ein make distclean helfen um dort dann auch ein Image bauen zu können? oder sollte ich jeweils ein Checkout für ne MIPS-Box und eines dann für die ARM-Box haben ??

 

[PeterPawn]

Ich hatte schon vor einiger Zeit mal versucht, mir einen Überblick über die FREETZ-Symbole zu verschaffen ... ich hatte die Hoffnung, daß man mit wenigen Editor-Kommandos (sed) die spezifischen Einstellungen für die Box und die Toolchain aus so einer ".config"-Datei entfernen könne, damit man die ganze Geschichte mit der Paketauswahl nicht auch immer von vorne beginnen muß und diese (bei vielen hart erarbeiteten) Vorgaben dann für mehrere Modelle (auch mit unterschiedlicher Architektur - damit entsteht das Problem ja überhaupt erst so richtig, denn so lange Freetz nur MIPS unterstützte, hatte man ggf. noch Probleme beim Wechsel von MIPS nach MIPSEL (und umgekehrt), aber sonst nichts weiter) verwenden kann.

Das damalige Ergebnis habe ich vorhin noch etwas aufgehübscht (zwei Tests, damit's nicht gleich in die Hose geht beim falschen Aufruf) und an neue hinzugekommene Symbole angepaßt ... der derzeitige Stand ist im Branch "clearconfig" meines Freetz-Forks zu finden.

Wer seine eigene Paket-Zusammenstellung auf ein neues Modell übernehmen will, kann das Skript "clrconfig" als Filter für die ".config" benutzen ... es versucht, alle geräte- und modellspezifischen Einstellungen (inkl. der Toolchain) auf "is not set" zu setzen und gibt das Ergebnis wieder auf STDOUT aus. Das würde also in etwa so aussehen:

cp -a .config .config.saved
clrconfig < .config.saved > .config
make menuconfig
...

Den Unterschied (und damit die "gelöschten" Symbole) kann man sich auch vorher noch mit einem "diff .config.saved .config" ansehen (hier würde ich eher auf das "unified format" verzichten) und entscheiden, ob einem das Ergebnis zusagt oder nicht.

Auf alle Fälle werden auch beim Laden einer solchen ".config"-Datei dann wieder alle "nicht gesetzten" Einstellungen neu evaluiert und solche Geschichten wie mit den falschen Compiler-Flags kommen auch nicht mehr vor, weil die bei der Auswahl des passenden Modells (und damit der Architektur) definitiv neu gesetzt werden, da sie nicht aus der alten ".config" gelesen wurden. Ich habe mir dafür sogar noch ein "make target" (namens "clrconfig") eingebaut ... damit kopiere ich schon seit einiger Zeit die Konfigurationen zwischen verschiedenen Modellen.

Das ist zwar keine 100%-Lösung, weil auch mal eine von Hand vorgenommene Einstellung verschwinden könnte (z.B. bei mir immer in FREETZ_TARGET_CFLAGS das Ersetzen von "-Os" durch "-Ofast", wenn ich dran denke), aber es erspart einem doch viel Arbeit bei der Zusammenstellung seiner Paketauswahl ... bei mir ist es meist schon die BusyBox und deren Applets, an denen ich (bei einer "frischen" Konfiguration) fast 30 Minuten herumdoktern würde, damit da die BusyBox für das "yf_bin"-Repo und/oder "modfs" bei herauskommt.

 

[WileC]

Also das ".image" mag nicht auf die Box... weder per AVM-WebIf, noch per @PeterPawn Eva-Tools...

 

[er13]

@WileC: ich weiß nicht, ob die Terminologie NOR-/NAND-Box auf die ARM-Boxen vollumfänglich extrapoliert werden kann, aber ...

7530 scheint einer NAND-Box ähnlich zu sein: d.h. getrennte Partitionen für kernel.image und filesystem.image in jeweils doppelter Ausführung mit der Umschaltmöglichkeit mittels linux_fs_start. /etc/init.d/E03-flash_update ist vorhanden und unterscheidet sich nicht bzw. fast nicht von der einer NAND-Box. Der einzige Unterschied ist der hinzugekommene Aufruf von /etc/init.d/S45-openwrt (womit auch immer AVM da in Zusammenhang mit openwrt experimentiert). Von daher gehe ich bei der 7530 davon aus, dass diese mittels eva_to_memory und eines in-memory-Images wie eine NAND-Box geflasht werden kann (von daher steht die Option "Create in-memory image" für die 7530 auch zur Verfügung). Es sei jedoch angemerkt, dass es sich hierbei lediglich um eine Annahme handelt, die mittels eines Mitschnitts des Recovery-Vorgangs noch belegt werden muss. Es gibt allerdings einiges, was dafür spricht.

4040 scheint hingegen eher wie eine NOR-Box zu sein: kernel.image+filesystem.image befinden sich in der selben Partition. linux_fs_start wird zwar in /var/install einmal referenziert, aber es wird lediglich ausgelesen, danach passiert mit linux_fs_start nichts. /etc/init.d/E03-flash_update ist nicht vorhanden. Es spricht also einiges dafür, dass 4040 wie eine NOR-Box zu flashen ist. Ob mtd1 die richtige Partition ist, kann ich nicht sagen, der entsprechende Abschnitt aus /var/install sieht jedenfalls so wie unten aus. Man beachte, "running from ram-mtd", was auch immer AVM da sagen möchte. Es muss also noch verstanden werden, was für eine Art Box die 4040 ist. Ein Mitschnitt des Recovery-Vorgangs würde hierbei sehr helfen.

##################################################################################
# setting files to install (non-mirror, spi-nor, active system running from ram-mtd)
##################################################################################
echo install: ${kversion} getting mtds to install...
echo install: --mtd------------------------------------------------
var_kernel_mtdnr=`cat /proc/mtd  | grep '^mtd.*"rootfs_kernel_spi"' | sed 's/:.*//' | sed 's/^mtd//'`
var_non_res_fs_mtdnr=`cat /proc/mtd  | grep '^mtd.*"rootfs_ram"' | sed 's/:.*//' | sed 's/^mtd//'`
# get linux_fs_start
eval `cat $CONFIG_ENVIRONMENT_PATH/environment | grep "^linux_fs_start"  | tr '\t' '='`
# check
if test -z "$var_kernel_mtdnr" ; then
    echo "Install: Error: rootfs+Kernel mtdblock (rootfs_kernel_spi) not found. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_KERNEL_CHECKSUM
elif test -z "$var_non_res_fs_mtdnr" ; then
    echo "Install: Error: ram-filesystem mtdblock (rootfs_ram) not found. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_FILESYSTEM_CHECKSUM
fi
echo install: --assert---------------------------------------------
if ! test -f "/var/tmp/kernel.image" ; then
    echo "Install: Error: File 'kernel.image' doesn't exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_KERNEL_CHECKSUM
fi
if ! test -x "/sbin/update_image" ; then
    echo "install: missing Flash Update Tool (/sbin/update_image) - abort Update.";
    exit $INSTALL_OTHER_ERROR
fi
echo install: --addr+size------------------------------------------
    kernel_image_size="`ls -l /var/tmp/kernel.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
    echo install: kernel_start=${kernel_start}
    echo install: kernel_size=${kernel_size}
    echo install: kernel_image_size=${kernel_image_size}
    if [ -z "${kernel_image_size}" ] || [ "${kernel_image_size}" = "0" ]  ; then
        echo "install: Kernel Adress or Size error - Abort!"
        /bin/update_led_off; echo "set INFO led to off"
        exit $INSTALL_KERNEL_CHECKSUM
    fi
###########################################
need_reboot=$INSTALL_SUCCESS_REBOOT
###########################################
echo install: ${kversion} writing commands to install...
#### DEBUG-EXIT ####
# echo "#### DEBUG-EXIT ####" >>/var/post_install
# echo "exit 0" >>/var/post_install
# echo "####################" >>/var/post_install
####################
# ---
# flash mtds
echo "echo flash mtd partition '$var_kernel_mtdnr' ..." >>/var/post_install
if [ -x "/sbin/update_image" ] && [ -e "/dev/mtd$var_kernel_mtdnr" ] ; then
    echo "date" >>/var/post_install
    echo "/sbin/update_image -i /var/tmp/kernel.image -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
    echo '[ $? -ne 0 ] && echo ... failed with error "$?"' >> /var/post_install
    echo "date" >>/var/post_install
    if [ -x /var/tzupdate ] ; then
        echo "install: /var/tzupdate..."
        echo "echo calling /var/tzupdate" >> /var/post_install
        echo "/var/tzupdate" >> /var/post_install
    fi
    # letzte chance zum loeschen der C+P Logs
    echo "echo clear_id 95 >/proc/tffs" >>/var/post_install
    echo "echo clear_id 96 >/proc/tffs" >>/var/post_install
    ##################################################################################
else
    echo "install: missing Flash Update Tool or destination to flash to - abort Update.";
    exit $INSTALL_OTHER_ERROR
fi
# due to append sequence add exit to prevent accidently second run.
echo "exit 0" >>/var/post_install
chmod +x /var/post_install

 

[Shirocco88]

Aber ich finde im "menuconfig" nicht mehr die Option fürs "in-memory-image" ?! oder bin ich blind ?

ist "FREETZ_FWMOD_CREATE_IN_MEMORY_IMAGE" in .config Datei gesetzt ?

Hinweis: damit man mit Freetz ein In-Memory-Image erhält, sollte man die entsprechende Option mittels "make menuconfig" setzen.
Kontrolle:

grep FREETZ_FWMOD_CREATE_IN_MEMORY_IMAGE .config

seit Freetz CS 14966 sollte es eigentlich IMHO möglich sein;
siehe 'Unhide "Create in-memory image file"-option for ARM boxes'
https://github.com/Freetz/freetz/commit/39dea1349d5625060b82c1804bc1328c2c8f4cd7

 

[er13]

@Shirocco88: bei dem von dir verlinkten Changeset steht doch noch was in Klammern, oder?

Für 4040 steht die Option NICHT zur Verfügung, für 7530 dagegen schon und das ist richtig so.

 

[WileC]

@er13
Hilft vielleicht die Installationsanweisung von OpenWrt weiter?

https://openwrt.org/toh/avm/avm_fritz_box_4040

Ps: ich mag openwrt nicht.

 

[PeterPawn]

Wer ein wenig "zaubert" bei der Zusammenstellung seines Netzwerks (man braucht u.a. einen "UDP responder", der die passenden Discovery-Antworten erzeugt - aber das macht jedes "socat", wenn man will und man muß ja gar nicht dynamisch auf die Anfragen reagieren, wenn man einfach weiß, was zu senden ist), der kann auch mittels "nc" im "listen mode" einem Recovery-Programm von AVM etwas genauer auf den Zahn fühlen, ohne die entsprechende Box zu besitzen. Allerdings ist das dann tatsächllich "hardcore" und ein Packet-Dump deutlich einfacher, wenn man das Gerät besitzt.

Dafür hat man dann einigermaßen Zeit, um sich die Antworten zu überlegen, die man jetzt eintippen müßte (Korrekturen sind i.d.R. nicht möglich) bzw. um mit einer weiteren "nc"-Instanz bei "STOR" oder "RETR" dann die Daten vom Recovery-Programm zu "empfangen" bzw. zu senden.

Wobei man sich bei der 4040 ja schon wieder fast sicher sein kann (auch ohne Mitschnitt und Untersuchung des Recovery-Programms), wenn man die OpenWRT-Seite ansieht ... wenn dort davon die Rede ist, daß die originale Firmware (bzw. die "kernel.image" daraus) nach MTD1 geschrieben werden soll, dann ist das wohl dieselbe Prozedur wie bei jeder anderen NOR-Box.

 

[er13]

wenn man die OpenWRT-Seite ansieht ... wenn dort davon die Rede ist, daß die originale Firmware (bzw. die "kernel.image" daraus) nach MTD1 geschrieben werden soll, dann ist das wohl dieselbe Prozedur wie bei jeder anderen NOR-Box.

Sehe ich genauso.

@WileC:
Du kannst es also entweder zu Fuß oder mit dem beliebigen Tool deiner Wahl versuchen, z.B.

.\EVA-Discover.ps1 -maxWait 120 -Verbose -Debug
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\4040\var\tmp\kernel.image mtd1 }
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { RebootTheDevice }