Welche Änderungen werden am Code-Segment vorgenommen, wenn Unternehmen Softwareupdates bereitstellen?

Question

Ich habe darüber nachgedacht, wie, wenn ich meine Zieltafel programmiere, die PROGRAMMER die Zieltafel basierend auf den in der ausführbaren Datei vorhandenen Informationen programmiert, was meiner Meinung nach durch das Linkerskript erfolgt, die verschiedenen Dateien verbindet und Informationen von .init erzeugt, .text, .data, .fini, usw.

Ich frage mich, wenn zum Beispiel Apple ein iOS-Update ausgibt, das zum Beispiel 100MB groß ist, hat dieses Update seine eigenen Variablen - globale statische const, initialisiert, nicht initialisiert usw. Dies würde zu einer neuen Speicherzuordnung führen. Also, wenn dieses Update installiert auf dem Prozessor von einem iPhone dann wie funktioniert das? Gibt es noch zusätzlichen Speicher im .init, .text, .data, usw. Abschnitt des Betriebssystemcodes für solche zukünftigen Updates?

PS: Ich könnte einige technische Fehler in meiner Beschreibung oben gemacht haben, werde ich alle Bearbeitungen, um es zu schätzen wissen

Answer 1

Die Antwort auf Ihre Frage ist ziemlich einfach, ehrlich zu sein. Ihre primäre Frage lautet: "Woher bekommen Sie den Speicher für zukünftige Software-Updates?" Die Antwort ist der DRAM des Systems. Im ersten Teil Ihrer Frage sprechen Sie über Bare-Metal-Programmierung. Ihr zweiter Teil der Frage betrifft die Programmierung auf Betriebssystemebene. Für den ersten Teil setzen Sie den Prozessor grundsätzlich in den isp-Modus und programmieren den Flash oder anderen NV-Speicher. Im zweiten Teil ist die Funktionsweise völlig anders.

Grundsätzlich, (abgespeckte Mechanismus) ist Ihr Update in Teile unterteilt: Bootloader, Kernel, Initramfs, Firmware, Anwendung. Sie übertragen zuerst den Code (gebündeltes Paket) mit einem Protokoll wie say ftp auf das Gerät. Diese Übertragung setzt den Code wirklich auf den DRAM des Systems. Dann haben Sie auf Ihrem System (Linux-Beispiel) Code (Logik), um diesen Code zu dekomprimieren und Integritätsprüfungen (Prüfsumme von Dateien) durchzuführen. Dann hat das System weiteren Code, um all diese Komponenten zu analysieren und festzustellen, ob irgendwelche der vorhandenen Komponenten eine Aktualisierung benötigen (überprüfen Sie die MD5-Summe der eingehenden Komponente und vergleichen Sie sie mit der vorhandenen). Beispiel: Wenn Sie Änderungen an den Init-Skripten des Kernels vorgenommen haben oder ein neues Skript in der init.d wollen, haben Sie grundsätzlich die initramfs geändert. Also der Code auf dem System sieht dies und bestimmt, dass ich ein Update auf dem initramfs brauche.

Auch das ultimative Ziel für den neuen Code ist der Blitz. Da Flash bestimmte Regeln hat, denen Sie folgen müssen, um Schreib- und Löschvorgänge durchzuführen, mounten Sie grundsätzlich ein Flash-Dateisystem auf dem Flash. Aber Sie können das nicht verwenden, um Code darauf zu brennen, da Dateisysteme wie jffs2 Wear-Leveling-Mechanismen verwenden und die Daten daher im physischen Flash verstreut sind (mit jffs2 darauf). Dies ist übrigens inakzeptabel, weil Sie Ihren kompletten Bootloader, Kernel, initramfs usw. an zusammenhängenden Speicherorten im Flash haben wollen. In unserem Beispielsystem, auf dem Linux läuft, haben Sie also einen sogenannten mtd-Treiber. Sie können diesen Treiber verwenden, um den Flash mit allen Komponenten zu programmieren. Lange Rede, kurzer Sinn, der DRAM ist der Zwischenort für Software-Updates. Sie müssen also einen von zwei sicherstellen. 1. Sie haben genügend Speicher 2. Ihr Software-Update-Bundle passt in den DRAM.