sei doch froh dass es die Funktion nicht mehr gibt. Alle damit bisher erstellen inmemory sind fehlerhaft da sie die überflüssige Checksumme enthalten.
Das trifft für die Lösung in Freetz ja explizit nicht zu ... denn dort werden die beiden Dateien zur "in-memory"-Datei zusammengefügt (ab Zeile 1711), BEVOR die Prüfsummen für die beiden Dateien erzeugt werden (ab Zeile 1721):
https://github.com/Freetz/freetz/blob/master/fwmod#L1711
Aber man braucht - wenn man Freetz-NG nutzen will oder muß - ja tatsächlich nur den einen zusätzlichen Aufruf, wenn man lieber das "ungewöhnliche Format" haben will, daß da vom Bootloader (m.W. bei allen Boxen, was das "ungewöhnlich" irgendwie gewöhnlich und häufig anzutreffen erscheinen läßt) auch verstanden wird.
Letztlich ist sogar die "kombinierte Datei" bei den Modellen, wo die "filesystem.image" eine Größe von 0 Byte hat, dasselbe ... bei den früheren Modellen störte (iirc) auch die Prüfsumme an der "kernel.image" noch und mußte abgeschnitten werden, wenn man diese "aus dem RAM" starten wollte.
Es gab also den weiter oben gezeigten Code, der bei VR9-Boxen mit einem Offset nach dem Dateisystem sucht, noch nicht - bei Start aus dem Flash-Speicher startet bei NOR-Flash der Kernel eben auch automatisch an einer 256-Byte-Grenze, weil er ja an den Beginn der entsprechenden Partition (die i.d.R. an einer solchen Grenze ausgerichtet ist) geschrieben wird.
Das Prinzip des Startens aus dem RAM beherrschen die AVM-Boxen iirc seit der Umstellung von ADAM(2) auf EVA - bei TI sieht/sah das noch etwas anders aus, obwohl auch da schon "spezielle Images" gestartet werden konnten, für die es sogar ein paar nachgebildete Funktionen aus dem "YAMON interface" gab zum Zugriff auf die Konsole und für die Benutzung von ISR/ESR (Interrupt Service Routine/Exception Service Routine) - leider ist das ganze Zeug dazu "Copyright (c) 2004 MIPS Technologies, Inc. All rights reserved." und nicht OpenSource, daher kann/darf man es nicht weitergeben.
Aus dieser Zeit stammt jedenfalls das Prinzip mit dem "Header" vor dem (ggf. gepackten) Kernel und AVM hat dann (immer nur m.W. bzw. nach meinen Recherchen) den Teil dazugebaut, wo das eben nicht automatisch Flash-Speicher sein mußte, aus dem das System (bei "gleichbleibendem Prinzip") gestartet werden konnte (hier legte der Wert von "mtd1" dann die "Startadresse" fest), sondern wo das auch aus dem RAM möglich war, nachdem man Kernel und Dateisystem dorthin geladen hatte.
Die Angaben in den "kernel_args" zur Adresse und Größe des "mtdram"-Devices dienen erst dem gestarteten Kernel zur Orientierung ... für den Startversuch aus dem RAM an sich ist das spezielle Format des "STOR"-Kommandos im FTP-Dialog verantwortlich (deshalb gibt es die Fehlermeldung mit dem 553 auch in Reaktion auf dieses Kommando).
Man kann sich natürlich auch auf den Standpunkt stellen, das dabei von AVM verwendete Format wäre "ungewöhnlich" - nur ist das eben schon sehr, sehr lange auch in dieser Form "stabil" und wird auch von JEDEM AVM-Recovery-Programm genutzt, wenn das FRITZ!Box-Modell diese Form der Installation durch den Start aus dem RAM verwendet. In einem Recovery-Programm finden sich dann eben auch von Beginn an keine (TI-)Prüfsummen hinter den Teilen "Kernel" und "Dateisystem" - und obendrein stehen die auch in einem Recovery-Programm üblicherweise nicht hintereinander (zumindest nicht so, daß sie als ein gemeinsamer Stream übertragen werden könnten).
Dieses "ungewöhnliche" Format ist letztlich auch mit dem Flash-Inhalt bei NOR-Modellen identisch, nur werden die Daten beim Start aus dem RAM eben ans
obere Ende des verfügbaren Speichers geladen und genau diese Änderung des "Ankers" (mal "von vorne", mal "von hinten") ist der Grund dafür, daß die Prüfsumme (wenn vorhanden) zu einem "mis-alignment" beim Start aus dem RAM führt (was den Kernel gar nicht juckt, denn erst beim Suchen des Dateisystems geht das dann - mal mehr, mal weniger - schief) - beim Start aus dem (NOR-)Flash hängt die Prüfsumme einfach nur hinten dran und interessiert niemanden.
Das macht die Frage, ob das Vorhandensein einer solchen Prüfsumme nun als "Normalfall" oder nur als (alte) Absicherung bei BESTIMMTEN Vorgehensweisen anzusehen ist, doch gleich noch mal so interessant, denn bei genauerer Betrachtung ist die Feststellung:
Bei den AVM Geräten wird die Firmware als .Image verteilt.
ja auch falsch, solange da kein "unter anderem" oder auch ein "überwiegend" enthalten ist. Denn die Firmware wird natürlich auch in Form des Recovery-Programms verteilt und Freetz ist sogar in der Lage, aus einem solchen die beiden benötigten Images zu extrahieren und diese dann anstelle einer AVM-Image-Datei zu verwenden.
Diese ganzen Prüfsummem werden eben nur dann benötigt, wenn das originale Installations-Skript von AVM (/var/install in einer Image-Datei) verwendet wird, weil das (wohl eher aus historischen Gründen, denn aus tatsächlicher Notwendigkeit) diese Prüfsummen "sehen" und überprüfen will, obwohl die denkbaren Ursachen für Abweichungen an dieser Stelle nun wirklich sehr exotische Probleme darstellen würden.
Sogar ein Problem mit zu wenig freiem Speicher beim Entpacken (das ist einer der wenigen "glaubwürdigen" Fälle) würde auf diesem Weg (bei praktisch allen AVM-Images, die ich in letzter Zeit gesehen habe) nicht wirklich erkannt, weil das in der "/var/install" (die ganz vorne im TAR-File steht bei AVM) aufgerufene "chksum" erst nach der "filesystem.image" im TAR-File kommt und dann wohl auch nicht mehr erfolgreich entpackt werden könnte ... damit schlägt das dann nicht deshalb fehl, weil die Prüfsumme an der Datei nicht stimmt, sondern weil der Aufruf des Programms komplett in die Hose geht, da seine Existenz auch nicht überprüft wird, bevor man es bei AVM ausführen will.
Selbst das "CHECK"-Kommando im FTP-Server berechnet auch nur einen neuen CRC32-Wert (afaik über die gesamte Partition, auch wenn die nicht vollständig gefüllt ist) und vergleicht den nicht mit irgendwelchen Werten am Ende der (gültigen) Daten. Würde Freetz also - anstatt selbst eine Prüfsumme zu berechnen und anzuhängen - einfach nur deren Prüfung aus der "/var/install" entfernen, gäbe es das ganze Theater mit der Frage, ob da nun eine Prüfsumme dranklebt oder nicht, schon längst nicht mehr.
Ich habe ja auch kein Problem damit, wenn jemand eine bestimmte Vorstellung hat, wie etwas gemacht wurde/werden sollte und daran dann auch festhält, zumindest für sich selbst - nur muß man deshalb die anderen Wege ja nicht "entwerten" oder die Nachfrage nach diesen dann als "ungewöhnlich" ansehen oder den eigenen Weg als "besser" anstatt "anders" - zumindest nicht ohne nachvollziehbare Begründungen, wobei die eben nicht nur einen selbst, sondern die anderen überzeugen sollten.
Und wenn man - durch das "Abschaffen" der notwendigen Einstellungen - versucht, die Benutzer auf die eigene Lösung "hinzuleiten", dann sollte/muß diese eben auch funktionieren. Angesichts von einigen erheblichen Schnitzern in der Vergangenheit in "push_firmware", die auch über längere Zeit nicht auffielen, haben die Neuerungen in "push_firmware" diese Hürde in der Akzeptanz wohl bei "der breiten Masse" von Freetz-NG-Benutzern doch noch nicht gefunden (oder vielleicht hat sich das auch gebessert, nachdem die Schnitzer beseitigt waren - wobei ja immer noch einiges offen wäre, s.o.) - woran das nun am Ende liegen mag und wie da die Verteilung aussieht, weiß ich natürlich auch nicht.
Das wäre m.E. doch eigentlich alles gar nicht notwendig und ja nun auch sehr leicht zu korrigieren (selbst wenn die Positionen in den Dateien in Freetz-NG inzwischen etwas andere sind) ... etwas (Funktionierendes) aus dem "Eltern-Projekt" auszubauen, braucht schon eine sehr gute Begründung in meinen Augen und angesichts der Tatsache, daß da auch nichts groß "zu pflegen" wäre bei dieser Option oder das - außer dem Platzbedarf für die zusätzliche Datei und der ist wohl auch nur selten ein Thema - irgendwelche anderen Nachteile (für die Freetz-Benutzer) hätte, bleibt halt die Frage, warum das notwendig war und ob man das nicht noch einmal überdenken kann oder gar sollte.
Ein "braucht ohnehin keiner" kann es ja am Ende auch nicht gewesen sein, wenn der Bedarf besteht (und das sogar so häufig nachgefragt wird, daß Du (
@fda89) davon schon genervt bist und es zu diesem Thread überhaupt kam) und auch ein "geht ja auch anders" ist - beim "Ausbauen" einer Funktion, die keiner ständigen Pflege bedarf, wie irgendwelche Pakete o.ä. - sicherlich für die
Freetz-Benutzer nur schwer nachzuvollziehen (und am Ende sollen die ja sicherlich "die Zielgruppe" sein).
Die acht Zeilen aus dem "fwmod" in Freetz (und die zusätzliche Option in der Vorlagedatei für "Kconfig") machen den Kohl nun auch nicht mehr fett (da war das Entfernen sogar zusätzlicher Aufwand) und das ist auch keine "uralte Funktion", die nun
wirklich niemand (außer einer Handvoll von Leuten) mehr braucht (wie die Unterstützung von "Alice-Boxen" u.a.) oder die sich mit irgendeiner anderen Funktion oder Einstellung (weder in Freetz, noch in Freetz-NG) beißt oder einer anderen "weichen" mußte, weil sie mit ihrer puren Existenz das Implementieren
neuer Funktionen erschwerte und damit zum Hemmschuh wurde.
Das ist praktisch ein "in sich geschlossener Block" ohne irgendwelche anderen Abhängigkeiten - außer einem passenden Modell, weil Freetz das für die NOR-Boxen (obwohl es dort ebenso funktioniert, nur daß die Installation in den Flash-Speicher dabei nicht automatisch erfolgt) ohnehin nicht vorsah.
Letztlich stellt sich (für mich, der ich üblicherweise über den Bootloader installiere und nur sehr selten über selbst-signierte Images, wobei bei mir die Variante über das Freetz-GUI nicht in Frage kommt, weil ich ja keinen "Freetz-Mod" verwende) sogar die Frage, ob man nicht tatsächlich die Option zur Erzeugung des "in-memory"-Images noch dahingehend erweitern kann, daß eine zweite Option (die nur dann auswählbar ist) das Erstellen des kompletten Images (was nach dem Zusammenkopieren ja noch einige Zeit braucht) verhindern kann - wer ohnehin über den Bootloader installieren will, braucht dann auch kein anderes Format mehr ... egal wie gewöhnlich oder ungewöhnlich man das finden mag.
Das gesamte Signieren von Images (für das ich ja auch eine (mittlerweile in 100% und nicht nur in 95% (19 von 20) der möglichen Fälle für die "Restgröße" einer Imagedatei im letzten (10 KB-)Block) funktionierende Lösung anbiete) habe ich auch nicht primär für diese Fälle analysiert und nachgebaut - die Verwendung zum Signieren "kompletter Firmware-Images" ist eigentlich nur ein (nettes) Abfallprodukt. Wirklich interessant wird dieses Signieren dort, wo es um das "Nachladen" von solchen Image-Files im laufenden System geht, wie das z.B. beim Update von DECT-Firmware der Fall ist.
