[Info] Fehlende Bestandteile im OpenSource-Paket von AVM

[berndy2001]

Hallo,
mich bringt http://freetz.org/ticket/2774#comment:164 hierher.

user@zx:~/freetz-trunk$ make
make -j2 -f Makefile.freetz -C /home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt \
        CC="gcc"
make[1]: Entering directory '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt'
gcc -O2 -m32 -std=c99 -I. -D_GNU_SOURCE  -c -o fdt.o fdt.c
gcc -O2 -m32 -std=c99 -I. -D_GNU_SOURCE  -c -o fdt_ro.o fdt_ro.c
In file included from /usr/include/stdint.h:25:0,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdint.h:9,
                 from libfdt_env.h:56,
                 from fdt_ro.c:51:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: Datei oder Verzeichnis nicht gefunden
 #  include <sys/cdefs.h>
                         ^
compilation terminated.
In file included from /usr/include/stdint.h:25:0,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdint.h:9,
                 from libfdt_env.h:56,
                 from fdt.c:51:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: Datei oder Verzeichnis nicht gefunden
 #  include <sys/cdefs.h>
                         ^
compilation terminated.
<builtin>: recipe for target 'fdt_ro.o' failed
make[1]: *** [fdt_ro.o] Error 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
<builtin>: recipe for target 'fdt.o' failed
make[1]: *** [fdt.o] Error 1
make[1]: Leaving directory '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt'
tools/make/dtc-host/dtc-host.mk:21: recipe for target '/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt/libfdt.a' failed
make: *** [/home/user/freetz-trunk/source/host-tools/dtc-v1.4.2/libfdt/libfdt.a] Error 2

trunk ist frisch ausgecheckt. Fehlt mir was auf meiner Build-Umgebung (Debian 8.7 64bit)?

 

[er13]

Fehlt mir was auf meiner Build-Umgebung (Debian 8.7 64bit)?

s. hier (ab "# Auf 64-Bit Systemen sind zusätzlich folgende Pakete zu installieren")

 

[berndy2001]

Danke. Ich war der Meinung diese Pakte hätte eh installiert.

 

[er13]

Hallo Peter,

hast Du Dich zufälligerweise schon mit dem Thema "avm_kernel_config_area" im Zusammenhang mit den GRX5-Boxen (7560, 7580) auseinander gesetzt? kernel.image ist bei diesen nicht mehr lzma1 komprimiert, sondern irgendwie anders (xz?). Könntest Du bitte bei Gelegenheit {extract,gen}_avm_kernel_config anpassen? avm_kernel_config_area ist bei diesen Boxen laut verfügbaren kernel-sourcen 96KB groß.

Danke!

VG, Gene

 

[PeterPawn]

@er13:
Nein, habe ich noch nicht (intensiv) gemacht. Ich habe seit letztem Donnerstag eine 7580 hier und passe erst einmal mein "modfs" an die geänderte Dateisystem-Struktur an.

Nach allem, was ich bisher gesehen habe, kommt bei der 7580 aber der (OF-)FDT-Blob ohnehin aus dem Bootloader ... dieser stellt seinerseits sicher, daß an der Stelle, wo ansonsten HWSubRevision 0 liegen würde, die korrekten Daten für die aktuelle Box liegen und das ganze "Ablaufen" auf der Suche nach der passenden HWSubRevision bzw. der nächstkleineren, fällt bei GRX500 einfach aus - "subrev" wird stur auf "0" gesetzt in "arch/mips/kernel/setup.c".

Ich habe bisher noch keine Ahnung, was AVM da nun überhaupt im Konfigurationsbereich unterbringt ... der FDT ist es jedenfalls schon mal nicht. Nach allem, was man ansonsten in "init/avm_kernel_config.c" sehen kann, werden da auch keine zusätzlichen Typen von Einträgen verwendet ... zumindest enden alle neuen Typen am Ende in einem "pr_err()"-Aufruf, der sie als "unhandled" brandmarkt. Bleiben also noch die Versionsinformationen und die Module-Tabelle.

Allerdings habe ich noch nicht in den Speicher zwischen diesen beiden Symbolen (start und end) geschaut ... es ist nur bereits jetzt klar, daß der Code zur Suche nach dem FDT, mit dem der Konfigurationsbereich im VR9-Kernel ja lokalisiert wird, hier mit einiger Wahrscheinlichkeit nicht funktionieren wird, solange AVM dort nicht (sicherheitshalber) noch eine zusätzliche FDT-Struktur ablegt.

Das Erhöhen des Zählers für die möglichen "HWSubRevisionen" auf 256 könnte eine der Ursachen sein, warum das nun 96 KB sein sollen ... wobei ich eigentlich der Meinung bin, daß der Code für den GRX500 historisch sogar älter sein müßte, als der für den VR9 - auch der ältere Kernel spricht m.E. dafür.

Wobei im Moment ja für die 7580 die Quellen nicht zur aktuell veröffentlichten Firmware passen ... die Firmware ist die 06.81 vom 25.01.2017 und das Opensource-Paket ist (Stand heute) immer noch das für die 06.53 aus dem Oktober 2016. Mal sehen, wann da die aktuelle Version kommt ... 6 Wochen sind schon mal rum (wobei die 06.80 aus dem Dez. 2016 hier gar nicht betrachtet wird).

Gepackt sollte der Kernel mit "gzip" sein ... aber ich finde schon den Header nicht (falls AVM die Standardroutinen zum Entpacken benutzt (lib/decompress_inflate.c), müßte der Payload mit 0x1F8B08 starten) und auch das doppelte TI-Magic am Ende des Kernel-Files (ich hatte die 06.53 untersucht) läßt mich etwas skeptisch zurück, ob da alles mit rechten Dingen zugeht.

 

[er13]

@Peter: Ok, alles klar. Danke für die Antwort! Diese Woche ist bei mir recht voll, komme wahrscheinlich erst nächste Woche dazu, mich mit dem Thema weiter zu beschäftigen.

 

[PeterPawn]

Kernel-Konfiguration FRITZ!Box 7580

In der 7580 ist der Kernel ja mit der Option "CONFIG_IKCONFIG=y" und "CONFIG_IKCONFIG_PROC=y" übersetzt (153.06.54) ... infolgedessen steht die tatsächlich verwendete Konfiguration als "config.gz" unterhalb von "/proc" zum Auslesen bereit - siehe Anhang.

Vergleicht man das mit dem, was AVM im OpenSource-Paket für dieselbe Version "beilegt", ergeben sich bereits dort so gravierende Unterschiede, daß man schon fast von (bewußter?) Sabotage am OpenSource-Gedanken ausgehen muß:

@@ -181,7 +181,7 @@
 CONFIG_ARCH_DISCARD_MEMBLOCK=y
 # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
 CONFIG_PAGEFLAGS_EXTENDED=y
-CONFIG_SPLIT_PTLOCK_CPUS=999999
+CONFIG_SPLIT_PTLOCK_CPUS=4
 CONFIG_COMPACTION=y
 CONFIG_MIGRATION=y
 # CONFIG_PHYS_ADDR_T_64BIT is not set
@@ -430,7 +430,11 @@
 # CONFIG_DEFAULT_CFQ is not set
 # CONFIG_DEFAULT_NOOP is not set
 CONFIG_DEFAULT_IOSCHED="deadline"
-CONFIG_UNINLINE_SPIN_UNLOCK=y
+CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+CONFIG_INLINE_READ_UNLOCK=y
+CONFIG_INLINE_READ_UNLOCK_IRQ=y
+CONFIG_INLINE_WRITE_UNLOCK=y
+CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_LTQ_LIST_PREFETCH=y
 CONFIG_AVM_KERNEL=y
@@ -512,7 +516,8 @@
 # CONFIG_LTQ_CPUFREQ_DEBUG is not set
 CONFIG_LTQ_CPU_FREQ=y
 CONFIG_LTQ_CPUFREQ_DVS=y
-# CONFIG_AVM_IPI_YIELD is not set
+CONFIG_AVM_IPI_YIELD=y
+CONFIG_AVM_IPI_YIELD_DEBUG=y
 CONFIG_NET=y
 CONFIG_ETHERNET_PACKET_MANGLE=y
 # CONFIG_NET_DEV_LOAD is not set
@@ -539,7 +544,7 @@
 CONFIG_XFRM_IPCOMP=y
 CONFIG_NET_KEY=y
 # CONFIG_NET_KEY_MIGRATE is not set
-CONFIG_LANTIQ_MCAST_HELPER=n
+CONFIG_LANTIQ_MCAST_HELPER=m
 CONFIG_LANTIQ_MCAST_HELPER_ACL=y
 # CONFIG_LTQ_STAT_HELPER is not set
 CONFIG_AVM_RECV_HOOKS=y
@@ -612,15 +617,15 @@
 # CONFIG_INET6_IPCOMP is not set
 # CONFIG_IPV6_MIP6 is not set
 # CONFIG_INET6_XFRM_TUNNEL is not set
-CONFIG_INET6_TUNNEL=n
+CONFIG_INET6_TUNNEL=m
 # CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
 # CONFIG_INET6_XFRM_MODE_TUNNEL is not set
 # CONFIG_INET6_XFRM_MODE_BEET is not set
 # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
-CONFIG_IPV6_SIT=n
+CONFIG_IPV6_SIT=m
 CONFIG_IPV6_SIT_6RD=y
 CONFIG_IPV6_NDISC_NODETYPE=y
-CONFIG_IPV6_TUNNEL=n
+CONFIG_IPV6_TUNNEL=m
 # CONFIG_IPV6_GRE is not set
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_IPV6_SUBTREES=y
@@ -684,6 +689,7 @@
 CONFIG_L2TP_ETH=y
 CONFIG_STP=y
 CONFIG_BRIDGE=y
+CONFIG_AVM_BRIDGE_FLOOD_RATELIMITER=y
 CONFIG_BRIDGE_IGMP_SNOOPING=y
 CONFIG_AVM_BRIDGE_MULTICAST_TO_UNICAST=y
 CONFIG_AVM_BRIDGE_MULTICAST_TO_UNICAST_DEFAULT_THRESHOLD=3
@@ -708,26 +714,26 @@
 #
 CONFIG_NET_SCH_CBQ=y
 CONFIG_NET_SCH_HTB=y
-CONFIG_NET_SCH_HFSC=n
+CONFIG_NET_SCH_HFSC=m
 # CONFIG_NET_SCH_ATM is not set
-CONFIG_NET_SCH_PRIO=n
+CONFIG_NET_SCH_PRIO=m
 # CONFIG_NET_SCH_MULTIQ is not set
 CONFIG_NET_SCH_RED=y
 # CONFIG_NET_SCH_SFB is not set
-CONFIG_NET_SCH_SFQ=n
+CONFIG_NET_SCH_SFQ=m
 # CONFIG_NET_SCH_ESFQ is not set
-CONFIG_NET_SCH_TEQL=n
-CONFIG_NET_SCH_TBF=n
-CONFIG_NET_SCH_GRED=n
+CONFIG_NET_SCH_TEQL=m
+CONFIG_NET_SCH_TBF=m
+CONFIG_NET_SCH_GRED=m
 CONFIG_NET_SCH_DSMARK=y
-CONFIG_NET_SCH_NETEM=n
+CONFIG_NET_SCH_NETEM=m
 # CONFIG_NET_SCH_DRR is not set
 # CONFIG_NET_SCH_MQPRIO is not set
 # CONFIG_NET_SCH_CHOKE is not set
 # CONFIG_NET_SCH_QFQ is not set
-CONFIG_NET_SCH_CODEL=n
+CONFIG_NET_SCH_CODEL=m
 CONFIG_NET_SCH_LLQ=y
-CONFIG_NET_SCH_HW=n
+CONFIG_NET_SCH_HW=m
 CONFIG_NET_SCH_HW_BYPASS=y
 CONFIG_NET_SCH_FQ_CODEL=y
 CONFIG_NET_SCH_INGRESS=y
@@ -737,29 +743,29 @@
 # Classification
 #
 CONFIG_NET_CLS=y
-CONFIG_NET_CLS_BASIC=n
-CONFIG_NET_CLS_TCINDEX=n
-CONFIG_NET_CLS_ROUTE4=n
+CONFIG_NET_CLS_BASIC=m
+CONFIG_NET_CLS_TCINDEX=m
+CONFIG_NET_CLS_ROUTE4=m
 CONFIG_NET_CLS_FW=y
 CONFIG_NET_CLS_U32=y
 CONFIG_CLS_U32_PERF=y
 # CONFIG_CLS_U32_MARK is not set
 CONFIG_CLS_U32_EXTMARK=y
-CONFIG_NET_CLS_RSVP=n
-CONFIG_NET_CLS_RSVP6=n
-CONFIG_NET_CLS_FLOW=n
+CONFIG_NET_CLS_RSVP=m
+CONFIG_NET_CLS_RSVP6=m
+CONFIG_NET_CLS_FLOW=m
 # CONFIG_NET_CLS_CGROUP is not set
 CONFIG_NET_EMATCH=y
 CONFIG_NET_EMATCH_STACK=32
-CONFIG_NET_EMATCH_CMP=n
-CONFIG_NET_EMATCH_NBYTE=n
-CONFIG_NET_EMATCH_U32=n
-CONFIG_NET_EMATCH_META=n
-CONFIG_NET_EMATCH_TEXT=n
+CONFIG_NET_EMATCH_CMP=m
+CONFIG_NET_EMATCH_NBYTE=m
+CONFIG_NET_EMATCH_U32=m
+CONFIG_NET_EMATCH_META=m
+CONFIG_NET_EMATCH_TEXT=m
 CONFIG_NET_CLS_ACT=y
 CONFIG_NET_ACT_POLICE=y
 # CONFIG_NET_ACT_GACT is not set
-CONFIG_NET_ACT_MIRRED=n
+CONFIG_NET_ACT_MIRRED=m
 # CONFIG_NET_ACT_NAT is not set
 # CONFIG_NET_ACT_PEDIT is not set
 # CONFIG_NET_ACT_SIMP is not set
@@ -995,7 +1001,7 @@
 # CONFIG_BLK_DEV_COW_COMMON is not set
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_LOOP_MIN_COUNT=2
-CONFIG_BLK_DEV_CRYPTOLOOP=n
+CONFIG_BLK_DEV_CRYPTOLOOP=m
 # CONFIG_BLK_DEV_DRBD is not set
 # CONFIG_BLK_DEV_NBD is not set
 # CONFIG_BLK_DEV_NVME is not set
@@ -1217,7 +1223,7 @@
 #
 # Controllers with non-SFF native interface
 #
-CONFIG_SATA_AHCI=n
+CONFIG_SATA_AHCI=m
 # CONFIG_SATA_AHCI_PLATFORM is not set
 # CONFIG_SATA_INIC162X is not set
 # CONFIG_SATA_ACARD_AHCI is not set
@@ -1316,14 +1322,14 @@
 # CONFIG_I2O is not set
 CONFIG_NETDEVICES=y
 CONFIG_NET_CORE=y
-CONFIG_BONDING=n
+CONFIG_BONDING=m
 # CONFIG_DUMMY is not set
 # CONFIG_EQUALIZER is not set
 # CONFIG_NET_FC is not set
 CONFIG_MII=y
 # CONFIG_IFB is not set
 # CONFIG_NET_TEAM is not set
-CONFIG_MACVLAN=n
+CONFIG_MACVLAN=m
 # CONFIG_LTQ_ETHSW is not set
 # CONFIG_MACVTAP is not set
 # CONFIG_VXLAN is not set
@@ -1386,14 +1392,14 @@
 # CONFIG_IP1000 is not set
 CONFIG_NET_VENDOR_LANTIQ=y
 CONFIG_LANTIQ_VRX318=y
-CONFIG_ACCL_11AC=n
+CONFIG_ACCL_11AC=m
 # CONFIG_LANITQ_VRX318_PCIE_SWITCH_DSL_BONDING is not set
 # CONFIG_LANTIQ_ETH_FRAMEWORK is not set
 CONFIG_LTQ_ETH_XRX500=y
 CONFIG_XRX500_ETH_DRV_COC_SUPPORT=y
 CONFIG_SW_ROUTING_MODE=y
 # CONFIG_HAPS_CPU_LOOPBACK_TEST is not set
-# CONFIG_LTQ_ETH_OAM is not set
+CONFIG_LTQ_ETH_OAM=m
 CONFIG_LTQ_TOE_DRIVER=y
 CONFIG_LTQ_DATAPATH=y
 # CONFIG_LTQ_DATAPATH_MIB is not set
@@ -1436,7 +1442,7 @@
 # VRX318
 #
 CONFIG_VRX318_DATAPATH=y
-CONFIG_VRX318_TC=n
+CONFIG_VRX318_TC=m
 CONFIG_LTQ_DIRECTCONNECT_DP=y
 CONFIG_LTQ_DIRECTCONNECT_DP_DBG=y
 # CONFIG_JME is not set
@@ -1530,12 +1536,12 @@
 # CONFIG_USB_PEGASUS is not set
 # CONFIG_USB_RTL8150 is not set
 # CONFIG_USB_RTL8152 is not set
-CONFIG_USB_USBNET=n
+CONFIG_USB_USBNET=m
 # CONFIG_USB_NET_AX8817X is not set
 # CONFIG_USB_NET_AX88179_178A is not set
-CONFIG_USB_NET_CDCETHER=n
+CONFIG_USB_NET_CDCETHER=m
 # CONFIG_USB_NET_CDC_EEM is not set
-# CONFIG_USB_NET_CDC_NCM is not set
+CONFIG_USB_NET_CDC_NCM=m
 # CONFIG_USB_NET_CDC_MBIM is not set
 # CONFIG_USB_NET_DM9601 is not set
 # CONFIG_USB_NET_SMSC75XX is not set
@@ -1544,7 +1550,7 @@
 # CONFIG_USB_NET_NET1080 is not set
 # CONFIG_USB_NET_PLUSB is not set
 # CONFIG_USB_NET_MCS7830 is not set
-CONFIG_USB_NET_RNDIS_HOST=n
+CONFIG_USB_NET_RNDIS_HOST=m
 # CONFIG_USB_NET_CDC_SUBSET is not set
 # CONFIG_USB_NET_ZAURUS is not set
 # CONFIG_USB_NET_CX82310_ETH is not set
@@ -1574,16 +1580,16 @@
 # CONFIG_LTQ_PPA_XRX300 is not set
 # CONFIG_LTQ_PPA_XRX330 is not set
 CONFIG_LTQ_PPA_GRX500=y
-CONFIG_LTQ_PPA_API=y
+CONFIG_LTQ_PPA_API=m
 # CONFIG_LTQ_MINI_JUMBO_FRAME_SUPPORT is not set
 CONFIG_LTQ_PPA_API_DIRECTPATH=y
 CONFIG_LTQ_PPA_API_DIRECTPATH_BRIDGING=y
 CONFIG_LTQ_PPA_API_DIRECTPATH_HAS_NEW_API=y
 CONFIG_LTQ_PPA_HAL_SELECTOR=y
-CONFIG_LTQ_PPA_PAE_HAL=n
+CONFIG_LTQ_PPA_PAE_HAL=m
 CONFIG_LTQ_PPA_LRO=y
 CONFIG_LTQ_PPA_TMU_HAL=y
-CONFIG_LTQ_PPA_MPE_HAL=n
+CONFIG_LTQ_PPA_MPE_HAL=m
 CONFIG_LTQ_PPA_COC_SUPPORT=y
 CONFIG_LTQ_BRIDGE_LEARNING=y
 # CONFIG_LTQ_PPA_HANDLE_CONNTRACK_SESSIONS is not set
@@ -1591,7 +1597,7 @@
 # CONFIG_LTQ_PPA_DIRECTPATH_TX_QUEUE_SIZE is not set
 # CONFIG_LTQ_PPA_DIRECTPATH_TX_QUEUE_PKTS is not set
 # CONFIG_LTQ_PPA_DIRECTPATH_TX_IMQ is not set
-CONFIG_LTQ_PPA_API_PROC=n
+CONFIG_LTQ_PPA_API_PROC=m
 # CONFIG_LTQ_PPA_MFE is not set
 CONFIG_LTQ_PPA_AVM_PA=y
 CONFIG_LTQ_PPA_AVM_PA_COUNTER_INTERVAL=1
@@ -1599,7 +1605,7 @@
 CONFIG_LTQ_PPA_QOS_WFQ=y
 CONFIG_LTQ_PPA_QOS_RATE_SHAPING=y
 CONFIG_LTQ_PPA_IPv6_ENABLE=y
-CONFIG_LTQ_PPA_DATAPATH=y
+CONFIG_LTQ_PPA_DATAPATH=m
 
 #
 # Package Selection
@@ -1611,7 +1617,7 @@
 # CONFIG_LTQ_PPA_API_SW_FASTPATH is not set
 CONFIG_AVM_QOS=y
 CONFIG_AVM_QOS_GRX_TMU=y
-CONFIG_AVM_NET_LINK_AUDIO=n
+CONFIG_AVM_NET_LINK_AUDIO=m
 CONFIG_ISDN=y
 # CONFIG_ISDN_I4L is not set
 CONFIG_ISDN_CAPI=y
@@ -1625,7 +1631,7 @@
 #
 # AVM CAPI-CODEC
 #
-CONFIG_CAPI_CODEC=n
+CONFIG_CAPI_CODEC=m
 # CONFIG_CAPI_CODEC_SPEEX is not set
 CONFIG_CAPI_CODEC_ILBC=y
 CONFIG_CAPI_CODEC_G729=y
@@ -1639,7 +1645,7 @@
 #
 # AVM DECT Stack
 #
-CONFIG_AVM_DECT=n
+CONFIG_AVM_DECT=m
 # CONFIG_AVM_DECT_DEBUG is not set
 CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
 CONFIG_CAPI_TRACE=y
@@ -1653,11 +1659,11 @@
 # CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
 # CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
 # CONFIG_ISDN_DRV_AVMB1_C4 is not set
-CONFIG_ISDN_CAPI_ISDN_NT_PCMLINK=n
-CONFIG_ISDN_NT_PCMLINK_BLK=n
-CONFIG_ISDN_NT_PCMLINK_E1=n
-CONFIG_ISDN_NT_PCMLINK_STACK=n
-CONFIG_ISDN_NT_PCMLINK_ISDN_AB=n
+CONFIG_ISDN_CAPI_ISDN_NT_PCMLINK=m
+CONFIG_ISDN_NT_PCMLINK_BLK=m
+CONFIG_ISDN_NT_PCMLINK_E1=m
+CONFIG_ISDN_NT_PCMLINK_STACK=m
+CONFIG_ISDN_NT_PCMLINK_ISDN_AB=m
 # CONFIG_ISDN_NT_PCMLINK_DEBUG is not set
 # CONFIG_ISDN_NT_PCMLINK_NO_BCHANNEL is not set
 # CONFIG_ISDN_NT_PCMLINK_FAX is not set
@@ -1742,6 +1748,7 @@
 # CONFIG_TFFS_DEV_LEGACY is not set
 CONFIG_TFFS_DEV_MTDNAND=y
 CONFIG_TFFS_DEV_CACHE=y
+CONFIG_TFFS_DEV_CACHE_ENV_ONLY=y
 CONFIG_TFFS_ENV=y
 CONFIG_TFFS_PANIC_LOG=y
 CONFIG_TFFS_PANIC_LOG_ID=96
@@ -1770,13 +1777,13 @@
 #
 # AVM Piglet (no emif)
 #
-CONFIG_AVM_PIGLET_NOEMIF=n
+CONFIG_AVM_PIGLET_NOEMIF=m
 CONFIG_AVM_PIGLET_DECT=y
 
 #
 # AVM PCMLINK driver for PCM-Routing
 #
-CONFIG_UBIK2=n
+CONFIG_UBIK2=m
 CONFIG_UBIK2_DEVELOPMENT_SUPPORT=0
 CONFIG_UBIK2_MSEC_PER_IRQ=4
 CONFIG_UBIK2_ISDNSTACK_ON_CPU=0
@@ -1784,11 +1791,11 @@
 #
 # AVM DECT_IO
 #
-CONFIG_AVM_DECT_IO=n
+CONFIG_AVM_DECT_IO=m
 # CONFIG_LTQ_DSL_CPE_MEI_ARX is not set
 CONFIG_DSL_MEI_CPE_DRV=y
 CONFIG_LTQ_DSL_CPE_MEI_VRX=y
-CONFIG_LTQ_VOIP_TIMER=n
+CONFIG_LTQ_VOIP_TIMER=m
 CONFIG_LTQ_RCU=y
 
 #
@@ -1997,7 +2004,7 @@
 # CONFIG_W1 is not set
 # CONFIG_POWER_SUPPLY is not set
 # CONFIG_POWER_AVS is not set
-CONFIG_HWMON=n
+CONFIG_HWMON=m
 # CONFIG_HWMON_VID is not set
 # CONFIG_HWMON_DEBUG_CHIP is not set
 
@@ -2089,7 +2096,7 @@
 # CONFIG_SENSORS_ADS7871 is not set
 # CONFIG_SENSORS_AMC6821 is not set
 # CONFIG_SENSORS_INA209 is not set
-CONFIG_SENSORS_INA2XX=n
+CONFIG_SENSORS_INA2XX=m
 # CONFIG_SENSORS_THMC50 is not set
 # CONFIG_SENSORS_TMP102 is not set
 # CONFIG_SENSORS_TMP401 is not set
@@ -2106,7 +2113,7 @@
 # CONFIG_SENSORS_W83L786NG is not set
 # CONFIG_SENSORS_W83627HF is not set
 # CONFIG_SENSORS_W83627EHF is not set
-CONFIG_LTQ_SPDMON=n
+CONFIG_LTQ_SPDMON=m
 # CONFIG_THERMAL is not set
 # CONFIG_WATCHDOG is not set
 CONFIG_SSB_POSSIBLE=y
@@ -2256,8 +2263,8 @@
 # USB Host Controller Drivers
 #
 # CONFIG_USB_C67X00_HCD is not set
-CONFIG_USB_XHCI_HCD=n
-CONFIG_USB_XHCI_PLATFORM=n
+CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=m
 # CONFIG_USB_XHCI_HCD_DEBUGGING is not set
 # CONFIG_USB_EHCI_HCD is not set
 # CONFIG_USB_OXU210HP_HCD is not set
@@ -2273,8 +2280,8 @@
 #
 # USB Device Class drivers
 #
-CONFIG_USB_ACM=n
-CONFIG_USB_PRINTER=n
+CONFIG_USB_ACM=m
+CONFIG_USB_PRINTER=m
 # CONFIG_USB_WDM is not set
 # CONFIG_USB_TMC is not set
 
@@ -2313,7 +2320,7 @@
 #
 # USB port drivers
 #
-CONFIG_USB_SERIAL=n
+CONFIG_USB_SERIAL=m
 # CONFIG_USB_SERIAL_GENERIC is not set
 # CONFIG_USB_SERIAL_AIRCABLE is not set
 # CONFIG_USB_SERIAL_ARK3116 is not set
@@ -2358,8 +2365,8 @@
 # CONFIG_USB_SERIAL_TI is not set
 # CONFIG_USB_SERIAL_CYBERJACK is not set
 # CONFIG_USB_SERIAL_XIRCOM is not set
-CONFIG_USB_SERIAL_WWAN=n
-CONFIG_USB_SERIAL_OPTION=n
+CONFIG_USB_SERIAL_WWAN=m
+CONFIG_USB_SERIAL_OPTION=m
 # CONFIG_USB_SERIAL_OMNINET is not set
 # CONFIG_USB_SERIAL_OPTICON is not set
 # CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set
@@ -2543,7 +2550,7 @@
 #
 # HID Sensor RTC drivers
 #
-CONFIG_RTC_DRV_AVM_REF_CLOCK=n
+CONFIG_RTC_DRV_AVM_REF_CLOCK=m
 CONFIG_DMADEVICES=y
 # CONFIG_DMADEVICES_DEBUG is not set
 
@@ -2712,7 +2719,7 @@
 #
 CONFIG_FAT_FS=y
 CONFIG_MSDOS_FS=y
-CONFIG_VFAT_FS=n
+CONFIG_VFAT_FS=m
 CONFIG_FAT_DEFAULT_CODEPAGE=437
 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_NTFS_FS is not set
@@ -2731,12 +2738,12 @@
 CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_TMPFS_XATTR=y
 # CONFIG_HUGETLB_PAGE is not set
-CONFIG_CONFIGFS_FS=n
+CONFIG_CONFIGFS_FS=m
 CONFIG_MISC_FILESYSTEMS=y
 # CONFIG_ADFS_FS is not set
 # CONFIG_AFFS_FS is not set
-CONFIG_HFS_FS=n
-CONFIG_HFSPLUS_FS=n
+CONFIG_HFS_FS=m
+CONFIG_HFSPLUS_FS=m
 # CONFIG_BEFS_FS is not set
 # CONFIG_BFS_FS is not set
 # CONFIG_EFS_FS is not set
@@ -2789,11 +2796,11 @@
 # CONFIG_AFS_FS is not set
 CONFIG_NLS=y
 CONFIG_NLS_DEFAULT="iso8859-1"
-CONFIG_NLS_CODEPAGE_437=n
+CONFIG_NLS_CODEPAGE_437=m
 # CONFIG_NLS_CODEPAGE_737 is not set
 # CONFIG_NLS_CODEPAGE_775 is not set
-CONFIG_NLS_CODEPAGE_850=n
-CONFIG_NLS_CODEPAGE_852=n
+CONFIG_NLS_CODEPAGE_850=m
+CONFIG_NLS_CODEPAGE_852=m
 # CONFIG_NLS_CODEPAGE_855 is not set
 # CONFIG_NLS_CODEPAGE_857 is not set
 # CONFIG_NLS_CODEPAGE_860 is not set
@@ -2813,7 +2820,7 @@
 # CONFIG_NLS_CODEPAGE_1250 is not set
 # CONFIG_NLS_CODEPAGE_1251 is not set
 # CONFIG_NLS_ASCII is not set
-CONFIG_NLS_ISO8859_1=n
+CONFIG_NLS_ISO8859_1=m
 # CONFIG_NLS_ISO8859_2 is not set
 # CONFIG_NLS_ISO8859_3 is not set
 # CONFIG_NLS_ISO8859_4 is not set
@@ -2823,7 +2830,7 @@
 # CONFIG_NLS_ISO8859_9 is not set
 # CONFIG_NLS_ISO8859_13 is not set
 # CONFIG_NLS_ISO8859_14 is not set
-CONFIG_NLS_ISO8859_15=n
+CONFIG_NLS_ISO8859_15=m
 # CONFIG_NLS_KOI8_R is not set
 # CONFIG_NLS_KOI8_U is not set
 # CONFIG_NLS_MAC_ROMAN is not set
@@ -2837,7 +2844,7 @@
 # CONFIG_NLS_MAC_INUIT is not set
 # CONFIG_NLS_MAC_ROMANIAN is not set
 # CONFIG_NLS_MAC_TURKISH is not set
-CONFIG_NLS_UTF8=n
+CONFIG_NLS_UTF8=m
 # CONFIG_DLM is not set
 
 #
@@ -2862,7 +2869,7 @@
 # CONFIG_PANIC_ON_OOPS is not set
 CONFIG_PANIC_ON_OOPS_VALUE=0
 # CONFIG_DETECT_HUNG_TASK is not set
-CONFIG_SCHED_DEBUG=y
+# CONFIG_SCHED_DEBUG is not set
 # CONFIG_SCHEDSTATS is not set
 # CONFIG_TIMER_STATS is not set
 # CONFIG_DEBUG_OBJECTS is not set
@@ -2871,7 +2878,7 @@
 # CONFIG_DEBUG_KMEMLEAK is not set
 # CONFIG_DEBUG_RT_MUTEXES is not set
 # CONFIG_RT_MUTEX_TESTER is not set
-CONFIG_DEBUG_SPINLOCK=y
+# CONFIG_DEBUG_SPINLOCK is not set
 # CONFIG_DEBUG_MUTEXES is not set
 # CONFIG_DEBUG_LOCK_ALLOC is not set
 # CONFIG_PROVE_LOCKING is not set
@@ -2984,7 +2991,7 @@
 # CONFIG_CRYPTO_CTS is not set
 CONFIG_CRYPTO_ECB=y
 # CONFIG_CRYPTO_LRW is not set
-CONFIG_CRYPTO_PCBC=n
+CONFIG_CRYPTO_PCBC=m
 # CONFIG_CRYPTO_XTS is not set
 
 #
@@ -3001,40 +3008,40 @@
 CONFIG_CRYPTO_CRC32C=y
 # CONFIG_CRYPTO_CRC32 is not set
 CONFIG_CRYPTO_GHASH=y
-CONFIG_CRYPTO_MD4=n
+CONFIG_CRYPTO_MD4=m
 CONFIG_CRYPTO_MD5=y
-CONFIG_CRYPTO_MICHAEL_MIC=n
+CONFIG_CRYPTO_MICHAEL_MIC=m
 # CONFIG_CRYPTO_RMD128 is not set
 # CONFIG_CRYPTO_RMD160 is not set
 # CONFIG_CRYPTO_RMD256 is not set
 # CONFIG_CRYPTO_RMD320 is not set
 CONFIG_CRYPTO_SHA1=y
-CONFIG_CRYPTO_SHA256=n
-CONFIG_CRYPTO_SHA512=n
-CONFIG_CRYPTO_TGR192=n
-CONFIG_CRYPTO_WP512=n
+CONFIG_CRYPTO_SHA256=m
+CONFIG_CRYPTO_SHA512=m
+CONFIG_CRYPTO_TGR192=m
+CONFIG_CRYPTO_WP512=m
 
 #
 # Ciphers
 #
 CONFIG_CRYPTO_AES=y
-CONFIG_CRYPTO_ANUBIS=n
+CONFIG_CRYPTO_ANUBIS=m
 CONFIG_CRYPTO_ARC4=y
 CONFIG_CRYPTO_BLOWFISH=y
 CONFIG_CRYPTO_BLOWFISH_COMMON=y
 # CONFIG_CRYPTO_CAMELLIA is not set
-CONFIG_CRYPTO_CAST_COMMON=n
-CONFIG_CRYPTO_CAST5=n
-CONFIG_CRYPTO_CAST6=n
+CONFIG_CRYPTO_CAST_COMMON=m
+CONFIG_CRYPTO_CAST5=m
+CONFIG_CRYPTO_CAST6=m
 CONFIG_CRYPTO_DES=y
 # CONFIG_CRYPTO_FCRYPT is not set
-CONFIG_CRYPTO_KHAZAD=n
+CONFIG_CRYPTO_KHAZAD=m
 # CONFIG_CRYPTO_SALSA20 is not set
 # CONFIG_CRYPTO_SEED is not set
-CONFIG_CRYPTO_SERPENT=n
-CONFIG_CRYPTO_TEA=n
-CONFIG_CRYPTO_TWOFISH=n
-CONFIG_CRYPTO_TWOFISH_COMMON=n
+CONFIG_CRYPTO_SERPENT=m
+CONFIG_CRYPTO_TEA=m
+CONFIG_CRYPTO_TWOFISH=m
+CONFIG_CRYPTO_TWOFISH_COMMON=m
 
 #
 # Compression

Zwar braucht man jetzt bei der 7580 nicht zu raten, welche Kernel-Konfiguration AVM da nun verwendet haben mag ... aber die Chancen, mit dem reinen OpenSource-Paket (so wie es die GPLv2 eigentlich fordert) einen funktionsfähigen, identischen Kernel zu erstellen, dürften (augenscheinlich) gegen Null tendieren.

Wenn also man wieder jemand von oder bei AVM über die "vorbildliche" Bereitstellung von OpenSource-Paketen schwadroniert - sei es auf irgendeiner Messe oder anderswo, die CeBIT steht ja vor der Tür -, dann kann so jemand ja vielleicht auch diesen Widerspruch (zumindest für mich ist es einer, denn die mitgelieferte ".config" paßt nicht zum tatsächlich verwendeten Kernel - auch wenn man das bei den schon vorher sichtbaren Unterschieden zwischen "n" und "m" bei diversen LKM schon erwarten konnte) "auflösen".

EDIT: Korrektur meinerseits ... AVM hat die Quellen für die 06.54 noch gar nicht bereitgestellt (diese Firmware-Version wurde am 19.10.2016 erstellt). Die von mir zum Vergleich benutzte ".config" stammt also noch aus dem Paket zur 153.06.53. Ich werde bei Gelegenheit den in der 06.53 verwendeten Kernel (wenn ich ihn dann entpacken konnte, was ja auch noch als ToDo ansteht) untersuchen, dort die verwendete Konfiguration auslesen (sollte bei entpacktem Kernel mit "scripts/extract_ikconfig" aus den Kernel-Sourcen funktionieren) und dann noch einmal den oben stehenden Vergleich starten - ich erwarte zwar keine gravierenden Unterschiede, aber man weiß ja nie ...

 

[er13]

Das "=n" von AVM ist als "=m" von vanilla zu verstehen (und nicht als "# CONFIG_XY is not set"). Warum AVM "=n" verwendet kann ich nicht sagen. Eventuell verwenden sie irgendein altes oder irgendein eigenes Tool zum Konfigurieren des Kernels. Oder es ist sogar ein Fehler in deren Routine, die deren Open-Source-Pakete bastelt. Diese sind ja auch an einigen anderen Stellen unplausibel/komisch - Namen der Tarballs spiegeln nicht unbedingt den Inhalt wider, busybox-Tarball enthält z.B. gar keine busybox, usw.

Edit: das mit "=n" haben sie übrigens nicht von Anfang an gemacht, die "alten" .config's (die für 04.XX) enthalten noch "=m", ab 05.XX sind diese zu "=n" geworden.

 

[PeterPawn]

Ich habe schon durchaus auch eine Idee/Vermutung, was sich AVM dabei gedacht hat ... die Makefiles arbeiten ja häufig mit der Konstruktion:

obj-$(CONFIG_SOMEWHAT)     += somewhat.o

konkret z.B.:
obj-$(CONFIG_LTQ_PPA_DATAPATH)      += ltqmips_ppe_drv.o

für das Zusammenstellen von Listen-Variablen.

Damit werden also die ganzen von AVM als Module "angedachten" Dateien nicht in der Variablen "obj-m", sondern in "obj-n" gesammelt (im Code meist über Präprozessor-"#ifdef" abgefragt und da ist es egal, ob das "y", "m" oder "n" ist) und beim Linken bzw. beim Build für die Module damit nicht berücksichtigt, weil dort natürlich "obj-m" oder "obj-y" verwendet wird.

Damit dürfte man also das Problem "fehlender" Module (bzw. fehlender Quellen dafür) umgehen ... aber die Tatsache, daß das nirgendwo dokumentiert ist und man sich das alles selbst zusammensuchen und -reimen muß, führt natürlich die Forderung aus der GPLv2 trotzdem ad absurdum; ebenso der seit der Veröffentlichung der 06.54 vergangene Zeitraum, in dem die AVM-OpenSource-Pakete für diese Version nun schon fehlen. Inzwischen fehlen mittendrin ja auch die 06.80 und 06.81 - auch für die 7580 wird sicherlich die 06.83 nicht mehr lange auf sich warten lassen; die anderen Modelle sind ja inzwischen "versorgt".

So bleiben selbst beim Ausblenden dieser Unterschiede noch Differenzen übrig, die teilweise zwar tatsächlich dem Unterschied 06.53 (bei den Sourcen) und 06.54 (beim Kernel) zuzurechnen sind (das ist auch die Richtung für das folgende "diff"-Kommando):

# diff -u .config /tmp/.config | grep -v "^+.*=m\$" | grep -v "^-.*=n\$" | grep -v "^ " | grep -v "^@" | grep -v "^+++" | grep -v "^---"
-CONFIG_SPLIT_PTLOCK_CPUS=999999
+CONFIG_SPLIT_PTLOCK_CPUS=4
-CONFIG_UNINLINE_SPIN_UNLOCK=y
+CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+CONFIG_INLINE_READ_UNLOCK=y
+CONFIG_INLINE_READ_UNLOCK_IRQ=y
+CONFIG_INLINE_WRITE_UNLOCK=y
+CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
-# CONFIG_AVM_IPI_YIELD is not set
+CONFIG_AVM_IPI_YIELD=y
+CONFIG_AVM_IPI_YIELD_DEBUG=y
+CONFIG_AVM_BRIDGE_FLOOD_RATELIMITER=y
-# CONFIG_LTQ_ETH_OAM is not set
-# CONFIG_USB_NET_CDC_NCM is not set
-CONFIG_LTQ_PPA_API=y
-CONFIG_LTQ_PPA_DATAPATH=y
+CONFIG_TFFS_DEV_CACHE_ENV_ONLY=y
-CONFIG_SCHED_DEBUG=y
+# CONFIG_SCHED_DEBUG is not set
-CONFIG_DEBUG_SPINLOCK=y
+# CONFIG_DEBUG_SPINLOCK is not set

, aber das macht es ja nicht besser, wie AVM hier (wieder einmal) die OpenSource-Pakete behandelt. Mein Fehler war allerdings, daß ich vor dem ersten "diff" weiter oben nicht die tatsächliche Version des OSS-Paketes verifiziert hatte und damit 06.53 mit 06.54 (also Äpfel mit Pferdeäpfeln) verglichen habe.

Wobei es sich beim "BRIDGE_FLOOD_RATELIMITER" und bei "TFFS_DEV_CACHE_ENV_ONLY" wohl um bei der 06.54 erst neu eingeführte Parameter handelt, denn in der 06.53 sind sie ja nicht als "is not set" enthalten - der Unterschied bei "LTQ_PPA_API" und "LTQ_PPA_DATAPATH" dürfte sich aber direkt auf die Struktur des Kernels auswirken (hier ist "y" vs. "m" und das müßte sich beim Linken des Kernels eigentlich bemerkbar machen) und ich bin tatsächlich mal gespannt, ob die 06.53-Sourcen da mit dem 06.53-Kernel übereinstimmen werden.

Die unterschiedlichen "DEBUG"-Einstellungen kann man sicherlich ohnehin in den Skat drücken (für die Funktion oder das Versagen einzelner Feature jedenfalls), bei "CONFIG_USB_NET_CDC_NCM" dürfte das aber schon den Unterschied machen, ob einige Sticks (die nur mit NCM funktionieren) an der Box nach wie vor (in demselben Umfang wie bei der 06.54 von AVM) arbeiten oder nicht.

 

[er13]

Damit dürfte man also das Problem "fehlender" Module (bzw. fehlender Quellen dafür) umgehen

Ja, ist durchaus denkbar, klingt zumindest sehr plausibel.

... aber die Tatsache, daß das nirgendwo dokumentiert ist und man sich das alles selbst zusammensuchen und -reimen muß, führt natürlich die Forderung aus der GPLv2 trotzdem ad absurdum; ebenso der seit der Veröffentlichung der 06.54 vergangene Zeitraum, in dem die AVM-OpenSource-Pakete für diese Version nun schon fehlen.

Ja, das "GPL-Einhalten" ist leider überhaupt keine Stärke von AVM. Es ist sogar eine Dreistigkeit, was sie sich da so alles erlauben: für manche Boxen wurden bisher gar keine Quellen veröffentlicht für keine Firmware-Version (nur als Beispiel sei die 7412 genannt, die echte Liste ist viel länger), für manche Boxtyp/Firmware-Kombinationen wurde auch Jahre nach dem Release keine Quellen veröffentlicht (wieder nur als Beispiel seien AR10-Boxen und Fritz!OS 6.0X genannt). Wenn was veröffentlicht wird, konnte schon mehrfach nachgewiesen werden, dass das Veröffentlichte nicht dem tatsächlich Verwendeten entspricht (wieder nur als Beispiel, seien AR10-Boxen und Fritz!OS-5.5X genannt, s. hier). BuildRoot-Konfigurationen entweder fehlen gänzlich (ältere Pakete) oder sind nicht richtig, sodass die uClibc-Konfiguration daraus abgeleitet werden muss, welche Symbole es in der binären Version gibt. Den Quellcode für SquashFS-Tools habe ich ebenso noch nie in deren Paketen gesehen, usw. usw. usw.


Leider haben wie es auch nie geschafft, uns die Zeit zu nehmen, zu überlegen, wie wir AVM gegenüber auftreten könnten, damit sich die Situation bessert.

 

[chilango79]

Na am besten wenn Heise am Montag über die neue Fritzbox auf der Cebit berichtet da die Kommentarfunktion exesiv nutzen. Oder wir streuen das Gerücht das der Verfassungsschutz aus AVM verbietet die Sourcen korrekt zu veröffentlichen.

 

[PeterPawn]

@opto:
Ich werde trotzdem dabei bleiben, den Finger eher "öffentlich" in diese Wunde zu legen, zumal ich bei anderen Anfragen (nicht immer unter eigenem Namen, weil es eben auch mal "Verstimmungen" gibt und die Daten ohnehin eher für Kunden gebraucht wurden, weil mein "Arsenal" an Boxen recht übersichtlich ist, was die eigenen Modelle angeht) ähnliche Erfahrungen wie Du machen mußte.

Daher kritisiere ich im Normalfall (die Feststellung zur 153.06.54 war da eher ein Ausreißer, weil mich die 7580 bisher nicht tangierte und für die 7490 - auf der ansonsten meine Recherchen in den OSS-Paketen basieren - kamen die Pakete immer recht zeitnah) nicht den Zeitpunkt der Bereitstellung von OpenSource-Paketen, sondern deren Umfang und Inhalt - wobei ich diese Anfragen zur Bereitstellung inzwischen tatsächlich weitgehend anderen überlasse.

Das "notwendige Nacharbeiten" (u.a. beim "avm_kernel_config_area", was ja hier mal der Aufhänger für diesen Thread war) ist aber eben absolut nicht im Sinne der GPL und meine letzte Anfrage in dieser Richtung nach dem passenden, vollständigen Quell-Code stammte vom 19.05.2016 (kriegte damals die Ticket-ID 433246) - diese wurde dann am 15.06.2016 mit dem Hinweis, daß ich die Quellen unter dem bekannten Link abrufen könne, auch "erledigt"; dabei hatte sich am Umfang der Quellen aber bekanntermaßen nichts wirklich Relevantes geändert.

Allerdings gibt es praktisch keine "Entschuldigung" dafür, wenn AVM die Quellen für neu veröffentlichte Updates erst mit einer erheblichen Verzögerung "nachreicht" - wie es hier ja dann wohl für die 7390 geschieht, wenn Du dahingehend nachgefragt hast. Die Dateien müssen ja zum Zeitpunkt des Erstellens der Firmware bereits existiert haben und dann sind es mittlerweile fast 6 Wochen, seitdem die 84.06.80 erschienen ist - das ist vermutlich im Beamtenleben noch als "unmittelbare Reaktion" zu bewerten, im "real life" wohl eher nicht.

Da überholt dann mit einiger Wahrscheinlichkeit die nächste Firmware-Version (sollte es die 06.83 auch für die 7390 geben) die Veröffentlichung der Quellen für die 06.80 - wobei das an dieser Stelle AVM gar nicht der Notwendigkeit enthebt, die Quellen auch für die "outdated version" 06.80 bereitzustellen, nachdem man diese in Umlauf gebracht hat. Man könnte höchstens noch erklären, daß die Quellen sich nicht unterscheiden ... was angesichts der fehlenden "_avm_kernel_version_info" in den Quellen sogar stimmen könnte.

 

[PeterPawn]

So, ich habe mir den Kernel der 7580 mal etwas genauer angesehen ... der hat am Beginn irgendwie drei zusätzliche (Assembler-)Instruktionen:

00000000  [COLOR="#FF0000"]12 91 ed fe a8 30 3f 00  00 00 50 80[/COLOR] 81 12 ed fe  |.....0?...P.....|
00000010  85 de 2d 00 00 00 50 80  01 02 5a 07 6d de 2d 00  |..-...P...Z.m.-.|

(ich habe gerade keinen MIPS-Disassembler zur Hand, um deren Inhalt zu verstehen, aber das dritte 32-Bit-Wort ist die Ladeadresse des Kernels, sprich: das Ziel für das Entpacken, was aber 12 Byte weiter noch einmal steht) ... aber danach kommt dann offenbar doch wieder ein "normales" LZMA-komprimiertes Image, auch wenn die ".config" aus dem OSS-Paket für die 153.06.53 uns etwas anderes suggerieren will (und ich habe extra eine "frisch ausgepackte" Datei verwendet):

# grep CONFIG_KERNEL .config
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set

Hier habe ich natürlich diesmal zuerst auch noch anhand der 06.53-Firmware geprüft, daß AVM da nicht wirklich die Kompression gewechselt hat - auch die 06.53 hat einen LZMA-komprimierten Kernel.

Damit ist das dann auch wieder relativ leicht zu entpacken ... man muß nur auf die Offsets halt immer diese drei zusätzlichen 32-Bit-Worte aufaddieren. Um das etwas flexibler zu gestalten, habe ich das "unpack_kernel.sh" aus dem "avm_kernel_config"-Verzeichnis so angepaßt, daß vom ursprünglichen Offset in 32-Bit-Schritten (zusätzliche MIPS-Instruktionen sollten hier immer 32-Bit groß sein) nach dem Base64-Äquivalent des erwarteten LZMA-Headers (0x5d00008000) gesucht wird und dann die Verschiebung des Headers auf alle Offsets beim Lesen aufaddiert wird. Findet sich dabei kein Header mit dem erwarteten Inhalt innerhalb der nächsten 128 Byte, bleiben die Offsets unverändert und das Entpacken wird trotzdem versucht.

Damit klappt dann auch das Entpacken des Kernels für die 7580 (und auch die 7560) und das sogar so weit, daß das verwendete "lzma -d" sich nicht über ein vorzeitiges Ende der Daten beschwert.

Das Ergebnis sieht dann auch wieder gut aus (auf einmal stehen da wieder lesbare Zeichenketten im entpackten Kernel) und auch der AVM-Konfigurationsbereich existiert tatsächlich.

Da der Kernel an die Adresse 0x80500000 entpackt wird, muß man aber einigermaßen hin und her rechnen, wenn man die tatsächlich verwendeten Offsets finden will. Jedenfalls fehlt der Name für den Start des Bereiches (__avm_kernel_config_start) wohl auch bei den exportierten Symbolen, denn in der "kallsyms" taucht er nicht auf. Dort findet sich nur "__avm_kernel_config_end", was bei der 06.54 den Wert 0x80E58000 hat - damit ist der Beginn (ausgehend von den 96 * 1024 Byte, die da in der vmlinux.lds.S bei der 7580 zu finden sind) wohl bei 0x80E40000 zu suchen, was dann in der entpackten Kernel-Datei dem Offset 0x00940000 entspricht.

Und siehe da, an dieser Stelle finden sich dann durchaus bekannte Strukturen:

00940000  80 e4 00 04 00 00 00 01  80 e4 fc fc 00 00 00 02  |................|
00940010  80 e4 fc 3c 00 00 00 05  80 e4 a7 70 00 00 00 06  |...<.......p....|
00940020  80 e4 52 a4 00 00 01 04  80 e4 00 34 00 00 01 06  |..R........4....|
00940030  00 00 00 00 d0 0d fe ed  00 00 52 6d 00 00 00 38  |..........Rm...8|
00940040  00 00 4b 90 00 00 00 28  00 00 00 11 00 00 00 10  |..K....(........|
00940050  00 00 00 00 00 00 06 dd  00 00 4b 58 00 00 00 00  |..........KX....|
00940060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
00940070  00 00 00 00 00 00 00 03  00 00 00 04 00 00 00 00  |................|
00940080  00 00 00 01 00 00 00 03  00 00 00 04 00 00 00 0f  |................|
00940090  00 00 00 01 00 00 00 03  00 00 00 1c 00 00 00 1b  |................|
009400a0  6c 61 6e 74 69 71 2c 67  72 78 35 30 30 00 6c 61  |lantiq,grx500.la|
009400b0  6e 74 69 71 2c 78 72 78  35 30 30 00 00 00 00 03  |ntiq,xrx500.....|
009400c0  00 00 00 23 00 00 00 26  45 41 53 59 33 35 30 20  |...#...&EASY350 |
009400d0  41 4e 59 57 41 4e 20 28  47 52 58 33 35 30 29 20  |ANYWAN (GRX350) |
009400e0  4d 61 69 6e 20 6d 6f 64  65 6c 00 00 00 00 00 01  |Main model......|

Wie sich diese jetzt genau aufteilen und was da beim AVM-Kernel alles in diesem Bereich enthalten ist, ist aber ein Thema, was ich erst heute nachmittag weiter untersuchen werde.

@er13:
Ob Du das nun so ähnlich in der Freetz-Version nachziehst oder mein Skript zum Entpacken nimmst, bleibt Deine Entscheidung - aber das Entpacken des Kernels sollte damit abgehakt sein. Den Versuch, ob das "extract_ikconfig" aus den Kernel-Quellen im entpackten Kernel jetzt die komprimierte ".config" findet oder nicht, habe ich noch nicht unternommen.

 

[er13]

00000000  [B][COLOR=#008000]12 91 ed fe[/COLOR][/B] [COLOR=#ffa500]a8 30 3f 00[/COLOR][COLOR=#FF0000]  00 00 50 80[/COLOR] [B][COLOR=#008000]81 12 ed fe[/COLOR][/B]  |.....0?...P.....|
00000010  [COLOR=#ffa500]85 de 2d 00[/COLOR] [COLOR=#ff0000]00 00 50 80[/COLOR]  01 02 5a 07 6d de 2d 00  |..-...P...Z.m.-.|

der hat am Beginn irgendwie drei zusätzliche (Assembler-)Instruktionen:
(ich habe gerade keinen MIPS-Disassembler zur Hand, um deren Inhalt zu verstehen, aber das dritte 32-Bit-Wort ist die Ladeadresse des Kernels, sprich: das Ziel für das Entpacken, was aber 12 Byte weiter noch einmal steht)

Ich denke nicht, dass es irgendein Code ist. Das sieht stark nach einer Datenstruktur aus, bestehend aus

1. einem Magic (LE-32-Bit-Wort) 0xFEED9112 (sieht verdammt ähnlich dem TI-AR7-Magic, der in EVA verwendet wird: 0xFEED1281)
2. einem noch unbekannten Feld (LE?-32-Bit-Wort), vermutlich irgendeinde Länge
3. der LoadAddr (LE-32-Bit-Wort), wie Du schon selber festgestellt hast, diese steht 2 Mal da

Edit: vermutlich ist die Suche within 128 bytes nicht wirklich notwendig, man kann auf feste Offsets gehen, es wird bei 12 extra Bytes bleiben, man muss nur deren Bedeutung verstehen. Daraus resultiert übrigens eine weitere Aufgabe für Replace-Kernel: man muss lzma2eva all das beibringen bzw. diese 12 Bytes dem Output von lzma2eva hinzufügen.

Edit2: das 2.te Feld ist eindeutig ein Längenfeld. EntryAddr (0x8050E100 bei 7580_06.53) ist in der Datei 2 Mal zu finden:
1. 1stHeaderOffset(0) + LängenFeldAus1stHeader(4141224) + 20 = 4141244
2. 2ndHeaderOffset(12) + LängenFeldAus2ndHeader(3006085) + 20 = 3006117
Und da 3006117 nun mal deutlich kleiner ist als die Größe der gesamten Datei schlussfolgere ich daraus, dass kernel.image bei 7580 nicht nur den Kernel enthält, sondern hinten noch fast 1MB irgendwelcher anderer Daten. Die Größe von lzmaCompressedLen(3006061) bestätigt es.

Edit3: Vermutung - binäre Firmware irgendeiner verbauten Hardware-Komponente

 

[PeterPawn]

Mir auch recht ... vielleicht erklärt das auch irgendwie die doppelte TI-Prüfsumme (zumindest deren Magic) am Ende des Kernels - ggf. läßt sich mit dieser Prüfsumme der Inhalt aufsplitten, wenn man den Teil findet, für den der "innere" CRC32-Wert paßt. Der "äußere" gehört zum gesamten "kernel.image", das habe ich schon letztens geprüft, als ich das erste Mal diese zwei Magics angesprochen habe.

Bei mir lasse ich es aber trotzdem bei der Suche nach dem (ersten) LZMA-Header ... wer weiß, wann der nächste Kernel mit anderen Offsets auftaucht.

Auf alle Fälle sollte die Größe des entpackten Images an Offset 32 mit dem Wert 0x9a1080 (10..096.768) in etwa stimmen und - wie gesagt - "lzma" beschwert sich auch nicht, was meist ein gutes Zeichen dafür ist, daß der komprimierte Payload auch "abgeschlossen" ist.

Schaut man dann hinter den ersten Teil nach Deiner Vermutung, landet man bei Offset 0x2dde9d (Länge des ersten komprimierten Payloads (0x2dde6d) + 0x30 als Start des Payloads) und da kommen dann (um die "krumme Verschiebung" bereinigt) drei 32-Bit-Worte:

42 8f a9 68   00 00 00 00   00 e1 50 80

Das wäre dann ggf. im dritten noch einmal die Entry-Adresse ... und danach kommt dann (vermutlich mit Alignment) tatsächlich noch ein weiterer LZMA-Header (bei 0x2ddec8). Geht man von diesem wieder die bekannten 28 Byte (0x1c) zurück, landet man an 0x2ddeac und das sieht dann tatsächlich nach einem weiteren "image header" aus:

002ddea0  68 00 00 00 00 00 e1 50  80 00 00 00 [COLOR="#FF0000"]07 b0 ed fe[/COLOR]  |h......P........|
002ddeb0  [COLOR="#008000"]c3 51 11 00[/COLOR] 90 70 f6 8d  01 02 5a 07 [COLOR="#DDA0DD"]ab 51 11 00[/COLOR]  |.Q...p....Z..Q..|
002ddec0  [COLOR="#FF8C00"]14 ab 24 00[/COLOR] d9 0f ec c8  [COLOR="#0000FF"]5d 00 00 80 00[/COLOR] 00 00 00  |..$.....].......|
002dded0  00 00 02 af c7 74 e7 5f  05 50 97 d4 34 07 81 6f  |.....t._.P..4..o|

Die dort stehenden Daten wären dann 0x1151ab (1.135.019) Byte komprimiert und sollten beim Entpacken 0x24ab14 Byte (2.403.092) ergeben - und genau das machen sie auch. Schaut man dann dort hinein, ist das am Ende ein weiterer Linux-Kernel ... dabei fällt mir dann wieder auf und ein, daß es in den 7580-Quellen zwei verschiedene Setups für den Kernel gibt: grx500 und grx500_bootcore.

Jetzt wäre natürlich mal eine Entwicklerdokumentation für den GRX500 spannend ... durchaus denkbar, daß da irgendetwas im Hintergrund - quasi als Hypervisor - werkelt und schon hier die ersten Ansätze der ja mal angedachten Virtualisierung auch auf solchen Embedded-Devices existieren, mit denen die verschiedenen Funktionen voneinander abgeschottet werden könnten. Das wäre jedenfalls die erste Erklärung, die mir spontan für diesen "doppelten Kernel" einfallen würde ... ob da wirklich etwas dran sein könnte, muß man aber erst mal in aller Ruhe und Gründlichkeit anhand der sichtbaren Bestandteile (in erster Linie der Zeichenketten in den entpackten Versionen) und der Kernel-Quellen (insb. des Unterschieds zwischen "bootcore" und "nicht bootcore") untersuchen.

---

-Wie auch immer ... ich habe die Geschichte mit dem "avm_kernel_config" angepaßt an die Möglichkeit, daß es eine abweichende Größe des Bereiches geben könnte ... wobei das nur beim "extract_kernel_config_area" von Interesse war. Bei der Generierung des Assembler-Files spielt die Größe des Bereiches ja nicht wirklich eine Rolle, da wird halt das ausgegeben, was in der Eingabedatei steht - jedenfalls jetzt, denn zuvor gab es dort nur einen DTB und nicht mehrere. Das habe ich aber geändert und jetzt werden auch mehrere dieser DT-BLOBs sauber erzeugt, wenn mehrere in der Eingabedatei stehen.

Die korrekte Größe des Konfigurationsbereichs braucht man also nur beim Auslesen aus dem entpackten Kernel (extract_...) und beim Patchen des Linker-Files für den Kernel. Mir fällt spontan keine andere Möglichkeit ein, als das aus den AVM-Quellen zu extrahieren (aus der vmlinux.lds.S) und dann genauso auch wieder zu patchen. Zumindest dann, wenn man dieselbe Größe wie AVM verwenden will (oder muß) ... ich weiß aber nicht, ob die wirklich bei AVM statisch hinterlegt ist oder einfach (nach Alignment für den Konfigurationsbereich auf die nächste 32 KB-Grenze) anhand des Symbols für __avm_kernel_config_end ermittelt wird.

Irgendwelche Skript-Dateien für das Ermitteln dieser Größe und für das Patchen der "vmlinux.lds.S" (da funktionieren ja auch die Ankerzeilen für einen Patch nicht mehr, wenn da andere Zahlen stehen) fehlen noch in meinem Repository - das sollte aber für Freetz keine entscheidende Rolle spielen und die anderen Änderungen sollten erst einmal hinreichend sein, damit man auch einen Konfigurationsbereich für die 7580 und 7560 erzeugen kann.

---

-Wie man die Geschichte mit den zwei Kernel-Images nun managen will, muß man sich auch in Ruhe überlegen ... ggf. reicht es für das "replace kernel" im Freetz ja bereits, wenn man nur das erste Image austauscht (das zweite halte ich für die "bootcore"-Inkarnation, aber das muß nicht stimmen) und das zweite einfach beläßt.

Ach so ... die zweite TI-Prüfsumme am Ende (also die "innere", somit eigentlich die erste - jedenfalls die, welche bei der 06.54 den Wert 0x090b48a7 hat) stimmt dann auch wieder für das zweite Image ... von 0x2ddeac aus in der Länge 0x115200 berechnet.

- - - Aktualisiert - - -

Ich kannte die von Dir im letzten Freetz-CS verlinkte WHMF-Seite mit den Strukturen beim LZMA-Kernel in der EVA noch gar nicht (bei so einem Wiki ist eben sequentielles Lesen eher schlecht möglich) ... damit kann man ja - bei Kenntnis des Inhalts der Prüfsummen-Felder - sowohl die Daten verifizieren als auch das Entpacken des zweiten Kerns automatisieren, wenn die dort gezeigten Strukturen auch bei der 7580 verwendet werden für das "Verschachteln" zweier Kernel-Images.

 

[er13]

Ich kannte die von Dir im letzten Freetz-CS verlinkte WHMF-Seite mit den Strukturen beim LZMA-Kernel in der EVA noch gar nicht ... damit kann man ja - bei Kenntnis des Inhalts der Prüfsummen-Felder - sowohl die Daten verifizieren als auch das Entpacken des zweiten Kerns automatisieren, wenn die dort gezeigten Strukturen auch bei der 7580 verwendet werden für das "Verschachteln" zweier Kernel-Images.

Umgesetzt in r14181.
Denkbare Weiterentwicklungen wären:
1. Prüfung der Checksummen
2. Split-Modus (um z.B. nur eines der Kernels austauschen zu können/müssen)


Deine heutigen "avm_kernel_config"-Commits habe ich gelesen. Muss mir überlegen, wie ich das einbaue. Bisher wurde in Freetz Deine gestripte avm_kernel_config.h verwendet und gar nicht die aus dem Kernel-Baum. Auch die Binaries wurden nicht speziell für jedes FREETZ_KERNEL_LAYOUT bzw. FREETZ_AVM_SOURCE_BOXID_XX_YY kompiliert, wie es nun der jetzige Aufbau quasi verlangt. Muss vermutlich Deine avm_kernel_config-Sources in den Kernel-Baum kopieren und dort FREETZ_AVM_SOURCE_BOXID_XX_YY spezifisch übersetzen.

 

[PeterPawn]

Ich habe gesehen, daß Du Freetz an den Stand aus dem YourFritz-Repo angepaßt hast ... allerdings hatte ich wohl den einen Patch (zum Ändern der vmlinux.lds.S) herausgenommen, weil der unter die weiter oben angetexteten "fehlenden Skript-Files" fallen sollte, denn als Patch-File funktioniert das ja bei abweichender Größenangabe nicht richtig.

Das hat nun aber vermutlich direkte Auswirkungen auch für die 7490 (bzw. alle VR9-Modelle) beim "replace kernel" ... jetzt fehlt dort wohl der Patch und der Bereich wird beim Linken nicht eingebunden. Ich hatte nicht damit gerechnet, daß Du das so schnell nachziehst ... wir/Du/ich müssen nun irgendeine funktionierende Lösung finden (ich kann den Patch auch wieder reinnehmen, dann schlägt der eben bei der 7580 einfach fehl), sonst fällt der nächste Tester beim "replace kernel" auf die Nase und Du hast unnötige Tickets im Trac.

Das Übersetzen mit den jeweils aktuellen Kernel-Files kann man leider nicht verhindern oder sinnvoll umgehen ... die Definitionen der Tags (in avm_kernel_config_tags_irgendwas) sind unterschiedlich (halt "enum"s mit unterschiedlich vielen Werten) und selbst wenn man hier jetzt die bekannten zwei Varianten beim "relocate..." testen könnte, kann ja AVM jederzeit mit einer weiteren Variante um die Ecke kommen.

Die Änderung im Makefile und dem einen Include-File auf den Symlink mit dem Namen "linux" (der auf die Basis der Kernel-Quellen zeigen soll) für die Suche nach der "libfdt" und der "avm_kernel_config.h", hast Du ja sicherlich gesehen ... das müßte ja halbwegs zum Freetz passen, notfalls mußt Du eben das Makefile patchen.

Ich bin dann aber an der Stelle ins Grübeln (und die anschließende Recherche, die ich aber nicht konzentriert durchgehalten habe) verfallen, wo es um den korrekten Pfad zum Loader-Skript ging, wenn da auf einmal die Prozessor-Architektur in den Namen hineinspielen könnte.

Die Quellen der 6490 wollte ich mir an dieser Stelle nicht antun, denn die basiert ja noch auf einem 2er-Kernel ... und bei den anderen Kandidaten (mit ARM-Architektur) wie der 4020 und der 4040 war ich dann erst einmal auf der Suche, ob die überhaupt eine avm_kernel_config verwenden, denn bei mindestens einem dieser Modelle bilde ich mir ein, da eine Sonderregelung (für irgendwelche "QCA"-Definitionen) in den Kernel-Quellen gesehen zu haben - leider weiß ich nicht mehr, wo das war und dann bin ich bei der Recherche wieder vom Thema abgekommen und habe ganz andere interessante Sachen gefunden.

Jedenfalls fehlt da auch noch der komplette Teil mit dem Extrahieren der Größe des avm_kernel_config-Bereichs und dem anschließenden Ändern des Linker-Skripts ... wobei das bisher auch nur für MIPS-Prozessoren funktionierte (da war ja der Pfad im Patch-File hinterlegt) und man ggf. auch die anderen Architekturen erst einmal noch in den Skat drücken könnte (ich wollte nur eine Lösung, die nicht bei der nächsten Architektur dann wieder angefaßt werden muß) ... aber die Frage, ob da nun "64 * 1024" steht oder "96 * 1024", muß man trotzdem anders klären oder das Patch-File dynamisch generieren (besser ist aber sicherlich "sed" o.ä. anstelle von "patch" bei dieser Problemstellung).

 

[PeterPawn]

Der andere Aufbau der 7580 führt offenbar auch zu einem anderen "Timing" beim Start der Box.

Da, wo die VR9-Modelle direkt nach Power-On die GPIO-Ports initialisieren (ich rechne das "Aufblinken" aller LEDs diesem Vorgang zu) und anschließend mit den 5 Sekunden (oder sind es doch eher 10?) Empfängnisbereitschaft im Bootloader beginnen, braucht die 7580 schon erst einmal 5-7 Sekunden (das stoppt sich schlecht), bis die an diesem Punkt (GPIO-Initialisierung) überhaupt ankommt. Jedenfalls startet sie erst einmal mit dauerleuchtender Power-LED und nach dieser Zeit (nehmen wir mal das Mittel meiner Versuche, das wären sechs Sekunden) kommt dann das bekannte Aufblinken aller LEDs und der Bootloader reagiert wohl auch erst dann auf die UDP-Broadcasts. Wie sich die Ethernet-Ports bei der Initialisierung verhalten, habe ich vergessen zu beobachten, auch ab wann ARP-Requests beantwortet werden. Aber damit beginnen diese "kritischen fünf Sekunden" (falls jemand den FTP-Client von Hand verbinden will) hier deutlich später (und auch das sind handgestoppt eher zehn Sekunden, 5x Blinken der Power-LED mit 0,5 Hz) - nur falls jemand sein Freetz-Image (wenn er den Kernel beibehält, könnte er ja schon eines erstellen) über den Bootloader installieren lassen will (die Box arbeitet wieder mit dem Laden in den Speicher und schreibt dann das System aus dem RAM in die NAND-Partitionen).

Wegen des ausschließlich eingesetzten NAND-Flashs gibt es wohl auch zwei verschiedene Bootloader-Versionen in der "urlader"-Partition ... jedenfalls existieren dort Zeichenketten, die die Vermutung unterstützen, daß nur bei zwei funktionsfähigen Bootloadern (deren Zeichenketten auch tatsächlich doppelt vorkommen) ein Update eines der beiden gestattet wird. Ist einer defekt, wird wohl ein entsprechender Request über den FTP-Server abgelehnt, wobei es auch sein kann, daß das nur in der Seriellen sichtbar wird (ohne genauere Kenntnis des GRX500 und der Vorgänge beim Start werde ich das auch nicht probieren).

 

[stulle]

Ich habe am 20.03. ebenfalls AVM geschrieben, wann sie die aktuellen opensource-Files für die 7390 denn nun endlich veröffentlichen, selbst die für 06.69 habe ich angefragt. Sie haben mir sofort ein Tiket gegeben und um Geduld gebeten.
Bitte nicht über meinen ersten Beitrag wundern, bin seit 10 Jahren treuer Leser und Freetz-Benutzer über mehrere Boxengenerationen. Das wollte ich nur loswerden.

stulle

 

[er13]

Ich habe gesehen, daß Du Freetz an den Stand aus dem YourFritz-Repo angepaßt hast ...


Das hat nun aber vermutlich direkte Auswirkungen auch für die 7490 (bzw. alle VR9-Modelle) beim "replace kernel" ... jetzt fehlt dort wohl der Patch und der Bereich wird beim Linken nicht eingebunden. Ich hatte nicht damit gerechnet, daß Du das so schnell nachziehst ...

Du hast vermutlich übersehen, dass ich nicht auf die allerletzte Version, sondern auf die Version "vor den avm_kernel_config_area-Änderungen" aktualisiert habe. D.h. es funktioniert weiterhin für VR9-Boxen und funktioniert weiterhin NICHT für GRX5-Boxen.

wir/Du/ich müssen nun irgendeine funktionierende Lösung finden (ich kann den Patch auch wieder reinnehmen, dann schlägt der eben bei der 7580 einfach fehl)

Ich lese mich in Deinen avm_kernel_config_area-Code ein und versuche mal was vorzuschlagen. Mir wäre immer noch "(extract|gen).avm_kernel_config ist ein Tool unter tools (und nicht irgendwo unter Kernel-Quellen), welches für alle Boxen funktioniert, ggf. per Übergabe notwendiger Parameter" lieber.


Ich weiß nicht, ob es Dir aufgefallen ist, aber aktuell wird nicht mal libfdt aus den AVM-Kernel-Quellen verwendet, sondern das letzte Release davon (mit einigen cherry-picked Fixes) von github.

Edit: Ist diese Zeile aus 1f293608fa übrigens richtig? Diese Zeile lässt vermuten, eher nicht. Sollte die Schleife nicht bei avm_kernel_config_tags_device_tree_subrev_0 starten und in der zweiten Zeile es nicht i - avm_kernel_config_tags_device_tree_subrev_0 heißen?

Edit2:
Vorschlag1:
An einigen Stellen findet sich folgender Code

  while (entry->tag <= avm_kernel_config_tags_last)
  {
    if (entry->config == NULL) return bzw. break;
    ...
  }

Der Code liest sich so, als wäre entry->config == NULL ein allgemeingültiger Marker fürs Ende der Struktur, i.e. der Code wie folgt umgeschrieben werden könnte:

  while (entry->config != NULL)
  {
    ...
  }

Damit wäre man der Abhängigkeit an avm_kernel_config_tags_last los.