Allgemeines
Wir erinnern uns an Beitrag #8 (Erläuterung Dual-Boot System der FRITZ!Box):
qwertz-asdfgh hat geschrieben: ↑26. Okt 2017 03:14
Das hat (mindestens) 2 große Vorteile:
- Geht beim Update- bzw. Flashvorgang etwas schief (z.B. Stromausfall) dann wird nicht die aktuell laufende Firmware überschrieben sondern die nicht aktive im anderen Partitionsset (erst am Ende des Updatevorgang wird das inaktive Partitionsset aktiv gesetzt).
- Man kann in einem Partitionsset eine Firmwareversion ausprobieren ohne die funktionierende Firmware im anderen Partitionsset zu überschreiben. Man kann nur durch Umstellen einer Variable wieder die andere/vorhergehende Firmwareversion verwenden.
Genau das machen wir uns auch zu nutze, wir installieren die Retail-Version in das aktuell
nicht genutzte Partitionsset um die derzeit laufende Firmware-Version zu behalten (um im Notfall wieder auf diese zurückkehren zu können). Dazu müssen wir natürlich wissen, welches Partitionsset aktuell aktiv ist, daher wurde im 3. Schritt die Variable "linux_fs_start" ausgelesen. Ist der Wert dieser Variable aktuell z.B. 1 dann setzen wir diesen Wert am Ende (vor dem Reboot) auf 0 (und umgekehrt).
Zu beachten ist allerdings, dass jedes Partitionsset aus 4 Partitionen besteht (insgesamt gibt es also 8 Partitionen für die Firmware)!
Die FRITZ!Box 6490 verwendet einen SoC mit 2 (unabhängigen) Prozessoren (nicht mit einem DualCore-System zu verwechseln), einem ARM-Core und einem ATOM-Core (x86), für jeden dieser Prozessoren gibt es 2 Filesysteme, einmal für den Linux-Kernel und einmal für das Filesystem, macht insgesamt also 4 Partitionen pro Partitionsset die beschrieben werden müssen.
1. Partitionen aus Sicht des Bootloader (EVA)
Zu beachten ist, dass die Zuordnung
nicht fest sondern von der Variable "linux_fs_start" abhängig ist, diese wird vom Bootloader beim Starten ausgewertet (Details s.h. u.a. >
hier< von PeterPawn).
Code: Alles auswählen
mtd0 0x0,0x4000000 Filesystem ARM
mtd1 0x4000000,0x4800000 Kernel ARM
mtd2 0xa0000,0xc0000 Urlader
mtd3 0xc0000,0x100000 Environment
mtd4 0x100000,0x140000 Environment
mtd5 0x140000,0x1e0000 DOCSIS
mtd6 0x4800000,0x8800000 Filesystem ATOM
mtd7 0x8800000,0x9000000 Kernel ATOM
mtd8 0x0,0x80000 cefdk
mtd9 0x80000,0x90000 cefdk_config
mtd10 0x90000,0xa0000 GPT_Backup
mtd11 0x9000000,0xd000000 Filesystem ARM (reserved)
mtd12 0xd000000,0xd800000 Kernel ARM (reserverd)
mtd13 0xd800000,0x11800000 Filesystem ATOM (reserved)
mtd14 0x11800000,0x12000000 Kernel ATOM (reserved)
Firmware-Partitionen des aktiven Partitionsset:
- mtd0 = Filesystem ARM-Core
- mtd1 = Kernel ARM-Core
- mtd6 = Filesystem ATOM-Core
- mtd7 = Kernel ATOM-Core
Firmware-Partitionen des
inaktiven Partitionsset:
- mtd11 = Filesystem ARM-Core
- mtd12 = Kernel ARM-Core
- mtd13 = Filesystem ATOM-Core
- mtd14 = Kernel ATOM-Core
Wie schon geschrieben, die Zuordnung ist nicht fest, bei beispielsweise:
- aktuell linux_fs_start=0 wird das inaktive Partitionsset (mtd11, 12, 13 und 14) erst mit linux_fs_start=1 aktiviert (wird damit zu mtd0, 1, 6 und 7 im Bootloader) und bei
- aktuell linux_fs_start=1 wird das inaktive Partitionsset (mtd11, 12, 13 und 14) erst mit linux_fs_start=0 aktiviert (wird damit zu mtd0, 1, 6 und 7 im Bootloader).
Der Bootloader startet also immer die beiden Systeme (ARM und x86) von den Partitionen mtd1 und mtd7, die Variable
linux_fs_start beeinflusst also lediglich welche Partitionen der Bootloader darunter versteht.
Im laufenden FRITZ!OS-System sieht das anders aus, dort ist die Zuweisung der Partitionen dagegen wieder fest (zum Beispiel
/dev/mmcblk0p5 bleibt auch
/dev/mmcblk0p5, unabhängig vom eingestellten Wert der Variable linux_fs_start)!
Da wir die Variable "linux_fs_start" bis jetzt nicht geändert haben (nur ausgelesen) ist die bisher aktive Firmware in den Partitionen mtd0, mtd1, mtd6 und mtd7 zu finden. Damit man also das aktuell
inaktive Partitionsset überschreibt verwendet man also die Partitionen mtd11, mtd12, mtd13 und mtd14.
Wenn man die Variable "linux_fs_start" im laufenden Betrieb (Bootloader) ändert wird m.W.n. die Zuordnung der Partitionen nicht (Live) geändert, dazu müsste m.W.n. erst die Box bzw. der Bootloader neu gestartet werden.
Wenn man das gerade aktive Partitionsset überschreiben möchte verwendet man bei den entsprechenden Befehlen (unten Pkt. 4.1e bzw. 4.2a-d) anstatt mtd11 > mtd0, mtd12 > mtd1, mtd13 > mtd6 und mt14 > mtd7. Das kann evtl. sinnvoll sein, s.h. dazu zum Beispiel der Hinweis in Beitrag #9.
2. Firmware-Images für den ARM- und ATOM-Core vorbereiten
Zuerst wird das im 1. Schritt (Beitrag #8) heruntergeladene Retail Firmware-Image entpackt um die 4 Images (2 für jeden Prozessor) zu erhalten, unter Windows kann man dazu z.B. das Programm
7-Zip verwenden.
Man benötigt die Image-Dateien die sich in den Unterordnern
und
befinden.
Als Beispiel (Windows) legen wir uns einen Ordner "6490" auf Laufwerk C: an mit den beiden Unterordnern ARM und x86.
Das kann man natürlich auch mit dem Datei-Explorer machen, je nachdem wie es einem beliebt. Und natürlich ist das nur ein Beispiel, man kann die Ordner auch an einer anderen (geeigneten) Stellen im Dateisystem erstellen (z.B. c:\Users\[Username]\Downloads\6490\...]), man muss dann nur die Befehle entsprechend anpassen. Wer z.B. eine Linux-Distribution nutzt sucht sich natürlich eine entsprechend geeignete Stelle, z.B. "/home/
username/Downloads/6490/...".
In den Ordner "c:\6490\
ARM" kopieren wir die Dateien
"filesystem.image" und
"kernel.image" aus dem Ordner "...\var\remote\var\
tmp"
In den Ordner "c:\6490\
x86" kopieren wir die Dateien
"filesystem.image" und
"kernel.image" aus dem Ordner "...\var\remote\var\tmp\
x86"
Bitte beachten, die Dateien dürfen nicht durcheinandergebracht werden, die aus dem Unterordner "x86" sind für den ATOM-Core und die aus Ordner "tmp" für den ARM-Core!
Wer möchte kann die Dateien auch umbenennen und anschließend in einen gemeinsamen Ordner (z.B. c:\6490) kopieren/verschieben, z.B. in:
- arm-filesystem.image
- arm-kernel.image
- atom-filesystem.image (filesystem.image aus dem Unterorner x86)
- atom-kernel.image (kernel.image aus dem Unterorner x86)
dann braucht man nicht in der FTP-Sitzung mit "lcd" den Ordner wechseln. Die Befehle mit "put" sind dann natürlich entsprechend anzupassen.
3. Geeigneten FTP-Client verwenden/installieren
Der Standard Windows FTP-Client (ftp.exe), welcher im 2. und 3. Schritt noch ohne Probleme verwendet werden konnte, kann für das Hochladen der Firmware-Images
nicht mehr verwendet werden da er den "Passive Mode" nicht unterstützt der dafür benötigt wird!
Alternativen:
- Bei den 64-Bit Versionen (x64) von Windows 10 (seit Ver. 1709 aka "Fall Creators Update" offiziell) kann ein "Linux-Subsystem" installiert werden:
https://msdn.microsoft.com/de-de/comman ... tall_guide
Damit ist dann auch die Nutzung des unter *nix-Systemen bekannten Kommandozeilen-Programm "ftp" möglich welches den passive Mode unterstützt. Oder evtl. auch die Shell-Scripte "eva_discover" und "eva_store_tffs" von PeterPawn:
https://www.ip-phone-forum.de/threads/292912/
- Die Nutzung eines anderen FTP-Client unter Windows wie z.B. NcFTP Client oder lftp für Windows.
- Wer MacOS X, BSD oder Linux verwendet (z.B. auch in einer VM) kann "ftp" verwenden.
- Man verwendet unter Windows das PowerShell-Script "EVA-FTP-Client.ps1" von Peter Pawn, siehe Pkt. 4.1 (Variante 2)
Da ich selbst nicht (primär) mit Windows arbeite habe ich dbzgl. allerdings nicht viel Erfahrung, für Tipps/Hinweise zu einem geeigneten FTP-Client wäre ich also dankbar.
4. Mit dem Bootloader verbinden und Firmware hochladen
4.1 - Variante 1 (per FTP-Client mit dem Bootloader verbinden und Firmware hochladen)
Ich gehe mal von der Verwendung des FTP-Client NcFTP unter Windows aus, bei Verbindungsproblemen an eine evtl. aktive (Personal)-Firewall denken:
- Command-Line/Eingabeaufforderung starten.
- In das bei Pkt. 2 (Firmware-Images für den ARM- und ATOM-Core vorbereiten) angelegte Verzeichnis wechseln, also z.B.:
- Mit dem Bootloader (EVA) der FRITZ!Box verbinden (s.h. Beitrag #10):
So sieht das dann aus:
Code: Alles auswählen
c:\6490>ncftp -u adam2 -p adam2 192.168.178.1
NcFTP 3.2.6 (Nov 15, 2016) by Mike Gleason (http://www.NcFTP.com/contact/).
Resolving 192.168.178.1...
Connecting to 192.168.178.1...
ADAM2 FTP Server ready
Logging in...
User adam2 successfully logged in
Logging in...
Command not implemented
Command not implemented
Command not implemented
Logged in to 192.168.178.1.
ncftp / >
- Nun folgende Befehle eingeben um u.a. den Passive-Mode zu aktivieren:
Das sieht dann so aus:
Code: Alles auswählen
ncftp / > quote MEDIA FLSH
Media set to MEDIA_FLASH
ncftp / > binary
ncftp / > passive
passive on
ncftp / >
- Nun kann man mit dem übertragen der Firmware-Images beginnen. Wenn man die ARM und x86 Images in den jeweiligen Unterordnern belassen hat wechseln man zuerst mit "lcd" in das jeweilige Verzeichnis:
Wenn man dabei die Fehlermeldung "No such file or directory" bekommt war der Wechsel in das entsprechende Verzeichnis nicht erfolgreich (in dem Fall kontrollieren ob man sich evtl. vertippt hat oder den Order woanders angelegt hat!):
Code: Alles auswählen
ncftp / > lcd c:\6490\ARM
c:\6490\ARM: No such file or directory
Nun die beiden ARM-Images in das alternative Partitionsset hochladen (die Option "-z" ist bei Einsatz von NcFTP notwendig, bei z.B. Verwendung des *nix FTP-Client ist diese Option wegzulassen):
Code: Alles auswählen
put -z filesystem.image mtd11
put -z kernel.image mtd12
Per "lcd" in den "x86-Ordner" wechseln (falls die Images in den jeweiligen Unterordnern belassen wurden):
Die beiden ATOM-Images in das alternative Partitionsset hochladen (die Option "-z" ist bei Einsatz von NcFTP notwendig, bei z.B. Verwendung des *nix FTP-Client ist diese Option wegzulassen):
Code: Alles auswählen
put -z filesystem.image mtd13
put -z kernel.image mtd14
- Das Ergebnis sollte ungefähr so aussehen:
Code: Alles auswählen
ncftp / > lcd c:\6490\ARM
ncftp / > put -z filesystem.image mtd11
c:\6490\ARM\filesystem.image:
ncftp / > put -z kernel.image mtd12
c:\6490\ARM\kernel.image:
ncftp / > lcd c:\6490\x86
ncftp / > put -z filesystem.image mtd13
c:\6490\x86\filesystem.image:
ncftp / > put -z kernel.image mtd14
c:\6490\x86\kernel.image:
ncftp / >
- Nun wird das inaktive Partitionsset aktiviert, im 3. Schritt (Beitrag #11) wurde dazu mit GETENV die Variable "linux_fs_start" ausgelesen, man kann das jetzt auch noch einmal machen:
Code: Alles auswählen
ncftp / > quote GETENV linux_fs_start
Invalid reply: "linux_fs_start 1"
ncftp / >
In diesem Beispiel ist der Wert 1. Das bedeutet, das aktuell das 2. Partitionsset aktiv ist und der Wert mit SETENV auf 0 gesetzt werden soll:
Ergebnis:
Code: Alles auswählen
ncftp / > quote SETENV linux_fs_start 0
SETENV command successful
ncftp / >
Das kann auch noch einmal mit GETENV kontrolliert werden:
Code: Alles auswählen
ncftp / > quote GETENV linux_fs_start
Invalid reply: "linux_fs_start 0"
ncftp / >
(Wenn der Wert der Variable "linux_fs_start" vorher 0 ist wird natürlich auf den Wert 1 umgestellt, der Befehl ist entsprechend anzupassen!)
- Zum Schluss kann die FRITZ!Box mit folgendem Befehl rebootet
und mit "bye" die FTP-Sitzung beendet werden:
Das wars:
Code: Alles auswählen
ncftp / > quote REBOOT
Thank you for using the FTP service on ADAM2
ncftp / > bye
c:\6490>
4.2 - Variante 2 (per PowerShell-Script mit dem Bootloader verbinden und Firmware hochladen, für Windows)
Ich gehe davon aus, dass die PowerShell-Konsole aus dem vorherigen Schritt noch offen ist (wenn nicht s.h. Beitrag #10 - 2. Schritt, Pkt. 4.1 und 4.2), bei Verbindungsproblemen an eine evtl. aktive (Personal)-Firewall denken:
- Flashen der Partition mtd11 (ARM Filesystem) mit folgendem Kommando:
Code: Alles auswählen
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\ARM\filesystem.image mtd11 }
- Flashen der Partition mtd12 (ARM Kernel) mit folgendem Kommando:
Code: Alles auswählen
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\ARM\kernel.image mtd12 }
- Flashen der Partition mtd13 (x86/ATOM Filesystem) mit folgendem Kommando:
Code: Alles auswählen
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\x86\filesystem.image mtd13 }
- Flashen der Partition mtd14 (x86/ATOM Kernel) mit folgendem Kommando:
Code: Alles auswählen
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\x86\kernel.image mtd14 }
- Nun wird das inaktive Partitionsset aktiviert, im 3. Schritt (Beitrag #11) wurde dazu mit GETENV die Variable "linux_fs_start" ausgelesen. Man kann das allerdings auch automatisch vom Script "EVA-FTP-Client.ps1" machen lassen z.B. mit folgendem Kommando:
Code: Alles auswählen
.\EVA-FTP-Client.ps1 -Verbose -ScriptBlock { SwitchSystem }
In diesem Beispiel ist der aktuelle Wert 1. Das bedeutet, das Script setzt den Wert auf 0, das sieht dann so aus:
Code: Alles auswählen
PS C:\6490> .\EVA-FTP-Client.ps1 -Verbose -ScriptBlock { SwitchSystem }
AUSFÜHRLICH: current setting - linux_fs_start=1
AUSFÜHRLICH: new setting - linux_fs_start=0
AUSFÜHRLICH: new value set successfully
True
PS C:\6490>
(Wenn der Wert der Variable "linux_fs_start" vorher 0 ist wird natürlich auf den Wert 1 umgestellt.)
- Zum Schluss kann die FRITZ!Box mit folgendem Befehl rebootet werden:
Das wars:
Code: Alles auswählen
PS C:\6490> .\EVA-FTP-Client.ps1 -ScriptBlock { RebootTheDevice }
True
PS C:\6490> exit