[Gelöst] FW 6.50 für 7490 in Trunk rev. 13490 - keine Auswahlmöglichkeit
- Ersteller JohnDoe42
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Auch wenn das primär nichts mit dem nicht-startenden Kernel zu tun hat, plagt mich immer noch die Frage, warum die printk-Ausgaben nicht sichtbar sind.
Über die avm_debug.c bin ich dann in der kernel/printk.c gelandet und dort wird tatsächlich die Funktion vprintk_emit() in weiten Teilen so geändert, daß Nachrichten ohne spezielle Flags (hier FORCE_PRINTK_LINUX_FACILITIES_VALUE) über /dev/debug ausgegeben werden, solange das entsprechend eingestellt ist (über printk_avm_console_bend(1)). Zwar startet das System nach meiner Ansicht mit printk_avm_console_bend(0), aber das Verfolgen, ob und wann das bereits vor dem init_avm_kernel_config() umgeschaltet wird, ist etwas mühsam. Die Idee wäre daher, das vprintk_emit() in der kernel/printk.c so zu patchen, daß die Ausgabe in jedem Falle über die Konsole geht.
Auf der anderen Seite bilde ich mir ein, irgendwo in Freetz auch mal etwas davon gesehen zu haben, daß da auf AVM_PRINTK umgeschaltet wurde und dann etwas aus /dev/debug gelesen wurde. Das würde dann nicht mehr funktionieren, aber für die weitere Suche, was da im Moment mit "replace kernel" nicht funktionieren will, wäre es m.E. trotzdem hilfreich (und könnte später ja auch wieder deaktiviert werden).
Da die Übergabe von facility an vprintk_emit() "by value" ist, schadet es m.E. auch nicht, wenn man den Wert einfach direkt beim Betreten der Funktion entsprechend abändert. Einen dafür denkbaren Patch habe ich in meinem Fork von Freetz in GitHub mal eingecheckt ... einfach die "raw"-Datei laden und unter make/linux/patches/3.10.73/171-printk_to_console.patch ablegen - dann den Kernel neu bauen.
Der Patch ist nur auf "Übersetzung funktioniert" getestet, sein Ergebnis kann ich wieder (mangels Bestückung der seriellen Schnittstelle) nicht selbst überprüfen.
Über die avm_debug.c bin ich dann in der kernel/printk.c gelandet und dort wird tatsächlich die Funktion vprintk_emit() in weiten Teilen so geändert, daß Nachrichten ohne spezielle Flags (hier FORCE_PRINTK_LINUX_FACILITIES_VALUE) über /dev/debug ausgegeben werden, solange das entsprechend eingestellt ist (über printk_avm_console_bend(1)). Zwar startet das System nach meiner Ansicht mit printk_avm_console_bend(0), aber das Verfolgen, ob und wann das bereits vor dem init_avm_kernel_config() umgeschaltet wird, ist etwas mühsam. Die Idee wäre daher, das vprintk_emit() in der kernel/printk.c so zu patchen, daß die Ausgabe in jedem Falle über die Konsole geht.
Auf der anderen Seite bilde ich mir ein, irgendwo in Freetz auch mal etwas davon gesehen zu haben, daß da auf AVM_PRINTK umgeschaltet wurde und dann etwas aus /dev/debug gelesen wurde. Das würde dann nicht mehr funktionieren, aber für die weitere Suche, was da im Moment mit "replace kernel" nicht funktionieren will, wäre es m.E. trotzdem hilfreich (und könnte später ja auch wieder deaktiviert werden).
Da die Übergabe von facility an vprintk_emit() "by value" ist, schadet es m.E. auch nicht, wenn man den Wert einfach direkt beim Betreten der Funktion entsprechend abändert. Einen dafür denkbaren Patch habe ich in meinem Fork von Freetz in GitHub mal eingecheckt ... einfach die "raw"-Datei laden und unter make/linux/patches/3.10.73/171-printk_to_console.patch ablegen - dann den Kernel neu bauen.
Der Patch ist nur auf "Übersetzung funktioniert" getestet, sein Ergebnis kann ich wieder (mangels Bestückung der seriellen Schnittstelle) nicht selbst überprüfen.
Zuletzt bearbeitet:
Danke. Ich werde PeterPawns Patch so schnell wie möglich testen ( und den 170er weiterhin raus lassen). Kann leider evtl. bis Anfang der nächsten Woche dauern.
- - - Aktualisiert - - -
Der Dank für die Analyse geht natürlich nicht an mich, sondern an PeterPawn, er13 und andere.
PeterPawns Patch hat bei mir nichts am Protokoll geändert. Erst nachdem ich in der init/avm_kernel_config.c alle pr_err-Aufrufe durch prom_printf ersetzt hatte, lieferte das Protokoll eine Zeile mehr, nämlich
[init_avm_kernel_config] AVM Kernel Config (ptr 80819000)
Hier ist das ganze Protokoll:
Ich habe ja versprochen, meine .config und die Kernel-Konfig als Anhang zu posten, aber irgendwas funktioniert mit dem Pop-up-Fenster zu "Anhänge verwalten" bei mir nicht. Evtl. wechsel ich mal den Browser.
- - - Aktualisiert - - -
Der Dank für die Analyse geht natürlich nicht an mich, sondern an PeterPawn, er13 und andere.
PeterPawns Patch hat bei mir nichts am Protokoll geändert. Erst nachdem ich in der init/avm_kernel_config.c alle pr_err-Aufrufe durch prom_printf ersetzt hatte, lieferte das Protokoll eine Zeile mehr, nämlich
[init_avm_kernel_config] AVM Kernel Config (ptr 80819000)
Hier ist das ganze Protokoll:
Code:
[14580.190000] kdsld: kdsld_vcc_preunregister: *
[14583.460000] AVM_WATCHDOG_disable()
[14585.590000] SQUASHFS error: Major/Minor mismatch, older Squashfs 0.0 filesystems are unsupported
[14592.650000] [avm_urlader_env_set_variable] opening ID 0x198 for writing
[14592.740000] SysRq : Emergency Sync
[14592.750000] SysRq : Emergency Remount R/O
[14596.280000] [avm_power] PowerManagmentRelease(0x8f139b80)
[14596.590000] __gmac_dev_event: ath0: 0x9 (NETDEV_GOING_DOWN), pid=3844 (hostapd)
[14596.640000] __gmac_dev_event: ath0: 0x2 (NETDEV_DOWN), pid=3844 (hostapd)
[14597.180000] __gmac_dev_event: ath1: 0x9 (NETDEV_GOING_DOWN), pid=3844 (hostapd)
[14597.230000] __gmac_dev_event: ath1: 0x2 (NETDEV_DOWN), pid=3844 (hostapd)
[14598.420000] get_ul_manager: error: ll_handle= (null)
[14598.480000] [avm_power] PowerManagmentRelease(0x8f141680)
[14598.480000] Res
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000
[-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\][|][/][-][\]
(AVM) EVA Revision: 1.1964 Version: 2964
(C) Copyright 2005 AVM Date: Nov 27 2013 Time: 14:33:10 (1) 3 0x0-0x740D
[FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 16 sectors a 64kB)
[NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
[SYSTEM:] VR9 on 500MHz/250MHz/250MHz
.Atheros 8030/35 detected
Eva_AVM >##............................................................
Lantiq xDSL CPE VR9
phym = 10000000, mem = 10000000, max_pfn = 00010000
Reserving memory for CP1 @0xb0000000, size 0x00000000
[init_avm_kernel_config] AVM Kernel Config (ptr 80819000)
plat_device_tree_setup: AVM hardware subrevision 5
plat_device_tree_setup: Missing device-tree for AVM hardware subrevision 5
Lantiq xDSL CPE VR9
Lantiq xDSL CPE VR9Ich habe ja versprochen, meine .config und die Kernel-Konfig als Anhang zu posten, aber irgendwas funktioniert mit dem Pop-up-Fenster zu "Anhänge verwalten" bei mir nicht. Evtl. wechsel ich mal den Browser.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Das macht es weiterhin mystriös, wo die Ausgaben bleiben mögen ... aber egal, die denkbare Alternative mit dem Ersetzen des Makro-Aufrufs "pr_err" durch "prom_printf" hatten wir ja bereits auf dem Schirm.
Wenn da die erste Nachricht kommt (das ist die beim Betreten der Funktion init_avm_kernel_config in Zeile 18), aber keine weiteren ... dann kann das ja eigentlich nur daran liegen, daß es da nichts zu "kopieren" gibt und dann gibt es logischerweise auch keine der anderen Nachrichten aus dem "switch"-Statement.
Damit wären wir dann bei der Frage, warum da im selbstgebauten Kernel an __avm_kernel_config_start offenbar gar kein Pointer auf weitere Einträge steht (dann würde Zeile 23/24 greifen und init_avm_kernel_config verlassen werden) oder warum bereits im allerersten Eintrag dort entweder ein vollkommen falsches Tag steht (dann greift das komplette "switch"-Statement ins Leere, wo ansonsten jeder beliebige Zweig zumindest eine Nachricht produziert) oder der Pointer ab Offset 4 an der Stelle, auf die der Pointer an __avm_kernel_config_start zeigt, bereits im allerersten Eintrag "NULL" ist (was dann zum Rücksprung in Zeile 27/28 führen würde).
Bleibt also am Ende wohl doch nichts anderes, als den Inhalt des Speichers bei __avm_kernel_config_start zu ermitteln (keine Ahnung, ob EVA so etwas machen kann, nachdem der Kernel geladen und entpackt wurde) und sich dann weiter zu hangeln oder man versucht anhand des noch ungepackten Kernels nach dem "make" zu eruieren, was da stehen mag. Die Startadresse (also __avm_kernel_config_start selbst) zeigt die zusätzliche Nachricht ja an.
BTW (und sicherlich eher belanglos) ... was mich verwundert ist die um einiges kleinere Adresse (0x80859000 war es beim AVM-Kernel), denn dann muß davor ja irgendetwas im selbstgebauten Kernel "fehlen", was den Unterschied von 0x40000 (256 KByte) erklärt. Das könnten zwar problemlos irgendwelche LKM sein, die eben bei Freetz auch wirklich als "M" gebaut werden ... aber ich dachte bisher immer, daß ein solcher "minimaler Kernel" praktisch mit dem von AVM identisch wäre.
Jetzt bleibt wohl nichts weiter übrig, als sich in das Linken des Kernels zu vertiefen und zu ermitteln, was da an __avm_kernel_config_start steht und was nicht bzw. warum da wohl etwas fehlt. Aber nicht gleich ... erst einmal ist "Feiern" angesagt und vielleicht geht es heute am späten Abend weiter mit der Suche.
Wenn da die erste Nachricht kommt (das ist die beim Betreten der Funktion init_avm_kernel_config in Zeile 18), aber keine weiteren ... dann kann das ja eigentlich nur daran liegen, daß es da nichts zu "kopieren" gibt und dann gibt es logischerweise auch keine der anderen Nachrichten aus dem "switch"-Statement.
Damit wären wir dann bei der Frage, warum da im selbstgebauten Kernel an __avm_kernel_config_start offenbar gar kein Pointer auf weitere Einträge steht (dann würde Zeile 23/24 greifen und init_avm_kernel_config verlassen werden) oder warum bereits im allerersten Eintrag dort entweder ein vollkommen falsches Tag steht (dann greift das komplette "switch"-Statement ins Leere, wo ansonsten jeder beliebige Zweig zumindest eine Nachricht produziert) oder der Pointer ab Offset 4 an der Stelle, auf die der Pointer an __avm_kernel_config_start zeigt, bereits im allerersten Eintrag "NULL" ist (was dann zum Rücksprung in Zeile 27/28 führen würde).
Bleibt also am Ende wohl doch nichts anderes, als den Inhalt des Speichers bei __avm_kernel_config_start zu ermitteln (keine Ahnung, ob EVA so etwas machen kann, nachdem der Kernel geladen und entpackt wurde) und sich dann weiter zu hangeln oder man versucht anhand des noch ungepackten Kernels nach dem "make" zu eruieren, was da stehen mag. Die Startadresse (also __avm_kernel_config_start selbst) zeigt die zusätzliche Nachricht ja an.
BTW (und sicherlich eher belanglos) ... was mich verwundert ist die um einiges kleinere Adresse (0x80859000 war es beim AVM-Kernel), denn dann muß davor ja irgendetwas im selbstgebauten Kernel "fehlen", was den Unterschied von 0x40000 (256 KByte) erklärt. Das könnten zwar problemlos irgendwelche LKM sein, die eben bei Freetz auch wirklich als "M" gebaut werden ... aber ich dachte bisher immer, daß ein solcher "minimaler Kernel" praktisch mit dem von AVM identisch wäre.
Jetzt bleibt wohl nichts weiter übrig, als sich in das Linken des Kernels zu vertiefen und zu ermitteln, was da an __avm_kernel_config_start steht und was nicht bzw. warum da wohl etwas fehlt. Aber nicht gleich ... erst einmal ist "Feiern" angesagt und vielleicht geht es heute am späten Abend weiter mit der Suche.
Zuletzt bearbeitet:
Ich habe mal die If-Anweisung in Zeile 24 von avm_kernel_config.c geändert in
Code:
if (p == NULL)
{
prom_printf("p is NULL\n");
return;
}Resultat: Die Konsole zeigt, dass wir es tatsächlich mit einem Null-Pointer zu tun haben:
Code:
p is NULL
plat_device_tree_setup: AVM hardware subrevision 5
plat_device_tree_setup: Missing device-tree for AVM hardware subrevision 5Leider verstehe ich zu wenig vom Code, um den nächsten Schritt bei der Fehlersuche zu machen. Ich stehe aber für weitere Tests gerne zur Verfügung.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich versuche zur Zeit immer mal so nebenbei bei freier Zeit und Rechnerkapazität, die AVM-Quellen zu einem Kernel zusammenzusetzen ... für den 3er-Kernel hat da vermutlich jemand anderes das Zusammenstellen der Dateien übernommen (es geht also sowohl mit den 06.50- als auch mit den 06.51-Quellen nicht) und der hat sich vermutlich niemals der Mühe unterzogen, das Ergebnis dieser Arbeiten auch einmal zu überprüfen.
Jedenfalls steht da bei den 7490-Quellen irgendetwas von Kernel-Version 3.10.53 an verschiedenen Stellen in den Konfigurationsdateien und auch sonst macht das (zumindest oberflächlich) eher den Eindruck, daß da jemand die 6840 mit der 7490 verwechselt hat bei der Zusammenstellung.
Die diversen "init_avm"-Skripte funktionieren auch nur teilweise, schon bei der Unterscheidung zwischen "altem" und "neuem" avm_cpmac-Treiber fällt das Skript erbärmlich auf die Nase, weil da anstelle der erwarteten regulären Datei ein "dangling symlink" (also ein Symlink, der irgendwo in die Weltgeschichte zeigt (home/gjungnick/...) und dieses Ziel existiert natürlich nicht) existiert, der von einem normalen "cp"-Kommando nicht überschrieben wird (das würde auf die Datei hinter dem Symlink zugreifen wollen).
Zumindest die buildroot-Umgebung läßt sich (nach ein paar Korrekturen) schon mal bauen ... wie lange ich für einen Kernel zum Vergleich brauchen werde, weiß ich noch nicht (ist - wie gesagt - nur ein Nebenkriegsschauplatz). Ich will nur sicherstellen, daß bei den AVM-Quellen tatsächlich keine passenden Anweisungen zum Befüllen des Speichers ab "__avm_kernel_config_start" vorhanden sind und diese nicht eventuell nur beim Zusammenstellen derFRITZ! Freetz-Quellen (hier wird ja mit Patches gegen die 3490 gearbeitet, wenn ich das richtig in Erinnnerung habe) unter die Räder kommen.
Wenn das tatsächlich vollkommen fehlt, würde ich am ehesten die Strukturen beim AVM-Kernel analysieren (einfach durch Nachsehen im Speicher mit "devmem") und dann passende Anweisungen zum Erstellen der benötigten Pointer hinzufügen wollen (das klappt dann natürlich nur pro Modell und ist ein Heidenaufwand).
Jedenfalls steht da bei den 7490-Quellen irgendetwas von Kernel-Version 3.10.53 an verschiedenen Stellen in den Konfigurationsdateien und auch sonst macht das (zumindest oberflächlich) eher den Eindruck, daß da jemand die 6840 mit der 7490 verwechselt hat bei der Zusammenstellung.
Die diversen "init_avm"-Skripte funktionieren auch nur teilweise, schon bei der Unterscheidung zwischen "altem" und "neuem" avm_cpmac-Treiber fällt das Skript erbärmlich auf die Nase, weil da anstelle der erwarteten regulären Datei ein "dangling symlink" (also ein Symlink, der irgendwo in die Weltgeschichte zeigt (home/gjungnick/...) und dieses Ziel existiert natürlich nicht) existiert, der von einem normalen "cp"-Kommando nicht überschrieben wird (das würde auf die Datei hinter dem Symlink zugreifen wollen).
Zumindest die buildroot-Umgebung läßt sich (nach ein paar Korrekturen) schon mal bauen ... wie lange ich für einen Kernel zum Vergleich brauchen werde, weiß ich noch nicht (ist - wie gesagt - nur ein Nebenkriegsschauplatz). Ich will nur sicherstellen, daß bei den AVM-Quellen tatsächlich keine passenden Anweisungen zum Befüllen des Speichers ab "__avm_kernel_config_start" vorhanden sind und diese nicht eventuell nur beim Zusammenstellen der
Wenn das tatsächlich vollkommen fehlt, würde ich am ehesten die Strukturen beim AVM-Kernel analysieren (einfach durch Nachsehen im Speicher mit "devmem") und dann passende Anweisungen zum Erstellen der benötigten Pointer hinzufügen wollen (das klappt dann natürlich nur pro Modell und ist ein Heidenaufwand).
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich bin jetzt endgültig zu der Überzeugung gekommen, daß AVM bei den Kernel-Sourcen seit der Verwendung des Kernels 3.10 einige Dateien "schon immer" vergessen hatte.
Seit Kernel 3.10 wurde u.a. der frühere Mechanismus zum Reservieren von Hauptspeicher für nachzuladende LKM von der Verwendung von "modulemem" im Urlader-Environment auf die Verwendung einer Liste der Module (als Array aus "_kernel_modulmemory_config"-Strukturen) umgestellt (jedenfalls enthält der AVM-Kernel eine entsprechende Liste, die nach dem Code in "arch/mips/avm_enh/kseg0_module.c" dann auch verwendet wird, wenn sie existiert) und auch die notwendigen "boot_param_header"-Strukturen für die Verwendung mit "plat_device_tree_setup()" in der Datei "arch/mips/lantiq/common/ifxmips_setup.c" werden - meiner Überzeugung nach - auch bei den originalen AVM-Quellen nicht erzeugt (das ist also kein Phänomen, was auf die Freetz-Toolchain und die dort etwas abweichende Behandlung der AVM-Quellen zurückzuführen wäre). Das ist allerdings auch erst mit dem 3.10-Kernel hinzugekommen, daß da die "device_tree"-Adresse für den "open firmware"-Treiber ebenfalls im Rahmen von init_avm_kernel_config() auf den passenden Blob gesetzt wird (das ist ja eine AVM-Erweiterung).
Nun könnte man auf die Idee kommen, den passenden Eintrag einfach von Hand in den Quellen nachzubauen. Das sind allerdings recht komplexe Strukturen, die da in so einer "boot_header_param"-Struktur beschrieben werden (das ist ein "flattened device tree" für den OF-Treiber) und das würde ich eher nicht für zielführend halten, weil es ein Heidenaufwand wäre, der auch immer wieder aufs Neue RE-Arbeiten erforderlich machen würde. Die GPLv2 sollte da eigentlich ausreichend sein, damit AVM sich ein Herz faßt und mal überprüft, was da wirklich als OpenSource-Paket bereitgestellt wird und was man damit anfangen kann.
Also habe ich AVM mal eine E-Mail geschrieben und auf das Problem (das meiner Meinung nach hier existiert, wenn ich mich nicht nur zu blöd anstelle, was natürlich auch noch möglich wäre - aber ich habe mich auf das "pure AVM-Original" beschränkt bei meinen Versuchen) aufmerksam gemacht ... mal sehen, was daraus wird.
Nur der Vollständigkeit halber ... ich habe mich bei den Tests und Reviews auf die Dateien
vom AVM-FTP-Server gestützt.
Seit Kernel 3.10 wurde u.a. der frühere Mechanismus zum Reservieren von Hauptspeicher für nachzuladende LKM von der Verwendung von "modulemem" im Urlader-Environment auf die Verwendung einer Liste der Module (als Array aus "_kernel_modulmemory_config"-Strukturen) umgestellt (jedenfalls enthält der AVM-Kernel eine entsprechende Liste, die nach dem Code in "arch/mips/avm_enh/kseg0_module.c" dann auch verwendet wird, wenn sie existiert) und auch die notwendigen "boot_param_header"-Strukturen für die Verwendung mit "plat_device_tree_setup()" in der Datei "arch/mips/lantiq/common/ifxmips_setup.c" werden - meiner Überzeugung nach - auch bei den originalen AVM-Quellen nicht erzeugt (das ist also kein Phänomen, was auf die Freetz-Toolchain und die dort etwas abweichende Behandlung der AVM-Quellen zurückzuführen wäre). Das ist allerdings auch erst mit dem 3.10-Kernel hinzugekommen, daß da die "device_tree"-Adresse für den "open firmware"-Treiber ebenfalls im Rahmen von init_avm_kernel_config() auf den passenden Blob gesetzt wird (das ist ja eine AVM-Erweiterung).
Nun könnte man auf die Idee kommen, den passenden Eintrag einfach von Hand in den Quellen nachzubauen. Das sind allerdings recht komplexe Strukturen, die da in so einer "boot_header_param"-Struktur beschrieben werden (das ist ein "flattened device tree" für den OF-Treiber) und das würde ich eher nicht für zielführend halten, weil es ein Heidenaufwand wäre, der auch immer wieder aufs Neue RE-Arbeiten erforderlich machen würde. Die GPLv2 sollte da eigentlich ausreichend sein, damit AVM sich ein Herz faßt und mal überprüft, was da wirklich als OpenSource-Paket bereitgestellt wird und was man damit anfangen kann.
Also habe ich AVM mal eine E-Mail geschrieben und auf das Problem (das meiner Meinung nach hier existiert, wenn ich mich nicht nur zu blöd anstelle, was natürlich auch noch möglich wäre - aber ich habe mich auf das "pure AVM-Original" beschränkt bei meinen Versuchen) aufmerksam gemacht ... mal sehen, was daraus wird.
Nur der Vollständigkeit halber ... ich habe mich bei den Tests und Reviews auf die Dateien
Code:
[COLOR="#0000FF"]~/avm$[/COLOR] [COLOR="#008000"]sha256sum source*[/COLOR]
242ac42d88027d9e3c2fc8dc8efbb28943eefdf8ba88b9f6da87ca3db4376251 source-files-FRITZ.Box_7490-06.30.tar.gz
dcc13f635bb280b6d63d194315a81ce94f4274a4647dd266c1561b89cf752d06 source-files-FRITZ.Box_7490-06.50.tar.gz
281eceab31b74947f1135b06cac0e8384258feac2c6bd9c847129405f4c64a0f source-files-FRITZ.Box_7490-06.51.tar.gzPeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Zwischenstand:
E-Mail vom AVM-Support, meine Anfrage wurde weitergeleitet an die zuständigen Mitarbeiter, nun wird auf deren Antwort gewartet.
Bei der Gelegenheit ... die Quelldateien für die "device trees" haben sich doch noch angefunden (im Pfad arch/mips/boot/dts), wobei da trotzdem noch Teile fehlen, welche die kompilierten Beschreibungen (dazu gibt es den "dtc", um aus den "dts"-Files dann einen FDT (dtb) zu generieren) dann als Blob so in den Kernel einlinken, daß die ab der Adresse __avm_kernel_config_start zur Verfügung stehen (EDIT - natürlich als avm_kernel_config_tags_device_tree_subrev_X-Einträge, damit da niemand denkt, der Bereich startet gleich mit diesem Array).
Ich sehe auch durchaus Probleme auf AVM zukommen ... solange der veröffentlichte Kernel die Liste der AVM-Module (_kernel_modulmemory_config-Array) enthält und da die tatsächlichen Größen der LKM stehen sollen, wird das ohne die Möglichkeit, diese LKM ebenfalls passend zu übersetzen und zu linken, richtig spannend werden, wo da die Angaben zu den Größen herkommen sollen.
Da tippe ich mal auf eine "statische Liste", die zusammen mit den Source-Dateien erzeugt werden muß und dann nicht mehr ganz so dynamisch ist, wie das vermutlich bei den AVM-Objektdateien der Fall ist (man darf sicherlich annehmen, daß der AVM-Kernel immer die tatsächlichen Größen der passenden Module enthält). Das könnte dann wieder dazu führen, daß bei einer Vergrößerung so eines LKM (wenn AVM keine "Sicherheitsaufschläge" einbezieht - einige erinnern sich vielleicht noch an "patch areas") im Rahmen irgendeiner Änderung auch die Kernel-Quellen jedesmal überarbeitet werden müssen. Meine persönliche Spannung steigt jedenfalls ...
Ach so ... die Quellen für die 06.50 auf dem AVM-FTP-Server haben inzwischen das Datum vom 18.05.2016 - keine Ahnung, ob das schon vor oder erst nach meinem Beitrag oben veröffentlicht wurde.
Zumindest stehen damit die Dateien für den in #254 erwähnten Weg der eigenen Änderungen theoretisch zur Verfügung, falls AVM sich gar nicht bewegt ... glaube ich zwar nicht dran, aber für den Fall der Fälle könnte man damit dann wieder einen passenden Eintrag für _dtb_setup() bauen - zumindest bei der 7490 gibt es ja ohnehin derzeit nur die SubRevision 0 in diesem Baum (bei anderen Boxen aber offenbar mehrere).
E-Mail vom AVM-Support, meine Anfrage wurde weitergeleitet an die zuständigen Mitarbeiter, nun wird auf deren Antwort gewartet.
Bei der Gelegenheit ... die Quelldateien für die "device trees" haben sich doch noch angefunden (im Pfad arch/mips/boot/dts), wobei da trotzdem noch Teile fehlen, welche die kompilierten Beschreibungen (dazu gibt es den "dtc", um aus den "dts"-Files dann einen FDT (dtb) zu generieren) dann als Blob so in den Kernel einlinken, daß die ab der Adresse __avm_kernel_config_start zur Verfügung stehen (EDIT - natürlich als avm_kernel_config_tags_device_tree_subrev_X-Einträge, damit da niemand denkt, der Bereich startet gleich mit diesem Array).
Ich sehe auch durchaus Probleme auf AVM zukommen ... solange der veröffentlichte Kernel die Liste der AVM-Module (_kernel_modulmemory_config-Array) enthält und da die tatsächlichen Größen der LKM stehen sollen, wird das ohne die Möglichkeit, diese LKM ebenfalls passend zu übersetzen und zu linken, richtig spannend werden, wo da die Angaben zu den Größen herkommen sollen.
Da tippe ich mal auf eine "statische Liste", die zusammen mit den Source-Dateien erzeugt werden muß und dann nicht mehr ganz so dynamisch ist, wie das vermutlich bei den AVM-Objektdateien der Fall ist (man darf sicherlich annehmen, daß der AVM-Kernel immer die tatsächlichen Größen der passenden Module enthält). Das könnte dann wieder dazu führen, daß bei einer Vergrößerung so eines LKM (wenn AVM keine "Sicherheitsaufschläge" einbezieht - einige erinnern sich vielleicht noch an "patch areas") im Rahmen irgendeiner Änderung auch die Kernel-Quellen jedesmal überarbeitet werden müssen. Meine persönliche Spannung steigt jedenfalls ...
Ach so ... die Quellen für die 06.50 auf dem AVM-FTP-Server haben inzwischen das Datum vom 18.05.2016 - keine Ahnung, ob das schon vor oder erst nach meinem Beitrag oben veröffentlicht wurde.
Zumindest stehen damit die Dateien für den in #254 erwähnten Weg der eigenen Änderungen theoretisch zur Verfügung, falls AVM sich gar nicht bewegt ... glaube ich zwar nicht dran, aber für den Fall der Fälle könnte man damit dann wieder einen passenden Eintrag für _dtb_setup() bauen - zumindest bei der 7490 gibt es ja ohnehin derzeit nur die SubRevision 0 in diesem Baum (bei anderen Boxen aber offenbar mehrere).
Zuletzt bearbeitet:
@arch/mips/boot/dts: ich habe im Rahmen von r13638 den 100-evaloader.patch de-facto komplett neu machen müssen. Kann es sein, dass ich da einige boot-y += ... vergessen habe? Und dass diese dts's dann eben nicht kompiliert/dazu gelinkt werden. Oder basiert Deine Analyse auf den nakten AVM-Quellen? Nebenbei gefragt, welches Target muss da eigentlich bei AVM aufgerufen werden, um lzma-komprimiertes/eva-umgewandeltes kernel.image zu erzeugen? Ich sehe keins. Ist das nicht schon mal eine GPL-Verletzung?
@Datum der Quellen auf dem AVM-FTP: 7490.06.51 wurde auch silent upgedatet. Ich habe zuhause beide Versionen (kann später md5's von beiden nachreichen). Die Kernel-Sourcen haben sich dabei nicht geändert, es war irgendwas anderes, was sie in der ersten Version vergessen haben, dazu zu packen (habe vergessen was, könnten NTFS-related-Pakete sein, bin mir aber nicht mehr sicher).
@Datum der Quellen auf dem AVM-FTP: 7490.06.51 wurde auch silent upgedatet. Ich habe zuhause beide Versionen (kann später md5's von beiden nachreichen). Die Kernel-Sourcen haben sich dabei nicht geändert, es war irgendwas anderes, was sie in der ersten Version vergessen haben, dazu zu packen (habe vergessen was, könnten NTFS-related-Pakete sein, bin mir aber nicht mehr sicher).
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich habe (absichtlich, s.o.) nur mit AVM-Quellen gearbeitet und dort (nach ein paar Anpassungen im Makefile) erst einmal per "buildroot" die Toolchain bauen lassen ... da war also nichts von Freetz involviert, insofern glaube ich an einen AVM-Fehler.
Für den Kernel ist im Makefile kein Target enthalten, aber das Shell-Skript gpl_compile_kernel.sh soll sicherlich den Einstieg in den Kernel bieten ... ob am Ende (bei kompletten Quellen) tatsächlich ein LZMA-komprimiertes Kernel-Image entsteht, kann ich nicht sagen.
Ich würde erwarten, daß - ähnlich wie die AVM-Patches in den originalen Source-Zweig des Kernels gelangen sollen nach dem Makefile zu urteilen (Target dl/linux-$(LINUX_KERNEL_VERSION).tar.xz, auch das funktioniert ja mit dem AVM-Dateien schon nicht, wenn man nicht selbst entsprechende Vorarbeiten ausführt) - da das Makefile für den Kernel-Build so gepatcht wird, daß der "pure" Aufruf von "make" in der Funktion "compile_kernel" entweder den komprimierten Kernel auch gleich noch erstellt (das fehlt allerdings ebenfalls) oder daß irgendwo im "buildroot" beim Zusammenbau des Dateisystems (auch das ist ja sehr rudimentär, ich war bisher (vielleicht aufgrund eigener Unfähigkeit) immer noch nicht in der Lage, bei AVM etwas in der Richtung "mksquashfs" zu lokalisieren - über buildroot wird da jedenfalls nach den config-Dateien kein "BR2_TARGET_ROOTFS_SQUASHFS" gesetzt, also muß das Packen ja irgendwo anders erfolgen) der Kernel gepackt wird. Aus dem Shell-Skript entsteht jedenfalls ein Kernel mit einer Größe von 60 MB (not stripped) und das war es dann auch schon. Ich habe in den AVM-Quellen noch nichts gesehen, was anstelle eines gzip-gepackten Kernels einen mit LZMA-Kompression erstellen könnte ... das fehlt(e) wohl schon immer.
Der einzige Unterschied, den ich in den vorhergehenden 06.50-Quellen zur aktuell dort abgelegten Version gefunden habe, war eine Pfadangabe in irgendwelchen "for"-Schleifen über ein "find"-Resultat bei drei "init"-Files, mit denen die Symlinks in den Kernel-Quellen korrigiert werden - alles andere sind nur "Datumsstempel" (May 4 - vielleicht war da ja die Macht tatsächlich "with AVM" - vs. Dec 22) ohne wirkliche Änderungen.
Ich habe schon überlegt, ob das fehlende Verzeichnis "arch/etc/init.d/rc.${KERNEL_LAYOUT}.init" die Ursache des Problems sein könnte (in drivers/char/avm_new/init_avm), weil dort eine Liste als "AVM_NEW_HWREV_LIST" zusammengestellt wird, die dann über ein "-D" in den CFLAGS im Compiler landet ... aber ein "grep" nach diesem Symbol über den gesamten Quelltext-Baum bringt 0 Resultate; also wird das wohl nur in dem von AVM nicht veröffentlichten Teil der Quellen enthalten sein. Der initial leere "device tree" dürfte jedenfalls auch Absicht sein (DT_NOOP=y), wenn man sich init_avm_kernel_config ansieht.
Ich finde eigentlich per "grep" überhaupt keine weiteren sinnvollen Vorkommen von "OF_AVM_DT", was nach den Ergänzungen in der "Kconfig.avm" ja eigentlich die "device tree"-Unterstützung so richtig einschalten soll (ist auch gesetzt in der .config für VR9). Nur das Makefile im Verzeichnis mit den dts-Dateien und die Kconfig.avm tauchen da bei den Fundstellen auf (die Variable "OF_AVM_DT_ENV" ist ja nicht gesetzt, damit sind diese Fundstellen irrelevant) und dann wird darüber noch die Datei drivers/of/of_avm_dt.c (bzw. deren Object-File) eingebunden, die aber am Ende erst dann interessant wird, wenn aus dem "device tree" die früheren "hw_config"-Einträge abgeleitet werden sollen und bis dahin kommt man schon nicht.
Wenn die 06.51-Quellen aktualisiert wurden, kriegt das mein Mirror-Skript nicht mit, solange die Datumsstempel sich nicht ebenfalls ändern ... aber da werde ich gleich noch einmal von Hand nachsehen, deshalb habe ich ja die SHA256-Werte extra dazugeschrieben, damit solche "silent updates" nicht unnötige Verwirrung stiften (O-Ton: Was hast Du denn, geht doch ...).
Der Blob mit dem FDT (die dtb-Datei) wird beim Übersetzen des Kernels sogar erzeugt ... allerdings eben (wegen des Makefiles in arch/mips/boot/dts) für alle VR9-Modelle gleichzeitig und irgendwo muß ja beim Zusammenlinken des Kernels dann noch die zum Zielmodell passende dtb-Datei (oder auch mehrere, wenn es mehrere HWSubRevisionen gibt) ausgewählt und in den Kernel eingebunden werden.
Die eigentlich mal angestrebte Trennung von "device tree" und "operating system" ist hier ja eher nicht umgesetzt ... ich hätte mir auch noch vorstellen können, daß da der Urlader den passenden "device tree" enthält (und an den gestarteten Kernel die Adresse dieses Bereichs übergibt) oder nach dem Entpacken des Kernels die Adresse(n) im "kernel_config"-Bereich entsprechend einträgt (wobei das dann auch das Schreiben des gesamten Inhalts ab __avm_kernel_config_start sein müßte, denn das liegt ja beim AVM-Kernel schon direkt in den Kerneldaten) ... aber dazu müßte wohl auch der Urlader aktualisiert werden (bei meiner 7490 nicht erfolgt), damit dort diese - erst seit 3.10 genutzten - Daten dann auch vorliegen. Das mag bei künftigen Modellen mal so laufen, im Moment sehe ich das nicht. Bei der 4080 wird es wohl dann auch das Urlader-Environment über den "device tree" geben (AVM_DT_ENV=y).
Ansonsten sehe ich das mit der GPL allerdings ähnlich, es müssen zumindest alle notwendigen Dateien (und eigentlich auch die notwendigen (fehlerfreien) Skripte für die Übersetzung) vorliegen, damit ein funktionsgleicher Kernel (1:1-Übereinstimmung wird sicherlich nichts) daraus erstellt werden kann und das wäre hier eben ein LZMA-komprimierter Kernel. In arch/mips/boot/compressed wird zwar (dem Makefile nach) bei passenden Settings auch ein Target "vmlinuz" unterstützt, das ein LZMA-komprimierter Kernel sein könnte, aber ich weiß nicht sicher, ob EVA mit einem solchermaßen erstellten Kernel umgehen könnte (und bis dahin kommt der Prozess mit den AVM-Skripten (bei mir) ohnehin nicht).
Für den Kernel ist im Makefile kein Target enthalten, aber das Shell-Skript gpl_compile_kernel.sh soll sicherlich den Einstieg in den Kernel bieten ... ob am Ende (bei kompletten Quellen) tatsächlich ein LZMA-komprimiertes Kernel-Image entsteht, kann ich nicht sagen.
Ich würde erwarten, daß - ähnlich wie die AVM-Patches in den originalen Source-Zweig des Kernels gelangen sollen nach dem Makefile zu urteilen (Target dl/linux-$(LINUX_KERNEL_VERSION).tar.xz, auch das funktioniert ja mit dem AVM-Dateien schon nicht, wenn man nicht selbst entsprechende Vorarbeiten ausführt) - da das Makefile für den Kernel-Build so gepatcht wird, daß der "pure" Aufruf von "make" in der Funktion "compile_kernel" entweder den komprimierten Kernel auch gleich noch erstellt (das fehlt allerdings ebenfalls) oder daß irgendwo im "buildroot" beim Zusammenbau des Dateisystems (auch das ist ja sehr rudimentär, ich war bisher (vielleicht aufgrund eigener Unfähigkeit) immer noch nicht in der Lage, bei AVM etwas in der Richtung "mksquashfs" zu lokalisieren - über buildroot wird da jedenfalls nach den config-Dateien kein "BR2_TARGET_ROOTFS_SQUASHFS" gesetzt, also muß das Packen ja irgendwo anders erfolgen) der Kernel gepackt wird. Aus dem Shell-Skript entsteht jedenfalls ein Kernel mit einer Größe von 60 MB (not stripped) und das war es dann auch schon. Ich habe in den AVM-Quellen noch nichts gesehen, was anstelle eines gzip-gepackten Kernels einen mit LZMA-Kompression erstellen könnte ... das fehlt(e) wohl schon immer.
Der einzige Unterschied, den ich in den vorhergehenden 06.50-Quellen zur aktuell dort abgelegten Version gefunden habe, war eine Pfadangabe in irgendwelchen "for"-Schleifen über ein "find"-Resultat bei drei "init"-Files, mit denen die Symlinks in den Kernel-Quellen korrigiert werden - alles andere sind nur "Datumsstempel" (May 4 - vielleicht war da ja die Macht tatsächlich "with AVM" - vs. Dec 22) ohne wirkliche Änderungen.
Ich habe schon überlegt, ob das fehlende Verzeichnis "arch/etc/init.d/rc.${KERNEL_LAYOUT}.init" die Ursache des Problems sein könnte (in drivers/char/avm_new/init_avm), weil dort eine Liste als "AVM_NEW_HWREV_LIST" zusammengestellt wird, die dann über ein "-D" in den CFLAGS im Compiler landet ... aber ein "grep" nach diesem Symbol über den gesamten Quelltext-Baum bringt 0 Resultate; also wird das wohl nur in dem von AVM nicht veröffentlichten Teil der Quellen enthalten sein. Der initial leere "device tree" dürfte jedenfalls auch Absicht sein (DT_NOOP=y), wenn man sich init_avm_kernel_config ansieht.
Ich finde eigentlich per "grep" überhaupt keine weiteren sinnvollen Vorkommen von "OF_AVM_DT", was nach den Ergänzungen in der "Kconfig.avm" ja eigentlich die "device tree"-Unterstützung so richtig einschalten soll (ist auch gesetzt in der .config für VR9). Nur das Makefile im Verzeichnis mit den dts-Dateien und die Kconfig.avm tauchen da bei den Fundstellen auf (die Variable "OF_AVM_DT_ENV" ist ja nicht gesetzt, damit sind diese Fundstellen irrelevant) und dann wird darüber noch die Datei drivers/of/of_avm_dt.c (bzw. deren Object-File) eingebunden, die aber am Ende erst dann interessant wird, wenn aus dem "device tree" die früheren "hw_config"-Einträge abgeleitet werden sollen und bis dahin kommt man schon nicht.
Wenn die 06.51-Quellen aktualisiert wurden, kriegt das mein Mirror-Skript nicht mit, solange die Datumsstempel sich nicht ebenfalls ändern ... aber da werde ich gleich noch einmal von Hand nachsehen, deshalb habe ich ja die SHA256-Werte extra dazugeschrieben, damit solche "silent updates" nicht unnötige Verwirrung stiften (O-Ton: Was hast Du denn, geht doch ...).
Der Blob mit dem FDT (die dtb-Datei) wird beim Übersetzen des Kernels sogar erzeugt ... allerdings eben (wegen des Makefiles in arch/mips/boot/dts) für alle VR9-Modelle gleichzeitig und irgendwo muß ja beim Zusammenlinken des Kernels dann noch die zum Zielmodell passende dtb-Datei (oder auch mehrere, wenn es mehrere HWSubRevisionen gibt) ausgewählt und in den Kernel eingebunden werden.
Die eigentlich mal angestrebte Trennung von "device tree" und "operating system" ist hier ja eher nicht umgesetzt ... ich hätte mir auch noch vorstellen können, daß da der Urlader den passenden "device tree" enthält (und an den gestarteten Kernel die Adresse dieses Bereichs übergibt) oder nach dem Entpacken des Kernels die Adresse(n) im "kernel_config"-Bereich entsprechend einträgt (wobei das dann auch das Schreiben des gesamten Inhalts ab __avm_kernel_config_start sein müßte, denn das liegt ja beim AVM-Kernel schon direkt in den Kerneldaten) ... aber dazu müßte wohl auch der Urlader aktualisiert werden (bei meiner 7490 nicht erfolgt), damit dort diese - erst seit 3.10 genutzten - Daten dann auch vorliegen. Das mag bei künftigen Modellen mal so laufen, im Moment sehe ich das nicht. Bei der 4080 wird es wohl dann auch das Urlader-Environment über den "device tree" geben (AVM_DT_ENV=y).
Ansonsten sehe ich das mit der GPL allerdings ähnlich, es müssen zumindest alle notwendigen Dateien (und eigentlich auch die notwendigen (fehlerfreien) Skripte für die Übersetzung) vorliegen, damit ein funktionsgleicher Kernel (1:1-Übereinstimmung wird sicherlich nichts) daraus erstellt werden kann und das wäre hier eben ein LZMA-komprimierter Kernel. In arch/mips/boot/compressed wird zwar (dem Makefile nach) bei passenden Settings auch ein Target "vmlinuz" unterstützt, das ein LZMA-komprimierter Kernel sein könnte, aber ich weiß nicht sicher, ob EVA mit einem solchermaßen erstellten Kernel umgehen könnte (und bis dahin kommt der Prozess mit den AVM-Skripten (bei mir) ohnehin nicht).
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
E-Mail-Update vom AVM-Support (am Sonntag(!) und zwar wirklich den SMTP-Headerdaten nach auch heute generiert):
Die Pakete werden überarbeitet, nächste Nachricht kommt bei Bereitstellung der aktualisierten Quellen.
Die Pakete werden überarbeitet, nächste Nachricht kommt bei Bereitstellung der aktualisierten Quellen.
AVM hat mal wieder die Opensrc-Pakete für 7490.06.50 und 7490.06.51 (silent) aktualisiert.
Habe jetzt außer Kernel-Quellen noch nichts verglichen. Die von Dir, Peter, angefragten Änderungen sind meiner Auffassung nach noch nicht enthalten. Wenn man die Zeitstempel-Änderungen ignoriert, dann sieht der Diff so aus:
Ansonsten der Vollständigkeit halber die Checksums aller mir vorliegenden 7490.06.5x-Pakete:
Und der darin enthaltenen Dateien:
Habe jetzt außer Kernel-Quellen noch nichts verglichen. Die von Dir, Peter, angefragten Änderungen sind meiner Auffassung nach noch nicht enthalten. Wenn man die Zeitstempel-Änderungen ignoriert, dann sieht der Diff so aus:
Code:
--- 7490.06.51-v2-20160415_1026-kernel/linux-3.10/drivers/char/dect_io/init_dect_io
+++ 7490.06.51-v3-20160601_1118-kernel/linux-3.10/drivers/char/dect_io/init_dect_io
@@ -9,7 +9,7 @@
for i in `find . -name Makefile.$KERNEL_CLASS` ; do
dest=${i%.$KERNEL_CLASS}
- source="`pwd`/$i"
+ source="${i##*/}"
rm -f $dest
ln -fvs $source $dest
done
--- 7490.06.51-v2-20160415_1026-kernel/linux-3.10/drivers/char/flash_update/init_flash_update
+++ 7490.06.51-v3-20160601_1118-kernel/linux-3.10/drivers/char/flash_update/init_flash_update
@@ -9,7 +9,7 @@
for i in `find . -name Makefile.$KERNEL_CLASS` ; do
dest=${i%.$KERNEL_CLASS}
- source="`pwd`/$i"
+ source="${i##*/}"
rm -f $dest
ln -fvs $source $dest
done
--- 7490.06.51-v2-20160415_1026-kernel/linux-3.10/drivers/isdn/avm_dect/init_avm_dect
+++ 7490.06.51-v3-20160601_1118-kernel/linux-3.10/drivers/isdn/avm_dect/init_avm_dect
@@ -9,7 +9,7 @@
for i in `find . -name Makefile.$KERNEL_CLASS` ; do
dest=${i%.$KERNEL_CLASS}
- source="`pwd`/$i"
+ source="${i##*/}"
rm -f $dest
ln -fvs $source $dest
done
--- 7490.06.51-v2-20160415_1026-kernel/linux-3.10/drivers/isdn/isdn_fon5/init_isdn
+++ 7490.06.51-v3-20160601_1118-kernel/linux-3.10/drivers/isdn/isdn_fon5/init_isdn
@@ -9,7 +9,7 @@
for i in `find . -name Makefile.$KERNEL_CLASS` ; do
dest=${i%.$KERNEL_CLASS}
- source="`pwd`/$i"
+ source="${i##*/}"
rm -f $dest
ln -fvs $source $dest
doneAnsonsten der Vollständigkeit halber die Checksums aller mir vorliegenden 7490.06.5x-Pakete:
Code:
46c9c32a7a9381e881478025e1e951ee *7490.06.50-v1.tar.gz
431eb3938adf79b2a228b10004c6ba1f *7490.06.50-v2.tar.gz
8111e2da9808931cc7fdfb2ce8a4d242 *7490.06.50-v3.tar.gz
4ca0cb81f7525e359bfbeb1d86aa275d *7490.06.51-v1.tar.gz
96cf7c8b3e6a8cd156c7556543d2cc9f *7490.06.51-v2.tar.gz
491d599be71491e0072d4a62031860be *7490.06.51-v3.tar.gzUnd der darin enthaltenen Dateien:
Code:
8d6468f9a2cf7d4f81bfd82ee380278c *7490.06.50-v1-20160109_0035/GPL/BSD-libflac.tar.gz
11df71503db113ebe37c6cd1233148c1 *7490.06.50-v1-20160109_0035/GPL/GPL-avmacllib2.tar.gz
9c94441bdb664d1f1ab409df80762e76 *7490.06.50-v1-20160109_0035/GPL/GPL-busybox.tar.gz
5b7da7941173fdd599e3bb1d332d9535 *7490.06.50-v1-20160109_0035/GPL/GPL-chrony.tar.gz
ee22c04b779bccb852a853e0e1e1c442 *7490.06.50-v1-20160109_0035/GPL/GPL-davfs2.tar.gz
02e9e15b322939a11aefea7e27e65878 *7490.06.50-v1-20160109_0035/GPL/GPL-ftpd.tar.gz
6042e6399bfc42da67168da75bc865eb *7490.06.50-v1-20160109_0035/GPL/GPL-gcc.tar.gz
850a7cef98cd189f4a202d2c1822174a *7490.06.50-v1-20160109_0035/GPL/GPL-lte_tools.tar.gz
fd842146c79c8ffdab886fa22839ca77 *7490.06.50-v1-20160109_0035/GPL/GPL-ntfs.tar.gz
3b3d9bbab998dfefa3ad35fc85b8e02c *7490.06.50-v1-20160109_0035/GPL/GPL-release_kernel.tar.gz
ebc19520b41e22b1e9f854563bc04d44 *7490.06.50-v1-20160109_0035/GPL/GPL-samba.tar.gz
2e47388e13b67b9adb74bf551f4b3ae0 *7490.06.50-v1-20160109_0035/GPL/GPL-usb_host_tools.tar.gz
883647c9d6d8857898a5cc638eab63f8 *7490.06.50-v1-20160109_0035/GPL/GPL-wlan.tar.gz
7c8c788b72969a5d4e7bb429f2304de6 *7490.06.50-v1-20160109_0035/GPL/LGPL-GPL-release_fon_tools.tar.gz
b5062e123ec837c4efff7dfbdbb45747 *7490.06.50-v1-20160109_0035/GPL/LGPL-GPL-release_target_tools.tar.gz
a65651503183e0408f1fb3854fab4771 *7490.06.50-v1-20160109_0035/GPL/LGPL-libexif.tar.gz
c6542af9b36cb83697a613c2d562a834 *7490.06.50-v1-20160109_0035/GPL/LGPL-libosip.tar.gz
d983cb8ac433915283c77ef985cbb557 *7490.06.50-v1-20160109_0035/GPL/LGPL-multimedia_fon.tar.gz
a47462b9c319c6aec0d28cbda042b75a *7490.06.50-v1-20160109_0035/GPL/LGPL-neon.tar.gz
8f6513e78eb0baea7d70306ce5eb8bf2 *7490.06.50-v1-20160109_0035/GPL/ZLIB-libz.tar.gz
#
78418073a293a277e622ed8e2533b60b *7490.06.50-v2-20160518_1613/GPL/BSD-libflac.tar.gz
4ead5a0da91ae3cc2d80b9a32131d9ee *7490.06.50-v2-20160518_1613/GPL/GPL-avmacllib2.tar.gz
dc11c4f340c1edaef87297aca85da62d *7490.06.50-v2-20160518_1613/GPL/GPL-bridge-utils.tar.gz
b3f48f322b65f139e0b427db90383039 *7490.06.50-v2-20160518_1613/GPL/GPL-busybox.tar.gz
31455200b17e171a55b72f57fc9da7be *7490.06.50-v2-20160518_1613/GPL/GPL-chrony.tar.gz
6094bfde5efd52c0069212df9db2a704 *7490.06.50-v2-20160518_1613/GPL/GPL-davfs2.tar.gz
0a4c6ac6fee7486848b6204c96e5b291 *7490.06.50-v2-20160518_1613/GPL/GPL-ftpd.tar.gz
3eb2aa81127c7a0db80938994843a5fa *7490.06.50-v2-20160518_1613/GPL/GPL-gcc.tar.gz
96db3708690ea55e4bca04a340934ee3 *7490.06.50-v2-20160518_1613/GPL/GPL-iproute2.tar.gz
70f20c902776c32137be7a2590d18c41 *7490.06.50-v2-20160518_1613/GPL/GPL-lte_tools.tar.gz
028211103467411bf4b013e0d37d16bb *7490.06.50-v2-20160518_1613/GPL/GPL-ntfs.tar.gz
a644d1809d6f5540191b48ad14a97d9e *7490.06.50-v2-20160518_1613/GPL/GPL-release_kernel.tar.gz
4bd298c51ff231d55710c08b989f4ee7 *7490.06.50-v2-20160518_1613/GPL/GPL-samba.tar.gz
f9af599f709ac548e36bb2dce685192c *7490.06.50-v2-20160518_1613/GPL/GPL-usb_host_tools.tar.gz
1ab5e834e22594d3d866107ece8bf336 *7490.06.50-v2-20160518_1613/GPL/GPL-wlan.tar.gz
04d5f0c26dffe7f923c685f754639656 *7490.06.50-v2-20160518_1613/GPL/LGPL-GPL-release_fon_tools.tar.gz
7efb36300575d7bcf39f12ad8ca22bb3 *7490.06.50-v2-20160518_1613/GPL/LGPL-GPL-release_target_tools.tar.gz
518d5c47587566c6927f5e7718b5d4dd *7490.06.50-v2-20160518_1613/GPL/LGPL-libexif.tar.gz
175b35ada0ca8469d69c733732f68360 *7490.06.50-v2-20160518_1613/GPL/LGPL-libosip.tar.gz
ed8f0170ab6a933cc4a6528f0eaa1808 *7490.06.50-v2-20160518_1613/GPL/LGPL-multimedia_fon.tar.gz
b79515bc2c20704e845ac825d3e805d1 *7490.06.50-v2-20160518_1613/GPL/LGPL-neon.tar.gz
d1f318a34b6edbf8c9607345e3def91a *7490.06.50-v2-20160518_1613/GPL/ZLIB-libz.tar.gz
#
97e3ff66543023187b454113bae0fd2f *7490.06.50-v3-20160601_1117/GPL/BSD-libflac.tar.gz
5f2bd8f21f5f2b421d316eafae6c7d23 *7490.06.50-v3-20160601_1117/GPL/GPL-avmacllib2.tar.gz
1ecb3953d9ee3ac9409ccb244e17b92a *7490.06.50-v3-20160601_1117/GPL/GPL-bridge-utils.tar.gz
5bfc1d5372b0e6dc8d850e49d34ef4fb *7490.06.50-v3-20160601_1117/GPL/GPL-busybox.tar.gz
1c6c61c4ba9c9ee2e66b1ef3e377dc46 *7490.06.50-v3-20160601_1117/GPL/GPL-chrony.tar.gz
e2018be7bd3f27b3758fa3ed9956f0c6 *7490.06.50-v3-20160601_1117/GPL/GPL-davfs2.tar.gz
98fa1baf464ef4d4e0c4f1c12f408a7f *7490.06.50-v3-20160601_1117/GPL/GPL-ftpd.tar.gz
0a7b2173108131f91d4a49f0c1096910 *7490.06.50-v3-20160601_1117/GPL/GPL-gcc.tar.gz
2086ea9971023150d461c22f8ed95f78 *7490.06.50-v3-20160601_1117/GPL/GPL-iproute2.tar.gz
de95d0e2794525054c0773658261ca59 *7490.06.50-v3-20160601_1117/GPL/GPL-lte_tools.tar.gz
9a385c81cd72a1f5cbc36bbd7fa5edfc *7490.06.50-v3-20160601_1117/GPL/GPL-ntfs.tar.gz
4868a53d72db7557694c8d2d1951b64f *7490.06.50-v3-20160601_1117/GPL/GPL-release_kernel.tar.gz
9e8d4ee67ba4dfcd0eae8287f86117a1 *7490.06.50-v3-20160601_1117/GPL/GPL-samba.tar.gz
411cbff8d199e3b2f82d68aebecd791b *7490.06.50-v3-20160601_1117/GPL/GPL-usb_host_tools.tar.gz
3f16a843345c2ae8caf2bd08587ae123 *7490.06.50-v3-20160601_1117/GPL/GPL-wlan.tar.gz
94003dc1ededdf012db0402cf79bb018 *7490.06.50-v3-20160601_1117/GPL/LGPL-GPL-release_fon_tools.tar.gz
17d358f8a923f87bc6fcf642ac1c8dde *7490.06.50-v3-20160601_1117/GPL/LGPL-GPL-release_target_tools.tar.gz
dedaa9d2f0ea649723f0a222357351a5 *7490.06.50-v3-20160601_1117/GPL/LGPL-libexif.tar.gz
dbab78591abc7f39e5e82e294b15e889 *7490.06.50-v3-20160601_1117/GPL/LGPL-libosip.tar.gz
a4420393d5def9b6750db4438788393f *7490.06.50-v3-20160601_1117/GPL/LGPL-multimedia_fon.tar.gz
ff06d75b3c6511f769ad514c5469eeda *7490.06.50-v3-20160601_1117/GPL/LGPL-neon.tar.gz
ce9fe4df1240f5b7ce9d6338e70fc992 *7490.06.50-v3-20160601_1117/GPL/ZLIB-libz.tar.gz
#
8ce3fc0720350eaf65a537f04e059ae0 *7490.06.51-v1-20160224_1141/GPL/BSD-libflac.tar.gz
0028c08c250ddcff31099aedf51ece3a *7490.06.51-v1-20160224_1141/GPL/GPL-avmacllib2.tar.gz
df7aab979aa6a4e100b60f4f19c24902 *7490.06.51-v1-20160224_1141/GPL/GPL-busybox.tar.gz
19552db2ec64e8d7623f4f735a39c782 *7490.06.51-v1-20160224_1141/GPL/GPL-chrony.tar.gz
d5f2ff974e229080fde7415ee0589343 *7490.06.51-v1-20160224_1141/GPL/GPL-davfs2.tar.gz
6ab84f60b07937f10ab79fe57f50a266 *7490.06.51-v1-20160224_1141/GPL/GPL-ftpd.tar.gz
da50bf2307148f6fdee1d95b3c355bb2 *7490.06.51-v1-20160224_1141/GPL/GPL-gcc.tar.gz
9853cd56cc77b09be6d14ea17a072f31 *7490.06.51-v1-20160224_1141/GPL/GPL-lte_tools.tar.gz
e0e58073f090dcfed7c4d4254bd31f95 *7490.06.51-v1-20160224_1141/GPL/GPL-ntfs.tar.gz
a40371df0a90570939143404dbb153a3 *7490.06.51-v1-20160224_1141/GPL/GPL-release_kernel.tar.gz
580431bc1d9b42b92ab495b4ee305187 *7490.06.51-v1-20160224_1141/GPL/GPL-samba.tar.gz
379f94e979637951d08c2b6c4e6d4259 *7490.06.51-v1-20160224_1141/GPL/GPL-usb_host_tools.tar.gz
1b700ddb025f11eae59782694bca77b0 *7490.06.51-v1-20160224_1141/GPL/GPL-wlan.tar.gz
a8f88fe384000bfed46233fd81a4122a *7490.06.51-v1-20160224_1141/GPL/LGPL-GPL-release_fon_tools.tar.gz
215a189240b44c811956afac523758ad *7490.06.51-v1-20160224_1141/GPL/LGPL-GPL-release_target_tools.tar.gz
9a14df35ce062b04730c233083b3d3dd *7490.06.51-v1-20160224_1141/GPL/LGPL-libexif.tar.gz
a868072c5133fcd234b75b5d155f6517 *7490.06.51-v1-20160224_1141/GPL/LGPL-libosip.tar.gz
f578d91f2f31b72e5cd2e7d78cfc3f93 *7490.06.51-v1-20160224_1141/GPL/LGPL-multimedia_fon.tar.gz
0489f7eef60c67bf71bdb8aeba05b7c1 *7490.06.51-v1-20160224_1141/GPL/LGPL-neon.tar.gz
940d6b8024d1e9d61ff17b65d2ce2157 *7490.06.51-v1-20160224_1141/GPL/ZLIB-libz.tar.gz
#
3700cf9111afc580e70293d3dec517e9 *7490.06.51-v2-20160415_1026/GPL/BSD-libflac.tar.gz
c1244b891d9cc388aaf3dab2c0ffa08f *7490.06.51-v2-20160415_1026/GPL/GPL-avmacllib2.tar.gz
c8d3dfa6dbdaf6405545db844565d007 *7490.06.51-v2-20160415_1026/GPL/GPL-bridge-utils.tar.gz
1ebb30ef0436ee5697759f2c265e04f1 *7490.06.51-v2-20160415_1026/GPL/GPL-busybox.tar.gz
0dd9e441d0bdc652815dd9f9e15fa99a *7490.06.51-v2-20160415_1026/GPL/GPL-chrony.tar.gz
be3edadd6aabae599fb88ecd076ef2ab *7490.06.51-v2-20160415_1026/GPL/GPL-davfs2.tar.gz
2c5d9c0762d1d28a787824d1dbb8372a *7490.06.51-v2-20160415_1026/GPL/GPL-ftpd.tar.gz
b5e9b6d8c418d0e7c47f04b29dca2bed *7490.06.51-v2-20160415_1026/GPL/GPL-gcc.tar.gz
73b521fd3c5c4d346b965d34cdd5ca72 *7490.06.51-v2-20160415_1026/GPL/GPL-iproute2.tar.gz
7742489ca817a49cc08b3f24523f6eab *7490.06.51-v2-20160415_1026/GPL/GPL-lte_tools.tar.gz
4294258a7a060e702d45126119c44fc1 *7490.06.51-v2-20160415_1026/GPL/GPL-ntfs.tar.gz
1600ba509bf5e4235f3a9bb1e9306535 *7490.06.51-v2-20160415_1026/GPL/GPL-release_kernel.tar.gz
b6f171c3cb06e01d51423fa5ea04e8de *7490.06.51-v2-20160415_1026/GPL/GPL-samba.tar.gz
c33bcbcb2f493f3d14b3c0b795ece81b *7490.06.51-v2-20160415_1026/GPL/GPL-usb_host_tools.tar.gz
6772794b509ab19275094052830015ba *7490.06.51-v2-20160415_1026/GPL/GPL-wlan.tar.gz
197fcbf6e68090f52edbaf20efbe055a *7490.06.51-v2-20160415_1026/GPL/LGPL-GPL-release_fon_tools.tar.gz
ea46e3e0c5219577336a4378ddfc381f *7490.06.51-v2-20160415_1026/GPL/LGPL-GPL-release_target_tools.tar.gz
43259e280beb24d79693a27592f938de *7490.06.51-v2-20160415_1026/GPL/LGPL-libexif.tar.gz
75c03c0659a95a99a3fbb4ad5c7c044e *7490.06.51-v2-20160415_1026/GPL/LGPL-libosip.tar.gz
27594e12f7f9cf40149521945d36928c *7490.06.51-v2-20160415_1026/GPL/LGPL-multimedia_fon.tar.gz
e9087b3448351a1ef5fd0f1987e21493 *7490.06.51-v2-20160415_1026/GPL/LGPL-neon.tar.gz
dbac5d8d75159be7e3cd3995a5be91da *7490.06.51-v2-20160415_1026/GPL/ZLIB-libz.tar.gz
#
8fa754dfda95f1defadd7b8e3cc851fa *7490.06.51-v3-20160601_1118/GPL/BSD-libflac.tar.gz
a1bba62f799525316b9d9e9a59eea0c7 *7490.06.51-v3-20160601_1118/GPL/GPL-avmacllib2.tar.gz
1788468c7d781f9b6d5a49b6d7a9b0e3 *7490.06.51-v3-20160601_1118/GPL/GPL-bridge-utils.tar.gz
7a5958e57d1fe5e8f9f86671826159a3 *7490.06.51-v3-20160601_1118/GPL/GPL-busybox.tar.gz
77164e45d9e2a5050b44709ce62f75c2 *7490.06.51-v3-20160601_1118/GPL/GPL-chrony.tar.gz
2f1f56b4bcf23460619ebbd60dfd0a3e *7490.06.51-v3-20160601_1118/GPL/GPL-davfs2.tar.gz
05c85a44202ea33d148e7abd74bba4a5 *7490.06.51-v3-20160601_1118/GPL/GPL-ftpd.tar.gz
3a741860ceba18b26b19e28fa15bb5f9 *7490.06.51-v3-20160601_1118/GPL/GPL-gcc.tar.gz
635495aa43980ad1e482bbb232037cd6 *7490.06.51-v3-20160601_1118/GPL/GPL-iproute2.tar.gz
9c0dfbba0981cfd2d77f012c80e2d932 *7490.06.51-v3-20160601_1118/GPL/GPL-lte_tools.tar.gz
642fd1656add221416105b51072c73b7 *7490.06.51-v3-20160601_1118/GPL/GPL-ntfs.tar.gz
c7047f975ee0162fd652b92dc05f41f3 *7490.06.51-v3-20160601_1118/GPL/GPL-release_kernel.tar.gz
2e622858e48fc8637a774bb1bc192d6a *7490.06.51-v3-20160601_1118/GPL/GPL-samba.tar.gz
fc73a33b29d5f59233f2cd4ce88ed066 *7490.06.51-v3-20160601_1118/GPL/GPL-usb_host_tools.tar.gz
b7655941a5d194976f22cf3ec6381d6a *7490.06.51-v3-20160601_1118/GPL/GPL-wlan.tar.gz
6c4f458210dc85adb4ef6504d21e7575 *7490.06.51-v3-20160601_1118/GPL/LGPL-GPL-release_fon_tools.tar.gz
d2268f3112fc0baaab8fddffaa7f4520 *7490.06.51-v3-20160601_1118/GPL/LGPL-GPL-release_target_tools.tar.gz
4a36fece5d0cf554af651dbc7080db2e *7490.06.51-v3-20160601_1118/GPL/LGPL-libexif.tar.gz
247f484c8f0899f4b611bb0fa4dc11d5 *7490.06.51-v3-20160601_1118/GPL/LGPL-libosip.tar.gz
fb51c60055313ded8c0c958053577571 *7490.06.51-v3-20160601_1118/GPL/LGPL-multimedia_fon.tar.gz
5814b34797975a05d180ab52a19aee1a *7490.06.51-v3-20160601_1118/GPL/LGPL-neon.tar.gz
bd2d378f5e965fcd862d0ab1d9846c4d *7490.06.51-v3-20160601_1118/GPL/ZLIB-libz.tar.gzPeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Das sind die von mir für die 06.50-Quellen in #257 Abs. 4 bemerkten Korrekturen bei den Kommandos zum Ändern der Symlinks von "/home/gjungnick/..." auf die korrekten relativen Pfade im Kernel-Source-Baum - nun offenbar auch in den 06.51-Quellen geändert.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich habe gerade mal Zeit gehabt und bei der aktuellen Version der Quellen noch einmal in die arch/mips/kernel/vmlinux.lds.S geschaut:
Da ist (meines Erachtens) außer der Definition der beiden AVM-Symbole nichts zu sehen (die 64K dazwischen sind "unkonfiguriert") und - wenn ich das richtig verstehe - es fehlt entweder ein passendes Overlay-Linken irgendwo an anderer Stelle (so nach der Art: "Lade Modul XY an Adresse '__avm_kernel_config_start+x'.") oder gleich das Einbinden der passenden Objektdateien an dieser Stelle in das Datensegment des Kernels bzw. irgendwelche Assembler-Quellen (in C ist es sicherlich eher umständlich), die dann wieder "__avm_kernel_config_start" als "Referenzpunkt" für die Definition weiterer Datenstrukturen benutzen.
Die ersten 32 Bit an __avm_kernel_config_start sind ja erst einmal ein Pointer auf das Array aus _avm_kernel_config-Strukturen, über die in init/avm_kernel_config.c in der Funktion init_avm_kernel_config() dann iteriert wird.
Ich finde jedenfalls bei der Textsuche nach "__avm_kernel_config_start" über die gesamten Quellen nur drei Dateien, in denen das überhaupt auftaucht:
, die Stellen aus dem Header-File sind lediglich aus einer Inline-Funktion, welche die Adresse des Bereichs als externes Symbol enthält und beim Aufruf diese Adresse wieder als Pointer (mit dem Namen avm_kernel_config) auf die _avm_kernel_config-Struktur (bzw. auf den ersten Eintrag des Arrays) ablegt.
Im Assembler-Code für den Kernel taucht das sowohl bei ARM als auch bei MIPS dann nur als Name für den aktuellen Stand des Allocation-Counters auf und die zusätzliche Referenz im ARM-Kernel besteht auch nur aus einem unbenannten 32-Bit-Pointer unmittelbar nach einem "unconditional branch" (b 1f - was als Sprungziel unmittelbar nach diesem Pointer liegt).
Da auch diese Adresse erst einmal nirgendwo in ein Register geladen wird o.ä., kann ich mir nur vorstellen, daß das irgendwo über "kernel_entry+4" referenziert wird. Aber auch so eine Fundstelle findet sich in den von AVM bereitgestellten Quellen wieder nicht ... nun sind die ja (theoretisch) auch für ein MIPS-Gerät (selbst wenn AVM da wohl weitgehend aus einem Topf arbeitet).
Die neuen OpenSource-Pakete für die 06.50 (vom 01.06.2016, SHA1: a6179fb83b61bc6f3dab8ddd6aaaec2db2183117, interne Timestamps vom 31.05.2016) unterscheiden sich bei den Sourcen für den Linux-Kernel gleich gar nicht von der Vorgängerversion ... da müssen sich also andere Pakete (habe ich nicht geprüft) geändert haben, damit die Änderung/neue Veröffentlichung Sinn ergibt.
Code:
_sdata = .; /* Start of data section */
RODATA
/* writeable */
__data_start = .;
.data : { /* Data */
. = . + DATAOFFSET; /* for CONFIG_MAPPED_KERNEL */
INIT_TASK_DATA(THREAD_SIZE)
NOSAVE_DATA
CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
DATA_DATA
CONSTRUCTORS
. = ALIGN(4 * 1024);[COLOR="#FF0000"]
__avm_kernel_config_start = .;
. += 64 * 1024;
__avm_kernel_config_end = .;[/COLOR]
}
_gp = . + 0x8000;
.lit8 : {
*(.lit8)
}
.lit4 : {
*(.lit4)
}
/* We want the small data sections together, so single-instruction offsets
can access them all, and initialized data all before uninitialized, so
we can shorten the on-disk segment size. */
.sdata : {
*(.sdata)
}
_edata = .; /* End of data section */Die ersten 32 Bit an __avm_kernel_config_start sind ja erst einmal ein Pointer auf das Array aus _avm_kernel_config-Strukturen, über die in init/avm_kernel_config.c in der Funktion init_avm_kernel_config() dann iteriert wird.
Ich finde jedenfalls bei der Textsuche nach "__avm_kernel_config_start" über die gesamten Quellen nur drei Dateien, in denen das überhaupt auftaucht:
Code:
$ grep -r __avm_kernel_config_start
include/linux/avm_kernel_config.h: extern unsigned int __avm_kernel_config_start __attribute__ ((weak));
include/linux/avm_kernel_config.h: if (IS_ERR(&__avm_kernel_config_start) ||
include/linux/avm_kernel_config.h: (&__avm_kernel_config_start == NULL))
include/linux/avm_kernel_config.h: (struct _avm_kernel_config **)&__avm_kernel_config_start;
arch/arm/kernel/head.S: .word __avm_kernel_config_start
arch/arm/kernel/vmlinux.lds.S: __avm_kernel_config_start = .;
arch/mips/kernel/vmlinux.lds.S: __avm_kernel_config_start = .;Im Assembler-Code für den Kernel taucht das sowohl bei ARM als auch bei MIPS dann nur als Name für den aktuellen Stand des Allocation-Counters auf und die zusätzliche Referenz im ARM-Kernel besteht auch nur aus einem unbenannten 32-Bit-Pointer unmittelbar nach einem "unconditional branch" (b 1f - was als Sprungziel unmittelbar nach diesem Pointer liegt).
Da auch diese Adresse erst einmal nirgendwo in ein Register geladen wird o.ä., kann ich mir nur vorstellen, daß das irgendwo über "kernel_entry+4" referenziert wird. Aber auch so eine Fundstelle findet sich in den von AVM bereitgestellten Quellen wieder nicht ... nun sind die ja (theoretisch) auch für ein MIPS-Gerät (selbst wenn AVM da wohl weitgehend aus einem Topf arbeitet).
Die neuen OpenSource-Pakete für die 06.50 (vom 01.06.2016, SHA1: a6179fb83b61bc6f3dab8ddd6aaaec2db2183117, interne Timestamps vom 31.05.2016) unterscheiden sich bei den Sourcen für den Linux-Kernel gleich gar nicht von der Vorgängerversion ... da müssen sich also andere Pakete (habe ich nicht geprüft) geändert haben, damit die Änderung/neue Veröffentlichung Sinn ergibt.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Zur Info ... ich habe - nach mehr als 14 Tagen seit der letzten Information - heute noch einmal bei AVM wegen der korrekten OpenSource-Pakete angefragt.
In der letzten "Wasserstandsmeldung" hieß es ja nur, die Bereitstellung der Pakete würde (per E-Mail wahrscheinlich) bekanntgegeben und ich hatte (ich weiß ja nicht, wie es anderen da so gehen würde) nun eher nicht damit gerechnet, daß das längere Zeit in Anspruch nehmen würde (mal von den meinerseits vermuteten Schwierigkeiten bei der Abgrenzung zwischen "closed source" und "open source" abgesehen, aber dann würde ich zumindest eine entsprechende Nachricht erwarten, daß es sich (unvorhergesehen?) verzögert).
Da jetzt die Urlaubs- und Ferienzeit losgeht und mancher bestimmt auch diese nutzen würde, um sich mit seiner FRITZ!Box zu befassen (alle Jahre wieder, solche Nutzer gibt es ja auch), wäre es m.E. nicht so praktisch, wenn da noch zwei Monate ins Land gehen, bis die (funktionierenden) Quellen verfügbar sind - dann wäre bestimmt bereits wieder das nächste Release (vielleicht so um die IFA herum?) auf dem Weg und dann hinkt man mit Freetz (oder anderen eigenen Änderungen) immer weiter hinterher ... auch das ist ja nicht die Grundidee bei der GPL, daß man sich dann immer mit "etwas Altem" zufriedengeben muß, nur weil die Quellen für die geänderten Versionen (funktionsfähig) erst dann verfügbar sind, wenn bei den "closed source"-Teilen schon der Nachfolger in den Startlöchern steht.
Meine Mail ist gerade erst raus ... ich werde von der Reaktion berichten.
In der letzten "Wasserstandsmeldung" hieß es ja nur, die Bereitstellung der Pakete würde (per E-Mail wahrscheinlich) bekanntgegeben und ich hatte (ich weiß ja nicht, wie es anderen da so gehen würde) nun eher nicht damit gerechnet, daß das längere Zeit in Anspruch nehmen würde (mal von den meinerseits vermuteten Schwierigkeiten bei der Abgrenzung zwischen "closed source" und "open source" abgesehen, aber dann würde ich zumindest eine entsprechende Nachricht erwarten, daß es sich (unvorhergesehen?) verzögert).
Da jetzt die Urlaubs- und Ferienzeit losgeht und mancher bestimmt auch diese nutzen würde, um sich mit seiner FRITZ!Box zu befassen (alle Jahre wieder, solche Nutzer gibt es ja auch), wäre es m.E. nicht so praktisch, wenn da noch zwei Monate ins Land gehen, bis die (funktionierenden) Quellen verfügbar sind - dann wäre bestimmt bereits wieder das nächste Release (vielleicht so um die IFA herum?) auf dem Weg und dann hinkt man mit Freetz (oder anderen eigenen Änderungen) immer weiter hinterher ... auch das ist ja nicht die Grundidee bei der GPL, daß man sich dann immer mit "etwas Altem" zufriedengeben muß, nur weil die Quellen für die geänderten Versionen (funktionsfähig) erst dann verfügbar sind, wenn bei den "closed source"-Teilen schon der Nachfolger in den Startlöchern steht.
Meine Mail ist gerade erst raus ... ich werde von der Reaktion berichten.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ja und nein ... das bringt aber nichts, es erneut zu erklären, Du müßtest dazu den Thread mehr oder weniger komplett lesen (oder zumindest ein paar Seiten zurück).
Mit den derzeit verfügbaren Quellen (wenn es nicht schon wieder ein "stilles Update" gab ... habe ich nicht geprüft, weil mir ja eine Nachricht avisiert wurde bei Änderungen) kann man keinen funktionsfähigen Linux-Kernel in Version 3.10.73 erstellen (behaupte ich zumindest und versuche es auch zu belegen), wie er in der von AVM bereitgestellten Firmware (konkret hier für die 7490) enthalten ist.
Mithin ist in Freetz die Option "replace kernel" als Voraussetzung für einige Pakete nicht nutzbar und man kann auch keine anderen eigenen Änderungen abseits von Freetz am Kernel vornehmen (z.B. einen Backport von overlayfs einbauen, das erst ab 3.18 im Vanilla-Kernel enthalten ist).
Zuletzt bearbeitet:
Würde es etwas bringen, wenn mehr Leute beim AVM support funktionierende Quellen verlangen? Ich würde mich mit anschliessen.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Keine Ahnung ... mir fehlt im Moment die Zeit, "beweissicher" zu dokumentieren, daß und warum genau es m.E. nicht funktioniert.
Das ist auch ein ziemlicher Haufen an Arbeit, mit den AVM-Quellen die passende Toolchain zu erzeugen ... meine eigene Nachfrage bei AVM hat jedenfalls nicht den erhofften Erfolg gebracht (der derzeit verfügbare Stand funktioniert m.E. genauso wenig wie die Vorläufer mit dem 3er-Kernel) und bisher hat mich auch noch niemand auf einen Kardinalfehler aufmerksam gemacht bzw. mit diesen Quellen seinerseits einen funktionierenden Kernel erzeugt (oder zumindest hat m.W. noch niemand davon berichtet).
Ob da tatsächlich die Masse es macht bei weiteren Anfragen, kann ich nicht einschätzen ... ich bin noch nicht einmal 100%ig bereit, die Schuld an der Misere AVM anzulasten - jedenfalls nicht ohne nachvollziehbare und veröffentlichte Dokumentation, wo die AVM-Quellen eben nicht funktionieren.
Da am Ende AVM wohl ohnehin nur mit den Schultern zucken würde und dann (mit ganz ganz viel Glück) vielleicht die nächste Version bereitstellt (was man selbst dort an Zeit investieren muß, um so einen Nachweis zu führen, interessiert in diesem Falle ja wohl eher nicht bei AVM), bin ich hier ohnehin eher der Meinung, man sollte sich lieber selbst helfen.
Zumindest bei diesem konkreten Problem mit dem init_avm_kernel_config() ... hier müßte man sich ein Skript bauen, welches aus einem funktionierenden Kernel das Array an der Adresse __avm_kernel_config_start ausliest (das ginge mit "devmem"-Applet und /proc/kallsyms) und daraus die notwendigen Source-Dateien generiert, die man dann übersetzen und als Overlay in den Kernel mit einlinken müßte. Die einzige Box, wo ich das Bereitstellen eines OpenFirmware-kompatiblen DTB-Blobs bereits im Bootloader unterstellen würde, wäre die 7580 - soweit sich das anhand der bisher verfügbaren Firmware sagen läßt. Die sollte dann tatsächlich mit den AVM-Quellen funktionieren ... wobei auch da ein Blick in die Quellen sicherlich nicht schaden kann, denn die Module-Liste (die DTBs/Subrevisions-Einträge sind ja nur ein Teil der in init_avm_kernel_config() kopierten Daten) müßte auch bei der 7580 ja irgendwoher kommen.
Aber zumindest kann eine gewisse Menge an Anfragen an den Support wohl auch nicht schaden ... solange man es nicht übertreibt. Wenigstens wird dann aus dem Einzelfall vielleicht doch das Anliegen einer (größeren?) Gruppe ... daß ich da tatsächlich einige Probleme auf AVM zukommen sehe bei der Trennung von "open source" und "closed source", habe ich irgendwo auch schon geschrieben.
Leider würde es wieder einen erheblichen Aufwand bedeuten, den Nachweis der Unvollständigkeit zu führen und selbst dann kann in D eben nur einer der betroffenen Copyright-Holder AVM auch wirklich verklagen. Außer "schlechter Presse" (und auch das ist wohl selten einfach, weil AVM ja auch ein zahlender Werbekunde bei den meisten Fachzeitschriften ist) ist da wenig zu befürchten und seitdem immer mehr Leute auf Einplatinen-Computer für zusätzliche Aufgaben umsteigen, ist (mein Empfinden) auch das Interesse an der Modifikation der FRITZ!Boxen (zumindest an solchen, die einen eigenen Kernel erforderlich machen) so stark zurückgegangen, daß wohl kaum der notwendige Druck entstehen würde.
Vielleicht sollte man sich mal an die FSFE wenden ... aber dazu bräuchte es auch wieder den "Nachweis", daß die AVM-Quellen tatsächlich unvollständig sind. Solange die aber auch mal "silent" aktualisiert werden (das kriegt @er13 meist auch nur anhand der Hash-Werte mit), steht man m.E. bei so einem Vorhaben immer wieder auf verlorenem Posten - AVM könnte einfach die Quellen gegen funktionierende austauschen und man bleibt auf seinem gesamten Aufwand sitzen, weil wohl kein Gericht bei einem bereits behobenen Mißstand im Nachhinein noch ein Verfahren eröffnen würde, in dessen Rahmen man seinen Aufwand für die Beweisführung irgendwie abgelten lassen könnte.
So sehe ich das jedenfalls ... da ich auch nicht ausschließen will, daß ich mich nur zu dämlich anstelle, will ich auch keinen expliziten Vorwurf bisher erheben, solange ich den nicht beweisen kann. Wenn sich noch zwei bis drei Leute mit den entsprechenden Kenntnissen meinem Standpunkt anschließen, sieht das schon wieder ganz anders aus - ich stehe nur ungern als der dumme August da, der irgendwelche unhaltbaren Vorwürfe erhebt ... daher auch meine bisherige Zurückhaltung und die Betonung, daß das nur meine eigenen Erfahrungen/Erkenntnisse sind.
Sich auf diese jetzt bei einer Anfrage an AVM zu berufen, ist zwar nicht vollkommen abwegig (vielleicht läßt sich ja auch jemand bei AVM dazu herab, das korrekte/notwendige Vorgehen irgendwie mal zu dokumentieren) ... aber das sollte (derzeit) auch nicht darauf hinauslaufen: "Wie Sie im IPPF lesen können ..." in so einer Anfrage bei AVM.
Das dann bitte erst mit wasserdichter Beweisführung ... schon dieses "wasserdicht" ist nicht ganz so einfach, weil es eben kein umfassendes "Build-Skript" gibt (mal von "gpl_compile_kernel.sh" abgesehen, was m.W. auch nicht überall dabei ist), was man einfach nur aufrufen müßte.
Das fordert zwar die GPL eigentlich ausdrücklich:
Insofern ist das - und soweit gehe ich dann doch mit meiner Kritik an der Haltung von AVM - im Moment nur ein "Mäntelchen der Offenheit", was man sich da umhängt ... sicherlich keine ganz so schlechte Strategie (und das halte ich nicht für einen Zufall), um Kritik mit der Behauptung "Was wollt Ihr denn, da stehen doch die Dateien!" entgegentreten zu können. Ob die jetzt auch noch funktionieren, interessiert die Masse dann nicht mehr ... nicht einmal mehr irgendwelche Journalisten, wenn die dann noch über ein "quelloffenes FRITZ!OS" berichten und am Ende aber gar nicht wirklich wissen, wovon sie da gerade schreiben.
Das ist auch ein ziemlicher Haufen an Arbeit, mit den AVM-Quellen die passende Toolchain zu erzeugen ... meine eigene Nachfrage bei AVM hat jedenfalls nicht den erhofften Erfolg gebracht (der derzeit verfügbare Stand funktioniert m.E. genauso wenig wie die Vorläufer mit dem 3er-Kernel) und bisher hat mich auch noch niemand auf einen Kardinalfehler aufmerksam gemacht bzw. mit diesen Quellen seinerseits einen funktionierenden Kernel erzeugt (oder zumindest hat m.W. noch niemand davon berichtet).
Ob da tatsächlich die Masse es macht bei weiteren Anfragen, kann ich nicht einschätzen ... ich bin noch nicht einmal 100%ig bereit, die Schuld an der Misere AVM anzulasten - jedenfalls nicht ohne nachvollziehbare und veröffentlichte Dokumentation, wo die AVM-Quellen eben nicht funktionieren.
Da am Ende AVM wohl ohnehin nur mit den Schultern zucken würde und dann (mit ganz ganz viel Glück) vielleicht die nächste Version bereitstellt (was man selbst dort an Zeit investieren muß, um so einen Nachweis zu führen, interessiert in diesem Falle ja wohl eher nicht bei AVM), bin ich hier ohnehin eher der Meinung, man sollte sich lieber selbst helfen.
Zumindest bei diesem konkreten Problem mit dem init_avm_kernel_config() ... hier müßte man sich ein Skript bauen, welches aus einem funktionierenden Kernel das Array an der Adresse __avm_kernel_config_start ausliest (das ginge mit "devmem"-Applet und /proc/kallsyms) und daraus die notwendigen Source-Dateien generiert, die man dann übersetzen und als Overlay in den Kernel mit einlinken müßte. Die einzige Box, wo ich das Bereitstellen eines OpenFirmware-kompatiblen DTB-Blobs bereits im Bootloader unterstellen würde, wäre die 7580 - soweit sich das anhand der bisher verfügbaren Firmware sagen läßt. Die sollte dann tatsächlich mit den AVM-Quellen funktionieren ... wobei auch da ein Blick in die Quellen sicherlich nicht schaden kann, denn die Module-Liste (die DTBs/Subrevisions-Einträge sind ja nur ein Teil der in init_avm_kernel_config() kopierten Daten) müßte auch bei der 7580 ja irgendwoher kommen.
Aber zumindest kann eine gewisse Menge an Anfragen an den Support wohl auch nicht schaden ... solange man es nicht übertreibt. Wenigstens wird dann aus dem Einzelfall vielleicht doch das Anliegen einer (größeren?) Gruppe ... daß ich da tatsächlich einige Probleme auf AVM zukommen sehe bei der Trennung von "open source" und "closed source", habe ich irgendwo auch schon geschrieben.
Leider würde es wieder einen erheblichen Aufwand bedeuten, den Nachweis der Unvollständigkeit zu führen und selbst dann kann in D eben nur einer der betroffenen Copyright-Holder AVM auch wirklich verklagen. Außer "schlechter Presse" (und auch das ist wohl selten einfach, weil AVM ja auch ein zahlender Werbekunde bei den meisten Fachzeitschriften ist) ist da wenig zu befürchten und seitdem immer mehr Leute auf Einplatinen-Computer für zusätzliche Aufgaben umsteigen, ist (mein Empfinden) auch das Interesse an der Modifikation der FRITZ!Boxen (zumindest an solchen, die einen eigenen Kernel erforderlich machen) so stark zurückgegangen, daß wohl kaum der notwendige Druck entstehen würde.
Vielleicht sollte man sich mal an die FSFE wenden ... aber dazu bräuchte es auch wieder den "Nachweis", daß die AVM-Quellen tatsächlich unvollständig sind. Solange die aber auch mal "silent" aktualisiert werden (das kriegt @er13 meist auch nur anhand der Hash-Werte mit), steht man m.E. bei so einem Vorhaben immer wieder auf verlorenem Posten - AVM könnte einfach die Quellen gegen funktionierende austauschen und man bleibt auf seinem gesamten Aufwand sitzen, weil wohl kein Gericht bei einem bereits behobenen Mißstand im Nachhinein noch ein Verfahren eröffnen würde, in dessen Rahmen man seinen Aufwand für die Beweisführung irgendwie abgelten lassen könnte.
So sehe ich das jedenfalls ... da ich auch nicht ausschließen will, daß ich mich nur zu dämlich anstelle, will ich auch keinen expliziten Vorwurf bisher erheben, solange ich den nicht beweisen kann. Wenn sich noch zwei bis drei Leute mit den entsprechenden Kenntnissen meinem Standpunkt anschließen, sieht das schon wieder ganz anders aus - ich stehe nur ungern als der dumme August da, der irgendwelche unhaltbaren Vorwürfe erhebt ... daher auch meine bisherige Zurückhaltung und die Betonung, daß das nur meine eigenen Erfahrungen/Erkenntnisse sind.
Sich auf diese jetzt bei einer Anfrage an AVM zu berufen, ist zwar nicht vollkommen abwegig (vielleicht läßt sich ja auch jemand bei AVM dazu herab, das korrekte/notwendige Vorgehen irgendwie mal zu dokumentieren) ... aber das sollte (derzeit) auch nicht darauf hinauslaufen: "Wie Sie im IPPF lesen können ..." in so einer Anfrage bei AVM.
Das dann bitte erst mit wasserdichter Beweisführung ... schon dieses "wasserdicht" ist nicht ganz so einfach, weil es eben kein umfassendes "Build-Skript" gibt (mal von "gpl_compile_kernel.sh" abgesehen, was m.W. auch nicht überall dabei ist), was man einfach nur aufrufen müßte.
Das fordert zwar die GPL eigentlich ausdrücklich:
(im Original)GPLv2-Lizenz §3 - deutsche Übersetzung auf gnu.de schrieb:
, aber es war bis vor ca. 1,5 Jahren ja sogar so, daß es von AVM nicht einmal das "gpl_compile_kernel.sh" gab, dort kann man jetzt ja wenigstens sehen, welche (teilweise auch nur Dummy-)Module zusätzlich in den Kernel-Build integriert werden müssen. Von einem Skript zum "Bauen" eines FRITZ!OS-Images (das wäre theoretisch die komplette Image-Datei, so wie sie von AVM bereitgestellt wird in binärer Form, ggf. mit Ausnahme der Signatur, weil da wohl niemand das Veröffentlichen des privaten Schlüssels fordern würde) ist da weit und breit definitiv (und das schreibe ich selten so deutlich) nichts zu sehen.GPLv2 License schrieb:
Insofern ist das - und soweit gehe ich dann doch mit meiner Kritik an der Haltung von AVM - im Moment nur ein "Mäntelchen der Offenheit", was man sich da umhängt ... sicherlich keine ganz so schlechte Strategie (und das halte ich nicht für einen Zufall), um Kritik mit der Behauptung "Was wollt Ihr denn, da stehen doch die Dateien!" entgegentreten zu können. Ob die jetzt auch noch funktionieren, interessiert die Masse dann nicht mehr ... nicht einmal mehr irgendwelche Journalisten, wenn die dann noch über ein "quelloffenes FRITZ!OS" berichten und am Ende aber gar nicht wirklich wissen, wovon sie da gerade schreiben.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Na ja, so eine .config könnte man ja noch anpassen - da würde ich tatsächlich "Gnade vor Recht" ergehen lassen.
Aber im Moment fehlen eben notwendige Teile (noch mal: aus meiner Sicht) und selbst wenn man sich seine eigene Konfiguration zusammensucht, kann man aus den bereitgestellten Quelltext-Dateien keinen funktionierenden Kernel erstellen.
Da, wo beim Kernel 2.6 noch durch das Auskommentieren von "init_avm_kernel_config()" ein Workaround möglich war (da passierte auch noch deutlich weniger in dieser Funktion), ist seit 3.10 nur noch der Fehler beim Initialisieren des "device tree" als Ergebnis zu verzeichnen, weil in init_avm_kernel_config() eben kein Eintrag für einen solchen an der richtigen Stelle erzeugt wird, solange an der Adresse "__avm_kernel_config_start" keine Daten für das Kopieren liegen.
Aber im Moment fehlen eben notwendige Teile (noch mal: aus meiner Sicht) und selbst wenn man sich seine eigene Konfiguration zusammensucht, kann man aus den bereitgestellten Quelltext-Dateien keinen funktionierenden Kernel erstellen.
Da, wo beim Kernel 2.6 noch durch das Auskommentieren von "init_avm_kernel_config()" ein Workaround möglich war (da passierte auch noch deutlich weniger in dieser Funktion), ist seit 3.10 nur noch der Fehler beim Initialisieren des "device tree" als Ergebnis zu verzeichnen, weil in init_avm_kernel_config() eben kein Eintrag für einen solchen an der richtigen Stelle erzeugt wird, solange an der Adresse "__avm_kernel_config_start" keine Daten für das Kopieren liegen.
Neueste Beiträge
-
[Problem] 5690 wlan modul
- Letzte: Vivacala
-
5690 Pro - Manche Apps / Webseiten laden nicht über WiFi 7 (S24 Ultra)
- Letzte: Frank Bearson
-
Be.IP hinter Fritzbox Fiber- Letzte: chrsto
-
Yealink SIP T42U keine Auslandsgepräche
- Letzte: KunterBunter
-
Plain White Screen and Freezing Issues on Avaya J100 SIP Phones
- Letzte: evelynfreya
