Freetz aktuelles git 7412 bootet nicht

@er13:
Wenn Du ein Image hast, was Du gerne getestet haben würdest, laß es mir per Mail zukommen ... mir fehlt nur im Moment die Möglichkeit und die Zeit, selbst einen gesonderten Trunk für die 7412 aufzulegen, um mir ein eigenes Image zu bauen - aber in der 7412 ist die alternative Partition "zum spielen und testen" verfügbar, da ist das schnell geklärt, ob ein Image bootet und ggf. auch, wie weit es ansonsten kommt (S01-head schreibt auch hier die "firmware_info" neu und auch ptest kann man als Marker setzen, usw. - selbst ohne Serielle gibt es ja Tracepoints, anhand derer man eingrenzen kann.
 
Bei eBay kostet die Box um die 30-35 €, vielleicht kaufe ich mir eine um mal zu ergründen, woran es liegt.
Das Problem betrifft meiner Erinnerung nach nicht nur die 7412 sondern auch die 7430, beide VRX220 basiert (anstatt VRX288 bei den anderen VR9-Modellen).
 
Hallo Naerenbisch,
das sieht nicht nach "minimaler" config aus,
auch ist nach meiner Ansicht "replace kernel" aktiviert;

Frage: Soll diese Config zum Erstellen eines Freetz 06.3x Image sein ?

LG
PantaRhei

Hallo PantaRhei,

1) Komisch, im grafischen "menuconfig" war die Option NICHT gesetzt. Habe ich mich
drauf verlassen - jaja ich bin manchmal ein klick-kiddy, hatte bisher (zumindest bei der
freetz-configuration) auch keine Probleme.

2) Ja, sollte für 6.30 sein, ich dachte die Chancen stehen dann besser als mit 6.50, die ist
ja HIGHLY experimental

Danke für die Anteilnahme! :D
 
@qwertz.asdfgh:
Aus dem Bauch heraus würde ich eher darauf tippen, daß es irgendwie am CONFIG_NAS=n und dem damit einhergehenden Fehlen von einigen AVM-Dateien liegt ... Freetz fügt m.W. nur ein paar Dateien hinzu oder ersetzt welche. Wenn da bei AVM irgendein Tool nicht an Bord ist, welches beim Initialisieren von Freetz vorausgesetzt wird, könnte das ebenfalls eine Ursache sein. Meines Wissens ist der "remove NAS"-Patch die einzige Datei in Freetz, wo "CONFIG_NAS" überhaupt vorkommt ... bei AVM ergibt sich aus "n" aber noch mehr an fehlenden Dateien, als vom Freetz-Patch entfernt wird. Das geht beim "blkid" los und zieht sich bis zu den Filesystem- und USB-Treibern - wie gesagt, reines Bauchgefühl und das kann auch eine Magenverstimmung (oder ein -geschwür) sein. Die Frage, wie es bei der 7412 mit der 06.20 aussah, kann man sich wohl sparen. :mrgreen:

Wie aktuell sind denn die Meldungen, daß es mit der 7430 (auch) nicht funktioniert? Einige (inzwischen beseitigte) Probleme bestanden m.W. bis Mitte Februar ... gab es seitdem tatsächlich noch Meldungen, daß jemand mit Freetz auf eine 7430 losgegangen wäre und dabei Schiffbruch erlitten hat?
 
Zuletzt bearbeitet:
Code:
[COLOR=#dda0dd]FREETZ_DL_KERNEL_SOURCE_ID="3490_06.20"[/COLOR]
FREETZ_DL_KERNEL_SOURCE_MD5="16ba3988368eeb6c1603490ca2ea3aac"
FREETZ_DL_SITE="@AVM/fritzbox.7412/firmware/deutsch,@1&1/7412"
....
FREETZ_DL_SOURCE="FRITZ.Box_7412.137.06.30.image"
FREETZ_DL_SOURCE_MD5="a54fd8d38bdb66a7ef0408bbd717092d"
....
[COLOR=#dda0dd]FREETZ_AVM_SOURCE_3490_06_31=y
FREETZ_AVM_SOURCE_ID="3490_06.31"[/COLOR]

Hallo zusammen,
im config file ist öfters als Source 3490 angegeben;

Frage: ist dies so richtig oder liegt da ein Fehler vor ?

LG
PantaRhei
 
Früher gab es "diff"s gegen die Quellen der anderen Boxen ... sicherlich um auf den Mirror-Servern den Platz zu sparen und nicht für jedes Modell den kompletten Satz an Quellen aufbewahren zu müssen (zumal die sich bei AVM tatsächlich nur minimal unterscheiden für die Modelle mit demselben Prozessor). Ob das immer noch so ist, weiß @er13 am ehesten. Daß die ganz aktuellen Quellen für die 06.5x-Versionen ohnehin (meiner Meinung nach jedenfalls) unvollständig sind, hast Du sicherlich mitbekommen ... da muß man also streng zwischen Kernel 2.6 und 3.10 unterscheiden.
 
@PeterPawn:
Bzgl. 7430 war der mir zuletzt bekannte Stand folgender:
[post]2163190[/post]
also von Mitte Mai (nicht Februar). Edit: Irgendwie habe/hatte ich jedenfalls das (unbestätigte) Gefühl, dass die 7412 und die 7430 das gleiche Problem mit Freetz haben.

Mangels Besitz einer 7412 oder 7430 kann ich aber leider auch nur spekulieren.
 
Zuletzt bearbeitet:
Ich habe gerade mal ein 06.50-Image von @er13 getestet auf der 7412 ... bis auf den ersten Start (wo es eine "kernel panic" gab, Ursache war der pcmlink-Treiber) ist das bei mir problemlos stabil und daß es abseits von Freetz zu modifizieren ist (modfs bzw. -Starter, wenn es die 06.30/06.32 ist), ist auch schon lämger bekannt.

Ich weiß auch noch nicht, ob Gene etwas ggü. dem veröffentlichten Trunk geändert hat ... aber das startet bei mir seit dem zweiten Versuch problemlos bei inzwischen 5 Tests mit einfachem Neustart, 2 mit Umschaltung auf ein modfs-Image zwischendrin und dann wieder dem Wechsel von diesem auf das Freetz-Image.

Das war zwar erst die 06.50 ... aber ich kann das Problem nicht nachvollziehen - ich habe das Image aber auch nicht selbst erstellt, trotzdem mal aus diesem die .config ausgelesen und hier angehangen (@er13: Ich hoffe, das ist in Ordnung.). Den Vergleich, worin sich die "inline"-Version in #19 von der im Anhang unterscheidet (ich kann Anhänge verwenden), überlasse ich anderen.
 
@Peter: Danke fürs Testen und für die Logs! Die Images, die ich Dir hab' zukommen lassen, wurden auf Basis des unmodifizierten Trunks erstellt (sieht man am fehlenden M nach der RevNr im Namen der Datei). .config zu veröffentlichen ist OK.

@Logs: Bin noch nicht aus diesen schlau geworden, aber die ersten google-Treffer zeigen, dass das Problem auch auf den anderen Boxen auftritt, s. #2480 und diesen Thread. Aus noch unbekannten Gründen ist dieses halt einfacher auf der 7412 zu triggern.

Könnte es was mit dem fehlenden controlling tty zu tun haben? S. #2518
 
Ich würde das Problem auch nicht überbewerten ... das sind (ich spekuliere/interpretiere jetzt mal, wie ich das verstehe ... Korrekturen und bessere Erklärungen sind mir jederzeit willkommen) wohl nur Warnungen, wenn bei der Behandlung von Interrupts für die DECT-Anbindung (ob auch für AHA oder nur für Telefonie, will ich gar nicht wissen) zu viel Zeit vergeht und die Latenz der Interrupts damit zu hoch wird.

Wenn das nicht "in time" erfolgt, kommt sicherlich die DECT-Kommunikation durcheinander (bei der 7412 kann sich ja das "pcm" im Treibernamen eher nicht auf die ISDN-Funktionen beziehen und woanders wüßte ich jetzt nicht, wo da TDM (was für mich in diesem Kontext für "time division multiplexing" steht) zum Einsatz kommen sollte - dabei würde ich aber verstehen, daß es eben zeitkritisch ist) und wenn das zu oft passiert oder die Verzögerungen zu groß bzw. zu viele werden, dann startet die Box mit der "kernel panic" einfach neu in der Hoffnung, daß es nur ein "verklemmter Prozess" war, der da die Resourcen über Gebühr beansprucht hat.

Wenn ich Freetz richtig verstehe, würde das sogar zu meiner Beobachtung mit dem Absturz beim ersten Start mit einem Freetz-Image passen, denn da werden ja wohl auch erst einmal die "Standardeinstellungen" hergestellt und gesichert, wenn die Box in Bezug auf die Freetz-Konfiguration noch jungfräulich ist ... sprich, der erste Start könnte am Beginn eine höhere Last erzeugen als alle weiteren.

Wenn sich die Box dann erst einmal etwas ge"settled" hat, treten diese Warnungen nach meiner Beobachtung auch nur noch sehr selten auf.

Warum sie überhaupt entstehen bei deaktivierter DECT-Basis, ist mir allerdings auch ein Rätsel ... aber der pcmlink.ko könnte auch noch für die Anbindung der Reste dieser C55x-DSPs zuständig sein, die meines Wissens in all den eingesetzten Chipsets auch noch vorhanden sind und vermutlich die Echo-Cancellation und auch Encoding/Decoding für einige "übliche" Codecs machen, denn das ist für den Hauptprozessor dann doch etwas zu speziell (zumindest EC) und dafür wären die meisten Prozessoren wohl auch zu langsam, wenn die das in Software lösen müßten und möglichst noch für 3 Gespräche parallel.

Ich bin ja immer noch der Meinung, daß die Beschränkung der Boxen bei den möglichen parallelen IP-Telefonaten auch darauf zurückzuführen ist, daß da die DSPs ansonsten nicht ausreichen.

Jedenfalls halte ich diese Warnungen im Betrieb nicht für relevant ... ich würde sogar sagen, daß ich sie bei der originalen Firmware auch schon gesehen habe, wenn ich es am Beginn des init-Prozesses (da startet meiner Meinung nach eine Art Messung beim Laden des Treibers) mit dem Starten eigener Programme übertrieben hatte.

- - - Aktualisiert - - -

Inzwischen glaube ich eher an einen Zusammenhang mit einer anderen Gemeinsamkeit zwischen der 7412 und der 7430 ... das sind beides Modelle, die keinerlei NOR-Flash mehr haben (weder mit Data-Bus noch seriell) und bei denen eine Emulation des TFFS in einer einzelnen NAND-Partition erfolgt. Dieser "TFFS im NAND"-Treiber ist auch vergleichsweise neu gewesen ... da würde ich nicht ausschließen wollen (so sagt man das heutzutage wohl korrekt), daß da noch der eine oder andere Bug drin schlummert, der eben von Freetz nun getriggert wird. Das gab es bei der libusb-irgendwas ja auch, daß (nur leicht) unterschiedliche Konfigurationen der uClibc am Ende zu einer SEGV führten.

Bei der 06.50 startet das Freetz-Image - wie oben beschrieben - irgendwann ohne Probleme ... mit dem neuen Kernel wurde aber auch der TFFS-Treiber weitgehend "ausgemistet" und ist als "TFFS3" wiederauferstanden, diesmal von Beginn an mit der Unterstützung unterschiedlicher Speicher-Formen ... von "richtigem" NOR- über SPI- bis NAND-Flash und auch der Teil, der bei wirklich wirklich schlimmer Panik noch irgendwelche Spuren sichern soll, wurde komplett überarbeitet (die anfänglichen Konfigurationsverluste mit der 06.35 bei einigen hier im Forum, sind sicherlich auch auf diesen Neubau zurückzuführen).

Mit 06.30 geht die Box in eine ca. 45-48 sekündige Boot-Schleife ... das hat mit dem Aufbau des Images oder fehlenden Libs für die Busybox garantiert nichts mehr zu tun. Ich habe keine serielle Konsole dran an der 7412 ... mal schauen, ob ich noch ein Kabel mit Pegelwandler in einer Bastelkiste finde.

Auf die Idee mit dem Unterschied beim TFFS brachte mich dann die Feststellung, daß (nach der Umschaltung auf das alternative System) im TFFS keine "crash.log" bzw. "panic.log" vorhanden war (bzw. die betreffenden Daten im TFFS fehlen, auf den Kern der Story, was ein TFFS-Node ist, will ich jetzt mal nicht weiter eingehen).

Wenn es für die 7430 ebenfalls eine 06.50 geben sollte, könnte man also auch mit der mal probieren, um dann die 06.30 einfach auszulassen in Freetz.

Am Ende stellt sich mir de Frage, ob es sich tatsächlich lohnt, einem (vermutlichen) Fehler in der 06.30 nachzugehen, wenn die 06.50 verfügbar wäre (das mit dem "replace kernel" kriegen wir irgendwann auch in den Griff) - ein Downgrade von einem 3.10er-Kernel auf einen 2.6er ist auch mit Freetz nicht ohne weiteres möglich.

AVM hat ja nicht nur aus Sicherheitsgründen das Downgrade (aus dem laufenden System heraus ja auch nur) "abgeschafft" ... es ist ja aus objektiven Gründen nicht möglich, ein älteres Image (wo filesystem.image eben noch direkt ein SquashFS3-Image mit dem Inhalt von /wrapper ist) ohne zusätzliche Tools wie unsquashfs mit einem 3.10er-Kernel zu behandeln, weil der das schlicht nicht mounten kann (das muß ja auch in "modfs" mit "unsquashfs" seziert werden).

Erst wenn das Downgrade von AVM innerhalb einer Kernel-Generation nicht mehr zugelassen wird, erst dann stehen dahinter (vermutlich/hoffentlich) Sicherheitsgründe. Beim Verschwinden der ganzen älteren Recovery-Versionen (denen ist die Kernel-Version im zu überschreibenden System schlicht egal) gilt das natürlich auch ... da sollte wieder "Sicherheit" das Thema (gewesen) sein.
 
Mangels Besitz einer 7412 oder 7430 kann ich aber leider auch nur spekulieren.

Ich habe gerade eine 7430 vor mir (nicht mein Eigentum). Ein Freetz-Image (r13839, ganz frisch ausgecheckt) auf Basis von FritzOS 6.50 (.config s.h. Anhang, ist ein "Basis-Image") bootet nicht.
30s nachdem der Bootloader beginnt den Kernel zu laden kommt es zum Neustart. Auch der 10 Startversuch (kalt und warm) ändert daran nichts. Kurzum, der aktuelle Status für die 7430 ist somit wohl "fails to boot".
 

Anhänge

  • freetz_config.txt
    61.2 KB · Aufrufe: 1
  • freetz_config.compressed.txt
    109 Bytes · Aufrufe: 1
Wenn Du die Box noch in Reichweite hast, lies doch mal die Support-Daten aus einer startenden Original-Firmware aus. Die Zeitstempel in der dort enthaltenen "dmesg"-Ausgabe sollten ja zumindest einen Anhaltspunkt ergeben, was zum fraglichen Zeitpunkt auch in einem Freetz-Image passieren würde ... am Startprozess wird nur marginal etwas verändert.

Wenn Du noch etwas weiter suchen willst, wäre die nächste Frage, ob auch ein "Umpacken" mit "fwmod" (für "modfs" bräuchtest Du wohl erst einmal Shell-Zugriff, wobei man anhand der Support-Daten auch einschätzen könnte, ob "modfs-Starter" sich für die 7430 mit einer OS-Version ohne strikte Signaturprüfung anpassen ließe) schon zu einem nicht startenden Image führt. Ist das nicht der Fall, kann man ja dort den Telnet-Zugriff einbauen und das AVM-OS etwas genauer (in der laufenden Box, denn einiges bekommt man nur aus den (veröffentlichten) Quellen und der reinen Ansicht der Firmware eben doch nicht heraus) unter die Lupe nehmen.

Auch die Frage, ob nach dem fehlgeschlagenen Start mit dem Freetz-Image bei der Umschaltung auf das alternative System (die hat doch zwei, oder?) irgendetwas in crash.log oder panic.log in den Support-Daten auftaucht (dazu ggf. den automatischen Versand deaktivieren, der könnte auch löschen, wenn die Box keine Internetverbindung hat bzw. AVM nicht erreichen kann) oder nicht.

Das wäre insofern nicht ganz uninteressant, als auch die 7580 (nach dem, was ich in der Firmware dort bisher gesehen habe) so ein Modell ohne jeden NOR-Flash (weder Bus noch SPI) sein dürfte. Nun geht dort wegen des UBIFS wahrscheinlich Freetz ohnehin nicht so ohne weiteres, aber so ein nicht richtig startendes System wäre ja bereits am Beginn des Aus für jedwede Modifikation in dieser Richtung.
 
... lies doch mal die Support-Daten aus einer startenden Original-Firmware aus.
Hier mal die komplette Support-Datei einer 7430 mit originalem FritzOS 6.30 nach dem laden der Werkseinstellungen (ist zusätzlich noch anonymisiert, hoffentlich ausreichend ;)):
Anhang anzeigen support FRITZ.Box 7430 146.06.30_01.01.70_0101.7z

Hier der Abschnitt dmesg einer Support-Datei nachdem ersten Einschalten der 7430 (frisch aus der Verpackung genommen):
Anhang anzeigen support FRITZ.Box 7430 146.06.30_first-start.txt

Und hier noch einmal von einem späteren Start (ist aus der oben verlinkten kompletten Support-Datei):
Anhang anzeigen support FRITZ.Box 7430 146.06.30_later-start.txt

Und nun das ganze noch einmal mit FritzOS 6.50 (mit modfs angepasste Version, ist aber nicht der erste Start nach dem Update) und dem Abschnitt debug Kernel output:
Anhang anzeigen support FRITZ.Box 7430 146.06.50_later-start.txt

(für "modfs" bräuchtest Du wohl erst einmal Shell-Zugriff, wobei man anhand der Support-Daten auch einschätzen könnte, ob "modfs-Starter" sich für die 7430 mit einer OS-Version ohne strikte Signaturprüfung anpassen ließe)
Das wurde ja bereits im modfs-Thema geklärt, "modfs-Starter" ist sozusagen "7430 ready".

Auch die Frage, ob nach dem fehlgeschlagenen Start mit dem Freetz-Image bei der Umschaltung auf das alternative System (die hat doch zwei, oder?) irgendetwas in crash.log oder panic.log in den Support-Daten auftaucht (dazu ggf. den automatischen Versand deaktivieren, der könnte auch löschen, wenn die Box keine Internetverbindung hat bzw. AVM nicht erreichen kann) oder nicht.
Dumm gelaufen, die oben verlinkte Support-Datei ist zwar nach dem Wechsel vom Freetz-Image zurück zur 6.30 erstellt worden aber ich hatte zusätzlich unter 6.30 auch noch die Werkeinstellungen geladen, damit ist das dann wohl weg. Ich habe die Box noch bis morgen, ab übermorgen wird sie dann produktiv eingesetzt und steht nicht mehr zum "spielen" zur Verfügung. Wenn es keinen Hinweis auf das Problem gibt kann ich ja noch einmal von 6.30 aus ein Freetz-Image aufspielen um zu sehen ob was in crash.log oder panic.log steht.
 
Ich hab' nur mal kurz in die dmesg-Ausgabe der 06.50 hineingesehen (den Rest schaue ich bei Gelegenheit mal an, mich interessiert auch der Aufbau des Flash-Speichers) ... den ltqusb_host.ko kenne ich bisher nicht (zumindest ist er mir nicht geläufig), das könnte ein Unterschied sein zu anderen Modellen. Allerdings ist das bei ca. 19-20 Sekunden, das könnte noch etwas zu früh sein für die berichtete Schleife.

Man müßte ja an einem USB-Stick mit einer LED (so vorhanden) sehen können, ob/wann die Initialisierung der USB-Geräte startet ... danach kommt der DSL-Teil an die Reihe und dann sollten die 30 Sekunden auch lange um sein. Vielleicht kannst Du noch die Zeitdifferenz zwischen dem Start der Box und dem ersten Zugriff auf den USB-Stick ermitteln ... anhand dessen kann man die Verschiebung zwischen Start der Box und dem Zeitstempel 0 (bzw. dem Zeitpunkt des USB-Zugriffs) etwas genauer eingrenzen.

Ansonsten sollte eigentlich ein Eintrag in panic.log existieren (und damit in den Support-Daten nach Umschalten auf eine funktionierende 06.50-Version - bei 06.30 würde ich mich nicht darauf verlassen), das Initialisieren der notwendigen Funktionen dazu findet bei 1.8 Sekunden in dmesg statt und wenn dann das Freetz-Image einen Restart in der Startphase des Systems hinlegt, sollte man (einen funktionierenden TFFS-Treiber in 06.50 genauso unterstellt wie eine solche "panic") dann auch ein Protokoll auslesen können. Aber dazu müßte man eben zweimal 06.50 einsetzen ... die NAND-Teile im TFFS-Treiber v2 würde ich nicht als allzu stabil und ausgereift sehen, dafür waren die zu neu (wenn man mal 7412, 7430 und 7580 als Modelle mit TFFS im NAND ansieht - die sind alle nicht so richtig "alt").
 
Man müßte ja an einem USB-Stick mit einer LED (so vorhanden) sehen können, ob/wann die Initialisierung der USB-Geräte startet ...
Ich werde das morgen vielleicht nochmal in Angriff nehmen mit dem Freetz-Image.

danach kommt der DSL-Teil an die Reihe
In der Tat, an der Reaktion der Power/DSL-LED konnte ich erkennen, dass die 7430 mit dem Freetz-Image ca. 3-4s vor dem Neustart mit der DSL-Synchronisation begann.

(und damit in den Support-Daten nach Umschalten auf eine funktionierende 06.50-Version - bei 06.30 würde ich mich nicht darauf verlassen)
Dann werde ich wohl mal FritzOS 6.30 (incl. Shellina) in der ersten Partition für das Freetz-Image "opfern" müssen... ;)
Kann ich dafür nicht "./modfs update source_image" verwenden? Habe irgendwie in Erinnerung, dass es da wohl ein Problem gab i.V.m. Freetz-Images - oder täusche ich mich da?




(... mich interessiert auch der Aufbau des Flash-Speichers)
Der ist in der Tat spannend, da ja kein NOR-Flash für den Bootloader verwendet wird muss dieser ja folglich mit in den NAND-Flash und da die 7412 als auch die 7430 (von der Hardware aus betrachtet sind wirklich nur die 4 FE-Ports + 1x USB 2.0 als Unterschied zur 7412 festzustellen ansonsten ist alles gleich) so wie die 3272, 3370, 3390, 6840, 7272, 7362 SL usw. "nur" 128MB NAND-Flash haben sind es bei der 7430 dann tatsächlich keine 22MB (23.068.672 Byte) "NAS-Speicher" mehr wie bei den anderen Modellen mit 128MB NAND-Flash sondern nur noch 17,75MiB (18.612.224 Byte, die 256KiB+4MiB=4,25MiB werden für Bootloader und TFFS verwendet), bei der 7412 wird das vermutlich ebenfalls 17,75MiB große "nand-filesystem" wohl ausschließlich für AB- und Faxspeicher verwendet.

Mal zum Vergleich die Ausgabe von "cat /proc/mtd" bei der 7272 (linux_fs_start = 0, die Ergänzung in eckigen Klammern kommen von mir):
Code:
dev:    size   erasesize  name
mtd0: 00400000 00020000 "reserved-kernel"      [ 4.194.304 Byte NAND  >     4MiB               ]
mtd1: 03000000 00020000 "reserved-filesystem"  [50.331.648 Byte NAND  >    48MiB               ]
mtd2: 00400000 00020000 "kernel"               [ 4.194.304 Byte NAND  >     4MiB               ]
mtd3: 03000000 00020000 "filesystem"           [50.331.648 Byte NAND  >    48MiB               ]
mtd4: 00200000 00020000 "config"               [ 2.097.152 Byte NAND  >     2MiB               ]
[highlight]mtd5: 01600000 00020000 "nand-filesystem"      [23.068.672 Byte NAND  >    22MiB (7490: 406MiB)]
mtd6: 00040000 00001000 "urlader"              [ 262.144 Byte SFLASH  >   256KiB \             ]
mtd7: 00060000 00001000 "tffs (1)"             [ 393.216 Byte SFLASH  >   384KiB  - 1MiB SFLASH]
mtd8: 00060000 00001000 "tffs (2)"             [ 393.216 Byte SFLASH  >   384KiB /             ][/highlight]

und nun die 7430 (linux_fs_start = 1, die Ergänzung in eckigen Klammern kommen von mir):
Code:
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"               [ 4.194.304 Byte NAND  >     4MiB               ]
mtd1: 03000000 00020000 "filesystem"           [50.331.648 Byte NAND  >    48MiB               ]
mtd2: 00400000 00020000 "reserved-kernel"      [ 4.194.304 Byte NAND  >     4MiB               ]
mtd3: 03000000 00020000 "reserved-filesystem"  [50.331.648 Byte NAND  >    48MiB               ]
mtd4: 00200000 00020000 "config"               [ 2.097.152 Byte NAND  >     2MiB               ]
[highlight]mtd5: 011c0000 00020000 "nand-filesystem"      [18.612.224 Byte NAND  > 17,75MiB (7490: 406MiB)]
mtd6: 00040000 00020000 "urlader"              [   262.144 Byte NAND  >   256KiB               ]
mtd7: 00400000 00020000 "nand-tffs"            [ 4.194.304 Byte NAND  >     4MiB               ][/highlight]


Ach ja, und hier noch die Ausgabe von "cat /proc/partitions" bei der 7272 (Kernel 2.6.32):
Code:
major minor  #blocks  name

[highlight]   7        0      19400 loop0[/highlight]
  31        0       4096 mtdblock0
  31        1      49152 mtdblock1
  31        2       4096 mtdblock2
  31        3      49152 mtdblock3
  31        4       2048 mtdblock4
[highlight]  31        5      22528 mtdblock5[/highlight]
  31        6        256 mtdblock6
[highlight]  31        7        384 mtdblock7
  31        8        384 mtdblock8[/highlight]

und der 7430 (Kernel 3.10):
Code:
major minor  #blocks  name

[highlight]   7        0      15800 loop0[/highlight]
  31        0       4096 mtdblock0
  31        1      49152 mtdblock1
  31        2       4096 mtdblock2
  31        3      49152 mtdblock3
  31        4       2048 mtdblock4
[highlight]  31        5      18176 mtdblock5[/highlight]
  31        6        256 mtdblock6
[highlight]  31        7       4096 mtdblock7
   8        0    3932160 sda
   8        1    1048576 sda1
   8        2     524288 sda2[/highlight]
 
Das Installieren eines vollständigen Freetz-Images sollte eigentlich auch mit modfs funktionieren (modfs install <image> - aus dem Kopf und ohne Nachsehen, also nur 90% sicher)... wobei Du ja auch problemlos mit einem aktuellen Freetz-Trunk ein signiertes Image erstellen lassen kannst und dann nur Deinen eigenen öffentlichen Schlüssel z.B. mit "bind-Mount" über den key3 von AVM mounten müßtest (im mit "modfs" modifizierten System), um ganz normal über das AVM-GUI auch das Freetz-Image installieren zu können. Von Beginn an wirst Du sicherlich keinen eigenen Schlüssel in das "modfs"-Image integriert haben.

Hat eigentlich mal jemand eine 7412 aufgemacht? Mich interessiert in erster Linie, ob es vielleicht (unbestückte) USB-Ports auf dem PCB gibt. Wenn ja, müßte man ja fast einen solchen Port "nachrüsten" können.

Ich bin irgendwie durch den Treibernamen "ltqusb_host" darüber gestolpert, daß die Box ja durchaus einen USB2-Host im Chipset haben könnte - zumindest würde ich bei dem Namen darauf schließen, daß der USB-Teil von Lantiq stammt und da es wohl (nur m.W., die Infos sind ja mehr als spärlich - selbst bei Internet-Suche) keinen gesonderten USB-Chip gibt, muß der ja irgendwo "beheimatet" sein.

Vielleicht noch mit irgendeinem SELECT-Pin "freizuschalten" oder vielleicht reicht sogar schon der passende "device tree", um über irgendwelche MDIO-Operationen den USB-Port zu aktivieren ... alles noch ziemlich unausgegoren als Idee, aber ich bin erst durch diesen erwähnten Treiber überhaupt zu der Frage gekommen, woher bei der 7430 der USB-Port eigentlich kommen mag - wie sieht das eigentlich bei den anderen VR9-Modellen aus, die auch keine USB3-Ports haben?

Für USB3 (zumindest bei der 7490) gibt es einen gesonderten Chip, der über PCIe angebunden ist (https://www.renesas.com/en-us/products/usb-assp/upd720202.html):
Code:
$ lspci
00:00.0 Class 0604: 1bef:0011
[COLOR="#0000FF"]01:00.0 Class 0c03: 1912:0015[/COLOR]
Leider finde ich mal wieder das "Blockschaltbild" bei Lantiq/Intel nicht, um dort nachzusehen, ob da bereits ein USB2-(Host-)Controller im VR9 oder im dazugehörigen FE enthalten ist (wobei er in letzterem wohl eher nichts zu suchen hätte).
 
Zuletzt bearbeitet:
Ich befürchte nur ich schaffe es heute nicht mehr, der Tag ist schon gut mit Arbeit befüllt worden und heute Abend bin ich auch nicht da, und morgen geht sie bereits weg... Aber aufgeschoben ist nicht aufgehoben, bis zur nächsten 7430 die den kleinen Umweg über meinen Tisch nimmt, dann bin ich auch besser vorbereitet... ;)


Hat eigentlich mal jemand eine 7412 aufgemacht?
Das definitiv, sonst hätte ich einige Informationen nicht gehabt, frag mal ganz oben im Norden nach. ;)

Ich bin irgendwie durch den Treibernamen "ltqusb_host" darüber gestolpert, daß die Box ja durchaus einen USB2-Host im Chipset haben könnte
[noparse]So ist es, die USB-Ports aller AR9 (ARX188), AR10 (ARX388) und VR9 (VRX288 + VRX220) Modelle von AVM werden, 3490 und 7490 mit ihren USB 3.0 Ports natürlich ausgenommen (nur diese beiden Modelle haben also überhaupt einen separaten USB-Chip), von dem jeweiligen Lantiq-SoC zur Verfügung gestellt.

Interessant ist, die SoCs ARX188 (FB 7312, 7320, 7330), ARX388 (FB 3272 und 7272, die 3272 hat im Gegensatz zur 7272 auch 2 USB-Ports) und VRX288 (FB 3370, 3390, 7360 usw...) haben alle 2 USB-Host 2.0 Anschlüsse im Chipset integriert, der VRX220 (FB 7412, 7430) dagegen nur einen.[/noparse]
 
Hat er ... aber keinen Schraubendreher/Spachtel/was auch immer, um das Gehäuse zu öffnen bzw. bisher auch keinen Grund dafür und einfach nicht genug Alkohol, um das Zittern der Hände (rein durch die Aufregung bei "Hardware-Basteleien") bei derartig filligranen Tätigkeiten wirksam zu unterdrücken.

Wobei ich gerade mal einen Blick auf die Rückseite geworfen habe ... sieht nach zwei Schrauben mit Innensechskant hinter den Aufhängungsschlitzen aus und der Rest wird wohl am unteren Ende eingeklippt sein (mal so als Annahme). Jetzt müßte ich nur noch den Bitsatz suchen (nicht den Bitburger-Kasten) und dann könnte ich wohl tatsächlich selbst mal nachsehen ... wäre da nicht mein altes Problem.

Ich kriege (Späßle) solche Geräte leichter auseinandergenommen als zusammengesetzt ... und die 7412 brauche ich noch als Testgerät für alle möglichen Ideen. Da sie "kostenlos" war, bin ich da auch weitaus risikobereiter bei Änderungen an allen möglichen gefährlicheren Stellen - wobei ich sie auch noch nicht wirklich "kaputt gekriegt" habe ... mit dem Laden und Flashen eines "in-memory images" war das bisher immer wieder zu beheben. Insofern machen die NAND-Boxen irgendwie einen "unkaputtbaren" Eindruck auf mich ... was ja am Ende tatsächlich positiv wäre.
 
Es sind 4 Schrauben, sind eigentlich zu sehen, nix geklippt.
Ist ein Torx 6, die erste, bisher waren es immer Torx 8.

Hab sie noch mal aufgemacht, konnte aber nichts so richtig finden, obwohl es an 2 Stellen 4 Kontakte gibt.
Eines müßte die serielle sein (ist gebohrt).
Die andere ist ungebohrt, hat aber Farbe über den Kontakten und es würden die Massekontakte fehlen.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.