[Problem] FB7490 Netzwerk tot

[JojoS]

Hallo,
habe eine 7490 aus unserem E-Schrott gefischt weil die noch gut aussah und ich gehofft habe das evtl. nur ein Recovery nötig ist. War aber leider nicht möglich, keine Netzwerkverbindung, es gibt keinen physikalischen Link. Ist also ein härterer Fall.
Beim Start gehen ein paar LED an, nach ca. 1 min. blinken WLAN/Internet kurz und dann bootet die Box wieder. Ich habe dann die serielle Schnittstelle gesucht und ein Bootlog aufgezeichnet. Da sind ein paar Fehlermeldungen und Auffäligkeiten zu sehen, die Ursache habe ich aber noch nicht gefunden.
Ich habe den autostart disabled, dann einen restart gemacht und aufgezeichnet. EVA meldet sofort: .<ERROR no valid external Phy detected 0x0 0x0>
Der Phy (bzw. zwei) sind natürlich noch auf der Platine und 3,3V und 1,1V bekommen die auch. Das booten läuft weiter und werden nand pages angemeckert:

[    6.310000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x9a92)

ist das kritisch?
Zum Reboot führt dann

[   14.850000][0] [piglet] try to preload in progress-context: /lib/modules/bitfile_isdn.bit
[   15.920000][0] [piglet] bitfile 72761 bytes done
[   15.920000][0] [piglet] "wyatt_earp_unload_xilinx" not loaded

Es kann natürlich ein HW defekt sein, aber vielleicht kann hier jemand das Logfile besser deuten. Die Spannungsversorgung über ein Labornetzeil ist jedenfalls i.O. und auf der Platine messe ich auch an den Schaltreglern die typ. 5V, 3,3V, 2,5V usw.

 

[H´Sishi]

Moin.

Die Firmware paßt schonmal zu ner 7490 (113.06.24). WLAN-Key steht im Bootlog (SSID leider nicht), TR069-Daten existieren, Seriennr. fehlt.

Sind denn irgendwelche offensichtlichen Schäden zu sehen?
- durchgebrannte oder sonstwie beschädigte Bauteile (z.B. aufgeblähte Kondensatoren)
- abgebrochene oder abgelöste Beinchen (z.B. bei stehend montierten Widerständen oder Kondensatoren)
- zerkratzte, durchtrennte oder überbrückte Leiterbahnen (z.B. nach vorherigen Reparaturversuchen)

Machen die Schaltregler bzw. die dazugehörigen Spulen irgendwelche Geräusche (Pfeifen oder Zischen)?
Paßt das Netzteil zur Box (abgegebener Maximal-Strom)? Sehe grade, daß die Box von einem Labornetzteil versorgt wird.

Daß die Schaltregler die Spannungen korrekt abgeben bedeutet nicht, daß die auch sauber und stabil bei den Schnittstellen-Bauteilen ankommen (durchtrennte Leiterbahnen, defekte Transistoren).

[    6.140000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock3

*snip*

[    6.310000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x9a92)
[    6.320000] {ifx_hsnand_micron_read_page_hwecc} page 0x9a92 Sector 1 1 Biterror 0 OOB-Biterror 0 ECC-Biterror
[    6.340000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x7018)
[    6.350000] {ifx_hsnand_micron_read_page_hwecc} page 0x7018 Sector 1 1 Biterror 0 OOB-Biterror 0 ECC-Biterror
[    6.470000] [squashfs] use zip compression
[    6.540000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x7c72)
[    6.550000] {ifx_hsnand_micron_read_page_hwecc} page 0x7c72 Sector 2 1 Biterror 0 OOB-Biterror 0 ECC-Biterror
[    6.590000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x726b)
[    6.590000] {ifx_hsnand_micron_read_page_hwecc} page 0x726b Sector 0 1 Biterror 0 OOB-Biterror 0 ECC-Biterror

*snip*

[config-space] detected mtdmtd4: size '2097152'
modprobe: module nand not found in modules.dep

*snip*

[    8.350000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x8529)
[    8.360000] {ifx_hsnand_micron_read_page_hwecc} page 0x8529 Sector 2 1 Biterror 0 OOB-Biterror 0 ECC-Biterror
[    8.550000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0x7d95)
[    8.560000] {ifx_hsnand_micron_read_page_hwecc} page 0x7d95 Sector 2 1 Biterror 0 OOB-Biterror 0 ECC-Biterror

*snip*

[   22.210000] Kernel panic - not syncing: [piglet]bye bye - can't detect TDM-FS or TDM-CLK!
[   22.210000]
[   22.220000] Rebooting in 5 seconds..odules/bitfile_pots.bit
[   22.080000][0] [piglet] bitfile 72761 bytes done
[   22.080000][0] [piglet]TDM: FS: 8005 Hz CLK: 5 Hz

Entweder hat das Teil defekte Speicher oder ein Firmware-Update ist in die Hose gegangen.
Die 7490 hat zwei voneinander getrennte Flash-Partitionen für Firmwares, die man umschalten kann (siehe z.B. http://www.ip-phone-forum.de/showthread.php?t=272748 , "Bootmanager ..."). Vielleicht funktioniert die andere Partition. Ich weiß nur nicht, ob man die Box dazu bringen kann, die andere Partition zu verwenden, wenn sie nicht sauber hochfährt.

War es nicht auch möglich, ein Firmware-Update über die Konsole einzuspielen?

 

[PeterPawn]

Nach den AVM-Quellen (drivers/mtd/nand/ifxmips_mtd_dmanand.c, Z. 1013) ist "read block is critical" ein korrigierbarer ECC-Error, damit ist der Speicher dort sicherlich nicht vollkommen in Ordnung, aber nach wie vor lesbar. Ein nicht mehr über ECC zu korrigierender Fehler würde wohl als "read block failed" (Z. 1011) protokolliert.

Nach meiner Interpretation hat der Xilinx-DSP (DECT- und POTS-/ISDN-Anbindung) einen Schuß ... da das System bereits beim Laden des entsprechenden Treibers - der seinerseits die Firmware in den DSP laden soll - abstürzt, ist es wohl notwendig, die Ausführung von S11-piglet zu umgehen. Dieser Teil der Firmware ist aber komplett "closed source", da gibt es nicht mal sinnvolle Header-Files für die verwendeten Kernel-Module.

Zwar muß man die Box damit (vermutlich) noch nicht wegwerfen, solange man auf DECT-Basis und Telefonie-Funktionen verzichten kann, aber das ist einiges an Arbeit, was auf Dich zukäme und der Erfolg ist nicht unbedingt garantiert. Meines Erachtens reicht es noch nicht, nur die betreffenden Config-Variablen für DECT und Telefonie auf "n" zu setzen - das Laden der Module in S11-piglet ist jedenfalls nicht an den Wert irgendeiner CONFIG-Variablen aus rc.conf gebunden. Die Firmware kannst Du Dir ja auch auf einem beliebigen Linux-System entpacken und dort hineinsehen.

Um eine Firmware ohne S11-piglet zu aktivieren, müßtest Du aus einer normalen AVM-Firmware das betreffende File aus /etc/init.d entfernen (oder die Kernel-Module oder irgendetwas anderes, damit piglet_noemif.ko nicht geladen wird - dort löst das Fehlen der korrekten Signale von Xilinx-Chip nach meiner Meinung eine "kernel panic" aus) und diese Firmware dann per EVA ins RAM der Box laden, von wo aus sie sich dann selbst ins NAND-Flash schreibt (Skript /sbin/flash_update im äußeren Dateisystem) und beim nächsten Start sollte dann ein FRITZ!OS ohne die Unterstützung für den DSP starten. Wenn man parallel zum Entfernen von S11-piglet noch ein paar CONFIG-Variablen so setzt, daß da keine Telefonie-Unterstützung in der Box vermutet wird, schadet das sicherlich auch nicht unbedingt. Am Ende kann man sich vermutlich an der Firmware einer 3490 orientieren, event. kann man die sogar im Original verwenden - das ist aber reines Experimentieren. Da man ja aber zwei Partitionen hat und der Bootloader offenbar unbeschädigt ist (einmal Recovery mit parallelem WireShark zum Test schadet sicherlich auch nicht und man versteht dann gleich, welche Kommandos man zu Fuß ausführen müßte, um eine 7490 auf 3490 zu trimmen), sollte etwas Spaß an der Freude nicht weiter gefährlich sein.

Ich würde tatsächlich einfach einmal hingehen (wenn ich eine ohnehin schon weitgehend nutzlose Box habe) und die Variablen im Urlader-Environment der 7490 auf die Einstellungen bei einer 3490 ändern ... vielleicht findet sich ja hier jemand, der mal diese Werte aus den Support-Daten einer 3490 für Dich extrahiert (die Boxen sind m.W. recht wenig verbreitet hier, ich habe gerade mal "meine Dateischätze" durchsucht und keine Support-Daten einer 3490 gefunden). Nach einer Anpassung von "ProductID", "HWRevision" und "HWSubRevision" könnte es theoretisch schon funktionieren, daß sogar das AVM-Recovery-Programm die 7490 als 3490 akzeptiert und die betreffende Firmware in den Speicher lädt. Zumindest kannst Du damit m.E. nichts kaputt machen ... wenn das Recovery-Programm die Box ablehnt, passiert gar nichts und wenn das System am Ende nicht zur Box passen sollte (man kann ja auch mal die beiden ausgepackten Firmware-Versionen vergleichen, wenn man vorher etwas genauer schauen will), dann startet man eben nach dem Rücksetzen der Environment-Variablen auf die originalen Werte noch einmal das richtige Recovery-Programm.

Meines Wissens ist die 3490 ja gerade eine 7490 ohne DECT und die externe Telefonie, während sich ansonsten die "inneren Werte" (auch die jeweiligen Größen von Flash- und Hauptspeicher) nicht weiter unterscheiden, selbst der USB3-Anschluß ist bei der 3490 ja wohl vorhanden.

EDIT: Weil das oben etwas komisch klingt ... die "ProductID" dürfte dem Recovery-Programm sogar vollkommen egal sein, aber die Firmware sucht nach dem Start dann mittels dieser Variablen nach einem Verzeichnis unterhalb von /etc und daher sollte dieser Wert dann auch zur 3490 passen. Die anderen Variablen müßten eigentlich entweder für jede Box individuell sein oder bei einer 7490 und einer 3490 übereinstimmen (MTD-Layout usw.). Der Wert bei "firmware_info" spielt beim Start keine Rolle (außer ein dort angehangenes "recovered=x"), der wird nach jedem Start ohnehin neu gesetzt von der laufenden Firmware.

 

[enrico1973]

Man könnte sie ja auch mal zu AVM senden, die 7490 gibt es doch noch keine 5 Jahre lang. Also dürfte doch noch eine Chance auf Garantie bestehen?

 

[H´Sishi]

Die Box wurde bereits geöffnet (Zugriff auf die Konsolen-Pins) - Garantie hinfällig.

 

[PeterPawn]

Ich habe gerade noch einmal in den Kernel-Quellen etwas weiter gesucht ... wie es aussieht, unterscheiden sich die 7490 und die 3490 auch bei der Verdrahtung der GPIO-Pins nur bei der Bedeutung einiger LEDs und Buttons und eben bei der Anbindung des Xilinx-FPGA (die DSP-Funktion ist ja wohl nur ein Subset der dort stattfindenden Operationen, daher war die o.a. Formulierung, der Xilinx-SoC wäre ein DSP, nicht ganz korrekt):

--- arch/mips/mach-infineon/vr9/avm_hw_config_hw212.h   2015-12-15 19:30:44.774641460 +0100
+++ arch/mips/mach-infineon/vr9/avm_hw_config_hw185.h   2015-12-15 19:30:44.774641460 +0100
@@ -1,11 +1,11 @@
 /*------------------------------------------------------------------------------------------*\
  *
- * Hardware Config für FRITZ!Box Fon 3490
+ * Hardware Config für FRITZ!Box Fon 7490
  *
 \*------------------------------------------------------------------------------------------*/

 #undef AVM_HARDWARE_CONFIG
-#define AVM_HARDWARE_CONFIG  avm_hardware_config_hw212
+#define AVM_HARDWARE_CONFIG  avm_hardware_config_hw185


 struct _avm_hw_config AVM_HARDWARE_CONFIG[] = {
@@ -31,7 +31,7 @@
         }
     },
     {
-        .name   = "gpio_avm_led_lan_all",  /* led4 */
+        .name   = "gpio_avm_led_internet",  /* led4 */
         .value  = 47,
         .param  = avm_hw_param_gpio_out_active_low,
         .manufactor_hw_config.manufactor_lantiq_gpio_config = {
@@ -40,7 +40,7 @@
         }
     },
     {
-        .name   = "gpio_avm_led_wlan",  /* led3 */
+        .name   = "gpio_avm_led_festnetz",  /* led3 */
         .value  = 36,
         .param  = avm_hw_param_gpio_out_active_low,
         .manufactor_hw_config.manufactor_lantiq_gpio_config = {
@@ -49,7 +49,7 @@
         }
     },
     {
-        .name   = "gpio_avm_led_pppoe",  /* led2 */
+        .name   = "gpio_avm_led_wlan",  /* led2 */
         .value  = 35,
         .param  = avm_hw_param_gpio_out_active_low,
         .manufactor_hw_config.manufactor_lantiq_gpio_config = {
@@ -76,9 +76,9 @@
         }
     },

-    /*--- WPS button connected to EXTIN 1 ---*/
+    /*--- DECT button connected to EXTIN 1 ---*/
     {
-        .name   = "gpio_avm_button_wps",
+        .name   = "gpio_avm_button_dect", // "gpio_avm_button_power" für 3370
         .value  = 1,
         .param  = avm_hw_param_gpio_in_active_low,
         .manufactor_hw_config.manufactor_lantiq_gpio_config = {
@@ -97,6 +97,168 @@
         }
     },

+
+    /*--------------------------------------------------------------------------------------*\
+     * DECT
+    \*--------------------------------------------------------------------------------------*/
+    {
+        .name   = "gpio_avm_dect_reset",
+        .value  = 30,
+        .param  = avm_hw_param_gpio_out_active_low,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PIGLET,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_dect_uart_rx",
+        .value  = 11,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PIGLET,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
+        }
+    },
+    {
+        .name   = "gpio_avm_dect_uart_tx",
+        .value  = 12,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PIGLET,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+
+
+    /*--------------------------------------------------------------------------------------*\
+     * FPGA
+    \*--------------------------------------------------------------------------------------*/
+    {
+        .name   = "gpio_avm_piglet_noemif_prog",
+        .value  = 15,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_piglet_noemif_clk",
+        .value  = 28,
+        .param  = avm_hw_param_gpio_out_active_high,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_piglet_noemif_data",
+        .value  = 20,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_piglet_noemif_done",
+        .value  = 19,
+        .param  = avm_hw_param_gpio_in_active_low,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_PUDEN_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_piglet_noemif_fpgaok",
+        .value  =  8,
+        .param  = avm_hw_param_gpio_in_active_high,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
+        }
+    },
+    /*--- DECT Irq connected to EXTIN 5 ---*/
+    {
+        .name   = "gpio_avm_piglet_dect_in",
+        .value  =  9,
+        .param  = avm_hw_param_gpio_in_active_low,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_piglet_clockout",
+        .value  =  7,
+        .param  = avm_hw_param_gpio_in_active_low,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_FPGA,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    /*--------------------------------------------------------------------------------*\
+     * TDM-Check (Clockmessung)
+    \*--------------------------------------------------------------------------------*/
+    {
+        .name   = "gpio_avm_tdm_fsc",
+        .value  = 0,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_TDMCHECK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
+        }
+    },
+    {
+        .name   = "gpio_avm_tdm_dcl",
+        .value  = 40,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_TDMCHECK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
+        }
+    },
+
+    /*--------------------------------------------------------------------------------------*\
+     * PCM-BUS
+    \*--------------------------------------------------------------------------------------*/
+    {
+        .name   = "gpio_avm_pcmlink_fsc",
+        .value  = 0,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PCMLINK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDSEL_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDEN_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_pcmlink_do",
+        .value  = 25,
+        .param  = avm_hw_param_gpio_out_active_low,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PCMLINK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OD_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_pcmlink_di",
+        .value  = 41,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PCMLINK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDSEL_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDEN_SET
+        }
+    },
+    {
+        .name   = "gpio_avm_pcmlink_dcl",
+        .value  = 40,
+        .param  = avm_hw_param_no_param,
+        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
+            .module_id = IFX_GPIO_MODULE_PCMLINK,
+            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDSEL_SET | IFX_GPIO_IOCTL_PIN_CONFIG_PUDEN_SET
+        }
+    },
+

     /*--------------------------------------------------------------------------------------*\
      * SPI

 

[JojoS]

Vielen Dank für eure Anteilnahme! Besonders an Peter für die ausführlichen Erklärungen. Als ich noch eine 7090 hatte da habe ich mal mit Freetz beschäftigt, mittlerweile habe ich eine (funktionierende) 7390 und da hat AVM ja schon soviel reingepackt das sich das Basteln kaum noch lohnt. Trotzdem war der Ausflug in die Innereien lehrreich.

Ich bin mittlerweile einen Schritt weiter, es ist doch wie schon anzunehmen ein HW Defekt. Interessant war aber das der Prozessor noch läuft und evtl. nur die Peripherie betroffen ist. Ich habe die HW nochmal mit einer Lupe abgesucht und bin fündig geworden: direkt unter dem Herzen, dem VRX288, ist ein (wahrscheinlich) NPN Transistor (Aufdruck 9B noch lesbar), der hat einen winzigen Pickel. Habe das vorher schon gesehen und für einen kleinen Gussgrat gehalten, aber unter dem Mikroskop sieht man das es ein kleiner Krater ist. Bilder sind angehängt, für das USB Mikroskop habe ich aber keine vernünftige Halterung und heute morgen sind meine Hände noch nicht so ruhig .
Wenn es ein NPN UN2222 ist dann wäre die Beschaltung wie im Bild. Am Kollektor liegen 3,3V, am Emitter messe ich ca. 2 Ohm nach Masse. Damit fliessen >1A durch den kleinen wenn er angesteuert wird und da er nur max. 0,5 A ab kann ist ihm wohl der Hut hochgegangen :-( Was der Transi schalten soll ist schwer zu verfolgen bei BGA und Multilayer, ich vermute der aktiviert einen Schaltungsteil im Prozessor oder in dem Kollegen VRX208 (deshalb LAN platt?). Schaltungsunterlagen sind vermutlich nicht zu bekommen, aber die BGAs möchte ich nicht wechseln... Schon das einlöten der Stiftleiste ist bei dem Multilayerboard nicht einfach. Habe C und E auch mal mit dem Multimeter gebrückt, das geht kurz über 1A und dann geht der Schaltregler in die Knie.
Auch wenn der Prozessor noch läuft (das Nand hat ja vielleicht auch was abbekommen) ist das ohne Netzwerk und USB nicht wirklich ein brauchbarer Rechner. Falls die Konfiuration strubbelig ist, kann man die Bereiche mtd3+4 im Flash mit der EVA löschen?
Die serielle Schnittstelle ist auf dem anderen Bild: schwarz = GND, grün = TxD, gelb = RxD.

 

[PeterPawn]

Ist denn das Netzwerk wirklich sicher tot? Daß es während des Ladens des Kernels kein Netz gibt, ist vollkommen normal. Erst wenn innerhalb der ersten 5 Sekunden in EVA auch der Switch nicht aktiviert wird, würde ich von einem Hardware-Defekt beim Netzwerk ausgehen. Du schreibst zwar, es gäbe keinen physikalischen Link, aber es wird nicht vollkommen klar, auf welchen Zeitpunkt beim Start der Box Du Dich dabei beziehst.

In der Regel sind Defekte des FPGA das Ergebnis eines Überspannungsschadens, der über externe Telefonleitungen bei einem nahe gelegenen Blitzeinschlag irgendwelche Leitungstreiber zerstört und dabei vor deren Zerstörung noch genug Energie "passieren" ließ, daß dahinter liegende Bauteile ebenfalls in Mitleidenschaft gezogen wurden.

Probleme mit dem FPGA wurden gerade bei der 7390 auch schon in anderen Threads berichtet, auch bei microcontroller.net gibt es entsprechende Berichte. Auch wenn die 7490 wohl etwas robuster auf Überspannungen von der Telefonieseite reagiert, ist auch sie nicht vollkommen gegen entsprechende Schäden gefeit.

Das verbaute Xilinx-FPGA ist zwar bei der 7490 ein "Spartan XC3S100E" (71K-Bitfile in der Firmware) und bei der 7390 ein "Spartan XC3S250E" (165 K-Bitfile), aber ich glaube nicht, daß die Ingenieure in der Entwicklung bei AVM prinzipiell unterschiedliche Schaltungsvarianten ohne Not umsetzen würden - eine zusätzliche Ableitung kleinerer Spannungsspitzen bei der 7490 im Vergleich zur 7390 (oder eine geänderte Leitungsführung) dürfte da schon ausreichend gewesen sein, um die etwas unempfindlicher zu machen.

 

[JojoS]

Ist denn das Netzwerk wirklich sicher tot?

ja, sofort wenn EVA startet kommt ja schon die Meldung das externe Phy nicht erkannt wurden. Wie ich die Architektur verstehe sind damit wohl die zwei AR8035-A geimeint, und die internen sind die zwei im VRX208? Ich habe jedenfalls alle Ports probiert und mehrere Bootzyklen durchlaufen lassen, der Windows Rechner am anderen Ende meldet nur 'kein Netzwerkkabel' und die LEDs am Netzwerkport sind aus. Ich habe das am Switch probiert und auch Punkt-zu-Punkt an einer eigenen Netzwerkkarte.
Ich habe auch nochmal gesucht wer die 2R Last macht, aber die Leitung vom Transistor geht weder zum FPGA, VRX208 oder anderen zugänglichen Chips.

 

[ciesla]

Die Box wurde bereits geöffnet (Zugriff auf die Konsolen-Pins) - Garantie hinfällig.

Fachmännisch gemacht, sieht man das überhaupt nicht ...
Weder an den Gehäuseschrauben, daß diese gedreht wurden, noch an den Pins, daß dort ein Stecker draufsteckte.

 

[JojoS]

naja, auch wenn ich Stiftleiste wieder auslöte sieht man da bei genauem Hinsehen die Zinnreste... Aber ich habe die Box wie geschrieben aus unserer Schrottbox geholt, habe also keine Kaufbelege. Und so dreist die mit geliehenen Belegen einem Händler unterzujubeln bin ich nicht.
Wenn wenigstens ein Ethernetport oder USB ginge wäre das ja noch ein schöner Linux Rechner, aber zu Zeiten wo man den RaspPi Zero für 10€ bekommt lohnt sich selbst das nicht.

 

[PeterPawn]

ja, sofort wenn EVA startet kommt ja schon die Meldung das externe Phy nicht erkannt wurden.

Ah ja ... das war aus dem Bootlog nicht so richtig zu sehen, da die Meldung bzgl. des PHY noch einmal am Ende der Datei stand - ich hatte die andere vor den Kernel-Messages gar nicht für voll genommen.

Sehe ich das richtig, daß die Zeile mit den Punkten vor den Kernel-Messages u.a. die Zeit abdeckt, in der der FTP-Server auf die Connection wartet?

Ich habe bei einer 7490 noch keine serielle Konsole verwendet/verwenden müssen und weiß nicht, ob der FTP-Server parallel zur Seriellen schon bereit ist oder erst nach dem "go" - praktisch vor dem Laden des Kernels - loslegen würde.

Die Meldung zum fehlenden PHY wird sicherlich auch nur seriell ausgegeben - daher kenne ich sie nicht und weiß auch nicht, ob sie bei einer einwandfrei funktionierenden 7490 nicht ebenso auftaucht.

Wenn da explizit von "external PHY" die Rede ist, frage ich mich allerdings, warum dann auch die beiden internen nicht funktionieren: http://www.codico.com/fileadmin/bilder/produkte/akt/Lantiq_XWAY-VRX288_Product-Brief_02.pdf (Blockdiagramm Seite 2)

Soweit ich weiß, sind LAN1 und LAN2 über die PHYs im VRX288 angebunden - da würde ich also am ehesten während des Wartens von EVA auf eine FTP-Verbindung einen Link erwarten. Aber wenn die nach Deinen Messungen die ganze Zeit tot sind, ist mit einer derart defekten Box ja nun wirklich gar nichts mehr anzufangen ... selbst wenn WLAN noch funktionieren würde, müßte man ja erst mal ein System auf die Box bringen, das sich vom defekten LAN nicht abschrecken läßt und das ginge dann vermutlich nur über ein (E)JTAG-Interface - ob da der Zugriff auf den NAND-Speicher überhaupt möglich ist (eigentlich reicht ja der auf das SPI-Flash mit dem Bootloader im Normalfall vollkommen aus), weiß ich auch nicht.

 

[H´Sishi]

OT:

Fachmännisch gemacht, sieht man das überhaupt nicht ...
Weder an den Gehäuseschrauben, daß diese gedreht wurden, noch an den Pins, daß dort ein Stecker draufsteckte.

Mir fällt da schon eine Kennzeichnung ein, z.B. Siegellack mit einer ungewöhnlichen Farbe an Stellen, wo die Gehäusehälften kontaktieren. Direkt vor'm Zusammenschrauben aufgebracht verklebt der Lack die Berührungsflächen und bricht dann hörbar auf, wenn man die Gehäusehälften auseinanderzieht. Fehlt dieses *knack*, war die Box schonmal offen.

Will man als Hersteller auf Nr. Sicher gehen (z.B. ein Neu-Verkleben mit frischem Siegellack erkennen), definiert man im Gehäuse eine Sollbruchstelle (z.B. einen Plastikpin), der beim Zusammensetzen mit einem Gegenstück verklebt wird. Auch hier knackt es beim Öffnen.
/OT

@JojoS:
Jep, Krater auf Transistoren und ähnlichen Halbleitern ist ein Zeichen von Bauteile-Tod. Ein Transistor kann sogar so heiß werden, daß die Oberseite komplett absprengt.

Aber wenn die Belegung stimmt und an diesem Ort Platz ist ... was spräche dagegen, einen ähnlichen Transistor mit höherer Stromfestigkeit zu verbauen?

 

[andiling]

Zur Ergänzung die Daten der 3490:

HWRevision	212
HWSubRevision	1
ProductID	Fritz_Box_HW212

 

[JojoS]

Aber wenn die Belegung stimmt und an diesem Ort Platz ist ... was spräche dagegen, einen ähnlichen Transistor mit höherer Stromfestigkeit zu verbauen?

da hätte ich schon was gebastelt, aber der Transistor ist mit Sicherheit nur in Folge gestorben weil irgendwas anderes kapputes eine zu hohe Last verursacht. Dafür war ja der Test mit dem Überbrücken durch Multimeter im Strommessbereich. Den Strom von >1A liefert der interne Spannungsregler nicht mehr. Diesen Transistor findet man unter dem anderen Prozessor auch, da ist diese Last von 2R nicht vorhanden.

Habe jetzt auch mal mtd3+4 gelöscht, es kommt eine Meldung 'create new TFFS' und dann aber wieder der Crash an der gleichen Stelle.

 

[H´Sishi]

Die Idee ist bzw. war, daß der Transistor eine strombegrenzende Funktion für das nachgeschaltete Bauteil hat. Eine Überbrückung könnte dieses Bauteil überlasten, deswegen der Gedanke mit einem Ersatz-Transistor.

Ist denn außer dem Transistor noch ein Bauteil sichtbar defekt?

Ansonsten hätte ich noch eine gewagte Bastel-Idee: Welche Spannung liegt an dem Transistor an?

Diese Spannung mittels einem Labornetzteil mit regelbarer Spannung bzw. Strom an den (jetzt totliegenden) Ausgang vom Transistor anlegen (mit der Netzteil-Masse gegen Platinen-Masse) und dann langsam der Spannung des Transistor-Eingangs annähern. Entweder erwacht irgendein Baustein zum Leben oder winkt mit der weißen (Rauch-) Fahne.

 

[JojoS]

Erfolge!
Hatte die Leidensgeschichte auch schon im µC.net gepostet, da bin ich eher unterwegs. Es gab noch den Tip die 3,3V extern einzuspeisen. Das wollte ich erst nicht weil das auch schiefgehen kann aber dem Mutigen gehört die Welt...
Der ganze Thread ist hier: https://www.mikrocontroller.net/topic/385314?goto=4403852#4402259
Aber der Vollständigkeit halber kopiere ich das Ergebnis auch hier rein:

von User 'User':
Lass doch mal von außen an der Stelle 3,3V + ein paar A rein. Das
defekte Bauteil sollte sich schnell erwärmen bzw. dir entgegen kommen.
Vielleicht ist nur ein Folienkondensator kurzgeschlossen.

an das brute-force freibrennen hatte ich auch schon gedacht, wollte das
wegen möglicher Kollateralschäden aber als letztes machen...
Ok, Draht für die 3,3V angelötet, und Bingo, es kommt wieder die
Fehlermeldung im Terminal, aber jetzt klappt dieser POTS Mode für das
Bitfile laden und das Linux kommt auf die Füsse! Ich hatte einen 0R8
Widerstand (oder eine Drossel?) ausgelötet, da ging erst nur LAN3+4,
nach dem wieder einlöten war auch LAN0+1 wieder da. USB ist auch i.O.,
so ist die Box immerhin als Medienserver zu gebrauchen.
Auf der 12 V Leitung zieht die Box 0,55 - 0,61 A, auf der zusätzlichen
3,3 V Leitung fliessen jetzt 0,6 - 0,9 A.
Da bleibt noch die Frage was das jetzt für ein Transistor war, das '9B'
hatte ich hiernach als UN2222 gedeutet, aber 500 mA max wäre zu wenig
wenn die 0,9 A normal sind.
http://www.ecadata.de/ddv/mysucheca.php?F_SPRACHE=...
hinter dem 9B ist noch ein Pluszeichen, aber ein 9B+ habe ich als SMD
Code nicht gefunden, hat jemand ein besseres Angebot?
Ok, wenn das ein NPN ist sind 3,3 V etwas zu viel des Guten, da gehen ja
noch 0,7V ab... Da ist noch zweiter 9B auf dem Board, nachgemessen, ist
so. Bei 2,6 V Versorgung fliessen dann auch nur noch 350 mA, das sieht
schon besser aus. Jetzt brauche ich nur noch so einen Transistor, dieser
UN2222 hat noch integrierte Widerstände. Oder ein Adapterplatinchen
basteln.

Ob das DSL Interface ok ist muss ich später testen, jetzt hängen an meiner Leitung ein halbes Dutzend Leute, die laufen Amok wenn Internet aus ist

 

[H´Sishi]

Mh, das ging ja schneller als ich schreiben konnte - das andere Board kenne ich nicht, aber war dieselbe Idee .

Die Frage ist nun, was hinter dem kaputten Transistor ist. 0,6 bis 0,9A klingt nach viel, wenn dabei die originale Versorgung auf der Platine in die Knie geht. Gibt's fühl- oder riechbare Erwärmungen?

 

[JojoS]

mit der ext. Spannung bin ich schon länger dran, hatte sich jetzt überschnitten.
Es hat sich definitiv etwas freigebrannt, aber es ist nix zu riechen oder zu sehen. Die 2 Ohm sind weg, jetzt messe ich irgendwas >100k. Und wie geschrieben dürfen nur 2,6 V da angelegt werden, dann ist der Strom auch bei moderateren 350 mA. Die 3,3 V haben vielleicht schon was anderes kaputt gemacht.

 

[PeterPawn]

Da hättest Du auch gleich den passenden Link zu µC.net angeben können, wenn Du nicht alles noch einmal schreiben wolltest ... dann hätte ich mir einen guten Teil meiner eigenen Schreibarbeit und Suche in den Quellen sparen können. Auch die Tatsache, daß Dir schon bewußt war, daß das System beim Laden des FPGA ablebt, hast Du zwar bei µC.net geschrieben, hier aber in #1 irgendwie vergessen.

Das einzige, was ich ggü. dem dortigen Thread durch die Stelle aus dem Quelltext des Treibers zusätzlich ausschließen konnte, war wohl das mit dem nicht korrigierbaren ECC-Fehler beim NAND-Flash.

Alles andere wurde dort bereits mehr oder weniger in genau derselben Form erwähnt - hätte es jetzt hier meiner Meinung nach nicht unbedingt noch einmal gebraucht.