Da in der "S42-ptest" die Environment-Variable "ptest" wieder gelöscht wird, kann man irgendwelche eigenen Werte darin auch als Anzeiger benutzen, ob die Box bis zu diesem Punkt bei der Initialisierung gekommen ist. Aber egal ... rein von der Zeit her, muß die da schon vorbei sein.
Wenn ich die Zeiten vergleiche, dann braucht das Initialisieren des NAS-Speichers ca. 16 Sekunden ... komisch ist das kurze Abschalten von Power und WLAN beim ersten Mal bei Sekunde 85.
Trotzdem ist das (nach meiner Meinung) viel zu lange nach dem Initialisieren des WLAN, als daß es wirklich daran liegen sollte. Aber Du kannst es ja gerne probieren, ob Du das WLAN auslassen kannst (zumindest kann man das wohl wieder an den LEDs erkennen, ob die Änderung wirksam wird) ... dazu muß in das ansonsten leere TFFS-Image (als das Ergebnis von "build_tffs_image") noch zusätzlich eine "wlan.cfg" mit folgendem Inhalt aufgenommen werden:
Code:
wlancfg {
ap_enabled = 0;
ap_enabled_saved = 0;
ap_enabled_scnd = 0;
ap_enabled_scnd_saved = 0;
channel = 0;
bg_mode = 23;
bg_mode_scnd = 53;
encryption = 3;
allowSharedKeyAuth = no;
key_value0 = "";
key_len0 = 0;
key_value1 = "";
key_len1 = 0;
key_value2 = "";
key_len2 = 0;
key_value3 = "";
key_len3 = 0;
force_channel_conversion = no;
wps_mode = 1;
wireless_stickandsurf_enabled = no;
wlan_coexistence = 1;
band_steering = yes;
band_steering_saved = yes;
}
Das ist - bis auf die ersten vier Werte - der Inhalt der "wlan.cfg" aus "/etc/default..." - die ersten vier Angaben sollten dafür sorgen, daß kein WLAN automatisch gestartet wird.
Diese Datei muß jetzt gepackt werden (weil "build_tffs_image" nicht selbst packt - wie das geht, steht in "tffs_add_file" (in "zlib_deflate"), wo eine ungepackte Datei erwartet wird) - dafür kann man auch diverse andere Wege nehmen, von Perl bis zu OpenSSL mit zlib-Support (ist u.a. im großen 6490-Thread beim ersten Vorstellen von "build_tffs_image" für diesen "Mißbrauch" - denn das war ja für ganz andere Zwecke gedacht - diskutiert, welche Möglichkeiten es da alles gibt). Die gepackte Datei gibt man dann als vierten Parameter beim "build_tffs_image" an - die Minor-ID für den Node wird aus dem Dateinamen abgeleitet. Welche ID die "wlan.cfg" hat, steht irgendwo in der "tffs.files".
Anschließend kann (meint: sollte) man durch Zerlegen des entstandenen TFFS-Images noch einmal prüfen, daß alles wie erwartet eingetragen wurde und dann kann man das TFFS-Image wieder flashen ... hier muß es natürlich wieder in beide Partitionen geschrieben werden, denn die automatische Auswahl des FRITZ!OS wird ja nur in "tffs_add_file" dadurch "ausgetrickst", daß dort die erzeugte Image-Datei eine kleinere ID erhält und damit nach Ansicht des Systems dann neuer wäre - das findet bei "build_tffs_image" alles nicht statt.
Ich glaube zwar nicht wirklich daran, daß sich durch das Abschalten des WLAN etwas ändert, aber einen Versuch ist es wohl wert.
Ansonsten sieht es ja so aus, als ob 21 bis 25 Sekunden nach dem Start der WLAN-Initialisierung der Neustart erfolgt ... das kann dann entweder direkt eine Aktion beim Start irgendeines neuen Daemons sein oder die Reaktion auf das Ablaufen eines Watchdog-Timers.
Ich kann mich irgendwie des Eindrucks nicht erwehren, daß hier der ARM-Core nicht mitmacht ... der Ablauf beim Initialisieren wäre jetzt folgender:
1. Im Rahmen von "rc.S" wird die "E46-net" aufgerufen (nach allen "S4*"-Dateien) und die fügt an ihrem Ende die "rc.net" ein.
2. In der "rc.net" wird dann die "rc.wlan" aufgerufen und bei deren "start"-Aktion fängt dann mit dem Laden des "wland" auch irgendwann das Geblinke der LED an.
3. Danach wird in der "rc.net" eigentlich nur noch der "dsld" gestartet ... das sollte aber auch klappen.
4. Nach der "E46-net" wieder zurück in "rc.S", käme jetzt in der "E47-voip" der Start des "voipd" an die Reihe ... solange keine Konfiguration vorhanden ist, sollte der auch nichts weiter anstellen.
5. Und damit wäre dann auch die Abarbeitung der "Gruppe 4" beendet und das nächste Skript ist jetzt "S50-lan-sync" - hier wird jetzt auf die ARM-CPU gewartet bzw. darauf, daß diese CPU ihrerseits bis zu einem bestimmten Punkt in der Initialisierung kommt.
Im Punkt 5 würde jetzt unendlich lange auf den ARM-Core gewartet, wenn nicht irgendwo anders dann doch ein Watchdog zuschlägt ... zum Beispiel wird in "S05-watchdog" ein Timer aufgesetzt, der nach spätestens 120 Sekunden die Box neu startet, wenn bis dahin die Initialisierung nicht abgeschlossen wurde. Das paßt nur leider auch wieder nicht zu den beobachteten Zeiten ... aber es ist auch nicht der einzige Watchdog, der verwendet wird, da gibt es noch in den diversen Daemons (und auch im "dsld", der ja schon gestartet wurde) ein paar weitere.
Ich kann mir problemlos vorstellen, daß sich jemand die Box auch dadurch zerschießt, daß er die "config-space"-Partition im SPI-Flash irgendwie versucht zu manipulieren (von Änderung bis Löschen) ... die wird ja auf dem ARM-Core als "/nvram" gemountet (mit JFFS2-Format) und enthält wichtige Daten für den Start der Intel-Programme für das CM. Ob der ARM-Core seinerseits auch ein Zurücksetzen des Gerätes auslösen würde, habe ich mir seit 06.8x (da ist das FRITZ!OS ja dann auf den ATOM-Core umgezogen) nicht mehr angesehen ... denkbar wäre es aber auch.
Es gibt aber noch eine Möglichkeit, mit der man das hier überprüfen kann ... erstens würde nach erfolgreichem Synchronisieren mit der anderen CPU in "S50-lan-sync" der USB-Stack initialisiert (in "S55-usb") und wenn man dort einen Speicher-Stick mit LED ansteckt, müßte man an deren Blinken (beim Zugriff auf ihren Controller, die darf dann nicht nur beim Schreiben leuchten, was auch einige Sticks machen) erkennen können, ob das System überhaupt bis zu diesem Punkt kommt oder nicht. Bei "nicht", ist die Schlußfolgerung, daß das System in der unmittelbar davor abzuarbeitenden "S50-lan-sync" hängt, sicherlich naheliegend.
Dann bliebe noch die Chance übrig, die Synchronisation zwischen den Kernen durch die Angabe von "no_core_sync=1" (getestet wird nur auf "no_core_sync", eine "0" als Wert ist also nicht das Gegenteil) in den Kernel-Parametern zu übergehen ... dazu muß man das einfach nur in "kernel_args" im Environment hinzufügen. Kommt das System danach dann doch bis zum Initialisieren von USB-Geräten (das läuft nach dem Start des Stacks ja auch asynchron über den "udevd" weiter), weiß man wenigstens einigermaßen sicher, daß es an einem Problem bei der Synchronisation mit dem ARM-Kernel liegt. Woran genau, muß man dann auf dem ARM-Core weiter erforschen.