[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,274
Punkte für Reaktionen
1,751
Punkte
113
Edit DM41: Thema abgetrennt aus dem Sammelthema zur AVM FRITZ!Box 7520

Wenn Du die (doch etwas komplexeren) Aktionen zum Einbau der Aktivierung des "telnetd" (wenn man den wieder über Telefon-Codes starten und stoppen will, braucht es mehr als den Symlink) auch "von Hand" hinbekommst, kannst Du das natürlich gleich mitmachen.

Wenn es nicht auf Anhieb klappt, bliebe als Alternative noch dieses: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2366717 (fünfter Abschnitt, dritter Absatz bzw. gleich: https://github.com/PeterPawn/modfs/blob/master/run_modscripts) - die für Telnet und die privaten Funktionen des "telefon"-Daemons notwendigen Skript-Dateien aus "modscripts", sollten auch bei einer 7520/7530 funktionieren.
 
Zuletzt bearbeitet von einem Moderator:
Vielen Dank für die Erklarung und die Links.
Wenn ich es richtig verstehe, führe ich modfs im Verzeichnis indem ich das Image ausgepackt habe aus - packe das Image wieder zusammen und lade das auf die 7520 ? Das probiere ich die nächsten Tage mal aus.
 
führe ich modfs [...] aus
Nein - "run_modscripts" und das kriegt als Parameter das Verzeichnis mit der entpackten FRITZ!OS-Struktur.

Wobei das mit "fwmod" nicht so ganz einfach ist - das kann auch mal schiefgehen. Grund ist i.d.R. das von "fwmod" verwendete "fakeroot" - eigentlich sind alle Zugriffe auf Strukturen, die von "fakeroot" erzeugt wurden, zu vermeiden bzw. unter Verwendung genau derselben Umgebung auszuführen:
https://man.cx/fakeroot(1) schrieb:
"[...] fakeroot will behave in odd ways unless you leave the files touched inside the fakeroot alone when outside the environment."
Daher sollte man dann das "run_modscripts" auch aus einem "fakeroot"-Kontext heraus verwenden.

Entpackt man die Daten gleich als "richtiger" Superuser (aka "root"), muß man sich darüber keine Gedanken machen. Das mit dem "fakeroot" sollte man bei Verwendung von "fwmod" immer mit "ansagen".

Am Ende braucht man ein "fwmod -u" bzw. "fwmod -p" fast nie wirklich - ein "tar" und ein "unsquashfs" bzw. "mksquashfs" ist "von Hand" leichter ausgeführt (gerade bei einer Box mit getrenntem Kernel und "echtem" SquashFS-Image als Dateisystem: https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/ - bei VR9 und "gefaketem" SquashFS-Image mag das komplizierter sein), als erst jemandem zu erläutern, wie er sein "fakeroot"-Environment richtig verwendet, solange er die Änderungen nicht im "no-freetz-mode" und innerhalb der "fwmod_custom" ausführt (wo dann das passende Environment automatisch von "fwmod" verwaltet wird).

EDIT: Ach so ... und man muß bei der Verwendung von "run_modscripts" natürlich auch selbst dafür sorgen, daß nur die "gewünschten" Skript-Files in "modscripts" stehen - die einzelnen Abfragen sind da nicht implementiert.
 
  • Like
Reaktionen: genuede
Nein - "run_modscripts" und das kriegt als Parameter das Verzeichnis mit der entpackten FRITZ!OS-Struktur.
Code:
toni@ubuntu:~/modfs$ ./run_modscripts /home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem
Running script 'copy_binaries' ...
Unable to find binaries file 'files/binaries_164_4.4.60.tgz' to be unpacked.
Finished script 'copy_binaries', rc=3
Running script 'edit_rcuser' ...
chown: /home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/sbin/edit_rcuser: Operation not permitted
Finished script 'edit_rcuser', rc=0
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_default_show_mac' ...
Finished script 'mod_default_show_mac', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_exec_on_nand' ...
Finished script 'mod_exec_on_nand', rc=0
Running script 'mod_exec_on_usb' ...
Finished script 'mod_exec_on_usb', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_leddisplay' ...
Finished script 'mod_leddisplay', rc=0
Running script 'mod_mount_by_label' ...
Finished script 'mod_mount_by_label', rc=0
Running script 'mod_multi_annex' ...
Finished script 'mod_multi_annex', rc=0
Running script 'mod_night' ...
Finished script 'mod_night', rc=0
Running script 'mod_no_tainted_message' ...
Finished script 'mod_no_tainted_message', rc=0
Running script 'mod_ntp_on_ip_client' ...
Finished script 'mod_ntp_on_ip_client', rc=0
Running script 'mod_prefer_fonnumber_name' ...
Finished script 'mod_prefer_fonnumber_name', rc=0
Running script 'mod_profile' ...
Finished script 'mod_profile', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_remove_avm_vpn_from_overview' ...
Finished script 'mod_remove_avm_vpn_from_overview', rc=0
Running script 'mod_show_name' ...
Finished script 'mod_show_name', rc=0
Running script 'mod_show_vpn_on_overview' ...
Finished script 'mod_show_vpn_on_overview', rc=0
Running script 'mod_swapoff' ...
Finished script 'mod_swapoff', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
Running script 'mod_volatile_nas_dir' ...
Unter dem NAS-Pfad 'volatile' wird zusätzlich ein flüchtiger Speicherverfügbar gemacht.
Finished script 'mod_volatile_nas_dir', rc=0
Running script 'mod_xchg_sort_icons' ...
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/1und1/css/default/images/sort_down.gif': No such file or directory
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/1und1/css/default/images/sort_up.gif': No such file or directory
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/1und1/css/default/images/sort_down.gif.swap': No such file or directory
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/avm/css/default/images/sort_down.gif': No such file or directory
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/avm/css/default/images/sort_up.gif': No such file or directory
mv: can't rename '/home/toni/freetz-devel/freetz-devel/fwmod-7530/original/filesystem/usr/www/avm/css/default/images/sort_down.gif.swap': No such file or directory
Finished script 'mod_xchg_sort_icons', rc=0
Running script 'mod_yourfritz_key' ...
Der öffentliche Schlüssel wurde als 'etc/plugin_global_key.pem' installiert.
Finished script 'mod_yourfritz_key', rc=0
toni@ubuntu:~/freetz-devel/freetz-devel$ ./fwmod -p -d fwmod-7530/ FRITZ.Box_7530-07.14.image
detected firmware 7530_de 164.07.14 rev73183 (08.11.2019 13:46:33)

STEP 3: PACK
WARNING: Modifications (STEP 2) and this step should never
         ever be run with different configurations!
         This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
cp: Zugriff auf 'fwmod-7530//original/filesystem/etc/plugin_global_key.pem' nicht möglich: Ist kein Verzeichnis
cp: Lesen der symbolischen Verknüpfung 'fwmod-7530//original/filesystem/etc/hotplug/storage' nicht möglich: Das Argument ist ungültig
cp: Lesen der symbolischen Verknüpfung 'fwmod-7530//original/filesystem/etc/init.d/rc.conf' nicht möglich: Das Argument ist ungültig
cp: 'fwmod-7530//original/filesystem/usr/sbin/telnetd' kann nicht zum Lesen geöffnet werden: Zu viele Ebenen aus symbolischen Links
invoking custom script
  restoring support for /var/flash/debug.cfg
    patching ./filesystem/etc/init.d/rc.tail.sh
  checking for left over version-control-system files
packing var.tar
creating filesystem image (SquashFS4-xz)
  SquashFS block size: 64 kB (65536 bytes)
copying kernel image
  kernel image size: 2.9 MB, max 4.0 MB, free 1.1 MB (1181440 bytes)
copying filesystem image
  filesystem image size: 19.4 MB, max 44.0 MB, free 24.6 MB (25841664 bytes)
adding checksum to kernel.image
adding checksum to filesystem.image
packing fwmod-7530//7530_07.14.de_20200523-120516.image
  unsigned image file size: 24.0 MB (25149440 bytes)
using unsigned image as the final one
done.

FINISHED
toni@ubuntu:~/freetz-devel/freetz-devel/tools/yf/eva_tools$ ./image2ram < /home/toni/freetz-devel/freetz-devel/fwmod-7530/7530_07.14.de_20200523-120516.image > 7530_siab.image.in-memory

PS C:\> c:\Master\eva_tools\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage c:\YourFritz\Images\7530_siab.image.in-memory 0 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.10288 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x10000000 (256 MB)
DEBUG: Memory size used     : 0x10000000 (256 MB)
DEBUG: Image size found     : 0x017fc000
DEBUG: Set memory size to   : 0x0e804000
DEBUG: Set MTD RAM device to: 0x8e804000,0x90000000
DEBUG: Sent
SETENV memsize 0x0e804000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8e804000,0x90000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'c:\YourFritz\Images\7530_siab.image.in-memory' to '0x8e804000 0x90000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,0)

================
DEBUG: Sent
STOR 0x8e804000 0x90000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
553 Execution failed.

================
DEBUG: Sent
SETENV memsize 0x10000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\Master\eva_tools\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException
Bekomme das nicht mit modfs leider nicht hin. Ein Modifiziertes Image ohne modfs lässt sich ohne Probleme flashen.
 
Das mit der klugen Auswahl der im Unterverzeichnis "modscripts" zu belassenden Dateien (der Rest sollte gelöscht werden), hatte ich weiter vorne ja schon geschrieben. Und von der Verwendung des "fakeroot"-Environments beim Aufruf von "run_modscripts" ist auch nichts zu sehen - ich habe schon in #147 versucht zu erklären, daß (und warum) es da Probleme geben wird.

Die Fehler, die sich auch beim Packen mit "fwmod -p" dann zeigen, sind (vermutlich) genau darauf auch zurückzuführen - was da jetzt genau für ein Image herauskommt und warum das sich nicht starten läßt, kann man in dem Protokoll aber nicht erkennen. Nur schon der Ansatz, sowohl "mod_rc_tail_sh" als auch die Änderung durch Freetz parallel zu verwenden, wirkt halt befremdlich:
Code:
invoking custom script restoring support for /var/flash/debug.cfg
patching ./filesystem/etc/init.d/rc.tail.sh
checking for left over version-control-system files
- auch wenn er das Problem beim Starten des Images nicht erklären kann.

Das mit dem:
Ein Modifiziertes Image ohne modfs lässt sich ohne Probleme flashen.
wage ich einfach auch mal zu bezweifeln, wobei das eben davon abhängt, was man beim "Modifizieren" tatsächlich macht und ob/wie sich das auf die Dateien unter "fakeroot control" auswirkt. Jede hinreichend weitgehende Modifikation der entpackten Strukturen hat exakt dasselbe Problem, wie Du selbst in diversen Threads zum Thema "fakeroot" und Freetz nachlesen kannst - das Problem liegt also nicht am "modfs", sondern daran, wie Du es anwendest bzw. daß Du "fwmod" zum Entpacken und Packen verwendest und das nicht als Superuser mit "unsquashfs" und "mksquashfs" selbst machst.

Auch den Thread dazu hatte ich oben verlinkt ... selbst wenn der sich mit 7580/7560/7590 befaßt, ist das Prinzip bei einer 7530/7520 dasselbe, daß man den Kernel und das Dateisystem hintereinander kopieren muß für die Datei, die man ins RAM laden lassen kann - nur wird bei diesen Modellen halt das LE-Format verwendet (und damit funktioniert das theoretisch sogar mit den "squashfs-tools" der Distro und braucht nicht mal die Tools aus Freetz bzw. die vorübersetzten aus YourFritz bzw. yf_bin).

===========================================================================================

Wenn ich das - zugegebenermaßen ohne "fwmod" - einfach einmal "durchexerziere", gibt es die ganzen Fehler, die man bei Dir sehen kann, nicht:
Rich (BBCode):
peh@vidar:~> mkdir /tmp/7530
peh@vidar:~> cd /tmp/7530
peh@vidar:/tmp/7530> wget -q -O avm.tar http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.14.image
peh@vidar:/tmp/7530> tar -x -f avm.tar -O ./var/tmp/kernel.image >kernel
peh@vidar:/tmp/7530> dd of=kernel.bin if=kernel bs=8 count=$(( ( $(stat -c %s kernel) / 8 ) - 1 )) 2>/dev/null
peh@vidar:/tmp/7530> rm kernel
peh@vidar:/tmp/7530> tar -x -f avm.tar -O ./var/tmp/filesystem.image >fs.sqfs
peh@vidar:/tmp/7530> rm avm.tar
peh@vidar:/tmp/7530> ls -l
total 23232
-rw-r--r-- 1 peh users 20295688 May 23 12:59 fs.sqfs
-rw-r--r-- 1 peh users  3012864 May 23 12:58 kernel.bin
peh@vidar:/tmp/7530> git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
remote: Enumerating objects: 718, done.
remote: Counting objects: 100% (718/718), done.
remote: Compressing objects: 100% (418/418), done.
remote: Total 3482 (delta 390), reused 526 (delta 295), pack-reused 2764
Receiving objects: 100% (3482/3482), 4.23 MiB | 6.14 MiB/s, done.
Resolving deltas: 100% (2102/2102), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/tmp/7530/YourFritz/bin'...
remote: Enumerating objects: 396, done.
remote: Counting objects: 100% (396/396), done.
remote: Compressing objects: 100% (248/248), done.
remote: Total 825 (delta 102), reused 345 (delta 77), pack-reused 429
Receiving objects: 100% (825/825), 58.69 MiB | 11.43 MiB/s, done.
Resolving deltas: 100% (192/192), done.
Cloning into '/tmp/7530/YourFritz/first_aid'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 42 (delta 0), reused 3 (delta 0), pack-reused 38
Receiving objects: 100% (42/42), 21.63 MiB | 9.90 MiB/s, done.
Resolving deltas: 100% (13/13), done.
Submodule path 'bin': checked out '7cd06e296f58f95eb9aa3ca616fd3765cea58c56'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
peh@vidar:/tmp/7530> git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
Cloning into 'modfs'...
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 1638 (delta 14), reused 23 (delta 10), pack-reused 1605
Receiving objects: 100% (1638/1638), 17.16 MiB | 9.65 MiB/s, done.
Resolving deltas: 100% (1105/1105), done.
peh@vidar:/tmp/7530> YourFritz/bin/squashfs/x86_64/unsquashfs4-le -s fs.sqfs
Found TI checksum (0x64C552D1) at the end of the image.
Found a valid little endian SQUASHFS 4:0 superblock on fs.sqfs.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 19817.53 Kbytes (19.35 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 314
Number of inodes 4301
Number of ids 1
peh@vidar:/tmp/7530> sudo YourFritz/bin/squashfs/x86_64/unsquashfs4-le fs.sqfs
[sudo] password for root:
Found TI checksum (0x64C552D1) at the end of the image.
Filesystem on fs.sqfs is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
4021 inodes (4644 blocks) to write

[===================================================================-] 4644/4644 100%

created 3406 files
created 280 directories
created 602 symlinks
created 13 devices
created 0 fifos
peh@vidar:/tmp/7530> sudo chown -R peh:users squashfs-root/
peh@vidar:/tmp/7530> rm fs.sqfs
peh@vidar:/tmp/7530> ls -l
total 2944
-rw-r--r-- 1 peh users 3012864 May 23 12:58 kernel.bin
drwxr-xr-x 1 peh users     340 May 23 13:18 modfs
drwxr-xr-x 1 peh users     128 Nov  8  2019 squashfs-root
drwxr-xr-x 1 peh users     738 May 23 13:06 YourFritz
peh@vidar:/tmp/7530> mv modfs/modscripts/ modfs/modscripts.org
peh@vidar:/tmp/7530> mkdir modfs/modscripts
peh@vidar:/tmp/7530> cp modfs/modscripts.org/gui_boot_manager_v0.6 modfs/modscripts/
peh@vidar:/tmp/7530> cp modfs/modscripts.org/mod_enable_calllog modfs/modscripts/
peh@vidar:/tmp/7530> cp modfs/modscripts.org/mod_fixed_branding modfs/modscripts/
peh@vidar:/tmp/7530> cp modfs/modscripts.org/mod_telnet_enable modfs/modscripts/
peh@vidar:/tmp/7530> cp modfs/modscripts.org/mod_rc_tail_sh modfs/modscripts/
peh@vidar:/tmp/7530> ls -1 modfs/modscripts
gui_boot_manager_v0.6
mod_enable_calllog
mod_fixed_branding
mod_rc_tail_sh
mod_telnet_enable
peh@vidar:/tmp/7530> cd modfs/
peh@vidar:/tmp/7530/modfs> ./run_modscripts ../squashfs-root/
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
peh@vidar:/tmp/7530/modfs> cd ..
peh@vidar:/tmp/7530> YourFritz/bin/squashfs/x86_64/mksquashfs4-le squashfs-root/ fs.sqfs -all-root
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on fs.sqfs, block size 65536.
[===================================================================-] 4032/4032 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 19827.22 Kbytes (19.36 Mbytes)
        28.58% of uncompressed filesystem size (69385.33 Kbytes)
Inode table size 35094 bytes (34.27 Kbytes)
        23.75% of uncompressed inode table size (147760 bytes)
Directory table size 43342 bytes (42.33 Kbytes)
        41.57% of uncompressed directory table size (104262 bytes)
Number of duplicate files found 1298
Number of inodes 4304
Number of files 3408
Number of fragments 314
Number of symbolic links  603
Number of device nodes 13
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 280
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
peh@vidar:/tmp/7530> YourFritz/bin/squashfs/x86_64/unsquashfs4-le -s fs.sqfs
Found a valid little endian SQUASHFS 4:0 superblock on fs.sqfs.
Creation or last append time Sat May 23 13:32:16 2020
Filesystem size 19827.22 Kbytes (19.36 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 314
Number of inodes 4304
Number of ids 1
peh@vidar:/tmp/7530> cat kernel.bin fs.sqfs >new.image
peh@vidar:/tmp/7530> ls -l
total 45544
-rw-r--r-- 1 peh users 20303872 May 23 13:32 fs.sqfs
-rw-r--r-- 1 peh users  3012864 May 23 12:58 kernel.bin
drwxr-xr-x 1 peh users      340 May 23 13:18 modfs
-rw-r--r-- 1 peh users 23316736 May 23 13:36 new.image
drwxr-xr-x 1 peh users      128 Nov  8  2019 squashfs-root
drwxr-xr-x 1 peh users      738 May 23 13:06 YourFritz
peh@vidar:/tmp/7530>
Die jetzt vorhandene new.image sollte sich problemlos über EVA installieren lassen - wobei ich diesen Schritt (mangels 7520/7530) jetzt nicht prüfen kann. Dabei habe ich aber dann auch nur den Boot-Manager, den Telnet-Daemon (inkl. Start/Stop über Telefon-Codes und "system_status" bei wiederholter Aktivierung) und die Abarbeitung der "rc.user" (oder "debug.cfg") wieder einbauen lassen, ebenso das "feste" Branding mit "avm". Hier kann man natürlich auch noch "HWRevision" "festmachen", dann klappt es sogar wieder mit der Suche nach weiteren Dateien bei AVM. Wobei man die dann natürlich immer noch nicht "original" installieren lassen sollte (obwohl es klappen müßte), weil es dann beim nächsten Update nicht mehr funktionieren würde, da die AVM-Firmware ja die Modifikationen wieder nicht enthält.

Aber schreibt man die notwendigen Kommandos hintereinander in eine Datei (das nennt sich dann ja "Skript") und startet die dann nur noch, kann man auch einfach "messen", wie lange diese Aktionen insgesamt wohl dauern mögen (beim parallelen "Dokumentieren" dauert das naturgemäß alles noch länger, als wenn man die Kommandos nur eintippt) - wobei ich hier auf die Anzeigen mit unsquashfs4-le -s ... für die Eigenschaften des SquashFS-Images - das gibt es oben auch gleich zweimal, damit man die Eigenschaften des AVM-Images mit dem selbst erstellten vergleichen kann - und ls -l ebenso verzichte, wie auf die "progress indication" der SquashFS-Tools, weil mich hier nur die Dauer wirklich interessiert:
Rich (BBCode):
peh@vidar:~> cat > modify_7530.sh <<'EOT'
> mkdir /tmp/7530
> cd /tmp/7530
> wget -q -O avm.tar http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.14.image
> tar -x -f avm.tar -O ./var/tmp/kernel.image >kernel
> dd of=kernel.bin if=kernel bs=8 count=$(( ( $(stat -c %s kernel) / 8 ) - 1 )) 2>/dev/null
> rm kernel
> tar -x -f avm.tar -O ./var/tmp/filesystem.image >fs.sqfs
> git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
> git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
> sudo YourFritz/bin/squashfs/x86_64/unsquashfs4-le -no-progress fs.sqfs
> sudo chown -R peh:users squashfs-root/
> rm fs.sqfs
> mv modfs/modscripts/ modfs/modscripts.org
> mkdir modfs/modscripts
> cp modfs/modscripts.org/gui_boot_manager_v0.6 modfs/modscripts/
> cp modfs/modscripts.org/mod_enable_calllog modfs/modscripts/
> cp modfs/modscripts.org/mod_fixed_branding modfs/modscripts/
> cp modfs/modscripts.org/mod_telnet_enable modfs/modscripts/
> cp modfs/modscripts.org/mod_rc_tail_sh modfs/modscripts/
> cd modfs/
> ./run_modscripts ../squashfs-root/
> cd ..
> YourFritz/bin/squashfs/x86_64/mksquashfs4-le squashfs-root/ fs.sqfs -all-root -no-progress
> cat kernel.bin fs.sqfs >new.image
> ls -l
> EOT
peh@vidar:~> time bash ./modify_7530.sh
Cloning into 'YourFritz'...
remote: Enumerating objects: 718, done.
remote: Counting objects: 100% (718/718), done.
remote: Compressing objects: 100% (418/418), done.
remote: Total 3482 (delta 390), reused 526 (delta 295), pack-reused 2764
Receiving objects: 100% (3482/3482), 4.23 MiB | 5.98 MiB/s, done.
Resolving deltas: 100% (2102/2102), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/tmp/7530/YourFritz/bin'...
remote: Enumerating objects: 396, done.
remote: Counting objects: 100% (396/396), done.
remote: Compressing objects: 100% (248/248), done.
remote: Total 825 (delta 102), reused 345 (delta 77), pack-reused 429
Receiving objects: 100% (825/825), 58.69 MiB | 11.41 MiB/s, done.
Resolving deltas: 100% (192/192), done.
Cloning into '/tmp/7530/YourFritz/first_aid'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 42 (delta 0), reused 3 (delta 0), pack-reused 38
Receiving objects: 100% (42/42), 21.63 MiB | 9.87 MiB/s, done.
Resolving deltas: 100% (13/13), done.
Submodule path 'bin': checked out '7cd06e296f58f95eb9aa3ca616fd3765cea58c56'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
Cloning into 'modfs'...
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 1638 (delta 14), reused 23 (delta 10), pack-reused 1605
Receiving objects: 100% (1638/1638), 17.16 MiB | 9.65 MiB/s, done.
Resolving deltas: 100% (1105/1105), done.
[sudo] password for root:
Found TI checksum (0x64C552D1) at the end of the image.
Filesystem on fs.sqfs is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
4021 inodes (4644 blocks) to write


created 3406 files
created 280 directories
created 602 symlinks
created 13 devices
created 0 fifos
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on fs.sqfs, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 19827.23 Kbytes (19.36 Mbytes)
        28.58% of uncompressed filesystem size (69385.33 Kbytes)
Inode table size 35090 bytes (34.27 Kbytes)
        23.75% of uncompressed inode table size (147760 bytes)
Directory table size 43342 bytes (42.33 Kbytes)
        41.57% of uncompressed directory table size (104262 bytes)
Number of duplicate files found 1298
Number of inodes 4304
Number of files 3408
Number of fragments 314
Number of symbolic links  603
Number of device nodes 13
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 280
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
total 70104
-rw-r--r-- 1 peh users 25149440 Nov 28 13:58 avm.tar
-rw-r--r-- 1 peh users 20303872 May 23 14:04 fs.sqfs
-rw-r--r-- 1 peh users  3012864 May 23 14:04 kernel.bin
drwxr-xr-x 1 peh users      340 May 23 14:04 modfs
-rw-r--r-- 1 peh users 23316736 May 23 14:04 new.image
drwxr-xr-x 1 peh users      128 Nov  8  2019 squashfs-root
drwxr-xr-x 1 peh users      738 May 23 14:04 YourFritz

real    0m49.231s
user    0m39.744s
sys     0m7.790s
peh@vidar:~>
Wenn man das also passend vorbereitet, dauert die Modifikation (inkl. Downloads von AVM und Klonen der Repos, sogar mit manueller Eingabe des "root"-Kennworts für das "sudo" - das sind natürlich "variable Kosten" hinsichtlich der benötigten Zeit) keine 50 Sekunden (und das System ist nicht mal besonders potent, auf dem ich das demonstriert habe) ... da kommt dann ggf. noch der Upload und der Start auf der Box hinzu.

Allerdings braucht es dazu tatsächlich das Wissen (und die vorbereiteten Dateien in meinen Repos, aber die stehen jedem offen) und wie lange man für dessen Erwerb braucht, kann (und will) ich nicht einschätzen. Ich wollte nur mal wieder demonstrieren, daß das Modifizieren einer Firmware für eine FRITZ!Box keine "rocket science" ist und auch wenn das hier ggf. etwas kondensierter steht und praktisch ohne "Erläuterungen", finden sich die einzelnen "Versatzstücke" definitiv auch hier im IPPF - allerdings eben auch mal in unterschiedlichen Threads, aber das ist nun mal der Natur der Sache geschuldet.
 
Zuletzt bearbeitet:
Guten Morgen,

ich möchte mich ganz herzlich bei @PeterPawn bedanken. Dein Script habe ich Heute durchlaufen lassen und das "new.Image" ging ohne Probleme auf die 7520 drauf.

Code:
PS C:\> Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted

Ausführungsrichtlinie ändern
Die Ausführungsrichtlinie trägt zum Schutz vor nicht vertrauenswürdigen Skripts bei. Wenn Sie die Ausführungsrichtlinie
 ändern, sind Sie möglicherweise den im Hilfethema "about_Execution_Policies" unter
"https:/go.microsoft.com/fwlink/?LinkID=135170" beschriebenen Sicherheitsrisiken ausgesetzt. Möchten Sie die
Ausführungsrichtlinie ändern?
[J] Ja  [A] Ja, alle  [N] Nein  [K] Nein, keine  [H] Anhalten  [?] Hilfe (Standard ist "N"): J
PS C:\> \Master\eva_tools\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage c:\YourFritz\Images\new.image 0 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.10288 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x10000000 (256 MB)
DEBUG: Memory size used     : 0x10000000 (256 MB)
DEBUG: Image size found     : 0x0163c900
DEBUG: Set memory size to   : 0x0e9c3700
DEBUG: Set MTD RAM device to: 0x8e9c3700,0x90000000
DEBUG: Sent
SETENV memsize 0x0e9c3700
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8e9c3700,0x90000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'c:\YourFritz\Images\new.image' to '0x8e9c3700 0x90000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,0)

================
DEBUG: Sent
STOR 0x8e9c3700 0x90000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
226 Transfer complete

================
True
PS C:\>
Dabei habe ich aber dann auch nur den Boot-Manager, den Telnet-Daemon (inkl. Start/Stop über Telefon-Codes und "system_status" bei wiederholter Aktivierung) und die Abarbeitung der "rc.user" (oder "debug.cfg") wieder einbauen lassen, ebenso das "feste" Branding mit "avm". Hier kann man natürlich auch noch "HWRevision" "festmachen", dann klappt es sogar wieder mit der Suche nach weiteren Dateien bei AVM.
Kannst Du mir einen Tip geben wie ich das aktivieren kann? Habe im ausgepacktem Image schon in /etc/init.d/rc.config die SETENV reingeschrieben aber die werden nicht erkannt.
Code:
##### TITLE Version /etc/version: /etc/init.d/rc.conf: line 8: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 9: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 10: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 11: SETENV: not found
164.07.14
##### TITLE SubVersion /etc/version: /etc/init.d/rc.conf: line 8: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 9: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 10: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 11: SETENV: not found

##### TITLE Produkt Fritz_Box_HW236
##### TITLE Datum Sat May 23 12:32:05 CEST 2020
/etc/version: /etc/init.d/rc.conf: line 8: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 9: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 10: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 11: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 8: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 9: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 10: SETENV: not found
/etc/version: /etc/init.d/rc.conf: line 11: SETENV: not found
##### BEGIN SECTION Support_Data Supportdata Linux FritzMeshClient 4.4.60 #1 SMP PREEMPT Mon Sep 16 17:07:21 CEST 2019 armv7l Version 164.07.14
Für mich ist das alles Neuland mit der Fritzbox.
Bei einem Debian oder Ubuntu würde ich die SETENV Befehle in die /etc/rc.local schreiben damit die ausgeführt werden beim starten aber wo macht man das bei der Fritzbox?

Jetzt muss ich schauen wie ich Telnet aktiviert bekomme mit dem Telefon. Auf jeden Fall ist das sehr einfach gewesen mit diesem Script.

@Mods der Beitrag #149 sollte angepinnt werden damit der nicht verloren geht und leicht gefunden wird.
 
  • Like
Reaktionen: genuede
Man kann aber nur ganze Threads anpinnen, nicht einzelne Beiträge. :(
Man kann den Beitrag trennen und ein neuen Thread öffnen mit passendem Titel. Diese gute Anleitung in #149 im 7520 Sammelthema bräuchte doch einen eigenen Thread.

Was ich gekämpft habe um erstmal "freetz-devel" installiert zu bekommen mit fwmod (immer Fehlermeldungen mit umask 0022 und nochmal git auschrecken und kein root.....) das war echt frustrierend.

Edit: Telnet habe ich aktiviert bekommen :) habe nicht gedacht, dass es so einfach per Telefon geht.
 

Anhänge

  • Screenshot_20200524-121046_Network Discovery.jpg
    Screenshot_20200524-121046_Network Discovery.jpg
    217.4 KB · Aufrufe: 79
Zuletzt bearbeitet:
Dabei habe ich aber dann auch nur den Boot-Manager ...
Nur als Hinweis. Bei der letzten Inhaus (7530-07.19-78653) erhalte ich in der GUI bei "Neustart" ein weißes Fenster
Ich kann gerne beim Testen helfen.

Der Rest geht. Auch die beiden: mod_exec_on_nand und mod_exec_on_usb

Code:
7520/30:$(pwd)# gui_bootmanager html_display
<h4>Die Umschaltung zwischen zwei installierten Systemen ist auf dieser FRITZ!Box nicht verf&uuml;gbar.</h4>
Sollte doch aber verfügbar sein, oder? linux_fs_start existiert.
Oder liegt es daran, daß die FW nicht zur HW paßt?
###############################################################

Durch das "große Verschieben" ist das hier mein 1. Beitrag.
Ich mache hier mal ein kleines unvollständiges Inhaltsverzeichnis, da ich sonst die besten Beiträge nicht mehr finde. In Klammern sind Befehle, die dabei benutzt werden.

#92 - install_inactive_rootfs nur für VR9 Boxen?
#94 - update_kernel, GRX + IPQ Boxen über CLI flashen
#99 - Prüfsumme an Datei anhängen (cksum, ticksum) + aus dem RAM installieren
#101 - in-memory zerlegen in kernel.raw und filesystem.raw d.h. ohne Prüfsumme
#104 - VR9 Boxen über CLI flashen (losetup)
 
Zuletzt bearbeitet:
Bei der letzten Inhaus
Aber auf der 7490 funktioniert der Patch? Wie war es bei der vorherigen Inhouse-Version? (wenn Du das wissen solltest)

Eigentlich ist der nicht für IPQ40x8/9 gemacht, weil der "gui_bootmanager" diese Plattform noch gar nicht berücksichtigt: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L133

Trotzdem sollte das nicht in einer leeren Seite enden ... hat wer Zugriff auf eine Shell auf einem passenden Gerät und kann mal die Ausgabe von "gui_bootmanager debug" posten?

Wenn's nicht zu kompliziert wird (ich hasse Tests über drei Ecken), würde ich mal probieren, die 7520/7530 hinzuzufügen (die 4040 hat ja wohl - trotz desselben SoC - nur eine System-Version).

Die Unterschiede in den Lua-Pages (zwischen 7490 und 7530) kriege ich noch mit einem "diff" heraus - aber "praktisch" auf der Box kann ich es nicht (selbst) testen.

Ähnliches gilt dann für die 07.14 - wenn "gui_bootmanager" gar nicht erst funktioniert (obwohl bei diesen Versionen ja nicht mehr direkt HTML generiert wird, sondern nur JSON zum Browser gesendet wird), wäre es nicht verwunderlich ... aber eine leere Seite deutet ja eher darauf hin, daß die ausgegebenen und/oder generierten HTML-Elemente am Ende nicht passen.
 
Aber auf der 7490 funktioniert der Patch?
Nicht getestet.
Wie war es bei der vorherigen Inhouse-Version?
Ich habe es erstmals mit dieser Inhaus probiert.

Code:
7520/30:$(pwd)# gui_bootmanager debug
system type =
system selector = 0
system is switched = false
system branding = avm
system branding is changeable = false
active kernel =
active filesystem =
active system version = 164.07.19-78653
active system date = 15.05.2020, 04:51:55 Uhr
active system modification date =
active system modification source = -
brandings supported on active system = avm (fixed)
inactive kernel =
inactive system is installed = false
inactive filesystem =
inactive system checks skipped

Bei Freetz (nicht freetz-ng) fast das gleiche, auch da ist das Fenster weiß:
Code:
   __  _   __  __ ___ __
  |__ |_) |__ |__  |   /
  |   |\  |__ |__  |  /_

   The fun has just begun ...


BusyBox v1.27.2 built-in shell (ash)

7520:/var/mod/root# gui_bootmanager debug
system type =
system selector = 1
system is switched = false
system branding = avm
system branding is changeable = false
active kernel =
active filesystem =
active system version = 164.07.14
active system date = 08.11.2019, 05:46:33 Uhr
active system modification date = 09.02.2020, 01:58:07 Uhr
active system modification source = Freetz
brandings supported on active system = 1und1 avm
inactive kernel =
inactive system is installed = false
inactive filesystem =
inactive system checks skipped



(die 4040 hat ja wohl - trotz desselben SoC - nur eine System-Version).
Richtig, die hat ja auch nur 32MB NOR-Flash.
 
Zuletzt bearbeitet:
Guten Morgen,

gibt es eine Möglichkeit die /etc/init.d/rc.conf bei laufender Fritzbox beschreibar zu stellen?
Habe schon probiert:
Code:
chmod 666 /etc/init.d/rc.conf
chmod +x /etc/init.d/rc.conf
Leider bleibt die schreibgeschützt.
Meine Absicht ist nach einem Update die rc.conf die auf dem USB Stick ist, zurück zu schreiben ohne neu flashen zu müssen.
Sicherung
Code:
cat /etc/init.d/rc.conf > /var/media/ftp/blablausb/rc.conf
Rücksicherung
Code:
cat /var/media/ftp/blablausb/rc.conf > /etc/init.d/rc.conf
 
Nein, keine Chance, da die ganze Partition RO (readonly) ist.

Wie sieht denn das "gui_bootmanager debug" bei dir aus?
 
Zuletzt bearbeitet:
Dem Skript zum Installieren nach zu urteilen, ähnelt der Aufbau/Ablauf der 7530 dem von den GRX-Boxen - UBI als zusätzlicher Layer für den "Rest" des NAND-Flashs und das Dateisystem (mit LE-Kodierung) als SquashFS-Image in einer dieser UBI-Partitionen und auch die Namen der Partitionen scheinen mit einem Präfix "reserved-" zu arbeiten (wenn's auch in einem Kommentar anders steht, nämlich als "filesystem_reserved").

Ich bräuchte dann mal die Ausgaben folgender Kommandos (ohne Anspruch auf Vollständigkeit der Liste im ersten Anlauf) für eine 7520/7530, wenn ich die Unterstützung dafür in den Boot-Manager einbauen will/soll:
Code:
cat /proc/cpuinfo
cat /proc/mtd
ubinfo -a
Im ersten Schritt geht es darum, die Plattform sicher von den anderen zu unterscheiden - im Moment wird sie gar nicht erkannt, wie man in der Debug-Ausgabe sehen kann.

Ich habe am JS-Code noch Änderungen vorgenommen, damit auch bei fehlenden Daten aus "gui_bootmanager get_values" die "reboot.js" weiterhin gültige HTML-Elemente (inkl. Fehlernachricht für den Boot-Manager) erzeugt - aber Einzug in das "modfs"-Repo hält das erst mit einem geänderten "gui_bootmanager"-Skript.
 
  • Like
Reaktionen: Insti
Aber gerne doch, wird doch für freetz auch gebraucht:

Von der FW 7.14 freetz:

Code:
7520:/var/mod/root# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
cpu MHz : 716.000
BogoMIPS        : 96.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 1
model name      : ARMv7 Processor rev 5 (v7l)
cpu MHz : 716.000
BogoMIPS        : 96.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 2
model name      : ARMv7 Processor rev 5 (v7l)
cpu MHz : 716.000
BogoMIPS        : 96.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 3
model name      : ARMv7 Processor rev 5 (v7l)
cpu MHz : 716.000
BogoMIPS        : 96.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Qualcomm (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000
Code:
7520:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "reserved-kernel"
mtd1: 002c0000 00020000 "urlader"
mtd2: 00840000 00020000 "nand-tffs"
mtd3: 00400000 00020000 "kernel"
mtd4: 06d00000 00020000 "ubi"
mtd5: 02c14000 0001f000 "reserved-filesystem"
mtd6: 02c14000 0001f000 "filesystem"
mtd7: 0020f000 0001f000 "config"
mtd8: 00c79000 0001f000 "nand-filesystem"
Code:
7520:/var/mod/root# ubinfo -a
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:58
Present UBI devices:            ubi0

ubi0
Volumes count:                           4
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     872 (110723072 bytes, 105.6 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  20
Current maximum erase counter value:     7
Minimum input/output unit size:          2048 bytes
Character device major/minor:            245:0
Present volumes:                         0, 1, 2, 3

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        364 LEBs (46219264 bytes, 44.1 MiB)
State:       OK
Name:        avm_filesys_0
Character device major/minor: 245:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        364 LEBs (46219264 bytes, 44.1 MiB)
State:       OK
Name:        avm_filesys_1
Character device major/minor: 245:2
-----------------------------------
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        17 LEBs (2158592 bytes, 2.1 MiB)
State:       OK
Name:        avm_config
Character device major/minor: 245:3
-----------------------------------
Volume ID:   3 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        103 LEBs (13078528 bytes, 12.5 MiB)
State:       OK
Name:        avm_userdata
Character device major/minor: 245:4
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Insti und PeterPawn
mtd1: 002c0000 00020000 "urlader"
Habe eine 7520 getötet weil ich dachte den mtd1 bearbeiten zu müssen mit den Env der 7530.
Jetzt lass ich in Zukunft die Finger von den mtdblocks.
Es heißt ja ein bisschen Schwund ist immer und ich will ja was lernen :)

Ps: wenn es jemand interessiert kann ich gerne den mtd1 "vor" dem Mord und den bearbeiteten verantwortlichen mtd1 bereitstellen.
Was mir noch aufgefallen ist an der 7530 und 7520, dass wenn man die bestromt kurz ein Reset durchgeführt wird und alle LEDs gehen kurz an und dann bootet die Box erst.
 
Zuletzt bearbeitet:
Hätte aber klappen können, wenn man alles richtig macht.

Jetzt kannst du ja noch lernen, wie man den Urlader per EJTAG wieder drauf lädt. ;)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Insti
Ich habe mal eine geänderte Version des Bootloaders eingecheckt: https://raw.githubusercontent.com/PeterPawn/YourFritz/master/bootmanager/gui_bootmanager - noch ohne Änderungen an der Beschreibung.

Wenn man die auf eine IPQ4019-Box lädt (der Link zeigt schon auf den "raw content" - man braucht nur eine BusyBox, deren "wget" auch TLS kann oder etwas Adäquates) und per "sh <filename> debug" aufruft, sollte (wenn alles klappt) eine vollständige Ausgabe erscheinen. Wenn das so wäre, ändere ich noch einige Kommentare und dann war's das schon für die IPQ4019-basierten Boxen.

Was mir noch aufgefallen ist an der 7530 und 7520, dass wenn man die bestromt kurz ein Reset durchgeführt wird und alle LEDs gehen kurz an und dann bootet die Box erst.
Das ist bei anderen Boxen aber ebenso.

Habe eine 7520 getötet
Die Frage, die ich mir hier stelle, wäre eher, wie genau Du da schreiben wolltest - das ist ja immerhin Flash-Speicher und einfach ein "cat > /dev/mtd[block]<something>" funktioniert nur, wenn der zuvor gelöscht wurde.
 
  • Like
Reaktionen: Insti
sollte (wenn alles klappt) eine vollständige Ausgabe erscheinen.
Leider noch nicht, aber "system type" klappt schon mal:
Code:
7520:/var/mod/root# gui_bootmanager3 debug
system type = IPQ4019
system selector = 1
system is switched = false
system branding = avm
system branding is changeable = false
active kernel =
active filesystem =
active system version = 164.07.14
active system date = 08.11.2019, 05:46:33 Uhr
active system modification date = 09.02.2020, 01:58:07 Uhr
active system modification source = Freetz
brandings supported on active system = 1und1 avm
inactive kernel =
inactive system is installed = false
inactive filesystem =
inactive system checks skipped
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.