Ja, (großes) SORRY ... ich hatte vergessen, die nachträglich noch gewonnenen Erkenntnisse hier auch aufzuschreiben.
Denn ich hatte hinterher noch mal in den VR9-Quellen gesucht und dabei festgestellt, daß es für die 3370 (nun aber wirklich als einziges Modell, zumindest bei diesem Chipset und wenn man den Kernel-Quellen traut) tatsächlich in der GPIO-Belegung einen "Power Off"-Button gibt (aus
avm_hw_config_hw175.h
):
C:
90 /*--- POWER button connected to EXTIN 1 ---*/
91 {
92 .name = "gpio_avm_button_power",
93 .value = 1,
94 .param = avm_hw_param_gpio_in_active_low,
95 .manufactor_hw_config.manufactor_lantiq_gpio_config = {
96 .module_id = IFX_GPIO_MODULE_LED,
97 .config = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
98 }
99 },
und auch im Handbuch der 3370 ist das ja beschrieben:
https://avm.de/fileadmin/user_uploa...Z_Box/Weitere_Box/Handbuch_FRITZ_Box_3370.pdf
Damit kann die Box dann natürlich auch wirklich "ausgeschaltet" sein - bleibt die Frage, wer da nach 30 (oder 90) Sekunden die Änderung für den GPIO-Port signalisieren sollte und warum.
Da hätte ich aber in jedem Falle gleich besser recherchieren sollen (und in meiner Welt auch müssen) ... was damit aber immer noch nicht erklärlich ist, wäre die Frage, warum die Zeit bis zum Ausschalten sich ändert, wenn da ein anderes System installiert, aber noch gar nicht gestartet wird.
Aber um diese Zeit dann zu "überlisten", kann man - neben der Empfehlung, eine Textdatei dafür zu benutzen und das per C&P von Hand im FTP-Client zu machen - auch die passenden "eva_tools" verwenden ... wobei EVA bei der 3370 offenbar sogar noch verwendet werden kann/konnte (wenn man OpenWRT-Commits dazu liest:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0b62fe5ed87ecac52301096b15abb69f96117c8c), um direkt in den (NAND-)Flash zu schreiben, was AVM bei den späteren Modellen zwar auch nicht verhindert, was aber - hier mehrfach berichtet von Besitzern solcher Modelle - im besten Falle dann nicht mehr funktioniert und im schlimmsten Falle sogar die Box erlegt.
Wobei mich bei diesem Modell und dem Flashen direkt über EVA dann wieder interessieren würde, wohin das genau geschrieben wird ... denn die hat ja wohl (den Quellen nach zu urteilen) auch eine "mirrored"-Architektur (wo mit "linux_fs_start" das zu ladende System ausgewählt wird) und kennt (dem Environment nach zu urteilen) nur fünf MTD-Partitionen im Bootloader insgesamt (anders als z.B. die Puma6-Boxen, wo ja die MTD-Namen in EVA je nach "linux_fs_start"-Wert verändert werden). Von einer Architektur, wo tatsächlich zwei Flash-Chips vorhanden sind und über ein CS (Chip Select) einer der beiden ausgewählt wird (wie bei der 6360), ist bei der 3370 m.W. auch nichts bekannt. Wie entscheidet hier also der Bootloader (EVA), welche der vorhandenen Partitionen zu beschreiben wären, wenn das Kommando einfach "STOR mtd0" heißt (für das Dateisystem, der Kernel steht wohl in "mtd1", wie bei AR7 und Nachfolgern üblich)?
PS: Das ist auch nicht nur reine Neugierde oder die Freude am Nachdenken ... ich bräuchte diese Infos tatsächlich für die notwendigen Vorsichtsmaßnahmen im Boot-Manager und/oder für "modfs" (
https://github.com/PeterPawn/modfs/blob/master/modfs#L51), wo die 3370 wie alle anderen VR9-Modelle behandelt wird.
@stoney: Du hattest mir (iirc) mal das Angebot gemacht, daß Du auf eine 3370 zugreifen könntest ... kannst Du zu diesen Fragen irgendetwas sagen? Hast Du event. da mal ein Recovery-Programm mitgeschnitten? Schon das wäre ja interessant zu wissen, ob AVM hier selbst den Weg über das direkte Schreiben nimmt oder doch über den Hauptspeicher installiert - zumal bei diesem Modell m.W. (trotz des unterschiedlich großen Flash-Speichers (wobei der "Rest" sicherlich wieder als NAS genutzt wird, egal wie groß der ist) und trotz unterschiedlicher NAND-Flash-Treiber (nach dem OpenWRT-Commit ja mal mit und mal ohne Hardware-ECC, so daß der Kernel das unterscheiden muß) von AVM offiziell keine "Revisionen" eingeführt wurden, wie bei 7270 oder 7360. Das würde dann ja heißen, daß auch die aktuelle Firmware für die 3370 ALLE Versionen unterstützt, egal wie die Hardware aussieht. Oder habe ich da etwas vollkommen verpennt?
EDIT: Die Frage kann ich mir im Prinzip doch alleine beantworten (und die fehlende Zeit bisher für diese - jetzt aber nachgeholte - Recherche war auch der Grund, warum ich das noch nicht korrigiert hatte) - der Blick in die 3370-Firmware zeigt, daß diese - genauso wie bei allen anderen VR9-Boxen mit diesem Aufbau - dafür ausgelegt ist, aus dem RAM gestartet zu werden und sich dann selbst in den Flash-Speicher zu schreiben. Ich wäre auch überrascht gewesen, wenn ich in "modfs" die Unterstützung für die 3370 freigeschaltet hätte, ohne das zuvor zu prüfen - nur war ich mir da nicht sicher (jedenfalls nicht mit der notwendigen Bestimmtheit).
Damit stellt sich mir die Frage, warum das bei der 3370 so funktioniert bzw. so funktionieren soll - oder es wird dabei eben doch (auch erfolgreich) geschrieben, nur ist das dann eben das Partition-Set, was nur bei "linux_fs_start=0" benutzt wird und die ganzen Berichte über Mißerfolge beim Flashen von NAND-Boxen über EVA (mal abgesehen vom Bricken bei GRX-Modellen - vorher konnten ja auch, fast "über Jahre", die NAND-Boxen mit VR9 nicht per EVA "bespielt" werden) beruhen letztlich nur darauf, daß da jeweils gerade "linux_fs_start=1" gesetzt war und die Box deshalb aus dem falschen Partition-Set startet(e).
Ich bin am Überlegen, ob ich das bei (m)einer 7490 einfach mal probiere - angesichts der Tatsache, daß das AVM-Recovery-Programm es so eben auch nicht nutzt (was ja problemlos möglich wäre, wenn es beim Schreiben des TFFS-Images "linux_fs_start" einfach wegließe oder explizit auf 0 setzen würde - ich war mittlerweile so konfus, daß ich erst noch einmal nachgesehen habe, ob das Recovery-Programm nicht doch "linux_fs_start" ändert oder löscht, was - bei mir - jedenfalls nicht der Fall ist/war), war das bisher für mich eigentlich ein Tabu und axiomatisch, daß das bei den VR9-Boxen mit NAND-Flash so nicht funktioniert, weil die Bootloader "nicht smart genug" sind, um die verschiedenen denkbaren NAND-Aufbauten (auch sind es mal Chips mit ONFI und mal welche ohne, afaik) auseinanderzuhalten.
EDIT2:
@julizyfflich
Damit mußt Du Dir diese Gedanken:
Zudem habe ich Bedenken, dass dies dann genau passiert, wenn ich die Images via FTP übertrage.
aber auch nicht machen. Verwendest Du den AVM-Weg und lädst die zu installierende Firmware in den Hauptspeicher (bei meinem Angebot wäre das die Verwendung von "eva_to_memory"), startet die Box erst mal aus dem RAM (und das natürlich auch nur dann erfolgreich (also mit mountbarem Root-FS), wenn die Übertragung komplett war) und wenn erst mal der Linux-Kernel das Regiment übernommen und die GPIO-Pins passend initialisiert hat, sollte da auch kein "vagabundierendes" Power-Off mehr kommen. Dann schreibt sich die Firmware selbst in den Flash (und zwar in den Satz von Partitionen, der gerade aktiv ist nach dem Wert von "linux_fs_start") und startet danach die Box neu. Da gibt es dann praktisch kein Risiko ... wobei ansonsten ja ohnehin noch das zweite Partition-Set (in dem man dann eine funktionierende Firmware haben sollte) bliebe als Alternative, wenn es irgendein (anderes) Problem gibt.