Freetz für AVM DVB-C Repeater verfügbar?

H
Laut Übersicht sollte da was gehen:
Code:
Fritz!WLAN Repeater DVB-C 

- 133.06.32 rev31507 {ALL}
- 133.06.50 rev33858 {ALL}
- 133.07.01 rev63069 {ALL}
- 133.07.08 rev66669 {ALL} [MESH18] (Inhaus)
- Alien 1750E {GER} (No dvbc!)
Hallo Zusammen

Edit: beziehe mich auf den Alien 1750E!
Ich muss hier meinen Senf dazugeben: Das Alien Image (zumindest in 7.20) kann man bauen und erfolgreich flashen. Der DVB-C geht (mit 7.20) in Betrieb, aber nicht nur ohne DVB-C (was ja klar war), auch ohne WLAN.
Ich hab irgendwo gelesen, die GPIOs wären anders gepinnt - dürfte wohl so sein.

Schöne Grüße!
 
Zuletzt bearbeitet von einem Moderator:
Problem ist auch unter https://github.com/Freetz-NG/freetz-ng/issues/15 beschrieben, aber leider keine Lösung.

Was mich ein wenig irritiert, dort wurde zwar empfohlen sich mal die Quelltextpakete näher anzuschauen aber die HW-Beschreibungsdateien scheint man wohl leider ausgelassen zu haben beim Vergleich (die müssen sich in den Paketen auch nicht unterscheiden denn die sind in den Quelltextpaketen i.d.R. für mehrere HW-Versionen vorh.):

./linux/arch/mips/boot/dts/Fritz_Box_HW205.dtsi = DVB-C​
./linux/arch/mips/boot/dts/Fritz_Box_HW206.dtsi = 1750E​

Somit fällt das beim Vergleichen beider Quelltextpakete als Gesamtes auch nicht auf, da diese in beiden Paketen jeweils identisch vorhanden sind. Und was jetzt für mich tatsächlich neu war, es gibt da mehr Unterschiede als ich jetzt erwartet hätte, u.a. bzgl. Nutzung der GPIOs. Zum Beispiel "gpio_avm_peregrine_reset" mit 109 vs 17 oder "gpio_avm_pcie_reset" mit 110 vs 18.

Aber glücklicherweise scheinen im Kernel-Quelltext für FRITZ!OS 7.20 auch noch die Beschreibungsdateien für die HW-Vers. 205 (also den DVB-C Repeater) vorhanden zu sein (ich habe sie mir aber dort nicht näher angesehen). Also bräuchte man evtl. "nur" den Kernel noch kompilieren für HW205 (aka "Replace Kernel" bei freetz, muss dann aber natürlich für HW205 kompiliert werden und nicht für HW206).
 
Den Symbolen nach arbeitet auch der Kernel für die Repeater aber mit "avm_kernel_config" - wofür AVM ja keine Quellen (und auch keinen Generator für solche Dateien) dazu packt.

Wer also den Kernel ändern möchte, sollte/muß das über Freetz (oder auch -NG) machen (lassen), wo der Rest (zusätzlich zum reinen Kompilat des "dtc") dann auch noch richtig generiert/gelinkt wird.

Rein nach dem Alter der Hardware zu urteilen, würde ich bei diesen Geräten eher nicht damit rechnen, daß EVA da einen "förmlichen FDT" an den Kernel übergibt, wenn sie ihn startet - damit MUSS dann die Hardware-Beschreibung im Kernel passen, spätestens die für HWSubRevision 0.

Wer das wirklich zu Fuß bzw. von Hand machen möchte (mit eigener Toolchain), der muß sich ein Äquivalent zu "avm_kernel_config" zulegen (meine erste Version und die spätere Adaption in Freetz/-NG unterscheiden sich gewaltig) und das entsprechend in den "make"-Prozess einbauen. Auf eine "Automatik" (à la "make kernel" und gut ist's) kann man sich dabei definitiv nicht verlassen.

Die gute Nachricht daran ist es dann aber, daß man sich um die Frage "HWRevision=205" oder "HWRevision=206" nicht wirklich sorgen muß - beim Generieren wird ohnehin der Inhalt des Kernels verwendet (afaik auch für den FDT-Blob) und das wäre hier dann vermutlich wieder der 1750E-Kernel ... denn dessen Firmware dient ja (soweit ich das verstanden habe) als Vorlage (und damit natürlich auch dessen Kernel).

Das führt uns dann aber wieder zu der schlechten Nachricht ... eben wegen dieses Mechanismus (wenn ich ihn richtig im Kopf habe - es spricht also nichts dagegen, meine Behauptungen erst mal zu prüfen, denn ich könnte mich irren) wird das mit dem derzeitigen Stand in Freetz (egal welcher Fork) auch nichts werden.

====================================================================

Soviel zu meinem Versuch, jemanden von (vermutlich zum Scheitern verurteilten) Versuchen abzuhalten ... ich hätte aber noch einen Vorschlag, wie man das dennoch umsetzen könnte.

Das ursprüngliche "avm_kernel_config"-Zeugs (und m.W. hat sich das mit den Änderungen in Freetz nicht gewandelt) sucht ja den gesamten Bereich zwischen "avm_kernel_config_start" und "avm_kernel_config_end" nicht anhand der Symbole des vorliegenden Kernels (das war mir zu aufwendig, weil diese Symboltabellen (die Namen) noch gepackt sind), sondern es lokalisiert die Signatur des FDT im vorliegenden Kernel und extrahiert dann die Daten von der vorhergehenden 4K-Grenze an.

Wenn man sich jetzt jeweils das Kompilat des "dtc" für HWRevision 205 und HWRevision 206 ansieht und die beiden miteinander vergleicht, sollte man schon alle Unterschiede in der Hardware-Beschreibung haben und - solange die Länge der Beschreibung für den 1750E nicht kleiner ist, als der für den DVB-C-Repeater benötigte Platz (als Blob) - diese muß man jetzt nur noch als (binären) Patch auf die Hardware-Beschreibung im entpackten Kernel (die passende Verschiebung kann man ja ermitteln) anwenden bzw. wenn die Längen identisch sind, kann man das gesamte Blob auch per "dd" o.ä. austauschen lassen.

Anschließend kann man einfach den Kernel wieder packen lassen, so wie das bei einem selbsterstellten Kernel auch der Fall wäre.

Mein eigener Lösungsweg (wenn ich vor der Aufgabenstellung stünde) wäre hier also das gezielte Ändern des vorhandenen FDT im vorhandenen Kernel ... und nicht der Versuch, einen eigenen Kernel zu erstellen (außer man hat tatsächlich die eigene Toolchain oder paßt sich Freetz (oder einen Fork) entsprechend an).
 
Zuletzt bearbeitet:
  • Like
Reaktionen: double-gee und NDiIPP
@PeterPawn danke für den Tipp. Das Einspielen des Kernels des DVB-C in das 1750e-Alien-Image würde ich gerne ausprobieren, das beschrieben Vorgehen übersteigt aber meine Kenntnisse von freetz. Kann man nicht einfach im Image die komprimierte Kernel-Datei irgendwie austauschen statt rumzupatchen?
 
Kann man nicht einfach im Image die komprimierte Kernel-Datei irgendwie austauschen statt rumzupatchen?
Wogegen denn tauschen? Kernel und Dateisystem sollten halt zusammenpassen (und dieselbe FRITZ!OS-Version repräsentieren) - und wenn das Dateisystem vom 1750E kommt und für die Version 07.21 gedacht ist, sollte das auch für den Kernel gelten. Nun gibt es den Kernel einer Version 07.21 aber eben nicht für den DVB-C-Repeater ... sonst müßte man das gesamte Thema ja nicht erneut ventilieren.

Will man den 07.21-Kernel für den 1750E nehmen (zusammen mit dem passenden Dateisystem), muß man ihn halt so verändern, daß er auf dem DVB-C-Repeater auch läuft - aus meiner Sicht wird das nur dann etwas, wenn man den bereits erwähnten "avm_kernel_config"-Bereich entsprechend ändert. Den hat sich AVM ja offensichtlich genau aus dem Grund "einfallen" lassen (das ist ja kein Feature des Vanilla-Kernels), daß man denselben Stand der Kernel-"Objektdateien" auch mit mehr als einer Hardware verwenden kann - dazu muß der halt mit Informationen versorgt werden, wie die Hardware des designierten Systems aussieht (wenn es da Unterschiede gibt und das ist hier ja wohl auch der Fall).
 
HI All,

Sorry for writing in English but I have the same issue with 7.27 firmware I built for dvb-c. I already commented in https://github.com/Freetz-NG/freetz-ng/issues/15 but maybe you have some more advices:

"I updated the alien patch with both recommendations from this thread. Please find it and support logs attached. I don't see now errors in logs that wifi can't be initialized but it still doesn't work. It looks like it is active for the short time after restart and then down again. Anything more we could do to test further?"
 

Anhänge

  • FRITZ.WLAN_Repeater_DVB-C_133.07.27-freetz-ng-18484M-4ae9ecb5e_2021-08-06_1734_support.tgz.zip
    21.4 KB · Aufrufe: 2
  • meshsupport FRITZ.WLAN Repeater DVB-C 133.07.27_06.08.21_1744.txt.zip
    4.5 KB · Aufrufe: 2
  • support FRITZ.WLAN Repeater DVB-C 133.07.27_06.08.21_1743.txt.zip
    59.8 KB · Aufrufe: 1
  • alien.patch.txt
    4.6 KB · Aufrufe: 4
I updated the alien patch with both recommendations from this thread.
Unfortunately the Alien Patch does not consider the different assignment of the GPIO Pins. Therefore no WLAN.
 
I built the kernel out of 1750E sources with applied dtsi patch.
According to the supplied source code files, the 1750E works with an avm_kernel_config area, too. As a result, it's not enough to patch any DTS source files somewhere - you've to make sure, that the resulting object files are linked at the right place or the correct binary data of the generated "flattened device tree" (FDT) is included into AVM's configuration area.

Usually the existing avm_kernel_config area is extracted from AVM's original kernel and some assembler source files are generated from it - see https://github.com/PeterPawn/YourFritz/tree/main/avm_kernel_config or the adapted Freetz implementation of the former project: https://github.com/Freetz/freetz/tree/master/tools/make/yourfritz-akc-host ... afaik the Freetz-NG fork uses a 1:1 copy of the Freetz part.

The generated assembler sources are translated to binary data later and THOSE object files are linked together to create a duplicate of AVM's configuration area (with the correct FDT), that may be included while linking the kernel (file arch/mips/kernel/vmlinux.lds.S, line 104).

What does this mean finally? You're required to create your own assembly source file (as the option with least efforts) as a "binary large object" (BLOB) from the binary version of the FDT for a DVB-C repeater device. One option could be to patch the DTS sources, compile them and create (at your own) a proper assembler file containing their/its output.

Another (imho much better/simpler) option is it, to generate the assembler file for the FDT from an older kernel for the DVB-C repeater - the content of these files doesn't change. Then you may copy this file over the generated one for the 1750E kernel and it will be used while linking your own kernel.

But that's even the version, where you really need to replace the kernel with your own version - compiled from scratch and linked yourself. Another option (nothing for someone with lack of courage, but with a result that's much closer to the original kernel) is it, to unpack the 1750E kernel, patch the contained FDT area from AVM's kernel configuration (it doesn't contain any absolute addresses, iirc) and (re-)pack the kernel.

Neither of these options is (yet) possible with an unmodified Freetz-NG project - you have to apply your changes at the right points yourself. First you have to get the assembler source for the FDT of a DVB-C device from a build-run with the last (officially supported) FRITZ!OS version for this device - save this file somewhere, so you can copy it over the generated version for the 1750E later ... but the point, where it's time to overwrite this file, is embedded deeply into the Freetz-NG build-run and you have to patch the make control files at the proper point.

Here starts the part with avm_kernel_config related targets: https://github.com/Freetz/freetz/bl...4cd37707c6e929ca0ec/make/linux/kernel.mk#L143 and you have to replace the generated file AFTER the bin2asm call - the file to replace is generated in-between.



And by the way - my recommendations, how this problem could be solved, were written down already in #24 and #26 and I can't see any circumstances, which have been changed meanwhile. As far as no new facts are discovered, this will be my last post regarding this theme. I wrote it only for anyone, who can't understand the aforementioned posts in German.
 
Another (imho much better/simpler) option is it, to generate the assembler file for the FDT from an older kernel for the DVB-C repeater - the content of these files doesn't change. Then you may copy this file over the generated one for the 1750E kernel and it will be used while linking your own kernel.

Indeed I can't communicate in German unfortunately and using google translate bring more questions when translating your # 24 post. Also I am not strong in programming and kernel structure understanding so this avm_kernel_config thingy is still not clear for me. If avm_kernel_config is not part of sources does that mean even 1750E device when built from 1750E sources will not be working?

Afaiu the easiest to do is the above.

So I have the original DVB-C 7.01 release image and 7.08 inhaus image. And I need to use your tools https://github.com/PeterPawn/YourFritz/tree/main/avm_kernel_config to extract the original kernel and disassemble some FDT file and then replace this file inside the 1750E 7.27 sources and built the image out of those 1750E sources? Which exact file name it should be? Sorry for dumb questions.
 
Run a complete Freetz-NG build with an older version of AVM's firmware first.

After this run you will find the generated source code file somewhere in the file structure of your build (at the build-host, not in the generated image). This file should be named avm_kernel_config_area.$(DL_SOURCE_ID).S according to this line: https://github.com/Freetz-NG/freetz...c60fffac6eba11c65ad/make/linux/kernel.mk#L157

I don't know, which value of $DL_SOURCE_ID will be replaced within the name - and I'll not search or analyze the variables to find it out myself.

But you don't have to know the complete name to locate the file ... you may simply use a (recursive) wildcard search, because there're usually no other files matching this pattern.

If you think, you've located the file, copy it to a safe place and show its content here at the board. This is the first step and it's useless to describe things further, if this one isn't made successfully first.

EDIT: To answer your first question:
If avm_kernel_config is not part of sources does that mean even 1750E device when built from 1750E sources will not be working?
Yes, that's true. These parts are missing from the archive provided by AVM - that's simply the reason, too, why I wrote this utility in the past. Without this (or an adequate replacement) it's impossible to create an own (working!) kernel - or much more code from vanilla kernel, that was changed by AVM, has to be patched.
 
Zuletzt bearbeitet:
I don't know, which value of $DL_SOURCE_ID will be replaced within the name - and I'll not search or analyze the variables to find it out myself.
Code:
freetz@freetz:~/freetz-ng$ grep -r DL_SOURCE_ID ./
./make/Makefile.image.in:export DL_SOURCE_ID=$(shell echo $(DL_SOURCE_LOCAL) | tools/imagename2id)
./make/linux/kernel.mk:$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).bin: $(DL_FW_DIR)/$(DL_SOURCE_LOCAL) | $(KERNEL_DIR)/.unpacked $(AVM_KERNEL_CONFIG_DIR) tools
./make/linux/kernel.mk:$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).S: $(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).bin | $(KERNEL_DIR)/.unpacked $(AVM_KERNEL_CONFIG_DIR) tools
./make/linux/kernel.mk:# Force kernel rebuild if avm_kernel_config_area.S differs from avm_kernel_config_area.$(DL_SOURCE_ID).S
./make/linux/kernel.mk:$(shell diff -q "$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.S" "$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).S" >/dev/null 2>&1 || $(RM) "$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.S" >/dev/null 2>&1)
./make/linux/kernel.mk:$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.S: $(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).S
freetz@freetz:~/freetz-ng$ grep -r DL_SOURCE_LOCAL ./
./make/Makefile.image.in:export DL_SOURCE_ID=$(shell echo $(DL_SOURCE_LOCAL) | tools/imagename2id)
./make/linux/kernel.mk:$(AVM_KERNEL_CONFIG_DIR)/avm_kernel_config_area.$(DL_SOURCE_ID).bin: $(DL_FW_DIR)/$(DL_SOURCE_LOCAL) | $(KERNEL_DIR)/.unpacked $(AVM_KERNEL_CONFIG_DIR) tools
Not sure what DL_SOURCE_LOCAL points to, but I will search for the final file as you advised.

PS: The build is running for the DVB-C 7.0X inside the freetz-ng.

Yes, that's true. These parts are missing from the archive provided by AVM - that's simply the reason, too, why I wrote this utility in the past. Without this (or an adequate replacement) it's impossible to create an own (working!) kernel - or much more code from vanilla kernel, that was changed by AVM, has to be patched.
Really weird. I would assume if freetz-ng exists for quite some time it should already know about this thingy and provide some solution to it. Ex. I've built the Wireguard module with kernel replacement for my 7490 w/o any issues on freetz-ng. Or inside the freetz-ng the issues appear only when building the firmware for different device? In this case avm_kernel_config is not propagated from the original firmware?

But you don't have to know the complete name to locate the file ... you may simply use a (recursive) wildcard search, because there're usually no other files matching this pattern.
Hmm. I could find it in the 7490 dir only which seems to be incorrect as I built the DVB-C image 7.0X (7490 I've built earlier):

Code:
freetz@freetz:~/freetz-ng$ find ./ -name "avm_kernel_config_area*"
./source/kernel/ref-vr9-7490_07.27/linux-3.10/arch/mips/kernel/avm_kernel_config_area.S
./source/kernel/ref-vr9-7490_07.27/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.27.S
./source/kernel/ref-vr9-7490_07.27/linux-3.10/arch/mips/kernel/avm_kernel_config_area.fritz.box_7490-07.27.bin
./source/kernel/ref-vr9-7490_07.27/linux-3.10/arch/mips/kernel/avm_kernel_config_area.o

Ok, I've made the "make distclean" which cleared sources dir but left downloaded packages. The new build is running, lets see...

Code:
freetz@freetz:~/freetz-ng$ fmake
Command 'fmake' not found, but there are 16 similar ones.
freetz@freetz:~/freetz-ng$ which fmake

root@freetz:~# apt install fmake
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
E: Paket fmake kann nicht gefunden werden.

@All,

Anyone can help in finding original image and sources for 1750E 7.01?
 
The text below was written while your last posts weren't available yet.



If you know what you're doing ... the second step is it, to repeat this procedure with the current 1750E kernel (the one, you want to use for your alien image) and to save the same file from this build-run, too (and once again show it here).

Afterwards the content of both files should be "diff"ed - only the lines for the BLOB data are of interest. The content of the two BLOBs (the assembler code is only a byte-wise array containing the binary data) should be always the same, no matter which version of FRITZ!OS is used as template - but only for the two used devices. Due to this assumption it should be possible to create a diff output file, which may be used to apply the needed changes for the DVB-C FDT to the 1750E file, after the latter one was created by the [...].bin2asm tool.

After the needed change to kernel.mk (to apply the patch after [...].bin2asm), you should remove all files matching the template avm_kernel_config_area* to
enforce their rebuild. The next make call (with 1750E settings) should create your own kernel, with a properly changed avm_kernel_config area.



I would assume if freetz-ng exists for quite some time it should already know about this thingy and provide some solution to it.
I don't understand this sentence.

I wrote this tool in the past to SOLVE exactly this problem and it was (partially as code and in a whole as idea) incorporated into Freetz - and as a result into Freetz-NG, too. Are you really astonished, that your use case of 1750E as an "alien" for a DVB-C device isn't fully supported from scratch by Freetz-NG?

If you've used a "standard configuration" for your 7490 with Freetz-NG, the same tool was used to extract the avm_kernel_config area from the original kernel - logically. But there's no source code BY AVM for these parts and other toolchains beside Freetz and its forks will not be able to build a working kernel without a solution for this problem.



And on again to the problem from #35 ... the found names look like results from a very different setting - usually from a 7490 build. Are you sure, you're looking in the right place? Had you a look at file times? Possibly the correct file is the one without any $DL_SOURCE_ID part - I had a reason for my wish/request to show the content here in the board (as attachment or within a CODE block).

If there's really no other file matching the pattern and the file without DL_SOURCE_ID isn't the needed one, you have to repeat the build process and to create a log file for it (using the provided fmake script in the base folder of your Freetz-NG checkout - this script is able to show you a help screen, how to use it correctly), which you may attach here. It's rather long, but it's needed completely to analyze, whether the build steps were run and where the results are located.



---------- assembled posts ----------

If you've started a new build, you should consider to stop it, clear the intermediate results and restart it once again - but this time already using fmake to save the build log.
 
Zuletzt bearbeitet:
Ok, there are indeed no files with names pattern like below (I've made distclean so the only kernel sources were used are ref-qca955x-1750_07.01):

freetz@freetz:~/freetz-ng$ find ./ -name "avm_kernel_config_area*"
freetz@freetz:~/freetz-ng$

Ok, I will run it one more time with fmake.
 
Possibly the "Replace kernel" option was never used/tested with 1750E and DVB-C models and it wouldn't really work.

If the steps for a build of avm_kernel_config are not executed, the first idea would wrong settings for these two variables: https://github.com/Freetz-NG/freetz...c60fffac6eba11c65ad/make/linux/kernel.mk#L147, where finally the whole targets inside the ifeq/ifneq conditions aren't included to make rules.



As I wrote, the fmake script may be found in the base directory of your Freetz-NG checkout.



And what do you want to do with the 7.01 sources for a 1750E device? You don't need them. If the "Replace kernel" implementation for 1750E and DVB-C are wrong, this may get corrected using the sources for the latest available FRITZ!OS versions for both models.
 
Ok, I've built the 7.0x firmware for DVB-C inside the freetz-ng and it worked! W/o avm_kernel_config. Maybe older Freetz!Wlan don't use avm_kernel_config?

As I wrote, the fmake script may be found in the base directory of your Freetz-NG checkout.
Thx, I've clean and distclean and running fmake now for the original DVB-C 7.0X.

I've enabled ssh access and tried to use your https://raw.githubusercontent.com/PeterPawn/YourFritz/main/avm_kernel_config/dump_kernel_config.sh:


Code:
root@fritz:/var/mod/root# sh -x /var/1.sh > /var/1.s
+ prefix=__avm_kernel_config_
+ symbols='end start'
+ source=/proc/kallsyms
+ memory=/dev/mem
+ align=4096
+ '[' -t 1 ]
+ unset end
+ loc=end
+ unset start
+ loc='end\|start'
+ sed -n -e 's|^\([0-9A-Fa-f]\{8\}\) . __avm_kernel_config_\(\(end\|start\)\)|\2=0x\1|p' /proc/kallsyms
sed: /proc/kallsyms: No such file or directory
+ eval
+ eval 'v=$end'
+ v=
+ '[' -z end ]
+ '[' 0 -ne 0 ]
+ eval 'v=$start'
+ v=
+ '[' -z start ]
+ '[' 0 -ne 0 ]
+ set -- end start
+ len=0
+ '[' 0 -le 0 ]
+ printf 'Computed config area size is invalid.\n'
Computed config area size is invalid.
+ exit 1
root@fritz:/var/mod/root# less /var/1.s
1.s   1.sh
root@fritz:/var/mod/root# cat /var/1.s
root@fritz:/var/mod/root#

If the steps for a build of avm_kernel_config are not executed, the first idea would wrong settings for these two variables: https://github.com/Freetz-NG/freetz...c60fffac6eba11c65ad/make/linux/kernel.mk#L147, where finally the whole targets inside the ifeq/ifneq conditions aren't included to make rules.
Code:
freetz@freetz:~/freetz-ng$ grep -r 'FREETZ_KERNEL_VERSION_3_10_MIN' ./
./fwmod:[ "${FREETZ_KERNEL_VERSION_3_10_MIN}" == "y" ] && TARGET_TOOLCHAIN_ID__KERNEL_SUFFIX="_kernel-${FREETZ_KERNEL_VERSION_MAJOR}"
./toolchain/make/Makefile.in:TARGET_TOOLCHAIN_COMPILER:=$(TARGET_ARCH_ENDIANNESS_DEPENDENT)_gcc-$(TARGET_TOOLCHAIN_GCC_VERSION)_uClibc-$(TARGET_TOOLCHAIN_UCLIBC_VERSION)$(if $(FREETZ_AVM_UCLIBC_NPTL_ENABLED),-nptl)$(if $(FREETZ_KERNEL_VERSION_3_10_MIN),_kernel-$(KERNEL_VERSION_MAJOR))
./DVB-c-Alien1750E_07.27.all_freetz-ng-18484-4ae9ecb5e_20210805-193049/etc/.config:FREETZ_KERNEL_VERSION_3_10_MIN=y
./make/linux/kernel.mk:KERNEL_IMAGE_BUILD_SUBDIR:=$(if $(FREETZ_KERNEL_VERSION_3_10_MIN),/arch/$(KERNEL_ARCH)/boot)
./make/linux/kernel.mk:ifeq ($(strip $(FREETZ_KERNEL_VERSION_3_10_MIN)),y)
./make/busybox/Config.in.busybox.1_33:  depends on FREETZ_KERNEL_VERSION_3_10_MIN && !FREETZ_AVM_PROP_UCLIBC_0_9_28 && !FREETZ_AVM_PROP_UCLIBC_0_9_29 && !FREETZ_AVM_PROP_UCLIBC_0_9_32
./make/busybox/Config.in.busybox.1_27:  depends on FREETZ_KERNEL_VERSION_3_10_MIN && !FREETZ_AVM_PROP_UCLIBC_0_9_28 && !FREETZ_AVM_PROP_UCLIBC_0_9_29 && !FREETZ_AVM_PROP_UCLIBC_0_9_32
./make/busybox/generate.sh:depends_on NSENTER "FREETZ_KERNEL_VERSION_3_10_MIN \&\& !FREETZ_AVM_PROP_UCLIBC_0_9_28 \&\& !FREETZ_AVM_PROP_UCLIBC_0_9_29 \&\& !FREETZ_AVM_PROP_UCLIBC_0_9_32"
./.config:FREETZ_KERNEL_VERSION_3_10_MIN=y
./tools/latest/etc/.config:FREETZ_KERNEL_VERSION_3_10_MIN=y
./config/ui/toolchain.in:       depends on FREETZ_AVM_GCC_4_6_MIN && FREETZ_AVM_VERSION_06_9X_MAX && FREETZ_KERNEL_VERSION_3_10_MIN
./config/.cache.in:     depends on FREETZ_KERNEL_VERSION_3_10_MIN && !FREETZ_AVM_PROP_UCLIBC_0_9_28 && !FREETZ_AVM_PROP_UCLIBC_0_9_29 && !FREETZ_AVM_PROP_UCLIBC_0_9_32
./config/.cache.in:     depends on FREETZ_KERNEL_VERSION_3_10_MIN && !FREETZ_AVM_PROP_UCLIBC_0_9_28 && !FREETZ_AVM_PROP_UCLIBC_0_9_29 && !FREETZ_AVM_PROP_UCLIBC_0_9_32
./config/.cache.in:     depends on FREETZ_AVM_GCC_4_6_MIN && FREETZ_AVM_VERSION_06_9X_MAX && FREETZ_KERNEL_VERSION_3_10_MIN
./config/.cache.in:             (FREETZ_CPU_MODEL_MIPS_34Kc && FREETZ_KERNEL_VERSION_3_10_MIN) || \
./config/.cache.in:             FREETZ_KERNEL_VERSION_3_10_MIN
./config/.cache.in:     depends on FREETZ_KERNEL_VERSION_3_10_MIN
./config/.cache.in:config FREETZ_KERNEL_VERSION_3_10_MIN
./config/.cache.in:     depends on FREETZ_KERNEL_VERSION_3_10_MIN
./config/avm/compiler-traits.in:                (FREETZ_CPU_MODEL_MIPS_34Kc && FREETZ_KERNEL_VERSION_3_10_MIN) || \
./config/avm/kernel.in:         FREETZ_KERNEL_VERSION_3_10_MIN
./config/avm/kernel.in: depends on FREETZ_KERNEL_VERSION_3_10_MIN
./config/avm/kernel.in:config FREETZ_KERNEL_VERSION_3_10_MIN
./config/avm/kernel.in: depends on FREETZ_KERNEL_VERSION_3_10_MIN
 
As a comment to your statement:
If the original kernel isn't replaced, why should such a build not work? Are you sure, that the kernel image you've installed isn't the original one by AVM? If a new kernel, which replaces the other, isn't built, Freetz(-NG) uses the original one without any problem.

The idea building an older firmware for the DVB-C device was it, to get the right kernel configuration file for it. But it seems, that the value of FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0 is set to y: https://github.com/Freetz-NG/freetz...fac6eba11c65ad/config/.img/1750--07_2X.in#L57 (at least for the 1750E model and then it's highly probable, that the settings for the DVB-C model are the same) and therefore it's not really a miracle, why the whole avm_kernel_config part is ignored.



The assumption, that an avm_kernel_config area is used by this model, is solely based on the source files provided by AVM. If the options used to compile the kernel for a DVB-C repeater do not expose the (virtual) file with kernel symbols (the error message "sed: /proc/kallsyms: No such file or directory" is a first hint for this), this script may not be used - no file, no data. So you should first attempt to prove, whether the symbols are exposed and that the path to this file is correct (or it has to be changed in the script, if it's not /proc/kallsyms).

But the other option (extracting it - offline - from a kernel image) may still work - it doesn't depend on kernel symbols. It looks for the signature of a FDT in the kernel data and if this tool is unable to extract a valid avm_kernel_config area (some validations are included to ensure, the area has the right format), there's really no configuration area.

Instead of switching to other options, you should try to stay on a single solution, until it doesn't make sense anymore. If you simply want to make sure, whether the device uses really a avm_kernel_config area, you may execute the steps to extract data manually ... but on the build host.

You have to unpack a kernel image first (there is a solution in my avm_kernel_config source and another one in Freetz(-NG)) and afterwards you may use the (compiled C-)program to extract data from the unpacked image. If this doesn't work either, there may be no configuration area. But this would be a bad message - because there're no other ideas yet, why the "alien" kernel doesn't support WLAN on the DVB-C repeater.
 
Zuletzt bearbeitet:
Code:
freetz@freetz:~/freetz-ng$ grep -r 'FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0' ./
./DVB-c-Alien1750E_07.27.all_freetz-ng-18484-4ae9ecb5e_20210805-193049/etc/.config:FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0=y
./make/linux/kernel.mk:ifneq ($(strip $(FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0)),y)
./.config:FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0=y
./tools/latest/etc/.config:FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0=y
./config/mod/kernel.in:         ! (FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0) && \
./config/.img/7583--07_2X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1750--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6820_V2.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6820_V1--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6820_V1--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1759--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/4020--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0540--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0546--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0540--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7590--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6000.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7580--DE--07_2X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1750--07_2X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7584.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1759--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/5530.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/4060.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1750--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6890--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7560--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7539.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7590--07_2X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6660.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7583--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0546--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/2400.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7599.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6591.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6890--07_2X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0450--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6820_V1--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1240--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1750--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/1240--07_0X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/6820_V3.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/7580--DE--07_25.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.img/0450--07_1X.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:config FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0
./config/.cache.in:             ! (FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0) && \

If the original kernel isn't replaced, why should such a build not work? Are you sure, that the kernel image you've installed isn't the original one by AVM? If a new kernel, which replaces the other, isn't built, Freetz(-NG) uses the original one without any problem.
How to check it? In the freetz gui I see:


Code:
Box typeDVB-C AVM firmware version07.01 Regionall
Kernel version4.4.60 (jwetter@NL1) (gcc version 5.4.0 (Buildroot 2016.05-g4d7c863) )
Freetz versionfreetz-ng-18488M-a20d364d9
Creation date08.08.2021 21:21:55
Initial file nameDVB-C_07.01.all_freetz-ng-18488M-a20d364d9_20210808-212155.image

The idea building an older firmware for the DVB-C device was it, to get the right kernel configuration file for it. But it seems, that the value of FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0 is set to y: https://github.com/Freetz-NG/freetz...fac6eba11c65ad/config/.img/1750--07_2X.in#L57 (at least for the 1750E model and then it's highly probable, that the settings for the DVB-C model are the same) and therefore it's not really a miracle, why the whole avm_kernel_config part is ignored.
Seems yes, see below:

Code:
./.config:FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0=y

And finally please see the fmake.log attached.
 

Anhänge

  • fmake.log.gz.zip
    1.4 MB · Aufrufe: 1
We should cool down a bit (this is not a chat system) ... it's not helpful, if more and more posts are written always, while I'm writing the answer to the last I've read so far. So it's time to quit for today (it's even 12:45 AM in Berlin) ... tomorrow is another day, too.



Using a fresh Freetz-NG checkout I've found meanwhile, that the "Replace kernel" option isn't available for both models, neither for the 1750E nor for the DVB-C repeater. So it doesn't make any difference, whether the build extracts a avm_kernel_config area or not - it's never needed, as long as not an own kernel will be used.

As the result are more changes needed ... but it's still possible. I didn't look at the other patches for this "alien" case ... but there must be a patch, too, that enables the "Replace kernel" option (and the actions behind) ... otherwise you'll never get an own kernel.

You've got a proposal, how to extract the avm_kernel_config area manually from the DVB-C kernel image (last two paragraphs of #46) - this would prove at the same time, whether such an area exists or not. Let's take it step by step ... all other doesn't make sense.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,085
Beiträge
2,245,798
Mitglieder
373,539
Neuestes Mitglied
Horst Fürst
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.