Vorab ein Wort der Warnung ... die Kombination aus "einfache Lösung" und "eine 07 version von der 7362 SL" funktioniert (zumindest nach meiner Erfahrung) so garantiert nicht. Ich will nicht behaupten, daß es komplett aussichtslos wäre - schließlich arbeiten beide Geräte mit demselben (Haupt-)Prozessor, aber schon bei der Frage, ob sie auch beim WLAN identische Komponenten verwenden, würde ich mich erst einmal vergewissern und das gilt ebenso für die weiteren (AVM-spezifischen) Komponenten wie das verwendete FPGA, den DECT-Chip, etc. - wenn Du das schon geklärt hast und die identisch sind (ich habe keines der alten Modelle, die einzigen VR9-Boxen sind die 7490 und die 7412, weil die einige Besonderheiten aufweist), dann lohnt es sich u.U. auch, da weiter zu machen.
Man kann Freetz auch unabhängig von dem Ziel mit 07.xx auf der Box kennenlernen - für eigene Versuche, die (m.E.) nötig wären, um das Problem hier in Angriff zu nehmen - ist die gesamte Toolchain (von den "host tools" bis hin zum "fwmod" als Image-Builder) aber zu unflexibel oder zumindest zu unhandlich. Teile davon kann man durchaus nutzen, aber mit einem einfachen
make und einer Portion Gottvertrauen wird man nicht weit kommen - weil man dann seine eigenen Änderungen auch alle so gestalten muß, daß sie sich in das Freetz-Framework einfügen. Ich würde mir auch nicht die Arbeit machen, das Ganze dann über drei FRITZ!OS-Generationen lösen zu wollen (es sei denn, das primäre Ziel wäre das Erweitern von Freetz-NG um genau diese Optionen), sondern - wenn schon, denn schon - direkt auf das Ziel losmarschieren.
Am Ende willst Du ja offensichtlich einen "Spezialfall", der in Freetz-NG nur für ältere Modelle zur Verfügung steht, wobei man das eben auch erst noch verifizieren müßte (was sicherlich schon lange niemand mehr getan hat), denn bei Dir funktioniert das ja (wenn ich's richtig lese) auch mit der 06.33 für die 7360v1 nicht (ich vermute mal, daß das
06.20+ die 06.3x-Reihe (als Release) einschließen soll). Es ist nun mal nicht auszuschließen, daß Änderungen in Freetz-NG die Funktion dieses Pakets beeinflußt haben. Der einfachste Weg, das zu überprüfen (und erst mal ein
bisect(ing) durchzuführen), wäre es jetzt, dasselbe mit dem originalen Freetz zu versuchen (die Unterstützung für die 7360v1 mit 06.33 ist da ebenso vorhanden):
https://github.com/Freetz/freetz/blob/75984884e4353db3b45b04cd37707c6e929ca0ec/FIRMWARES#L217 ... damit kann man zumindest schon mal feststellen, ob man vor oder nach dem Fork suchen muß, welcher Patch das "zerstört" hat (wobei es soo viele Patches an den Dateien, die tatsächlich das Paket ausmachen, gar nicht gab, der überwiegende Teil ist noch aus 2013-2014).
Aber das ist dennoch (nach meiner Ansicht) ein sehr langer und auch sehr steiniger Weg - und den willst Du dann gleich für mehrere FRITZ!OS-Versionen gehen, die sich auch in den "inneren Werten" deutlich weiterentwickelt haben im Laufe der Zeit. Das würde ich auch nicht machen ... sondern (wenn ich die Zeit opfern wollte, was mindestens von den o.a. (Er-)Kenntnissen abhängt und den damit anzunehmenden Erfolgsaussichten) mir gleich die "finale" Version greifen und zunächst mal deren Kernel (und ggf. auch deren Dateisystem) so weit modifizieren, daß tatsächlich am Beginn nur die Aktionen ausgeführt werden, die für eine Initialisierung des USB-Stacks und die Benutzung von Storage-Devices am (internen) USB-Hub erforderlich sind. Das ist schon genug "Kram", der da gebraucht wird, aber alles das läßt sich immer noch ganz bequem im verfügbaren Flash-Speicher unterbringen. Letztlich macht das Freetz nach demselben Prinzip ... auch hier werden die Treiber für die USB-Unterstützung "außer der Reihe" geladen:
https://github.com/Freetz/freetz/bl...usbroot/files/root/etc/init.d/rc.usbroot#L421 (ansonsten übernimmt das der
udevd) und auch alle anderen "Vorbereitungen", die ansonsten in den
init-Skripten stattfinden (auch dann noch, wenn neuere FRITZ!OS-Versionen mit
supervisor (einen
systemd-Derivat) arbeiten), werden in
rc.usbroot ja in den versionsspezifischen Funktionen "von Hand" ausgelöst:
https://github.com/Freetz/freetz/bl...usbroot/files/root/etc/init.d/rc.usbroot#L148 - warum die
piglet-Treiber noch davor geladen werden, weiß ich nicht - entweder da gibt/gab es Abhängigkeiten oder es sollte die AVM-Reihenfolge so gut es geht nachgebildet werden.
Aber was auch immer der Hintergrund sein mag - am Prinzip, daß erst einmal der Kernel starten muß und der dann (ob nun per Flash-Scanner wie bei AVM oder über ein eingebettetes
initramfs) irgendwo nach einem
rootfs sucht, ändert sich ja nichts und damit ist das auch der allererste Teil (mit der richtigen Kernel-Version), den man zum Laufen bringen muß. Ob man danach das "richtige" Dateisystem auf dem USB-Speicher als SquashFS-Image mountet und mittels
pivot_root dorthin wechselt (so macht es AVM ja selbst bei den VR9-Modellen mit NAND-Flash, nur daß für dessen Nutzung eben kein USB-Stack gebraucht wird) oder ob man es mit einem Overlay versucht (ich weiß nicht mehr genau, ab wann OverlayFS im Kernel verfügbar ist - aber bei AVM ist es (iirc) bei den VR9-Boxen nicht eingeschlossen), kann man sich immer noch überlegen, wenn man es erst einmal bis zu einem solchen Kernel geschafft hat.
Und vor diesem Erfolg (gerade dann, wenn Du am Ende bei einer Firmware landen willst, die eigentlich von NAND-Flash ausgeht, wie bei der 7362SL) hast Du noch so einige Hürden zu überwinden. Das geht - selbst wenn die Komponenten dieselben sind wie bei der 7362SL - dann wieder bei der Frage los, ob das Hardware-Layout (welcher GPIO-Pin ist wohin verbunden und wofür wird er genutzt) auch paßt - ansonsten muß man es erst einmal passend machen. Wenn bei der 7362SL das RST-Signal für irgendeinen Ethernet-PHY an der Stelle liegt, wo der Kernel eine der LEDs "vermutet", würde jeder Versuch, die LED zu schalten, den PHY zurücksetzen ... ähnliches gilt auch für die Anbindung des NAND-Flashs und praktisch aller weiteren Komponenten, die eben nicht über irgendeinen (komplexeren) Bus mit dem Hauptprozessor kommunizieren.
Es läuft dann vermutlich am Ende ohnehin auf einen eigenen Kernel, ggf. auf Basis der passenden Kernel-Quellen für die gewünschte FRITZ!OS-Version, hinaus - aber auch den mußt Du dann eben erst einmal "zusammen kriegen" (wobei Dir die Freetz-Toolchain (in Maßen) helfen kann) und (ausgiebig genug) testen - wobei die Initialisierung dieser Hardware-Komponenten i.d.R. schon direkt beim Start des Kernels erfolgt und das alles noch lange vor der Notwendigkeit eines
rootfs erledigt ist. Danach muß man dann erst mal erkunden, welche Treiber bei der gewählten FRITZ!OS-Version tatsächlich benötigt werden, um den USB-Stack so weit zu initialisieren, daß man überhaupt daran denken kann, Storage-Devices dort zu erkennen und zu mounten.
Da das ganze
usb_root-Zeug auch noch aus einer Zeit stammt, wo es bei AVM gerade mal eine Handvoll an SoC gab, die es zu unterstützen galt (praktisch alle MIPS - ggf. auch mal als LE-Variante), wird das vermutlich auch eher eine "Speziallösung" für VR9-Prozessoren werden - was man berücksichtigen müßte, wenn das Primärziel die Erweiterung von Freetz-NG sein sollte ... das Interesse an VR9-Boxen läßt inzwischen (bei der Masse der Benutzer) auch deutlich nach, das an Vx180-Geräten (primär 7390) ist - m.E. - praktisch gar nicht mehr vorhanden, weil die Plattform zu alt ist für moderne Anschlüsse (u.a. hat dieses SoC nur einen Core und ist damit entsprechend "unflexibel").
Ich will Dich auch nicht entmutigen ... aber anstatt über
kexec nachzudenken (bis zu dem Punkt, wo man einen solchen Syscall überhaupt ausführen könnte, muß man auch erst mal kommen und dann diesen neuen auszuführenden Kernel auch erst einmal von irgendwo laden können), solltest Du Dich eher darauf konzentrieren, einen
passenden Kernel für die Box zu erstellen (wie geschrieben, hast Du da bei der Initialisierung der Hardware vermutlich schon genug zu tun, auch wenn das meinerseits nur "geraten" ist anhand dessen, was ich so aus den Kernel-Quellen kenne), der tatsächlich den USB-Zugriff ermöglicht zu einem Zeitpunkt, wo der Rest der AVM-Komponenten noch gar nicht initialisiert ist. Denn bei einen Restart der Box findet eben auch ein Gutteil der Initialisierung schon im Bootloader statt (den kann man ja praktisch als BIOS sehen, auch wenn er kein API für das OS bietet, wie es ein "klassisches BIOS" nun mal macht) und irgendwelche "nachträglichen" Initialisierungsversuche durch einen neuen Kernel würden die meisten Komponenten auch erst einmal wieder zurücksetzen, womit dann auch wieder die Funktion des USB-Stacks in Frage gestellt würde, etc. ... das
kexec ist nicht umsonst ein "spezieller" Syscall, der eher für Fehlersuchen und Entwicklung gedacht ist.
Was Du aber mal testen könntest ... ich bin mir nicht sicher (weil ich noch keine 7360v1 selbst getestet habe, die "abgespeckten" Modelle sind nicht so meins), würde dennoch behaupten/annehmen, daß auch bei der 7360v1 ein Start des OS aus dem RAM möglich ist (das ging auch bei der 7390). Zwar wird dieser Weg von AVM selbst nicht genommen, um das OS zu installieren (wie bei den Modellen mit NAND-Flash und
wrapper-Partition mit YAFFS2-FS), aber das heißt noch nicht automatisch, daß man ihn nicht selbst gehen könnte. Man kann ja noch einmal in die Kernel-Quellen sehen (den Flash-Parser findet man schnell), ob das (a) unterstützt wird und (b), welche Dateisystemformate dabei berücksichtigt werden. Dann kann man sich aus dem Kernel und einem passenden Dateisystem wieder ein Image zusammenbauen, das man direkt aus dem RAM starten kann - das kostet zwar ein paar MB an Hauptspeicher zur Laufzeit, schont aber den Flash-Speicher und braucht i.d.R. auch weniger Zeit, als wenn man das Zeug erst in den Flash schreiben und dann von dort starten läßt.
Zumindest für die ersten Gehversuche (die sich ja i.d.R. darum drehen würden, erst mal einen "fehlerfreien" Start des Kernels zu ermöglichen) wäre das ein gangbarer Weg - erst recht dann, wenn man die serielle Console bestückt hat. Da bleibt auch noch genug übrig von den vorhandenen 128 MB RAM, so daß man diese Phase durchlaufen kann, ohne auch nur ein einziges Byte in den NOR-Flash (für das System zumindest) zu schreiben. Selbst wenn der Parser bei der 7360v1 ungenutzten Flash-Speicher als JFFS-Partition für den AB nutzen wollte, muß man eben dafür sorgen, daß er keinen solchen ungenutzten Platz findet. Da man (vermutlich zumindest) ohnehin einen eigenen Kernel verwenden muß, sind ein paar eigene Anpassungen da auch kein zusätzliches Problem bzw. kein zusätzlicher Arbeitsschritt/größerer Aufwand.
Ich denke jedenfalls nicht, daß ein (originaler) 07.12-Kernel für die 7362SL auf einer 7360v1 überhaupt eine Chance hat zu funktionieren - schon der Unterschied NOR vs. NAND erfordert ja ein anderes Layout, denn NAND-Flash ist eben nicht über den Data-Bus direkt als Speicher adressierbar und muß praktisch "sequentiell" ausgelesen und die Daten ins RAM geschrieben werden. Vielleicht hat AVM ja tatsächlich in den VR9-Quellen sowohl die Unterstützung von NOR-Flash als auch von NAND-Flash vorgesehen (da gibt/gab es immer mal wieder ein paar Symbole, die das nahelegen könnten), aber dann müßtest Du vermutlich immer noch den eigenen Kernel mit den richtigen Settings bauen (lassen).
Jedenfalls erfordert Dein Vorhaben schon einigermaßen solide Kenntnisse davon, wie Linux an sich und auf "embedded devices" im Speziellen funktioniert und wie AVM einiges davon gelöst hat. Da kommt dann noch ein grundlegendes Verständnis von C-Programmierung dazu, denn ganz ohne eigene Änderungen an den Kernel-Quellen (und die sind praktisch zu 100% C-Code) wird es vermutlich auch nichts werden. Das wird also ein recht anspruchsvolles Hobby ... was Dich nicht entmutigen sollte. Aber Du solltest dann eben auch nicht erwarten, daß Du sehr schnell große Erfolge erzielen kannst oder gewaltige Fortschritte sich quasi automatisch einstellen - wenn Du erst beginnst, Dich mit der Materie zu befassen, wird das eine lange "Lehrzeit" werden.
Aber auch eine Reise von tausend Meilen beginnt mit einem einzigen Schritt (wird als Zitat m.W. Konfuzius zugeschrieben) ... und wenn Du Dir "einen Plan" machst, solltest Du - meine Empfehlung - an den Anfang das Erkunden der Möglichkeiten der Hardware/des Bootloaders setzen (das wäre u.a. das Starten aus dem RAM) und den Vergleich der (primär Hardware-)Komponenten zwischen der 7360v1 und dem Gerät, dessen Firmware Dein "eigentliches Ziel" wäre. Du kannst zwar auch Schritt für Schritt den AVM-Versionen folgen (das wäre dann die 06.33 für die 7360v1, danach irgendwann mal die 06.8x für die 7360v2, dann später noch die 07.12 für die 7362SL), machst Dir aber am Ende auch dreimal die Arbeit. Allerdings stehen die Chancen, das bei der Firmware für die 7360v2 hinzubekommen, m.E. auch deutlich besser, als beim Versuch, eine - in weiten Teilen andere - Firmware (wie die der 7362SL) auf die 7360v1 zu bekommen.
AVM ist eigentlich nicht dafür bekannt, populäre Modelle allzu schnell fallen zu lassen (zumindest war das bis vor einigen Jahren so) und wenn da die Entscheidung getroffen wurde, die 7360v1 ab 06.5x nicht mehr zu unterstützen, hatte das sicherlich auch seinen Grund. Bei anderen Modellen mit knappem Flash-Speicher (wie z.B. der 7390) hat man sich ja auch etwas einfallen lassen (allerdings hat die auch noch internen Flash fürs NAS, den man dabei (mittlerweile) nutzt) und einen Plugin-Mechanismus eingebaut, der u.a. die für das WLAN benötigte Software (als "größerer Brocken") erst bei bestehender Internet-Verbindung von einem AVM-Server nachlädt - ähnliches könnte man (als Hobby zumindest) auch noch in Erwägung ziehen.
Wenn man es erst einmal hinbekommen hat, daß man ein Storage-Volume ansprechen kann, BEVOR die ganzen AVM-Komponenten initialisiert wurden, dann ist das schon deutlich mehr als nur die halbe Miete ... vielleicht wäre es doch klüger (je nach Nachhaltigkeit Deiner Ambitionen), entgegen meinem ersten Vorschlag, sich eher auf die Firmware der 7360v2 zu konzentrieren. Nur wirst Du mit der eben auch final nur auf einem Firmware-Stand landen, den man eigentlich nicht mehr einsetzen sollte - da man nicht genau weiß, wo die (Sicherheits-)Probleme der AVM-Firmware wirklich liegen (ich kenne auch nur eine kleine Auswahl davon und habe versucht, die zu dokumentieren), wird daraus dann vermutlich auch kein Gerät, was man guten Gewissens tatsächlich irgendwo produktiv nutzen kann (zumindest nicht in dem Umfang, wie es eine AVM-Firmware erlauben würde und wenn man den "zusammenstreicht", kann man sich auch gleich nach Alternativen umsehen).
Wenn man also ein so altes Gerät "in vollem Umfang" nutzen will (und wenn man sich eine 07.xx-Firmware wünscht, kann das ja fast nur noch wg. Mesh und/oder SmartHome sein, denn ansonsten hat AVM in den letzten Versionen ja (fast) nichts (wesentlich) geändert), dann lohnt sich (in meinen Augen) der Aufwand nicht (auch nicht "zum Üben", weil neuere Modelle dann auch wieder anders aufgebaut sind und andere Probleme haben/bereiten) ... etwas anderes wäre es z.B., wenn man das nur als zusätzliche DECT-Basis für einen zweiten Aufstellort oder als (internen) SIP-Registrar nutzen wollte, wobei man dann auch nicht zwingend auf eine 07.xx-Version muß - und mit der Option, nicht verwendete Teile aus der Firmware zu entfernen, auch schon wieder realistischere Aussichten hat, das in den vorhandenen Flash-Speicher zu packen. Aber ein "ich will alles" steht solchen Alternativen dann halt auch im Weg - die aber ohnehin nur in Frage kommen, wenn es sich um eine "rein interne" Nutzung handelt (ansonsten ist das Risiko wieder unkalkulierbar - das ist schon bei rein interner Nutzung "kein Spaß").
