[ gelöst ] 6490 per ftp/bootloader flashen

[PeterPawn]

Eine FRITZ!Box als Router verwendet einen "packet accelerator" (PA), mit dem bestimmte Pakete gar nicht mehr den kompletten Weg durch das System nehmen (sonst würden diese Geräte keine 100 MBit/s-DSL-Leitung mit Vectoring bedienen können) und i.d.R. von der Hardware bereits die meisten Pakete modifiziert (da geht es ja nur um das Umschreiben von Adressen und ggf. Ports) und direkt weitergeleitet werden, nachdem so eine TCP-Verbindung erst einmal aufgebaut wurde. Das erklärt dann vielleicht auch, warum in dem Mitschnitt praktisch alles zwischen SYN und FIN fehlt für diese Verbindungen.

Solange man auf so einer Box also den PA aktiviert hat (der Paketmitschnitt sollte den eigentlich automatisch deaktivieren, aber das klappt von Modell zu Modell und von Version zu Version sehr unterschiedlich), taugt sie nicht für derartige Untersuchungen ... hat man den aber manuell deaktiviert, geht (funktioniert) theoretisch auch eine solche Box. Allerdings ist das schon eine Menge an Arbeit bei der "Vorbereitung", wenn man bei einer halbwegs aktuellen FRITZ!OS-Version (ohne Shell-Zugang "ab Werk") erst einmal den PA deaktivieren will.

Vom zweiten Absatz verstehe ich noch den ersten Satz (bis zum zweiten Bindestrich) ... danach muß ich passen. Auch beim mehrmaligen Lesen erschließt sich mir der Sinn vom Rest nicht ... wenn es also wichtig ist, was dort steht und ich das verstehen sollte, mußt Du das noch einmal (anders und/oder deutlicher) schreiben.

 

[stoney]

Ok - F!B ohne tiefgreifende Eingriffe sind als Mirror nicht tauglich.

Sry ja jetzt nachdem ich es nochmals lese....

Also:
Ich habe noch eine zweite ehemalige UM Box da welche schon 6.63/6.62 installiert hat. (certs = old/old)

Mit dieser könnte ich ja das flashen per FTP in die einzelnen mtd's nochmals unter gleichen Vorraussetzungen testen, ob es wirklich am "Sender" liegt (natürlich unter den gleichen Bedingungen bei beiden PCs), wenn diese Übertragungen korrekt verlaufen und die Box dann in beiden Partitionen die 6.63 liegt, kann es ja an der HW sowie der einzelnen speziefischen config nicht liegen, oder liege ich da falsch?

Denn Certs kann ich nicht kaputt machen - da eh nicht vorhanden - Bootloader intakt (Box startet und lies sich von 6.62 online auf 6.63 updaten)

Bitte halte mich auf, falls ich mich (vor morgen bzw. heute Abend) irre.

Danke

- - - Aktualisiert - - -

Die 3370 war als IP Cient eingerichtet (... falls von Bedeutung.... / oder für spätere Leser)

 

[PeterPawn]

So ein Test mit demselben PC und einer anderen Box macht nur dann Sinn (nach meiner Ansicht), wenn die Boxen ansonsten identisch sind und das meint in allererster Linie die Version des Bootloaders. Es tritt ja offensichtlich auch nicht bei jeder Bootloader-Version auf (es gab ja erst kürzlich wieder jemanden, der einfach MTD3 und MTD4 mit einer leeren Datei beschrieben hat), daß die Box dann mit dieser komischen MAC-Adresse (nochmal, das ist das hexadezimale Äquivalent zu "0x00, " und wohl eher eine falsch interpretierte Zeichenkette oder irgendein nicht richtig initialisierter Speicher-/Pufferinhalt) arbeiten will und erst mittels ARP-Eintrag und Schreiben eines TFFS-Images wieder halbwegs auf Linie gebracht werden muß.

Solange das also nicht dieselbe Loaderversion ist, macht so ein Kreuztest in meinen Augen keinen wirklichen Sinn (und auch eine Box mit "old/old" kann noch DVB-C streamen bzw. als LAN1-Router dienen).,

 

[fesc]

Falls es hier hilft, ich habe in meinem repository ein tool geschrieben ("athtool") mit dem man den L2 switch in der box (an dem die 1000BastT ports hängen) umkonfigurieren kann (VLANs, mirroring, L2 table).

D.h. man kann einen port dediziert aus dem internen VLAN 2 herausnehmen und als mirror-port einrichten. Dann markiert man von welchem anderen port man ingress/egress traffic dorthin spiegeln will. Man kann sogar in der L2 tabelle einen statischen Eintrag mit einem "MIRROR" flag versehen.

Sag bescheid wenn das helfen würde, dann schicke ich die genauen kommandos. Das tool läuft auf dem ARM core (download sektion, letzter ARM tarball).

 

[PeterPawn]

Die Box (also die fragliche 6490) hat ja gar kein System mehr (spätestens seit dem Versuch, das (kurze) TFFS-Image auch in die Kernel- und FS-Partition zu schreiben, um die Ursache des Abbruchs bei der Datenübertragung einzugrenzen) und ich vermute mal, Dein "athtool" wird auf ein laufendes Linux aufsetzen wollen.

Etwas ähnliches gibt es dann - falls jemand bei der Suche im Internet auf diesen Thread trifft - bei der 7580 direkt von/bei AVM (theoretisch kann man sich das auch selbst für alle Lantiq-Chipsätze erstellen, die AVM-Kernel haben aber meist das notwendige Interface (Device "switch_api") nicht eingebaut) mit dem Kommando "switch_cli" - die Quellen dafür sind in den OpenSource-Paketen von AVM enthalten (stammen halt von Lantiq).

 

[fesc]

Die Box (also die fragliche 6490) hat ja gar kein System mehr (spätestens seit dem Versuch, das (kurze) TFFS-Image auch in die Kernel- und FS-Partition zu schreiben, um die Ursache des Abbruchs bei der Datenübertragung einzugrenzen) und ich vermute mal, Dein "athtool" wird auf ein laufendes Linux aufsetzen wollen.

Etwas ähnliches gibt es dann - falls jemand bei der Suche im Internet auf diesen Thread trifft - bei der 7580 direkt von/bei AVM (theoretisch kann man sich das auch selbst für alle Lantiq-Chipsätze erstellen, die AVM-Kernel haben aber meist das notwendige Interface (Device "switch_api") nicht eingebaut) mit dem Kommando "switch_cli" - die Quellen dafür sind in den OpenSource-Paketen von AVM enthalten (stammen halt von Lantiq).

haben die den gleichen atheros switch?

Gesendet von meinem F5321 mit Tapatalk

 

[PeterPawn]

Eher nicht ... siehe "arch/mips/include/asm/mach-lantiq/xway" in den betreffenden Source-Paketen (bei den MIPS-Boxen, bei der 6490 hat AVM die iirc nicht "beigepackt").

Inwieweit der eingebaute Switch im Chipsatz event. auf einem Design und entsprechenden Lizenzen von Atheros aufsetzen könnte, weiß ich nicht.

 

[fesc]

, bei der 6490 hat AVM die iirc nicht "beigepackt"

Da gibt es m.W. gar nix im kernel. Der Zugriff auf den switch erfolgt durch Funktionen in libticc.so, die wiederum irgendwas via /dev/mem mappt (wohl den MDIO controller, oder GPIOs fuer ein bitbang interface).
Darauf bauen die "/usr/sbin/extswitch" tools auf.

Ansonsten natürlich korrekt, ich dachte @stoney0815 hat noch eine laufende 6490 die man als mirror dazwischenschalten könnte ...
.. so oder so muss man an den mirror-port einen dediziertes interface anschliessen damit man dort den traffic mitschneiden kann. (ich bin am überlegen wie man den switch so verkonfiguriert dass man den Atom core zum mitschneiden verwenden kann..).

 

[stoney]

Ich habe von 71xx über 327x 33xx 727x 73xx 7490 7560 sowie 7580 und 6490 (welche läuft) hier

An einer geeigneten F!B für dein Scipt sollte es nicht scheitern

Werde dann mal die Bootloaderversion der funktionierenden 6490 nachschauen. Falls dieser der gleiche wäre, kann ja wie schon gefragt ansich nichts schief gehen wenn ich in die inaktiven Partitonen schreibe ?!

Das die funktionierende auch mit old/old noch zu gebrauchen ist, ist mir bewusst (danke für den Hinweis - auch wenn schon öfters getippt - für die "Neulinge" auf jedenfall kein Fehler dies nochmals zu lesen)

 

[PeterPawn]

@fesc:
Bei der 6490 wird der Switch m.W. ohnehin über die Intel-Programme konfiguriert (die sind schon da (irgendwas mit l2switch) und werden (vermutlich, nach dmesg-Ausgaben) von AVM nachgenutzt und beim "echten" Bridge-Mode muß der Switch ja auch irgendwie passend eingerichtet werden anhand der Provisionierung vom CMTS - da hat m.W. der Intel-Code "den Hut auf") ... bei anderen Modelle muß der "dsld" ja den Switch jeweils selbst passend konfigurieren, schon um z.B. ein Gastnetz an LAN4 anbieten zu können und auch die "ipsecbrX"-Interfaces brauchen so einen Zugriff.

Ansonsten hat @stoney0815 wohl tatsächlich eine zweite 6490 - da hatte ich Deine Bemerkung dann fälschlicherweise so interpretiert, daß Du es auf dem "Problemkind" anwenden wolltest.

---

-Inner noch @fesc:
Wenn ich das damals richtig gesehen und es auch noch richtig in Erinnerung behalten habe, dann kommunizieren die beiden Systeme im Netzwerk über den Switch nur per VLAN-Tagging miteinander und damit unterscheidet der ATOM-Core anhand des Tags dann, woher so ein Paket kommt (LAN, WLAN, Guest):

# [COLOR="#0000FF"][B]for f in $(rpc find /proc/net/vlan -type f); do echo "==== remote file $f ===="; rpc cat $f; done[/B][/COLOR]
==== remote file /proc/net/vlan/eth0.1000 ====
eth0.1000  VID: 1000     REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== remote file /proc/net/vlan/eth0.99 ====
eth0.99  VID: 99         REORDER_HDR: 1  dev->priv_flags: 4001
         total frames received         5542
          total bytes received       842472
      Broadcast/Multicast Rcvd         5542

      total frames transmitted            0
       total bytes transmitted            0
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== remote file /proc/net/vlan/eth0.2 ====
eth0.2  VID: 2   REORDER_HDR: 1  dev->priv_flags: 4001
         total frames received      2252411
          total bytes received   1012775896
      Broadcast/Multicast Rcvd       221157

      total frames transmitted      1453489
       total bytes transmitted    291615494
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== remote file /proc/net/vlan/config ====
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.2         | 2  | eth0
eth0.99        | 99  | eth0
eth0.1000      | 1000  | eth0
#[COLOR="#0000FF"][B] for f in $(find /proc/net/vlan -type f); do echo "==== local file $f ===="; cat $f; done[/B][/COLOR]
==== local file /proc/net/vlan/l2sd0.1000 ====
l2sd0.1000  VID: 1000    REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
Device: l2sd0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== local file /proc/net/vlan/l2sd0.99 ====
l2sd0.99  VID: 99        REORDER_HDR: 1  dev->priv_flags: 4001
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted         5552
       total bytes transmitted       921340
Device: l2sd0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== local file /proc/net/vlan/l2sd0.2 ====
l2sd0.2  VID: 2  REORDER_HDR: 1  dev->priv_flags: 4001
         total frames received      9429939
          total bytes received  11205334371
      Broadcast/Multicast Rcvd       187967

      total frames transmitted      6582022
       total bytes transmitted    813499807
Device: l2sd0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:
==== local file /proc/net/vlan/config ====
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
l2sd0.2        | 2  | l2sd0
l2sd0.99       | 99  | l2sd0
l2sd0.1000     | 1000  | l2sd0

, denn es gibt ja nur ein "physikalisches" Interface zum x86-System.

Da würde ich dann erst einmal ganz platt versuchen, den Verkehr vom zu überwachenden Port auf den Port zum x86-Core zu duplizieren (wenn so ein "Mirror-Port" als Ziel nicht 1:1 nur dasselbe "sieht", wie der originale) - ich weiß aber auch nicht, ob der AVM-Kernel für den ATOM-Core alles Notwendige enthält, damit eine "libpcap" da sauber andocken kann.

 

[stoney]

6490 - brick

[I]SN: H154[/I]
bootloaderVersion 1.2567
urlader-version 3567

6490 - läuft

[I]SN: F093[/I]
bootloaderVersion 1.2279
urlader-version 3279

- - - Aktualisiert - - -

KANN BITTE EIN ADMIN / MOD ab #4 http://www.ip-phone-forum.de/showthread.php?t=287470&p=2210380&viewfull=1#post2210380 das ganze in einen eigenen Thread schieben ? > [Problem] 6490 - flashen per FTP schlägt fehl (426 +501)

 

[fesc]

Unter "l2switch" ist auf der 6490 i.A. der interne l2 switch im puma6 gemeint. Der externe läuft unter dem namen "extswitch".
Ich habe vor kurzem mal ein Blockdiagramm gemalt, s.u.

Wenn ich einfach den CPU port als mirror angebe wuerde ginge dort der komplette traffic (ungetaggt) hin. Ich denke das wuerde die Box komplett verwirren.

Die tools (tcpdump, etc.) habe ich bereits auf dem Atom am laufen. Was ich versuche ist entweder ueber einen internen loopback im switch, oder ueber einen externen kabel-loop, den gemirrorten traffic ueber ein neues VLAN (3) an den atom core zu schicken. Dann koennte ich dort mit tcpdump diesen traffic dort mitschneiden.
Leider blockiert der interne l2 switch diese vlan (noch). Da bin ich noch am probieren wie ich an den ran komme.

FB6490/Puma6 block diagram (no claim for correctness)
+----------------------------+Puma 6+---------------------------------------+
|                                                                           |
|    +---+ARM Core (NP CPU)+----+  +---+ATOM Core (APP CPU)+--+             |
|    |                          |  |                          |             |
+----+---+    Box mgmt (PP, CM) |  | NAS, USB                 |             |
| Phones?|    Webif, DHCPd      |  | WLAN       +-----+-------+-------------+
+----+---+    VoIP, EVA(?)      +  + DVB+C Strm |     |  ath0 (2.4G WiFi)   |
|    |                          MBOX            |     +---------------------+
|    |  +--------+------------+ +  +            |     |  ath1 (5G WiFi)     |
|    |  |        | lan bridge | |  |            |     +-------+-------------+
|    |  |guest br| [x.x.x.1]  | |  | +--------+ |lan bridge   |             |
|    |  |VLAN 99 | 192.254.1.1| |  | |guest br| |[x.x.x.254]  |             |
|    |  |        | VLAN 2     | |  | |VLAN 99 | |192.168.1.254|             |
|    |  +----+---+------------+ |  | |        | |VLAN 2       |             |
|    |       |    l2sd0       | |  | +--------+-------+-------+  +----------+
|    |       +-------------+--+ |  | |      eth0      |       +--+SATA Gen2 n.c.
|    |                     |    |  | +----+-----------+       |  +----------+
|    | +---------------+   |    |  |      |                   |             |
|    | |wan/erouter/.. |   |    |  |      |                   +----+        |
|    +---+-------------+--------+  +--------------------------+    |        |
|        |                 |              |                      +-+--------+
|    +---+--------------+  |       +------+------------------+   |USB2(EHCI)|
|    |                  |  |       |                         |   +----------+
|    | Packet Processor +--+       | Internal L2 Switch      |              |                                                                  +
|    | proxy/NAT/router/|          |                         |              |
|    | ...              +----------+                         |              |
|    +---+--------------+          +----+--------------------+              |
|        |                              |                                   |
|        |                              |                                   |
|    +---+---+         +----+        +--+--+                   +----+ +---+ |
|    |CM     |         |MDIO|        |RGMII|                   |eMMC| |SPI| |
+------------+-----------+--------------+-------------------------+-----+---+
                         |              |                         |     |
                     +---+--------------+------------+----+       |     |
                     |             |Port 0 (tagged)  |    |       |     |
                     |             +-----------------+    |       |     |
                     | Atheros AR8327 Switch              |       |     |
                     |                                    |       |     |
                     | +------+1000BaseT ports+-----------+       |     |
                     | |P1    |P2    +P3    +P4    |P5/6  |       |     |
                     | |VLAN 2|VLAN 2|VLAN 2|VLAN 2|unused|       |     |
                     | |untag |untag |untag |untag |      |       |     |
                     +-----------------------------+------+       |     |
                   (probably different in guest/LAN1 setup)       |     |

 

[PeterPawn]

Wegen des fehlenden Zugriffs auf das "Competence Center" (den Du m.W. hast?) wußte ich nicht einmal, daß es noch einen externen Switch in der 6490 gibt - reichen denn die internen Switch-Ports nicht aus? Ich hatte so etwas wie den 7-Port-Switch im VR9 erwartet, wo höchstens noch extern ein PHY zu ergänzen wäre.

- - - Aktualisiert - - -

Wobei ich mich (vor mir selbst) auch wegen des Inhalts der "/var/tmp/lsddb_rt.ini" auf dem ARM-Core mit der Erklärung zufrieden gegeben hatte, daß ext1-ext4 dort die (externen) Ports LAN1-LAN4 sein würden - beim genaueren Nachdenken stellt sich ja dann schon die Frage, warum da nur 5 Ports über l2switch_init konfiguriert werden (die auch noch alle "npconnected" sind) und da hätte ich auch früher drauf kommen können.

 

[fesc]

Obwohl der interne switch auch 7 ports hat weiss gar nicht ob der Puma noch pins fuer externe PHYs (oder gar interne) hat, auser dem RGMII interface zum extSwitch (den ich uebrigens bei einem Blick aufs PCB entdeckt habe, datenblätter habe ich auch nicht).
Ich denke der interne switch ist nur für die Vermittlung zwischen den Komponenten da. DOCSIS, RGMII, Atom ports habe ich identifiziert, man findet in libticc so einiges das man intuitiv anhand des Funktionsnamens aufrufen kann.

 

[noob_noob]

6490 - brick

[I]SN: H154[/I]
bootloaderVersion 1.2567
urlader-version 3567

box mit dem bootloader hab ich liegen...

Thu Jan  1 01:03:01 CET 1970
2.6.39.3
HWRevision    213
HWSubRevision    4
ProductID    Fritz_Box_HW213a
SerialNumber    0000000000000000
annex    Kabel
autoload    yes
bootloaderVersion    1.2567
bootserport    tty0
country    049
cpufrequency    450000000
firstfreeaddress    0x4A092104
firmware_info    141.06.63
firmware_version    avm
flashsize    nor_size=0MB sflash_size=2MB nand_size=2048MB
language    de
maca    C8:0E:14:A3:
macb    C8:0E:14:A3:
macwlan    C8:0E:14:A3:
macwlan2    C8:0E:14:A3:
macdsl    C8:0E:14:A3:
memsize    0x10000000
modetty0    38400,n,8,1,hw
modetty1    38400,n,8,1,hw
modulemem    3970548
mtd0    0x0,0x4000000
mtd1    0x4000000,0x4800000
mtd2    0xa0000,0xc0000
mtd3    0xc0000,0x100000
mtd4    0x100000,0x140000
mtd5    0x140000,0x1e0000
mtd6    0x4800000,0x8800000
mtd7    0x8800000,0x9000000
mtd8    0x0,0x80000
mtd9    0x80000,0x90000
mtd10    0x90000,0xa0000
mtd11    0x9000000,0xd000000
mtd12    0xd000000,0xd800000
mtd13    0xd800000,0x11800000
mtd14    0x11800000,0x12000000

 

[stoney]

Hast du die FW per FTP bzw eva_tools in die mtd's geschrieben/schreiben müssen?

 

[noob_noob]

eva & ftp. so wie ich es gepostet hab. die grössen der mtd devices mal verglichen?

 

[PeterPawn]

Ich weiß ja immer noch nicht, wann und wo die AVM-Firmware nun "firstfreeaddress" schreibt ... aber daß diese Angabe in #55 wieder näher an dem liegt, was ich hier im meinem "Archiv" mit verschiedensten Support-Daten habe, beruhigt mich wieder (wir hatten das ja weiter vorne schon mal als Thema, was da nun stehen sollte/müßte). Vielleicht kann man sogar (experimentell zu ermitteln) anhand des Wertes in dieser Variablen in etwa abschätzen, wie weit die Box beim Booten jeweils kommt? Ich bin da etwas ratlos. Diese Adresse jenseits von 0x4A000000 liegt dann jedenfalls wieder nachvollziehbar in dem Adressraum, den der ARM-Core verwendet und damit ist das wohl der Wert aus dem ARM-System.

Ich würde Dir jedenfalls (ohne JTAG-Interface) strikt davon abraten, da irgendeine "Transplantation" eines Bootloaders zu versuchen. Geht diese genauso schief wie alle anderen Zugriffe (du hast bisher nie mehr als 256 KB zur Box übertragen, wenn ich das richtig in Erinnerung habe), dann hast Du ggf. einen defekten Bootloader in der Box. Ich hoffe zwar, daß so ein Update für den Bootloader erst komplett in den Hauptspeicher der Box geladen würde (Platz im RAM sollte dafür reichen) und erst dann das Löschen der Partition im SPI kommt ... aber es gibt da so ein Sprichwort mit Pferden und Apotheken und ich würde es ohne JTAG-Zugang und genaue Kenntnis des Ablaufs so eines Flash-Vorgangs (der bei der 6490 auch noch anders laufen dürfte als bei anderen Modellen, denn für diese Low-Level-Aktionen ist nach meiner Überzeugung der Intel-Loader aus dem CEFDK zuständig - zumindest nach den Zeichenketten, die man im Loader so findet) eher nicht riskieren.

- - - Aktualisiert - - -

@fesc:
Die libticc.so sollte ja eigentlich zum Intel-CEFDK gehören und damit vermutlich auch samt Doku für jemanden zugänglich sein (gar im Quellcode), der ins "Competence Center" von Intel kommt. Ich hatte irgendwie im Hinterkopf, daß Du das wärst ... wenn nun doch nicht, könntest Du noch mal suchen, wer sich (irgendwann mal, weiß nicht mehr wo und wann) da "zu erkennen gab" und ggf. kann dieser "jemand" Dir ja beim Problem der Konfiguration mittels der "L2SWITCH_..."-Funktionen in der libticc.so helfen.

 

[stoney]

eva & ftp. so wie ich es gepostet hab. die grössen der mtd devices mal verglichen?

HWRevision            213
HWSubRevision         4
ProductID             Fritz_Box_HW213a
SerialNumber          0000000000000000
annex                 Kabel
autoload              yes
bootloaderVersion     1.2567
bootserport           tty0
cpufrequency          1200000000
firstfreeaddress      0x00b20000
firmware_version      lgi
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
linux_fs_start        0
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
modulemem             3967966
mtd0                  0x0,0x4000000
mtd1                  0x4000000,0x4800000
mtd2                  0xa0000,0xc0000
mtd3                  0xc0000,0x100000
mtd4                  0x100000,0x140000
mtd5                  0x140000,0x1e0000
mtd6                  0x4800000,0x8800000
mtd7                  0x8800000,0x9000000
mtd8                  0x0,0x80000
mtd9                  0x80000,0x90000
mtd10                 0x90000,0xa0000
mtd11                 0x9000000,0xd000000
mtd12                 0xd000000,0xd800000
mtd13                 0xd800000,0x11800000
mtd14                 0x11800000,0x12000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
provider              other
req_fullrate_freq     100000000
sysfrequency          100000000
urlader-version       3567

Die größen der mtd's sind identisch

Den bootloader hätte ich nicht tauschen wollen Peter - trotzdem danke für den Hinweis - aber kannst du dir einen Reim daraus machen wie der Bootloader corrupt gegangen sein soll, bei den bekannten Fehlern der älteren FW Versionen der 6490 (oder speziell bei meinem damaligen Vorgehen)?

- - - Aktualisiert - - -

also firstfreeaddress wird direkt nach dem "Strom an" also sobald der Zugriff zum Bootloader möglich ist, nach einem quote UNSETENV firstfreeaddress (quote GETENV firstfreeaddress > 501 environment variable not set) wieder auf den angegeben Wert gesetzt und ändert sich auch nicht wenn ich die Box bis zur rot blinkenden Info LED laufen lasse und dann erst auf den Bootloader zugreife (dieser ist sozusagen bei der Box immer erreichbar)

 

[noob_noob]

http://www.wehavemorefun.de/fritzbox/ADAM2_Shell
mal mit erase versucht die parttionen vor dem flashen zu löschen?
keine ahnung, ob das funktioniert aber versuch macht kluch.
zur allergrössten not hab ich auch nen jtag interface. aber noch nie mit jtag und ner 6490 gerarbeitet...