Wiki:help/howtos/development/firmware_update_details

Howtos: Entwicklung

  1. Entpacken und Packen von Firmware-Images
    1. Tools und Syntax
    2. Vorgehensweise
    3. Verwendung von fwmod im "no freetz"-Modus
  2. Patches in Freetz einspielen
  3. Example 3: NZBGet
    1. Build manually
    2. Add package to Freetz
    3. Create new image with added package
    4. Testing
    5. Preparing New Package for Public Integration to Freetz Trunk
  4. Example 2: par2cmdline
    1. Build manually
    2. Add package to Freetz
    3. Create new image with added package
    4. Testing
    5. Preparing New Package for Public Integration to Freetz Trunk
  5. Example 1: Httptunnel
    1. Build manually
    2. Add package to Freetz
    3. Call Procedures "make menuconfig" and "make"
    4. Testing
    5. Preparing New Package for Public Integration to Freetz Trunk
    1. Signieren von Firmware
    2. Konkrete Anwendung in Freetz
  7. Ablauf eines Firmware-Updates
  8. Eigene Programme kompilieren
  9. Dynamische Bandbreitenanzeige per SVG
    1. Anleitung zur Test-Installation
  10. Platz sparen im Dateisystem der FritzBox
    1. Vorwort und Motivation
    2. Bestandsaufnahme: Wo stecken die Platzfresser?
    3. Weitere Spartricks
    4. Schlußwort
  11. Flash-Partitionen im laufenden Betrieb sichern
    1. Motivation
    2. Voraussetzungen
    3. Lösungsweg
    4. Wege, sich schnell einen Überblick zu verschaffen
    5. Zusammenfassung
  12. Release Management
    1. Subversion Repository
    2. Checklists
    3. GIT
    4. Downloads
    5. References
  13. First steps - How to start your first freetz package
    1. Info
    2. Build Environment
    3. File Structure
    4. Examples Binary Package
    5. Configuration Handling
    6. Examples Web-Interface
    7. Trouble shooting
  14. Kernel konfigurieren und kompilieren
  15. Menükonfiguration pflegen
    1. Einstieg
    2. Beispiel-Konfiguration für ein neues Paket
    3. Menuconfig-Warnungen beheben
    4. Erklärung und Anwendung der erweiterten MK-Targets
    5. Syntax-Fehler in MK-Dateien finden
    6. Syntax-Hervorhebung für MK-Dateien
  16. ADAM2-Bootloader
    1. Bootloader-Backup anlegen
    2. Bootloader überschreiben
    3. Bootloader-Befehle
    4. Bootloader-Quelltext
    5. Aufbau des Bootloaders
    6. Bootloader und Freetz
  17. Einstellungen speichern im Urlader-Environment
    1. Vorwort und Motivation
    2. Lösungsmöglichkeiten
    3. Bootloader Environment
    4. Variable "kernel_args"
    5. Kernel_Args-API
    6. Mögliche Anwendungsfälle
  18. Busybox konfigurieren und kompilieren
  19. Wie baue ich ein eigenes Paket für Freetz?
  20. Firmware-Image-Namen analysieren und interpretieren
    1. Einleitung
    2. Skript-Code
    3. Daten im Rohformat
    4. Ausgabe grundlegender Informationen
    5. Ausgabe erweiterter Informationen
    1. Web-interface HTTPTunnel
  22. Developer Information
  23. Addon Paket installieren
  24. Paketverwaltung für Freetz
    1. Erweiterung des Dateisystems
    2. Paketverwaltung
    3. Links
    4. Kommentare
  25. Wie die FritzBox Manipulationen erkennt
    1. Ursachen
    2. Diagnose
    3. Lösungen
    4. Schlußwort und Ausblick
  26. Shell Coding Conventions
    1. Shell Language
    2. Basic Format
    3. If, For, and While
    4. Test Built-in
    5. Single-line conditional statements
    6. Infinite Loops
    7. Exit Status and If/While Statements
    8. Variable References
    9. Variable Naming
    10. Quoting
    11. Variable Assignments
    12. Testing for (Non-)Empty Strings
    13. Commenting
    14. Pathnames
    15. Interpreter Magic
  27. Package Development
    1. Persistent Package Settings
  28. Erstellen einer GUI für Pakete in Freetz
    1. Motivation
    2. Grundlagen
    3. Wie funktioniert das mit der GUI?
  29. Flash Partitionierung
    1. Hidden SquashFS
    2. Contiguous SquashFS
    3. Hidden Root
    4. NAND Root
    5. Dateisystem
    6. Kernel
    7. Weblinks
  30. Trac Hooks
    1. trac-post-commit-hook
    2. trac-post-revprop-change-hook
  31. Package Developing - Advanced Topics
    1. Adding conditional patches
    2. Adding multi-binary packages
  32. Eigene Dateien in die Firmware integrieren
    1. Feste Integration über das Freetz Image
    2. Erzeugen der Dateien aus der debug.cfg
    3. Nachladen vom Webserver
    4. Nachladen vom USB-Stick
    5. WebDAV Share mounten
    6. NFS-Share mounten
  33. Freetz Build-Prozeß
    1. Vorwort und Motivation
    2. Grundsätzliches
  34. Flash-Partitionen von außen mit FTP sichern
    1. Motivation
    2. Voraussetzungen
    3. Allgemeine Informationen zur Datensicherung
    4. Sicherung mit Linux-Standard-FTP (ftp)
    5. Sicherung mit Linux-NcFTP (ncftpget)
    6. Sicherung mit Cygwin-NcFTP (ncftpget)
    7. Uploads via FTP
  35. libmodcgi.sh
    1. cgi
    2. cgi_begin
    3. cgi_end
    4. sec_begin
    5. sec_end
    6. html
    7. check, select
    8. href
    9. back_button
    10. sec_level
    11. stat_bar
    12. cgi_param
    13. cgi_error, print_error
    14. path_info
    15. valid
  36. Cross-Compiler / Toolchain erstellen
  37. Eigene Download-Toolchain erstellen
  38. Target/Native-Compiler-Toolchain erstellen
    1. Using the dev-tools package to install compiler and tools

Ablauf eines Firmware-Updates

Bei einem Firmware-Update über das AVM-Web-Interface passiert in etwa Folgendes (kein Anspruch auf Vollständigkeit):

  • Die Steuerung des gesamten Vorgangs übernimmt das Binary /usr/www/cgi-bin/firmwarecfg. Es wird vom Webserver aufgerufen.
  • firmwarecfg ruft zunächst das Shell-Skript /bin/prepare_fwupgrade auf, um diverse Dienste zu stoppen und somit Platz im RAM für das Firmware-Archiv zu schaffen. Auch Spuren von evtl. früheren Updates in der RAM-Disk (/var) werden gelöscht. prepare_fwupgrade wird entweder mit dem Parameter start oder mit start_from_internet aufgerufen, je nachdem, ob ein Update von der AVM-Seite geladen werden soll oder von Festplatte. Der Unterschied besteht v.a. darin, daß der DSL-Daemon dsld im zweiten Fall zunächst nicht gestoppt wird.
  • Nachdem nun ein Großteil der Aktivitäten der FritzBox stillgelegt ist, wird das Firmware-Image in die RAM-Disk übertragen und dort mittels tar entpackt. Dabei wird die digitale Signatur des Pakets geprüft. Falls sie nicht korrekt verifiziert werden kann oder fehlt, wird später die bekannte Meldung über eine nicht freigegebene Firmware im Web-Interface angezeigt. Zunächst wird der Benutzer des Web-Interfaces via Rückmeldung von firmwarecfg aber einfach nur gefragt, ob er trotzdem die Firmware installieren möchte. Nehmen wir an, er bejaht das.
  • Die wichtigsten Dateien des entpackten Firmware-Archivs liegen nun unter
    • /var/install
    • /var/tmp/kernel.image
    • /var/tmp/filesystem.image
  • Die letzten beiden Dateien liegen nur vor, wenn es sich um ein "echtes" Update und nicht um ein Pseudo-Update, z.B. zum Aktivieren von Telnet oder zur Installation einer Software wie dem LCR Updater handelt. filesystem.image hat in vielen Fällen die Länge null, weil in kernel.image alle benötigten Daten fürs Flashen enthalten sind.
  • Ein zweites Mal wird /bin/prepare_fwupgrade aufgerufen, dieses Mal mit dem Parameter end. Jetzt werden endgültig die verbleibenden Dienste gestoppt, die noch während des Updates stören könnten, indem sie z.B. auf den Flash-Speicher zugreifen.
  • Jetzt wird das mit dem Firmware-Image entpackte Shell-Skript /var/install aufgerufen. Darin passiert eine ganze Menge, z.B.:
  • Es werden diverse Prüfungen durchgeführt, die bestimmen, auf welchem Stand die Box momentan ist, wie der Flash-Bereich partitioniert ist und was zu tun ist in Vorbereitung aufs Update. Je nachdem, was das Skript herausfindet über die Situation, gibt es am Ende einen der folgenden Werte zurück:
    • INSTALL_SUCCESS_NO_REBOOT (0) - alles okay, Neustart der Box nicht erforderlich. Dieser Wert sollte nur zurückgegeben werden, wenn an Dateisystem und Kernel im Flash nichts geändert wird.
    • INSTALL_SUCCESS_REBOOT = 1 - der Standardwert bei "richtigen" Firmware-Updates. Alles okay, Box neu starten.
    • INSTALL_WRONG_HARDWARE = 2 - Installation zurückweisen, weil etwas an der Hardware nicht zum Firmware-Image paßt (Problem mit dem Annex, falscher OEM).
    • INSTALL_KERNEL_CHECKSUM = 3 - fehlerhafte Kernel-Checksumme. Falls die beiden Image-Dateien (Kernel und Filesystem) existieren, werden ihre CRC-Checksummen durch Aufruf des ebenfalls in AVM-Paketen enthaltenen /var/chksum geprüft. Sind die Checksummen - nicht Verwechseln mit der o.g. Signatur - nicht in Ordnung, findet kein Update statt.
    • INSTALL_FILESYSTEM_CHECKSUM = 4 - siehe voriger Punkt.
    • INSTALL_URLADER_CHECKSUM = 5 - würde bedeuten, dass der zu installierende neue Urlader eine falsche Checksumme hat. Meistens enthalten Firmware-Updates jedoch keinen neuen Urlader.
    • INSTALL_OTHER_ERROR = 6 - sonstiger Fehler.
    • INSTALL_FIRMWARE_VERSION = 7 - Problem mit der aktuellen Firmware-Version. Entweder kann die aktuelle Version aus irgendeinem Grund nicht festgestellt werden oder der Versionssprung ist zu groß, weil noch jemand eine Uralt-Version installiert hat und zunächst ein Zwischen-Update auf eine andere Version ebötigt, um anschließend die neue einspielen zu können.
    • INSTALL_DOWNGRADE_NEEDED = 8 - es wird versucht, eine Firmware mit niedrigerer Versionsnummer zu installieren. Normalerweise blockieren aktuelle Firmwares das, weswegen man den Umweg über ein Recover bzw. einen manuellen Downgrade machen muss, um diese Hürde zu nehmen. (Man könnte auch einfach die Prüfung in diesem Skript auskommentieren.)
  • Das Skript hat auch einen Schalter -f, welcher es dazu veranlaßt, eine beliebige Firmware-Versionsnummer zu akzeptieren und somit ggf. auch einen Downgrade durchzuführen. Allerdings lässt sich der Schalter übers Web-Interface meines Wissens nicht setzen. Vermutlich wird er von den AVM-Recovery-Tools benutzt. Verbunden mit dem Setzen dieses Schalters ist, dass das gerade besprochene Install-Skript auch die Einstellungen im Flash löscht und somit die Box auf die Werkseinstellungen zurücksetzt. Grundsätzlich könnte man Letzteres durch Auskommentieren im Skript verhindern, aber es macht oft genug Sinn, es so zu lassen. Ein Downgrade bedeutet nun einmal, dass evtl. vorhandene Einstellungen für Features einer neuen Firmware-Version von einer älteren nicht richtig interpretiert werden könnten und somit schlimmstenfalls die Box schon beim Starten hängen bleiben und endgültig zum Recover-Fall werden würde.
  • Zum Schluß werden ggf. noch einige Spezialitäten abgehandelt, z.B. Entfernen veralteter Einstellungen oder Konvertierung alter Wahlregeln.
  • Das Skript schreibt während des Ablaufs parallel auch noch ein weiteres Skript nach /var/post_install, welches anschließend über init reboot indirekt vom führenden Prozeß firmwarecfg aufgerufen wird, sofern nicht einer der Fehler-Rückgabewerte dies verhindert. post_install wiederum setzt für den Flash-Vorgang notwendige Umgebungsvariablen und lädt das im Firmware-Image enthaltene Modul /var/flash_update.o (Kernel 2.4) bzw. /var/flash_update.ko (Kernel 2.6).
  • Übrigens gibt es auch standardmäßig ein /var/post_install, das beim Systemstart aus /var.tar extrahiert wird und vor jedem Reboot aufgerufen wird. Der Aufruf-Mechanismus über /etc/inittab ist der gleiche, der Inhalt des Skripts jedoch völlig anders als in der Spezialversion vor dem Flashen.
  • Jetzt erfolgt der eigentliche Flash-Vorgang (falls notwendig).

Nach dem eventuellen Reboot hat man ggf. eine nagelneue Firmware auf der Box, andernfalls die gewünschte nachinstallierte Funktionalität. Was /var/install macht und welchen Return-Wert es liefert, ist grundsätzlich für jeden Firmware-Bastler frei entscheidbar. Die anderen Rahmenbedingungen sind so, wie ich es eben beschrieben habe.

​Alexander Kriegisch (kriegaex)