Closed PeterPawn closed 2 years ago
freetz-ng-mod
commented
2 years ago Das, was du sagst, werde ich testen. Ich kann nur die Box nicht so lange anlassen, da sie zu heiß wird. Mit freetz. Aber dazu mache ich grade noch ein Test Original Image darauf und warte nun ca. 30 Min und schaue wie die Temperatur dann ist. Und dann 30 min mit freetz
PeterPawn
commented
2 years ago Bisher bringt es noch nichts, irgendetwas anderes als fitdump.sh oder fit-findfs.sh auf dieses Modell loszulassen. Wenn das Image in einer Partition stimmt, sollten diese beiden Skripte es auch verarbeiten können (ggf. wieder das zu löschende Verzeichnis beim fitdump.sh beachten). Am besten dann auf die Partition mit dem aktiven System gehen - da ist wenigstens sicher (sollte man jedenfalls annehmen), daß das FIT-Image auch ein passendes Format hat.
freetz-ng-mod
commented
2 years ago cat /proc/mtd
dev: size erasesize name
mtd0: 03200000 00020000 "fit0"
mtd1: 00180000 00020000 "urlader"
mtd2: 00800000 00020000 "nand-tffs"
mtd3: 03200000 00020000 "fit1"
mtd4: 01280000 00020000 "ubi"
mtd5: 0020f000 0001f000 "config"
mtd6: 00cf5000 0001f000 "nand-filesystem"wget https://github.com/PeterPawn/YourFritz/raw/fit-tools/fit_tools/fit-findfs.sh time sh fit-findfs.sh /dev/mtdblock0
Command exited with non-zero status 1
real 0m 3.28s
user 0m 0.04s
sys 0m 0.32stime sh fit-findfs.sh /dev/mtdblock3
Command exited with non-zero status 1
real 0m 7.46s
user 0m 0.01s
sys 0m 0.93swget https://github.com/PeterPawn/YourFritz/raw/fit-tools/fit_tools/fitdump.sh time sh fitdump.sh /dev/mtdblock0
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x26c1a4b (40639051)
Payload size (1260022786 = 0x4b1a6c02) at offset 0x04 doesn't match FDT data size at offset 0x4c (40639051 = 0x26c1a4b), processing aborted.
Command exited with non-zero status 1real 0m 0.33s user 0m 0.06s sys 0m 0.20s
rm -r fit-dump/ time sh fitdump.sh /dev/mtdblock3
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x26c2047 (40640583)
Payload size (1193307138 = 0x47206c02) at offset 0x04 doesn't match FDT data size at offset 0x4c (40640583 = 0x26c2047), processing aborted.
Command exited with non-zero status 1real 0m 0.32s user 0m 0.06s sys 0m 0.21s
PeterPawn
commented
2 years ago Ich hatte dieses Modell u.a. deshalb von den "anderen" getrennt, weil sich an diesem eine zuvor für mich noch offene Frage geklärt hatte ... nämlich die, inwieweit die ersten zwei 32-Bit-Werte in einer Image-Datei von der Byte-Order der jeweiligen Plattform abhängig sind (Big Endian vs. Little Endian).
Da die 5530 ja einen MIPS-Prozessor verwendet und der mit BE-Order arbeitet (das belegen zumindest die Binaries in der AVM-Firmware und ich wüßte nicht, daß da ein "Mischbetrieb" möglich ist), verwenden das AVM-Magic und die darauf folgende Größe der Daten im FDT (ab Offset 72) offenbar IMMER LE-Order bei der Speicherung.
Das macht es dann wieder erforderlich, diese Werte IMMER als LE einzulesen bzw. IMMER das Byte-Swapping auszuführen, bevor man sie als "Byte-Stream" auslesen und in einer Zahl verwandeln kann. Das war bisher (vor dieser Issue) nicht vorgesehen, da ich von "native order" für die jeweils verwendete Plattform ausging. Als ich das bemerkte, habe ich das "abgetrennt" und erst mal mit der Implementierung basierend auf "native byte order" weiter gemacht.
Die Tatsache, daß hier dann auch eine "ramdisk" für das OS zum Einsatz kommt, war nur ein weiterer Grund für eine "Sonderbehandlung" ... und die eingecheckten Skripte sind auch noch NICHT FERTIG, sonst hätte ich mich schon gemeldet und um erneute Tests gebeten.
Es ist nun mal vieles zu testen, wenn das auf verschiedenen Plattformen und mit unterschiedlichen Eingabeformaten alles in einem Rutsch verarbeitet werden soll - das Problem ist weniger das Implementieren an sich (deshalb habe ich auch mal einen "frischen Zwischenstand" gepusht, aber auch der ist "work in progress" und NICHTS zum Testen), als vielmehr der Test der jeweiligen Funktionen unter verschiedenen Umgebungen.
Das neueste Problem, über das ich z.B. beim Boot-Manager dann gestolpert bin, ist die Tatsache, daß ältere Firmware von AVM nur eine BusyBox enthält, die keine 64-Bit-Arithmetik beherrscht - damit sind dann die "Zahlen", die z.B. aus der "magic value" im FDT werden (BE: 0xd00dfeed) plötzlich negative Werte (das höchstwertige Bit wird als Vorzeichen interpretiert) und auch das muß man dann irgendwie abfangen an den Stellen, wo das Vorzeichen "gesetzt" sein KÖNNTE. Dann kommt noch hinzu, daß es auch Firmware OHNE mount-Applet mit offset-Option gibt und sogar OHNE losetup-Applet in der BusyBox - da kann man dann nicht mal "von Hand" per losetup mit Offset mounten, sondern muß tatsächlich erst mal das SquashFS-Image aus dem FIT-Image herauskopieren, damit man es mit einem "normalen" mount dann doch noch verwenden kann.
Da ist also vieles über mehrere Plattformen und FRITZ!OS-Versionen zu testen ... und das immer noch ohne eigenes Gerät, was mit einem FIT-Image arbeitet. Das braucht dann halt etwas länger (weil man erst mal an den richtigen Stellen die richtigen Testbedingungen auf der richtigen Plattform schaffen muß - denn in den EVA-Konfigurationsbereichen verwenden die LE-Modelle ja dann auch wieder LE-Byte-Order, das war ja die erste "Überraschung" mit den ARM-Prozessoren) und wenn ich wirklich wieder etwas zum Testen habe, melde ich mich garantiert - denn alleine KANN ich das zwar Funktion für Funktion auch "simuliert" testen, aber für einen kompletten Test bin ich dann auf Hilfe angewiesen.
Aber noch mal kurz: Bei der 5530 KANN das im Moment nicht funktionieren, SEITDEM ich den Test auf die Plausibilität der Dateigröße zusätzlich eingebaut habe (vorher funktionierte es natürlich schon - das war also eine Änderung, die das in einem speziellen Fall wieder zum Fehler werden läßt - dennoch ist die (an anderen Stellen) nützlich und bleibt deshalb auch drin) - das ist mir bewußt und wenn ich das korrigiert habe, melde ich mich auch mit der Bitte um weitere Tests. Es wäre sogar denkbar, daß ich die 5530 "vorziehe", weil das Extrahieren des etc-Verzeichnisses aus der "ramdisk" weniger kompliziert ist (das muß halt IMMER rauskopiert, entpackt und mit cpio weiter verarbeitet werden) als die verschiedenen Konstellationen, die beim Mounten eines SquashFS-Images auftreten können (da muß das verwendete SquashFS-Format auch noch zum Kernel passen, auf dem man das testet).
PeterPawn
commented
2 years ago Ich habe jetzt doch mal die Änderungen für die "Erkenntnisse" beim AVM-FIT-Format (die ersten beiden 32-Bit-Werte sind IMMER LE, auch wenn man's am "magic" nicht wirklich sieht - bei der Größe der Daten, die an Offset 4 steht, wird es deutlich) in die Tools im Verzeichnis fit_tools eingebaut und das als Branch fit_tools veröffentlicht.
Auf einer 7590 (die hat dieselbe MIPS-Architektur wie die 5530):
# sh /var/media/ftp/YourFritz/fitdump.sh /var/media/ftp/YourFritz/fit-image
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x2bf1cf7 (46079223)
// off_dt_struct: 0x38
// off_dt_strings: 0x2bf1be8
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x2bf1bb0
/ {
description = "FIT for HW257";
timestamp = <0x61a8afcf>; // Thu Dec 2 11:36:47 UTC 2021
avm,gu-version = <0x00016b4d>;
images {
prxI_HW257_kernel {
description = "Kernel for prxI_HW257";
avm,variants = "aon, pon";
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin"); // size: 3324358, offset=0x00000140
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x70000000>;
entry = <0x70798c00>;
hash_0 {
algo = "crc32";
value = <0xa623ea9a>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x70000000>;
avm,names = <0x70858c10>;
avm,token_table = <0x708aadb0>;
avm,token_index = <0x708ab0f0>;
avm,num_syms = <0x70858c00>;
avm,addresses;
avm,relative_base = <0x70858bf0>;
avm,offsets = <0x7083c920>;
};
};
prxI_HW257_flat_dt_0_aon {
description = "Device Tree for prxI_HW257_0_aon";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin"); // size: 8116, offset=0x0032bcc0
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xa6c2d94f>;
};
};
prxI_HW257_flat_dt_0_pon {
description = "Device Tree for prxI_HW257_0_pon";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin"); // size: 8130, offset=0x0032dd64
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xf4be8484>;
};
};
prxI_HW257_ramdisk {
description = "Ramdisk for prxI_HW257";
#address-cells = <0x00000001>;
data = /incbin/("image_004.bin"); // size: 39837668, offset=0x0032fe04
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x90000000>;
hash_0 {
algo = "crc32";
value = <0x09adcbfc>;
};
};
prxB_HW0257_kernel {
description = "Kernel for prxB_HW0257";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_005.bin"); // size: 1192229, offset=0x0292dee8
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x88000000>;
entry = <0x88299590>;
hash_0 {
algo = "crc32";
value = <0xce23a2b0>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x88000000>;
avm,names = <0x882c8ea0>;
avm,token_table = <0x882e9860>;
avm,token_index = <0x882e9bc0>;
avm,num_syms = <0x882c8e90>;
avm,addresses;
avm,relative_base = <0x882c8e80>;
avm,offsets = <0x882bcc30>;
};
};
prxB_HW0257_flat_dt_0 {
description = "Device Tree for prxB_HW0257_0";
#address-cells = <0x00000001>;
data = /incbin/("image_006.bin"); // size: 1114, offset=0x02a511c0
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x884f2000>;
hash_0 {
algo = "crc32";
value = <0x73fad255>;
};
};
prxB_HW0257_ramdisk {
description = "Ramdisk for prxB_HW0257";
#address-cells = <0x00000001>;
data = /incbin/("image_007.bin"); // size: 1704678, offset=0x02a516f8
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x8b000000>;
hash_0 {
algo = "crc32";
value = <0x79e0b2ac>;
};
};
};
configurations {
prxI_HW257_config_0_aon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_aon";
ramdisk = "prxI_HW257_ramdisk";
};
prxI_HW257_config_0_pon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_pon";
ramdisk = "prxI_HW257_ramdisk";
};
prxB_HW0257_config_0 {
kernel = "prxB_HW0257_kernel";
fdt = "prxB_HW0257_flat_dt_0";
ramdisk = "prxB_HW0257_ramdisk";
};
};
};
# ls -l fit-dump/
-rw-r--r-- 1 root root 5268 Mar 27 11:33 image.its
-rw-r--r-- 1 root root 3324358 Mar 27 11:32 image_001.bin
-rw-r--r-- 1 root root 8116 Mar 27 11:32 image_002.bin
-rw-r--r-- 1 root root 8130 Mar 27 11:32 image_003.bin
-rw-r--r-- 1 root root 39837668 Mar 27 11:33 image_004.bin
-rw-r--r-- 1 root root 1192229 Mar 27 11:33 image_005.bin
-rw-r--r-- 1 root root 1114 Mar 27 11:33 image_006.bin
-rw-r--r-- 1 root root 1704678 Mar 27 11:33 image_007.bin
lrwxrwxrwx 1 root root 13 Mar 27 11:33 kernel.image -> image_001.bin
lrwxrwxrwx 1 root root 13 Mar 27 11:33 ramdisk.image -> image_004.bin
# sh /var/media/ftp/YourFritz/fit-findfs.sh /var/media/ftp/YourFritz/fit-image
rootfs_type=ramdísk rootfs_offset=3341828 rootfs_size=39837668
#Es stimmt also sowohl die erzeugte its-Datei, als auch die Erkennung von Kernel- und RAM-Disk-Image (wie man an den Symlinks sieht) ... und auch die Suche nach dem Offset und der Größe der RAM-Disk klappt (inkl. Erkennung, daß es kein SquashFS-Image ist) - für cpio braucht's dann auch wieder die korrekte Größe des Images, damit das cpio am Ende der Datei nicht weint.
Damit sollten diese Teile jetzt auch auf der 5530 wieder laufen ... allerdings habe ich gerade noch (beim erneuten Test auf einer 6490 mit älterer Firmware) bemerkt, daß bei manchen BusyBox-Versionen (konkret ist es eine 1.20.2 von AVM) noch an weiteren Stellen negative Zahlen aufkommen (bei den Werten, die als Hexadezimal-Zahlen mit 32-Bit ausgegeben werden), was ich (nur für das fitdump.sh) auch noch korrigieren muß. Solange die 5530 jetzt aber nicht eine so alte BusyBox-Version verwendet (es kann auch nicht NUR an der Unterstützung für 64-Bit-Arithmetik in der Shell liegen, denn dann würde das Vorzeichen ja nicht auf die oberen 32-Bit erweitert werden), sollten die Skripte auf ihr wieder funktionieren.
PeterPawn
commented
2 years ago @freetz-ng-mod:
Wenn Du möchtest, kannst Du den aktuellen(!) Stand von fitdump.sh und fit-findfs.sh (im Branch fit_tools) jetzt noch einmal auf der 5530 testen (die ist eben auch wieder "anders", als die anderen FIT-Modelle, die ansonsten alle LE-Byte-Order verwenden) - oder Du wartest noch, bis ich das oben erwähnte Problem für "ganz alte" BusyBox-Versionen gelöst habe.
PeterPawn
commented
2 years ago So, mit dieser Version: 89c867c92c4c51334d17f59bc80d0197bd64a0cd erhalte ich jetzt auf der 6490 (mit BB 1.20.2 von AVM) und der 7590 (mit BB 1.29.2 von AVM) dieselbe Ausgabe in der image.its - damit hake ich das erst mal wieder ab.
Damit sollten die vier Skript-Dateien in fit_tools jetzt auf allen Plattformen und für alle (na gut, "die meisten") Eingabe-Dateien (also FIT-Images) dieselben Ergebnisse ausgeben. Dieselben Änderungen fließen dann auch in den Boot-Manager ein, sind aber NOCH NICHT dort umgesetzt.
freetz-ng-mod
commented
2 years ago Ich werde es später testen, denn jede Information kann ja auch hilfreich sein. Werde dann berichten
freetz-ng-mod
commented
2 years ago wget https://github.com/PeterPawn/YourFritz/raw/fit-tools/fit_tools/fitdump.sh wget https://github.com/PeterPawn/YourFritz/raw/fit-tools/fit_tools/fit-findfs.sh
bootslotctl get_active
0bootslotctl get_fw_version 0
07.21-83233bootslotctl get_fw_version 1
07.26-92084cat /proc/mtd
dev: size erasesize name
mtd0: 03200000 00020000 "fit0"
mtd1: 00180000 00020000 "urlader"
mtd2: 00800000 00020000 "nand-tffs"
mtd3: 03200000 00020000 "fit1"
mtd4: 01280000 00020000 "ubi"
mtd5: 0020f000 0001f000 "config"
mtd6: 00cf5000 0001f000 "nand-filesystem"time sh fit-findfs.sh /dev/mtdblock0
Command exited with non-zero status 1real 0m 3.02s user 0m 0.02s sys 0m 0.38s
time sh fit-findfs.sh /dev/mtdblock3
Command exited with non-zero status 1real 0m 7.17s user 0m 0.02s sys 0m 0.90s
time sh fitdump.sh /dev/mtdblock0
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x26c1597 (40637847)
// off_dt_struct: 0x38
// off_dt_strings: 0x26c1488
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x26c1450
/ {
fitdump.sh: eval: line 3: syntax error: EOF in backquote substitution
fitdump.sh: eval: line 3: syntax error: EOF in backquote substitution
Command exited with non-zero status 1real 0m 10.55s user 0m 0.30s sys 0m 1.36s
rm -r fit-dump/ time sh fitdump.sh /dev/mtdblock3
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x2b8ae63 (45657699)
// off_dt_struct: 0x38
// off_dt_strings: 0x2b8ad54
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x2b8ad1c
/ {
fitdump.sh: eval: line 2: syntax error: unterminated quoted string
fitdump.sh: eval: line 2: syntax error: unterminated quoted string
Command exited with non-zero status 1real 0m 6.80s user 0m 0.36s sys 0m 1.01s
PeterPawn
commented
2 years ago Alles wieder Freetz-Images oder ist da in irgendeinem Slot die originale AVM-Firmware installiert?
Wenn das alles Freetz-Images sind ... kannst Du das dann bitte mal mit einer originalen Firmware in irgendeinem der Slots testen?
Das KANN eigentlich nur noch an falschem Aufbau liegen (spätestens das fitdump.sh für mtdblock3) und beim fit-findfs.sh dachte ich langsam an wirklich jeder Stelle, wo ein Test schiefgehen könnte, auch eine korrekte Fehlermeldung auszugeben ... wenn dann das Format der gelesenen Daten auch noch stimmt.
Ich kann fast nicht glauben, daß die Probleme am Skript liegen - wie gesagt: Auf der 7590 (auch MIPS mit BE, wie die 5530) läßt sich das originale Image von AVM problemlos zerlegen. Man sieht ja auch an den gestoppten Zeiten, daß das Skript erst mal irgendetwas verarbeitet - und nicht direkt abbricht.
Der einzige alternative Test, der mir jetzt noch einfällt, wäre das Zerlegen des originalen AVM-Images (irgendwo unterhalb von build/original/... zu finden auf dem Build-Host) und das Zerlegen des modizifierten Images (das steht dann irgendwo unter build/modified/...) - beides auf dem Build-Host.
Wenn das für das AVM-Image klappt und für das Freetz-Image nicht, dann ist das Format des Freetz-Images nun mal falsch - ich nehme aber gerne wieder EIN (einzelnes) dieser Images, damit ich das noch einmal analysieren und vielleicht auch "zeigen" kann - aber ansonsten passe ich an dieser Stelle, weil ich dafür die Zeit nicht aufwenden WILL.
Wenn es am Perl-Tool keine Korrekturen gibt und das erzeugte Format nun mal nicht stimmt (zumindest war es ja bei dem einen, wo ich das bisher gezeigt habe, definitiv so - siehe dort), selbst wenn das sich wohl dennoch starten läßt, dann wird's halt noch dauern, bis ich die zwei ausstehenden "Aufgaben" zum Komplettieren einer Toolchain für das Entpacken und Erstellen von FIT-Images im AVM-Format erledigt haben werde.
freetz-ng-mod
commented
2 years ago bootslotctl get_fw_version 1 07.26-92084 << ist von FRITZ.Box_5530-07.26-recover.exe
zu Not, wenn du es wirklich willst, schicke ich dir das morgen mal.
PeterPawn
commented
2 years ago Hast Du dazu auch das AVM-Update? Wenn ja, extrahiere doch einfach mal die Datei var/tmp/fit-image auf dem Build-Host und setze das Skript (oder auch beide) auf diese Datei an. Gibt es dabei auch Probleme, nehme ich die AVM-Datei gerne selbst. Ich habe zum Zerlegen diese Datei aus der Firmware 257.07.29-93005 verwendet - das Ergebnis (auf der 7590) steht oben.
Ich weiß nicht mal, ob ich die Firmware ohne Box aus dem Recovery-Programm extrahieren kann - ja, ich bin nicht mal sicher, daß AVM dort immer noch die RLE-Kompression für die eingebetteten Images verwendet. Seitdem ich das Programm zum Dekomprimieren dieser Daten geschrieben habe (das ist auch schon wieder fast vier Jahre her), hat mich das nicht weiter interessiert.
freetz-ng-mod
commented
2 years ago AVM = Orginal FREETZ = IST MIT FREETZ Und ich habe es auf meinen System gemacht nicht auf der BOX. Und es ist das Image der 5530 FW 7.21 time sh fit-findfs.sh ~/Ubuntu/test/test/avm/fit-image
rootfs_type=ramdísk rootfs_offset=6193404 rootfs_size=35458093
real 0m3,989s
user 0m4,492s
sys 0m2,080stime sh fit-findfs.sh ~/Ubuntu/test/test/freetz/fit-image
rootfs_type=ramdísk rootfs_offset=6193404 rootfs_size=34443652
real 0m3,877s
user 0m4,351s
sys 0m2,023stime sh fitdump.sh ~/Ubuntu/test/test/avm/fit-image
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x27b9043 (41652291)
// off_dt_struct: 0x38
// off_dt_strings: 0x27b8f34
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x27b8efc
/ {
description = "FIT for HW0257";
timestamp = <0x5fa14b75>; // Di 3. Nov 12:22:13 UTC 2020
avm,gu-version = <0x00014521>;
images {
prxB_HW0257_kernel {
description = "Kernel for prxB_HW0257";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin"); // size: 1191017, offset=0x00000138
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x88000000>;
entry = <0x88298f10>;
hash_0 {
algo = "crc32";
value = <0xb4761fdd>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x88000000>;
avm,names = <0x882c8ec0>;
avm,token_table = <0x882e9830>;
avm,token_index = <0x882e9b90>;
avm,num_syms = <0x882c8eb0>;
avm,addresses;
avm,relative_base = <0x882c8ea0>;
avm,offsets = <0x882bcc70>;
};
};
prxB_HW0257_flat_dt_0 {
description = "Device Tree for prxB_HW0257_0";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin"); // size: 1092, offset=0x00122f54
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x884e2000>;
hash_0 {
algo = "crc32";
value = <0x3c53ca34>;
};
};
prxB_HW0257_ramdisk {
description = "Ramdisk for prxB_HW0257";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin"); // size: 1700705, offset=0x00123474
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x8b000000>;
hash_0 {
algo = "crc32";
value = <0x0ef19ad8>;
};
};
prxI_HW257_kernel {
description = "Kernel for prxI_HW257";
avm,variants = "aon, pon";
#address-cells = <0x00000001>;
data = /incbin/("image_004.bin"); // size: 3282652, offset=0x002c28e0
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x70000000>;
entry = <0x7077a400>;
hash_0 {
algo = "crc32";
value = <0xaa110233>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x70000000>;
avm,names = <0x70838590>;
avm,token_table = <0x70889d20>;
avm,token_index = <0x7088a060>;
avm,num_syms = <0x70838580>;
avm,addresses;
avm,relative_base = <0x70838570>;
avm,offsets = <0x7081c620>;
};
};
prxI_HW257_flat_dt_0_aon {
description = "Device Tree for prxI_HW257_0_aon";
#address-cells = <0x00000001>;
data = /incbin/("image_005.bin"); // size: 7917, offset=0x005e4174
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70fe4000>;
hash_0 {
algo = "crc32";
value = <0xcf9e37b4>;
};
};
prxI_HW257_flat_dt_0_pon {
description = "Device Tree for prxI_HW257_0_pon";
#address-cells = <0x00000001>;
data = /incbin/("image_006.bin"); // size: 7884, offset=0x005e6154
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70fe4000>;
hash_0 {
algo = "crc32";
value = <0xb9298e1b>;
};
};
prxI_HW257_ramdisk {
description = "Ramdisk for prxI_HW257";
#address-cells = <0x00000001>;
data = /incbin/("image_007.bin"); // size: 35458093, offset=0x005e80fc
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x90000000>;
hash_0 {
algo = "crc32";
value = <0x9b59e2d4>;
};
};
};
configurations {
prxB_HW0257_config_0 {
kernel = "prxB_HW0257_kernel";
fdt = "prxB_HW0257_flat_dt_0";
ramdisk = "prxB_HW0257_ramdisk";
};
prxI_HW257_config_0_aon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_aon";
ramdisk = "prxI_HW257_ramdisk";
};
prxI_HW257_config_0_pon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_pon";
ramdisk = "prxI_HW257_ramdisk";
};
};
};
real 0m6,713s
user 0m6,852s
sys 0m2,896srm -r fit-dump/ time sh fitdump.sh ~/Ubuntu/test/test/freetz/fit-image
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x26c1597 (40637847)
// off_dt_struct: 0x38
// off_dt_strings: 0x26c1488
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x26c1450
/ {
description = "FIT for HW0257";
timestamp = <0x5fa14b75>; // Di 3. Nov 12:22:13 UTC 2020
avm,gu-version = <0x00014521>;
images {
prxB_HW0257_kernel {
description = "Kernel for prxB_HW0257";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin"); // size: 1191017, offset=0x00000138
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x88000000>;
entry = <0x88298f10>;
hash_0 {
algo = "crc32";
value = <0xb4761fdd>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x88000000>;
avm,names = <0x882c8ec0>;
avm,token_table = <0x882e9830>;
avm,token_index = <0x882e9b90>;
avm,num_syms = <0x882c8eb0>;
avm,addresses;
avm,relative_base = <0x882c8ea0>;
avm,offsets = <0x882bcc70>;
};
};
prxB_HW0257_flat_dt_0 {
description = "Device Tree for prxB_HW0257_0";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin"); // size: 1092, offset=0x00122f54
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x884e2000>;
hash_0 {
algo = "crc32";
value = <0x3c53ca34>;
};
};
prxB_HW0257_ramdisk {
description = "Ramdisk for prxB_HW0257";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin"); // size: 1700705, offset=0x00123474
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x8b000000>;
hash_0 {
algo = "crc32";
value = <0x0ef19ad8>;
};
};
prxI_HW257_kernel {
description = "Kernel for prxI_HW257";
avm,variants = "aon, pon";
#address-cells = <0x00000001>;
data = /incbin/("image_004.bin"); // size: 3282652, offset=0x002c28e0
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x70000000>;
entry = <0x7077a400>;
hash_0 {
algo = "crc32";
value = <0xaa110233>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x70000000>;
avm,names = <0x70838590>;
avm,token_table = <0x70889d20>;
avm,token_index = <0x7088a060>;
avm,num_syms = <0x70838580>;
avm,addresses;
avm,relative_base = <0x70838570>;
avm,offsets = <0x7081c620>;
};
};
prxI_HW257_flat_dt_0_aon {
description = "Device Tree for prxI_HW257_0_aon";
#address-cells = <0x00000001>;
data = /incbin/("image_005.bin"); // size: 7917, offset=0x005e4174
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70fe4000>;
hash_0 {
algo = "crc32";
value = <0xcf9e37b4>;
};
};
prxI_HW257_flat_dt_0_pon {
description = "Device Tree for prxI_HW257_0_pon";
#address-cells = <0x00000001>;
data = /incbin/("image_006.bin"); // size: 7884, offset=0x005e6154
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70fe4000>;
hash_0 {
algo = "crc32";
value = <0xb9298e1b>;
};
};
prxI_HW257_ramdisk {
description = "Ramdisk for prxI_HW257";
#address-cells = <0x00000001>;
data = /incbin/("image_007.bin"); // size: 34443652, offset=0x005e80fc
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x90000000>;
hash_0 {
algo = "crc32";
value = <0x0e91b0a0>;
};
};
};
configurations {
prxB_HW0257_config_0 {
kernel = "prxB_HW0257_kernel";
fdt = "prxB_HW0257_flat_dt_0";
ramdisk = "prxB_HW0257_ramdisk";
};
prxI_HW257_config_0_aon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_aon";
ramdisk = "prxI_HW257_ramdisk";
};
prxI_HW257_config_0_pon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_pon";
ramdisk = "prxI_HW257_ramdisk";
};
};
};
real 0m6,469s
user 0m6,565s
sys 0m2,809sWenn ich mir beide Ergebnisse anschaue bei findfs.sh ist das fit-image bei avm viel größer. Fehlt da dann immer was im freetz fit-image
PeterPawn
commented
2 years ago Danke - damit ist dann erst einmal geklärt, daß die Images (sowohl das originale, als auch das mit Freetz gebaute) außerhalb der Box (sicherlich auf einem x86-System, also LE-Byte-Order) korrekt zerlegt werden können.
Der nächste, logische Schritt wäre es jetzt, das auf der Box auch noch einmal für genau diese beiden Image-Dateien zu machen - die kriegst Du ja per FTP auf die Box, wobei vermutlich der interne NAS-Flash nicht ausreichen wird und es ein USB-Volume bräuchte. Direkt ins tmpfs würde ich die Dateien nicht legen - sonst scheitert ggf. das Kopieren dorthin (https://github.com/PeterPawn/YourFritz/blob/f0fe4d8132d19c18c102851703ff45aa742a9fc5/fit_tools/fit-findfs.sh#L298), was ich derzeit aber gerne "sehen" würde (also beim Aufruf noch die Option -f mit angeben). Das führt dann ja zusätzliche Kommandos aus, die ansonsten nur zum Zuge kämen, wenn die Quelle für die Eingabedaten KEIN reguläres File wäre - was bei den weiter oben stehenden Aufrufen mit den Block-Devices ja der Fall wäre.
Wenn das auf der Box dann auch noch mit diesen Dateien funktioniert, DANN könnte man noch einmal darüber nachdenken, eine der beiden (oder auch beide nacheinander) in eine Partition flashen zu lassen und die Skript-Dateien dann auch noch einmal auf diese Partitionen anzusetzen (dann kommt der Code zum Kopieren automatisch zum Einsatz).
Warum das Freetz-Image jetzt etwas kleiner ist (das ist kein ganzes Megabyte), weiß ich auch nicht genau ... aber ich habe einen Verdacht. Bei Freetz werden die Verzeichnisse für die verschiedenen Brandings alle zu einem zusammengefaßt und dann für jedes enthaltene Branding nur ein Symlink angelegt - bei AVM sind die Dateien alle "doppelt vorhanden", was auch nur ein minimales Problem darstellt, weil Dateien mit wirklich IDENTISCHEM Inhalt auch nur einmal komprimiert gespeichert werden. Allerdings brauchen die Kopien zusätzlichen Platz zur Verwaltung ihrer Metadaten - das ist also schon mal ein Punkt, der die AVM-Images größer machen kann und zweitens ist es nicht überall so, daß die Inhalte der "Branding-Verzeichnisse" auch tatsächlich 1:1 identisch sind (insofern verändert Freetz die Firmware auch an dieser Stelle - normalerweise müßte man das jedesmal prüfen, BEVOR man die Verzeichnisse einfach alle zusammenlegt, gerade mittlerweile, wo ALLE Brandings in der Firmware versammelt sind) und daher können auch von dort zusätzliche Daten kommen, die komprimiert NICHT mit bereits gespeicherten übereinstimmen und daher neu zum SquashFS-Image hinzugefügt werden müssen.
Aber das ist auch nur "ein Verdacht" - ansonsten kann man sich auch mal die Statistiken für die SquashFS-Images anzeigen lassen (unsquashfs -s <image>) - wobei image NUR das SquashFS-Image sein darf, WEIL die Images in einem FIT-Image NICHT an einer 256-Byte-Grenze beginnen und die SquashFS-Tools auch mit meinem Patch für die Suche nach dem Superblock (Option -k) nur an einer 256-Byte-Grenze suchen, weil der eigentlich dafür gedacht war, bei den Modellen mit einer gemeinsamen Datei für den Kernel und das Filesystem den Beginn des Filesystems zu suchen.
EDIT:
Das SquashFS-Image in den zerlegten Dateien findest Du nach einem fitdump.sh im Unterverzeichnis fit-dump mit dem Symlink filesystem.image - das muß man also nicht selbst zerlegen (auch wenn ich das zu Kontrollzwecken natürlich mehrfach gemacht habe).
@fda77:
Wenn man den Patch anpassen würde (hier: https://github.com/Freetz-NG/freetz-ng/blob/194580d4a9b73de775c0e8ca736375496e143d47/tools/make/squashfs4-be-host/patches/610-unsquashfs_superblock_offset.patch#L60 anstelle der 256 eine 4 verwenden), dann braucht zwar auch die Suche nach dem Superblock 64-mal so lange (was aber immer noch nicht wirklich ins Gewicht fällt, denn das ist in C immer noch schnell), dafür sollte man aber sogar mit einem unsquashfs -k <fit-image> das ERSTE SquashFS-Image in einem FIT-Image entpacken können (bzw. das erste mit dem richtigen "magic", denn das unterscheidet sich bei AVM ja auch -> sqsh vs. hsqs), ohne das zuvor zerlegen zu lassen. Das bringt zwar in Freetz nicht unmittelbar etwas, aber andere Projekte, die auf die Freetz-Patches zurückgreifen, könnten davon profitieren (das https://github.com/fkie-cad/FACT_core hatte ich irgendwo schon mal verlinkt).
freetz-ng-mod
commented
2 years ago Ich hatte heute morgen die beiden 5530 fit-images auf der 7530AX da ging es auch ohne Fehler. Weil ich mein FTTH Anschluß noch nicht habe war die 5530 halt aus und in der Schublade. Aber ich habe mir vorgenommen gehabt das nach der Arbeit auf ihr zu testen. Mit -f
An das Branding habe ich auch schon gedacht. Aber ich weiß das dropbear und mc mit im image sind. Und die verbrauchen ja auch schon einiges. Ich baue nach der Arbeit eins wo die Sachen nicht drin sind.
PeterPawn
commented
2 years ago Da ich wahrscheinlich noch weitere Änderungen im Laufe des Tages vornehmen werde, benutze bitte IMMER die jeweils aktuelle Version - als wget wäre das dann:
wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/bootmanager/bootmanager (das Message-File ändert sich sicherlich nicht - jedenfalls vorerst)
wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/fit_tools/fitdump.sh (oder eben fit-findfs.sh)... es bringt ja wieder nichts, wenn da versehentlich alte und bereits korrigierte Probleme erneut auftreten. Wenn ich Änderungen vornehme, von denen ich denke, daß sie relevant sein KÖNNTEN, passe ich auch das Tag entsprechend an. Das macht ja nicht nur dann Sinn, wenn man ein neues Freetz-NG-Image bauen (lassen) will, sondern so hat man dann immer einen "Hinweis", welcher Stand zum Testen geeignet wäre (daher ja auch der Name des Tags).
freetz-ng-mod
commented
2 years ago Ok werde ich machen. Aber noch bin ich auf der Arbeit.
Klingt vielleicht dumm aber kannst nich ein echo ins Script einfügen das die Version mit ausgibt. Also so wie beim Bootmanager test von heute morgen 6000 und 1200AX
PeterPawn
commented
2 years ago Für die beiden Tools habe ich auch schon über einen Zeitstempel nachgedacht (eine Versionsnummer will ich nicht gleich bei jeder Änderung hochzählen) - aber bisher hielt ich das noch nicht für erforderlich und bei git kann man (leider, obwohl ich die Gründe absolut nachvollziehen kann) nicht auf die Zeitstempel der einzelnen Dateien (im Dateisystem) zurückgreifen.
Mal sehen, was ich da mache - das Problem ist nur, daß man solche Daten, wenn sie IM Skript stehen sollen, tatsächlich auch von Hand ändern muß (bzw. deren Änderung anstoßen muß), weil alle "git-hooks" die Datei(en) danach (also nach einem git stage - unmittelbar vor dem commit in einem pre-commit-Hook) nicht mehr ändern soll(t)en (danach erst recht nicht, denn dann geht die Signatur des Commits flöten) und "client-side hooks" (wozu pre-commit gehört) jeweils nur für den lokalen Client gelten - die würden also nicht repliziert beim Klonen eines Repos.
Man könnte ggf. noch über die CD-Funktionen von GitHub (Continuous Delivery) eine "Installation" zusammen packen lassen (da kann man dann auch wieder weitere Versionsinfos hineinschreiben) - nur bringt das auch nichts, wenn man neue Versionen per Download (als Text) von einer URL laden (lassen) will, weil das für Skript-Files nun mal am einfachsten (und am sichersten, weil jeder das zuvor "nachlesen" kann, der das will) ist. Als "Installation" müßte man das erst wieder speichern, auspacken, kopieren - der Aufwand steigt damit "am falschen Ende".
Mal sehen, was mir da einfällt - bisher benutzte ich halt immer die Git-Kommandos in der Kommandozeile und mache solche Operationen (git stage, git commit, git push) "zu Fuß" - das macht es auch nicht "einfacher", da entsprechende Wrapper zu verwenden.
Außer ich ersetze schon git durch ein Skript, was das auf ein stage prüft und dann für ausgewählte Dateien (auch das muß man erst mal "automatisieren", weil es ja nicht für alle gelten soll) noch den Zeitstempel aktualisiert. Das ist aber ein erheblicher Aufwand für so eine simple Sache - und daher schrecke ich vor der Automatisierung zurück und verzichte (im Moment) lieber noch auf diese Markierung - zumal das ja auch keine Skript-Dateien sind (die in fit_tools zumindest), die jetzt auf irgendwelchen FRITZ!Boxen bei ihren Benutzern auch mal "einige Monate" schon laufen könnten (im Gegensatz zum "bootmanager"). Das würde nur für die Tests jetzt einen Mehrwert haben - andererseits macht es das vielleicht doch auch leichter.
freetz-ng-mod
commented
2 years ago cd /var rm /var/tmp/bootmanager.*
wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/bootmanager/bootmanager
Connecting to raw.githubusercontent.com (185.199.110.133:443)
wget: note: TLS certificate validation not implemented
saving to 'bootmanager'
bootmanager 100% |**************************************************************************************************************************************************************************************************| 141k 0:00:00 ETA
'bootmanager' savedwget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/bootmanager/bootmanager.msg
Connecting to raw.githubusercontent.com (185.199.110.133:443)
wget: note: TLS certificate validation not implemented
saving to 'bootmanager.msg'
bootmanager.msg 100% |**************************************************************************************************************************************************************************************************| 4710 0:00:00 ETA
'bootmanager.msg' savedsh /var/bootmanager debug verbose
yf_bootmanager version = 0.8.5-202203272100
Urlader dump size isn't a power of two.
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = PRX300
model = AVM FRITZ!Box 5530
chipset manufacturer = intel
compatible = PRX321-SFU-QSPI-PON
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
inactive system is installed = false
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel =
active filesystem =
active system version = 257.07.21-83233
active system date = 03.11.2020, 13:20:49 Uhr (epoch: 1604406049)
active system modification date = 27.03.2022, 14:48:13 Uhr (epoch: 1648385293)
active system modification source = Freetz-NG
Urlader dump size isn't a power of two.
brandings supported on active system = 1und1 avm
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive kernel =
inactive filesystem =
inactive filesystem could not be mountedcat /proc/mtd
dev: size erasesize name
mtd0: 03200000 00020000 "fit0"
mtd1: 00180000 00020000 "urlader"
mtd2: 00800000 00020000 "nand-tffs"
mtd3: 03200000 00020000 "fit1"
mtd4: 01280000 00020000 "ubi"
mtd5: 0020f000 0001f000 "config"
mtd6: 00cf5000 0001f000 "nand-filesystem"wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/fit_tools/fit-findfs.sh
Connecting to raw.githubusercontent.com (185.199.110.133:443)
wget: note: TLS certificate validation not implemented
saving to 'fit-findfs.sh'
fit-findfs.sh 100% |**************************************************************************************************************************************************************************************************| 15351 0:00:00 ETA
'fit-findfs.sh' savedtime sh fit-findfs.sh -f /dev/mtdblock0
Command exited with non-zero status 1
real 0m 3.07s
user 0m 0.05s
sys 0m 0.37stime sh fit-findfs.sh -f /dev/mtdblock3
Command exited with non-zero status 1
real 0m 8.45s
user 0m 0.04s
sys 0m 0.80stime sh fit-findfs.sh /dev/mtdblock0
Command exited with non-zero status 1
real 0m 3.19s
user 0m 0.05s
sys 0m 0.32stime sh fit-findfs.sh /dev/mtdblock3
Command exited with non-zero status 1
real 0m 8.15s
user 0m 0.02s
sys 0m 0.78srm -r fit-dump/ time sh fitdump.sh /dev/mtdblock0
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x26c1597 (40637847)
// off_dt_struct: 0x38
// off_dt_strings: 0x26c1488
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x26c1450
/ {
fitdump.sh: eval: line 3: syntax error: EOF in backquote substitution
fitdump.sh: eval: line 3: syntax error: EOF in backquote substitution
Command exited with non-zero status 1real 0m 10.60s user 0m 0.36s sys 0m 1.27s
rm -r fit-dump/ sh fitdump.sh /dev/mtdblock3
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x2b8ae63 (45657699)
// off_dt_struct: 0x38
// off_dt_strings: 0x2b8ad54
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x2b8ad1c
/ {
fitdump.sh: eval: line 2: syntax error: unterminated quoted string
fitdump.sh: eval: line 2: syntax error: unterminated quoted string
Command exited with non-zero status 1real 0m 6.81s user 0m 0.40s sys 0m 1.00s
PeterPawn
commented
2 years ago Wenn das hier auch defekte Blöcke sind (die Skripte arbeiten ja erst mal eine Weile), dann muß halt auch hier der Inhalt anders ausgelesen werden (siehe "Bootmanager und FIT").
Das hier:
Urlader dump size isn't a power of two.
muß ich mir nochmal genau ansehen ... hier hat die Urlader-Partition offenbar eine Größe von 1,5 MB - was sich mit meiner "binären Suche" nach dem Konfigurationsbereich beißt, weil man das dann irgendwann nicht mehr ohne Rest durch 2 teilen kann.
Da muß ich noch etwas drüber nachdenken, welche Konsequenzen das dann auch für den Code auf anderen Modellen hat - vielleicht auch gar keine, weil es nie bis zum Wert "3" kommt, den man dann nicht mehr binär teilen kann.
Spannend wird es dann wieder, wie man ein SquashFS-Image innerhalb eines FIT-Images mountet, wenn das gar nicht in ununterbrochener, aufsteigender Folge in dem Block-Device gespeichert ist - da bleibt dann vielleicht gar nichts weiter, als das in jedem Falle auch wieder zu extrahieren und dann erst zu mounten. Das kostet dann natürlich auch wieder (temporär) Platz im tmpfs.
freetz-ng-mod
commented
2 years ago Ach fast vergessen Image ohne dropbear und mc 39,8 MB (39.845.888 Bytes) Original 41,7 MB (41.652.371 Bytes)
PeterPawn
commented
2 years ago Wie gesagt ... mit einem unsquashfs -s weiß man auch, wieviele Dateien (samt ihrer Meta-Daten) darin dann verwurstet wurden:
vidar:/home/GitHub/YourFritz/fit_tools $ unsquashfs -s fit-images/FB4060/fit-dump/filesystem.image
Found a valid SQUASHFS 4:0 superblock on fit-images/FB4060/fit-dump/filesystem.image.
Creation or last append time Sun Nov 8 23:54:24 1970
Filesystem size 26952864 bytes (26321.16 Kbytes / 25.70 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Uids/Gids (Id table) are compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 362
Number of inodes 7551
Number of ids 1
vidar:/home/GitHub/YourFritz/fit_tools $Bei diesem 4060-Image sind das dann 7551 "Dateien", wobei Symlinks und Verzeichnisse auch gezählt werden. Vielleicht arbeitet das mksquashfs in Freetz aber auch mit einer höheren Kompressionsrate - was dann beim Packen mehr Zeit braucht, aber weniger Platz benötigt im Ergebnis. Um das zu prüfen, muß man ja nur eine unveränderte Struktur erneut einpacken - ich habe bei meinen "Demonstrationen" (im IPPF) solche Ergebnisse auch schon gesehen.
fda77
commented
2 years ago Mit "tools/fwdu u IMAGE" kann man das Filesystem jedes Images entpacken, und danach vergleichen
PeterPawn
commented
2 years ago und danach vergleichen
Ein diff macht ja keinen Sinn (auch kein rekursives) - das ist beim Vergleich von AVM und Freetz so viel, daß das die meisten gar nicht überblicken können - zumal dann auch noch Binärdateien und Text gemischt wären.
Und jede Datei einzeln ansehen und/oder "zählen", bringt ja auch nicht wirklich etwas ... es ist ja zu erwarten, daß Freetz deutlich weniger Inodes belegen wird, wenn die Brandings (inzwischen ja in den allermeisten Modellen auch noch drei, denn avm, 1und und avme sind eigentlich immer irgendwo drin - außer bei den "richtigen" OEM-Versionen) auf eines zusammengeschrumpft werden.
Wenn Du jetzt also nicht noch ein "Kommando" kennst, mit dem das einigermaßen plausibel verglichen werden kann (auch ein du wird da nicht wirklich helfen, wenn man das erst "zusammenrechnen" soll), dann würde ich schon bei meiner Ansicht bleiben, daß ein unsquashfs -s am ehesten die Informationen liefert, wieviele Dateien da nun eingepackt sind (na gut, wieviele "inodes") und wieviel Platz das dann belegt.
Da kommt schon ganz schön was zusammen ... die Inode-Entries haben keine "feste" Größe und je nachdem, wieviele (komprimierte) Blöcke zu einer Datei gehören, "verlängert" sich dann auch so ein Inode-Entry im SquashFS-Image. Wenn ich mich richtig erinnere, gilt das "remove duplicates" auch nicht für die Metadaten, sondern nur für den Inhalt einer Datei.
Aber am Ende ist die Größe wieder mal egal ... solange da nach dem Hinzufügen von Dateien das Image nicht die Größe der Partition reißt, interessiert es niemanden und man könnte auch auf das all in Freetz ganz gut verzichten. Auch wenn man die Brandings so läßt, wie sie bei AVM sind, sollte da noch "genug Luft" sein, um einige Megabytes an Zusätzen einbauen zu können.
Wobei das tatsächlich bei den FIT-Modellen mit 50 MB-Partitionen wieder "enger" ist, als beispielsweise bei den GRX-Boxen, wo ja 8 MB Kernel und 45 MB Filesystem Usus waren ... bei den FIT-Images kommt dann noch hinzu, daß da auch noch weitere BLOBs (für "eingebettete Systeme") enthalten sein können - die "echten" FDTs fallen da kaum noch ins Gewicht. Man sieht's ja an einem "zerlegten" Image ganz gut, was da noch an "Images" eingebettet ist.
Ich weiß ja nicht, was aus dem Test der Größe des gepackten Images geworden ist oder werden soll ... daß das schon bei VR9-Modellen nicht mehr wirklich schlüssig war (weil YAFFS2 sich solchen "Überschlagsrechnungen" entzieht), hatten wir ja auch schon mal irgendwo (kann aber auch im IPPF gewesen sein). Bei den FIT-Modellen müßte man sich da schon noch eine "maximale Größe" überlegen (wenn man's schon beim Einpacken feststellen will) ... ansonsten könnte/müßte man das "fertige" Image bewerten und auch das kann gewaltig schief gehen, wie man an der 7530ax schön sehen kann im zweiten Slot.
Wenn da ein defekter Block vorhanden ist, verringert sich damit natürlich auch die Größe der darin noch zu speichernden Daten - jeder defekte Block kostet dann 128 KB an möglichem Inhalt und das KANN man einfach vorher nicht wissen, wie es auf einem konkreten Gerät als Ziel aussieht bzw. da kann es sogar sein, daß eine zu große Image-Datei in dem einen Slot noch paßt und in dem anderen auf zuviele defekte Blöcke trifft.
Da MUSS man also immer eine ausreichende Reserve einplanen ... was AVM für die eigene Firmware sicherlich auch macht bzw. dort könnte man Boxen mit zuvielen defekten Blöcken ja auch einfach tauschen. Man könnte glatt mal nachsehen, ob diese Angaben nicht sogar zu dem gehören, was Boxen (wo das erlaubt ist) an Telemetrie-Daten an AVM übermitteln. Wobei da (bei AVM zumindest) schon noch "sehr viel Luft" ist - aber das ist gleichzeitig eben auch ein Grund, warum es Freetz-NG nicht übertreiben sollte bei dem, was man einem einzelnen Image hinzufügt und dann vielleicht doch wieder mehr auf "externals" setzen müßte, wenn es enger wird.
Ich würde jedenfalls (nach eigenen Erfahrungen mit NAND-Flash (in der 7490) und den defekten Blöcken, die nach einigermaßen intensiven Schreibzugriffen stark zunehmen) etwas in der Richtung von 10% der Partitiongröße generell einplanen als "over-provisioning" und da eine rote Linie ziehen, wenn ein Freetz-Benutzer sein Image dermaßen aufblähen sollte.
fda77
commented
2 years ago Das mit der Maximalgröße bei FIT hat hippie schon in Planung, es gibt eine insgesamte und eine je Partition. Aktuell gibt es in Freetz keinen Test, die Ausgabe am Ende von make fehlt. Wenns beim flashen nicht passt wird man es schon merken. Meine 7490 die ich seit Markstart hab hat etwas über 2000 Reboots laut runclock, von denen dürften mindestens die Hälfte Flashvorgänge sein. Läuft noch wunderbar
# mtd3: 03000000 00020000 "reserved-filesystem"
$ time nanddump --bb=skipbad -f /tmp/nandump /dev/mtd3
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x03000000...
real 0m 10.43s
user 0m 0.52s
sys 0m 5.20s
$ du -s /tmp/nandump
49152 /tmp/nandumpIch hatte irgendwo im IPPF mal eine dmesg-Ausgabe beim Start meiner 7490 gezeigt - mit jeder Menge Fehlern im NAND-Flash, allerdings die meisten auch da, wo häufiger geschrieben wird - und das ist im NAS-Flash. Beim modfs und beim Testen von Änderungen habe ich nie mitgezählt, wie oft ich im NAS-Flash (anfangs zumindest, mittlerweile wird der standardmäßig ignoriert, WEIL ich bei meiner Entwickler-Box die Probleme bemerkt habe) herumgeschrieben habe und wie oft ich die Dateisystem-Partitionen "gequält" habe - die Kernel-Partitionen weniger, weil beim modfs ja nur das geflasht wird, was sich auch geändert hat.
Aber auch die Technologien beim NAND-Flash haben sich geändert ... mit QLC-Flash wird die Speicherdichte weiter erhöht, gleichzeitig sinkt die Anzahl der möglichen Schreibzyklen pro Zelle (und für einen defekten Block reicht es, wenn die ECC-Algorithmen die Daten nicht mehr sicher rekonstruieren können - dann ist der komplette Block "im Eimer") - was ein eMMC auch durch "over-provisioning" mit ausreichender Anzahl von reservierten Blöcken, die außerhalb des Controllers niemand jemals sieht und die dann für defekte Blöcke eingemappt werden, kompensiert.
Und für "raw NAND" (also als "memory technology device") muß sich dann der entsprechende Treiber darum kümmern ... und da der nicht über entsprechende "stille Reserven" verfügt und die dann einfach anstelle eines defekten Blocks auslesen oder beschreiben kann, kommt es häufig schon bei "fabrikneuem" NAND-Flash zu solchen defekten Blöcken.
Damit muß man dann nur umgehen können ... ich bin mal gespannt, was sich (wenn ich so weit bin und mich @freetz-ng-mod vielleicht auch auf dieses Modell läßt) bei der 5530 als Ursache der Probleme beim Zerlegen von FIT-Images aus den beiden Partitionen ergibt.
Das KANN zwar immer noch ein Problem im Code sein, aber wie schon mal geschrieben: das Zerlegen eines Images für die 5530 auf einer 7590 (PRX300 vs. GRX500 - also identische "Umgebung", was Byte-Order und Prozessor-Architektur generell betrifft) funktioniert bei mir aber - also tippe ich auch da eher auf Probleme beim Auslesen der Daten aus dem Flash (das wären dann wieder defekte Blöcke), als auf ein Problem im Skript und so viele Updates, daß der Flash mittlerweile "kaputtgeschrieben" wurde, sollte die 5530 auch noch nicht erhalten haben (mal von den Freetz-Versuchen abgesehen).
freetz-ng-mod
commented
2 years ago Ich werde nachher mal die 5530 mit ins Heimnetzwerk packen (spätestens am Wochenende).
freetz-ng-mod
commented
2 years ago Nur zur Info
cat /proc/mtd
[dev: size erasesize name
mtd0: 03200000 00020000 "fit0"
mtd1: 00180000 00020000 "urlader"
mtd2: 00800000 00020000 "nand-tffs"
mtd3: 03200000 00020000 "fit1"
mtd4: 01280000 00020000 "ubi"
mtd5: 0020f000 0001f000 "config"
mtd6: 00cf5000 0001f000 "nand-filesystem"](url) wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/fit_tools/fitdump.sh
Connecting to raw.githubusercontent.com (185.199.108.133:443)
wget: note: TLS certificate validation not implemented
saving to 'fitdump.sh'
fitdump.sh 100% |**************************************************************************************************************************************************************************************************| 29820 0:00:00 ETA
'fitdump.sh' savedtime sh fitdump.sh /dev/mtd0
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x2836be3 (42167267)
// off_dt_struct: 0x38
// off_dt_strings: 0x2836ad4
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x2836a9c
/ {
description = "FIT for HW257";
timestamp = <0x61a8afcf>; // Thu Dec 2 11:36:47 UTC 2021
avm,gu-version = <0x00016b4d>;
images {
prxI_HW257_kernel {
description = "Kernel for prxI_HW257";
avm,variants = "aon, pon";
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin"); // size: 3324358, offset=0x00000140
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x70000000>;
entry = <0x70798c00>;
hash_0 {
algo = "crc32";
value = <0xa623ea9a>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x70000000>;
avm,names = <0x70858c10>;
avm,token_table = <0x708aadb0>;
avm,token_index = <0x708ab0f0>;
avm,num_syms = <0x70858c00>;
avm,addresses;
avm,relative_base = <0x70858bf0>;
avm,offsets = <0x7083c920>;
};
};
prxI_HW257_flat_dt_0_aon {
description = "Device Tree for prxI_HW257_0_aon";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin"); // size: 8116, offset=0x0032bcc0
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xa6c2d94f>;
};
};
prxI_HW257_flat_dt_0_pon {
description = "Device Tree for prxI_HW257_0_pon";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin"); // size: 8130, offset=0x0032dd64
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xf4be8484>;
};
};
prxI_HW257_ramdisk {
description = "Ramdisk for prxI_HW257";
#address-cells = <0x00000001>;
data = /incbin/("image_004.bin"); // size: 35925711, offset=0x0032fe04
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x90000000>;
hash_0 {
algo = "crc32";
value = <0xc9f0e4de>;
};
};
prxB_HW0257_kernel {
description = "Kernel for prxB_HW0257";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_005.bin"); // size: 1192229, offset=0x02572dd4
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x88000000>;
entry = <0x88299590>;
hash_0 {
algo = "crc32";
value = <0xce23a2b0>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x88000000>;
avm,names = <0x882c8ea0>;
avm,token_table = <0x882e9860>;
avm,token_index = <0x882e9bc0>;
avm,num_syms = <0x882c8e90>;
avm,addresses;
avm,relative_base = <0x882c8e80>;
avm,offsets = <0x882bcc30>;
};
};
prxB_HW0257_flat_dt_0 {
description = "Device Tree for prxB_HW0257_0";
#address-cells = <0x00000001>;
data = /incbin/("image_006.bin"); // size: 1114, offset=0x026960ac
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x884f2000>;
hash_0 {
algo = "crc32";
value = <0x73fad255>;
};
};
prxB_HW0257_ramdisk {
description = "Ramdisk for prxB_HW0257";
#address-cells = <0x00000001>;
data = /incbin/("image_007.bin"); // size: 1704678, offset=0x026965e4
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x8b000000>;
hash_0 {
algo = "crc32";
value = <0x79e0b2ac>;
};
};
};
configurations {
prxI_HW257_config_0_aon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_aon";
ramdisk = "prxI_HW257_ramdisk";
};
prxI_HW257_config_0_pon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_pon";
ramdisk = "prxI_HW257_ramdisk";
};
prxB_HW0257_config_0 {
kernel = "prxB_HW0257_kernel";
fdt = "prxB_HW0257_flat_dt_0";
ramdisk = "prxB_HW0257_ramdisk";
};
};
};
Command exited with non-zero status 1real 1m 8.15s user 0m 11.39s sys 0m 43.06s
rm -r fit-dump/ time sh fitdump.sh /dev/mtd3
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x283d90f (42195215)
// off_dt_struct: 0x38
// off_dt_strings: 0x283d800
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x10f
// size_dt_struct: 0x283d7c8
/ {
description = "FIT for HW257";
timestamp = <0x61a8afcf>; // Thu Dec 2 11:36:47 UTC 2021
avm,gu-version = <0x00016b4d>;
images {
prxI_HW257_kernel {
description = "Kernel for prxI_HW257";
avm,variants = "aon, pon";
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin"); // size: 3324358, offset=0x00000140
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x70000000>;
entry = <0x70798c00>;
hash_0 {
algo = "crc32";
value = <0xa623ea9a>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x70000000>;
avm,names = <0x70858c10>;
avm,token_table = <0x708aadb0>;
avm,token_index = <0x708ab0f0>;
avm,num_syms = <0x70858c00>;
avm,addresses;
avm,relative_base = <0x70858bf0>;
avm,offsets = <0x7083c920>;
};
};
prxI_HW257_flat_dt_0_aon {
description = "Device Tree for prxI_HW257_0_aon";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin"); // size: 8116, offset=0x0032bcc0
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xa6c2d94f>;
};
};
prxI_HW257_flat_dt_0_pon {
description = "Device Tree for prxI_HW257_0_pon";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin"); // size: 8130, offset=0x0032dd64
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x70f9c000>;
hash_0 {
algo = "crc32";
value = <0xf4be8484>;
};
};
prxI_HW257_ramdisk {
description = "Ramdisk for prxI_HW257";
#address-cells = <0x00000001>;
data = /incbin/("image_004.bin"); // size: 35953660, offset=0x0032fe04
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x90000000>;
hash_0 {
algo = "crc32";
value = <0x0f60ca91>;
};
};
prxB_HW0257_kernel {
description = "Kernel for prxB_HW0257";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_005.bin"); // size: 1192229, offset=0x02579b00
type = "kernel";
arch = "mips";
os = "linux";
compression = "lzma";
load = <0x88000000>;
entry = <0x88299590>;
hash_0 {
algo = "crc32";
value = <0xce23a2b0>;
};
avm,kallsyms {
avm,endianess = "BE";
avm,kernel_text_start = <0x88000000>;
avm,names = <0x882c8ea0>;
avm,token_table = <0x882e9860>;
avm,token_index = <0x882e9bc0>;
avm,num_syms = <0x882c8e90>;
avm,addresses;
avm,relative_base = <0x882c8e80>;
avm,offsets = <0x882bcc30>;
};
};
prxB_HW0257_flat_dt_0 {
description = "Device Tree for prxB_HW0257_0";
#address-cells = <0x00000001>;
data = /incbin/("image_006.bin"); // size: 1114, offset=0x0269cdd8
type = "flat_dt";
arch = "mips";
compression = "lzma";
load = <0x884f2000>;
hash_0 {
algo = "crc32";
value = <0x73fad255>;
};
};
prxB_HW0257_ramdisk {
description = "Ramdisk for prxB_HW0257";
#address-cells = <0x00000001>;
data = /incbin/("image_007.bin"); // size: 1704678, offset=0x0269d310
type = "ramdisk";
arch = "mips";
os = "linux";
compression = "none";
load = <0x8b000000>;
hash_0 {
algo = "crc32";
value = <0x79e0b2ac>;
};
};
};
configurations {
prxI_HW257_config_0_aon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_aon";
ramdisk = "prxI_HW257_ramdisk";
};
prxI_HW257_config_0_pon {
kernel = "prxI_HW257_kernel";
fdt = "prxI_HW257_flat_dt_0_pon";
ramdisk = "prxI_HW257_ramdisk";
};
prxB_HW0257_config_0 {
kernel = "prxB_HW0257_kernel";
fdt = "prxB_HW0257_flat_dt_0";
ramdisk = "prxB_HW0257_ramdisk";
};
};
};
Command exited with non-zero status 1real 1m 8.51s user 0m 11.49s sys 0m 43.62s
wget https://raw.githubusercontent.com/PeterPawn/YourFritz/freetz-ng-test/fit_tools/fit-findfs.sh
Connecting to raw.githubusercontent.com (185.199.108.133:443)
wget: note: TLS certificate validation not implemented
saving to 'fit-findfs.sh'
fit-findfs.sh 100% |**************************************************************************************************************************************************************************************************| 16884 0:00:00 ETA
'fit-findfs.sh' savedtime sh fit-findfs.sh /dev/mtd0
rootfs_type=ramdísk rootfs_offset=3341828 rootfs_size=35925711real 0m 46.11s user 0m 7.65s sys 0m 34.40s
time sh fit-findfs.sh /dev/mtd3
rootfs_type=ramdísk rootfs_offset=3341828 rootfs_size=35953660real 0m 45.22s user 0m 7.57s sys 0m 33.67s
bootmanager debug verbose
yf_bootmanager version = 0.8.4-202203201227
Urlader dump size isn't a power of two.
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = PRX300
system selector = 1
system is switched = false
device branding =
device branding is changeable =
current branding = avm
inactive system is installed = false
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel =
active filesystem =
active system version = 257.07.29-93005
active system date = 02.12.2021, 12:35:28 Uhr (epoch: 1638444928)
active system modification date = 31.03.2022, 19:46:56 Uhr (epoch: 1648748816)
active system modification source = Freetz-NG
Urlader dump size isn't a power of two.
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive kernel =
inactive filesystem =
inactive filesystem could not be mountedEDIT Nach ca 31 Min Online sein Temperatur 72.113 °C Nach 71 Min Temperatur 72.292 °C
EDIT2
time nanddump --bb=skipbad -f /tmp/nandump0 /dev/mtd0
ECC failed: 0
ECC corrected: 4
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x03200000...
ECC: 2 corrected bitflip(s) at offset 0x01f1f000real 0m 11.36s user 0m 0.14s sys 0m 4.67s
time nanddump --bb=skipbad -f /tmp/nandump3 /dev/mtd3
ECC failed: 0
ECC corrected: 8
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x03200000...
ECC: 2 corrected bitflip(s) at offset 0x0000f800
ECC: 2 corrected bitflip(s) at offset 0x01ade000real 0m 12.27s user 0m 0.27s sys 0m 5.31s
fda77
commented
2 years ago Wie ist denn die Auslastung in dieser zeit gewesen? Für zb einen Raspberry 4 ist 75°C "normal" ohne Lüfter
freetz-ng-mod
commented
2 years ago Lauft zZ nur als Client, da mein FTTH Anschluss noch nicht geschaltet wurde
PeterPawn
commented
2 years ago Ja, die MIPS-Prozessoren sind langsamer als die ARM-Teile - 45 Sekunden für das Zerlegen sind schon happig. Andererseits drängelt ja auch niemand - keiner wird (hoffentlich) auf die Idee kommen, gleich nach einem Reboot wieder auf die Daten des Boot-Managers zugreifen zu wollen.
Wobei ich schon mal darüber nachgedacht habe, wie das wohl als C-Programm (dann eben leider "plattformabhängig") am Ende aussehen könnte ... andererseits kommen da mit neuen Modellen auch immer wieder neue Absonderlichkeiten ins Spiel, so daß sich C-Sourcen wohl eher doch nicht lohnen.
Ein schönes Beispiel war da für mich die abweichende EVA-Konfiguration bei den BCM963-Modellen (wobei die Bestätigung für den FR1200ax noch aussteht), die eben nicht in der urlader-Partition liegt, sondern wieder in nvram - wenn man das alles in C abbilden will, braucht man entweder tatsächlich wieder eine "Steuerdatei", in der der Aufbau der Box(en) beschrieben ist oder man müßte auch da ständig ändern.
Da schlucke ich doch lieber die Kröte der längeren Laufzeit (bis zu einer Minute oder noch knapp darüber), wenn das dann auch mit einer einzigen "Code-Basis" und ohne gesonderte Binaries für jede Plattform machbar wird.
Wobei das mit dem Suchen der EVA-Konfiguration für die Ermittlung, ob das Branding nun dauerhaft geändert werden kann oder nicht, vermutlich ohnehin "overkill" ist ... nur für einige 7490-Modelle, wo es tatsächlich verschiedene Konfigurationen im Bootloader gab, ist damit eine "gezielte" Entscheidung möglich, ob das nun funktioniert oder nicht. Aber man kann sich da nicht auf die Versionsnummer von EVA verlassen und daher war mir dieser Test "ein Bedürfnis". Bei neueren Geräten "fixiert" AVM aber wohl immer auch das Branding - wobei man sogar die Daten im Konfigurationsbereich ändern könnte, wenn man das sorgfältig macht - AVM macht in der Finalisierung ja auch nichts anderes.
PeterPawn
commented
2 years ago Ergebnis auf der 5530:
root@5530-client:/var# BM_DEBUG_EVA=1 BM_DEBUG_FIT=1 time sh bootmanager debug verbose
yf_bootmanager version = 0.8.5-202204061554
>>>>>>>>>> device configuration from EVA loader <<<<<<<<<<
Read 'memsize' value from urlader environment: 0x40000000
Read 'mtd0' value from urlader environment: 0x0,0x0
Read 'maca' value from urlader environment: 1C:ED:6F:xx:xx:xx
Read 'wlan_key' value from urlader environment: <removed>
Read 'mtd0' value from urlader environment: 0x0,0x0
Read 'mtd1' value from urlader environment: 0x980000,0x3B80000
Read 'mtd2' value from urlader environment: 0x0,0x180000
Read 'mtd3' value from urlader environment: 0x180000,0x980000
Read 'mtd4' value from urlader environment: 0x3B80000,0x6D80000
Read 'mtd5' value from urlader environment: 0x6D80000,0x8000000
Read 'mtd6' value from urlader environment: (empty)
Read 'mtd7' value from urlader environment: (empty)
Read 'mtd8' value from urlader environment: (empty)
Read 'mtd9' value from urlader environment: (empty)
Read 'mtd10' value from urlader environment: (empty)
Read 'mtd11' value from urlader environment: (empty)
Read 'mtd12' value from urlader environment: (empty)
Read 'mtd13' value from urlader environment: (empty)
Read 'mtd14' value from urlader environment: (empty)
Read 'mtd15' value from urlader environment: (empty)
Configuration area candidate found at offset: 1189888 (0x122800)
Configuration area found at offset: 1189888 (0x122800)
EVA configuration found at offset: 1189888 (0x122800)
'firmware_version' found in fixed values area.
EVA device configuration lookup lasted 28.398781332 seconds.
immutable=avm
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = PRX300
model = AVM FRITZ!Box 5530
chipset manufacturer = intel
compatible = PRX321-SFU-QSPI-PON
system selector = 1
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
>> (4) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 3341828 852476 1048576
>> >> (1) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 3341828 508 1024
>> >> >> (1) dd if=/var/tmp/11125_1649253367/fit-image-11125 bs=4 skip=835457 count=127
>> >> (2) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 3342336 851968 1024
>> >> >> (2) dd if=/var/tmp/11125_1649253367/fit-image-11125 bs=1024 skip=3264 count=832
>> (5) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 4194304 35907239 1048576
>> >> (2) dd if=/var/tmp/11125_1649253367/fit-image-11125 bs=1048576 skip=4 count=34
>> >> (6) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 39845888 255655 1048576
>> >> >> (1) dd if=/var/tmp/11125_1649253367/fit-image-11125 bs=1024 skip=38912 count=249
>> >> >> (3) copy_optimized /var/tmp/11125_1649253367/fit-image-11125 40100864 679 1024
>> >> >> >> (1) dd if=/var/tmp/11125_1649253367/fit-image-11125 bs=1 skip=40100864 count=679
FIT image rootfs offset lookup lasted 46.057337200 seconds.
inactive slot contains a FIT image = true
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /dev/mtdblock0
rootfs_type = ramdísk
rootfs_offset = 3341828 (0x32fe04)
rootfs_size = 36759715 (0x230e8a3)
inactive system version = 257.07.29-93005
inactive system date = 02.12.2021, 12:35:28 Uhr (epoch: 1638444928)
inactive system modification date = 02.04.2022, 21:00:07 Uhr (epoch: 1648926007)
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm avme
branding used by inactive system = avm (immutable)
real 1m 25.49s
user 0m 37.94s
sys 0m 45.99s
root@5530-client:/var# rm /var/tmp/bootmanager.*
root@5530-client:/var# time sh bootmanager get_values
active_version="257.07.29-93005"
active_date_epoch="1638444928"
active_date="02.12.2021, 12:35:28 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1649084474"
active_modified_at="04.04.2022, 17:01:14 Uhr"
active_brandings="1und1 avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="257.07.29-93005"
inactive_date_epoch="1638444928"
inactive_date="02.12.2021, 12:35:28 Uhr"
inactive_modified_by="Freetz-NG"
inactive_modified_at_epoch="1648926007"
inactive_modified_at="02.04.2022, 21:00:07 Uhr"
inactive_brandings="1und1 avm avme"
inactive_branding="avm"
inactive_change_branding_support=immutable
current_branding=avm
device_branding=avm
device_branding_changeable=false
switch_branding_support=false
current_switch_value=1
system_is_switched=false
bootmanager_version="0.8.5-202204061554"
real 1m 24.11s
user 0m 38.00s
sys 0m 45.26s
root@5530-client:/var# time sh bootmanager get_values
active_version="257.07.29-93005"
active_date_epoch="1638444928"
active_date="02.12.2021, 12:35:28 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1649084474"
active_modified_at="04.04.2022, 17:01:14 Uhr"
active_brandings="1und1 avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="257.07.29-93005"
inactive_date_epoch="1638444928"
inactive_date="02.12.2021, 12:35:28 Uhr"
inactive_modified_by="Freetz-NG"
inactive_modified_at_epoch="1648926007"
inactive_modified_at="02.04.2022, 21:00:07 Uhr"
inactive_brandings="1und1 avm avme"
inactive_branding="avm"
inactive_change_branding_support=immutable
current_branding=avm
device_branding=avm
device_branding_changeable=false
switch_branding_support=false
current_switch_value=1
system_is_switched=false
bootmanager_version="0.8.5-202204061554"
real 0m 0.24s
user 0m 0.08s
sys 0m 0.07s
root@5530-client:/var#Das "schwächste" Modell mit FIT-Image - beim ersten Aufruf unter 90 Sekunden (Laufzeit), danach "nicht erwähnenswert". Daten sehen für mich stimmig aus, Umschaltung nicht getestet.
PeterPawn
commented
2 years ago Für mich erst mal erledigt - notfalls neu zu öffnen.
freetz-ng-mod
commented
2 years ago Ich teste das Umschalten
So nun bin ich auf dem anderen System aber nun ist der BM natürlich weg lach
Discussed in https://github.com/PeterPawn/YourFritz/discussions/48