@qwertz.asdfgh:
Sind das Deine eigenen Erfahrungswerte (Dir traue ich zu, daß Du die Änderungen immer korrekt vornimmst und damit hat die Feststellung "geht nicht" dann auch entsprechendes Gewicht, weil sie von Dir dann sicherlich auf mehreren Geräten beobachtet und validiert wurde) oder basiert das "nur" auf Berichten Dritter?
Klar, ich kann mir auch vorstellen, daß bei einer 7490 das Branding in die Liste der "unveränderlichen" Werte aufgenommen wurde (ähnliches Verhalten zeigten ja schon einige Boxen bei "maca" und ein paar weiteren Variablen, wobei ich gerade keine "Liste" im Kopf habe und auch noch nicht nach etwas gesucht habe, was diesen "Unterschied" markieren würde) und sich nicht mehr ändern läßt.
Aber der Zusammenhang zum FDT aus dem Bootloader (wo das Environment im Zweig "chosen" enthalten ist und auch vom Kernel von dort kopiert/benutzt und nicht länger aus dem TFFS-Image gelesen wird - zumindest in "env_init()" in "kernel/env.c" und in der Folge bei jedem Aufruf vom "prom_getentv()") bei den GRX-Boxen existiert zumindest unbestreitbar.
Nun muß man sich vielleicht erst einmal hinsetzen und ermitteln, wie das Environment für den Zugriff über "/proc/sys/urlader" (also über den TFFS-Driver, der ja für diesen procfs-Zweig verantwortlich ist - siehe "drivers/char/tffs/tffs_proc.c") wirklich zusammengesucht wird bei den GRX-Boxen.
Der Teil der Firmware, der als Shell-Skript realisiert ist, greift ja über diesen Weg auf die Daten zu ... es gibt jedoch in der "libboxlib.so" noch einige Funktionen (boxenv_*), die aber vermutlich über "urlader_{get,set}env" in der "libavmcsock.so" auf das Environment zugreifen und die verwendet wohl (dem Augenschein nach jedenfalls) ebenfalls die Datei "/proc/sys/urlader/environment" für ihre Zugriffe.
Am Ende dürfte es also entscheidend sein, woher diese Zugriffsfunktion im TFFS-Proc-Driver (avm_urlader_setenv_sysctl()) ihre Daten beim Lesezugriff bezieht ... kostet halt einiges an Zeit, das nachzuverfolgen.
Angesichts der oben von mir angedeuteten Zusammenhänge könnte es ja genauso gut sein, daß gar kein direkter Zusammenhang zum Bootloader besteht oder daß das tatsächlich für alle Bootloader gilt, deren Versionsnummer größer als ein Schwellwert ist. Ebenso ist es aber auch möglich, daß es nur an FRITZ!OS-Versionen und deren Auswertung der Variablen liegt - mithin daran, woher die ihre Informationen beziehen. Oder am Ende an einer Kombination von beiden ... warum das bei der 7560 so problemlos klappen soll, will mir dann nämlich auch nicht richtig einleuchten.
Bis auf die Halbierung beim RAM und nur 1/4 des NAND-Flashs unterscheidet die sich ja auch nicht so sehr von den anderen beiden Modellen und m.W. hat noch niemand wirklich geprüft, ob nicht auch bei dieser genau derselbe "bootcore"-Kernel oder vielleicht sogar derselbe FRITZ!OS-Kernel verwendet wird, wie bei einer (versionsgleichen) 7580 - die Hardware-Unterschiede finden jedenfalls problemlos im FDT Platz und damit wäre es meiner Ansicht sogar denkbar, daß auch da derselbe Kernel zum Einsatz kommt. In Deiner Liste steht ja nur die 7560 mit einem Bootloader vor 1.31xx drin - vielleicht gilt das für die 7560 mit einem neueren Bootloader aber wieder genauso.
Das muß man sehr genau testen - am besten mit einem eigenen Kernel, der auch nicht sofort wieder irgendwas ins TFFS zurückschreibt, damit man wirklich den Zustand von FDT und TFFS bei der Übergabe der Steuerung an den Linux-Kernel festhalten kann.
Bis dahin bleibe ich erst einmal bei meiner Differenzierung "VR9 - geht" und "GRX - geht nicht" (mal sehen, wie sich das beim Puma6/7 dann entwickelt, die 6591 wird ja vermutlich einen neueren Bootloader haben) - wenn man die passenden Stellen im Kernel gefunden hat, kann man ja immer noch entscheiden, ob man das an irgendwelchen anderen Merkmalen besser festmachen könnte. Wobei das "geht nicht" eben auch immer darauf basiert, daß der Kernel nicht einfach den Wert aus dem TFFS nimmt und den FDT (an dieser Stelle) ignoriert ... notfalls kann man das sogar mit einem eigenen Kernel (wenn man den vielleicht ohnehin austauschen möchte, weil ihm z.B. das "overlayfs" fehlt beim VR9-Modell) wieder korrigieren, was AVM da "verzapft". Wobei das nur beim Unterschied deutsche und internationale Version überhaupt interessant ist ... bei "1und1" vs. "avm" würde ich mir auch keinen Kopf weiter machen, weil die halt beide in der deutschen Firmware enthalten sind.
