-
Die Erfindung betrifft ein Verfahren zum effizienten Ablegen von Daten in einem physikalischen Datenspeicher nach der im Oberbegriff von Anspruch 1 näher definierten Art.
-
Beim Ablegen von Daten in einem physikalischen Datenspeicher werden die einzelnen Daten in Form von Seiten oder Segmenten, welche nachfolgend als Datenteile bezeichnet werden, in verschiedenen Bereichen des physikalischen Speichers abgelegt. Soll nun beispielsweise eine Software in einem Flash-Speicher ein Update erhalten, so ist es typischerweise notwendig, bei einer laufenden Softwareversion A die neue Softwareversion B in den Speicher zu installieren, um dann beispielsweise beim nächsten Systemstart mit der neuen Softwareversion B starten zu können. In der Praxis ist deshalb immer ein physikalischer Speicher notwendig, welcher die Größe der beiden Softwareversionen A und B aufweist, da diese zumindest phasenweise parallel auf dem physikalischen Speicher installiert sein müssen.
-
Für die Übertragung der Daten auf den Speicher gibt es Methoden zur Steigerung der Effizienz. So ist es beispielsweise in der
US 2011/0173604 A1 beschrieben, dass lediglich die Differenz zwischen zwei Softwareversionen, also die Datenteile, in denen sich die beiden Versionen unterscheiden, entsprechend übertragen werden müssen, da die Teile, in welchen die Software gleich ist, bereits in dem Speicher vorhanden sind und entsprechend verschoben oder kopiert werden können.
-
Fener beschreiben auch der Fachartikel „Xia, W.; Jiang, H.;Feng, D.: A COMPREHENSIVE STUDY OF THE PAST, PRESENT AND THE FUTURE OF DATA DEDUPLICATION.; In. Proceedings of the IEEE, Vol. 104, No. 9, September 2016, S. 1681-1710“ und das Patent
US 9,898,225 B2 die sogenannte Daten Deduplication.
-
Zum weiteren allgemeinen Stand der Technik kann in diesem Zusammenhang außerdem auf die
US 9,946,533 B2 verwiesen werden.
-
Die Aufgabe der hier vorliegenden Erfindung besteht nun darin, ein Verfahren zum effizienten Ablegen von Daten in einem physikalischen Datenspeicher anzugeben, bei welchem eine sehr gute Nutzung des vorhandenen Speicherplatzes möglich ist.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1, und hier insbesondere im kennzeichnenden Teil des Anspruchs 1, gelöst.
-
Vergleichbar wie im eingangs genannten Stand der Technik werden neue Daten mit zuvor bereits abgelegten alten Daten verglichen, um nicht übereinstimmende Datenteile des Vergleichs zu dem Datenspeicher zu übertragen und abzulegen. Auf eine Übertragung identischer Datenteile kann also verzichtet werden.
-
Erfindungsgemäß ist es nun so, dass die in dem Datenspeicher abgelegten Daten über eine Speicherverwaltungseinheit, eine sogenannte MMU (Memory Management Unit) so adressiert werden, dass die neuen Daten und die alten Daten gemeinsame Datenteile, welche also sowohl in den alten als auch in den neuen Daten übereinstimmen, an demselben physikalischen Speicherort nutzen. Die MMU zeigt einem den physikalischen Speicher nutzenden System, z.B. eine Prozessor, dann ein entsprechendes Abbild der jeweiligen Daten, beispielsweise einer ausführbaren Software, an, welches dem erwartenden Datenaufbau entspricht. Tatsächlich kann sich das Abbild jedoch aus einer Mischung aus neuen Daten und alten Daten ergeben, welche durch die MMU quasi in das erwartete Abbild übersetzt wird. Dabei liegen identische Datenteile an demselben physikalischen Speicherort vor und sind damit in dem Speicher nur einmal vorhanden. Damit wird es nun möglich, den Speicherplatz sehr effizient zu nutzen, da verschiedene Abbilder über die MMU auf die jeweils selben gemeinsamen Datenteile gemeinsam zugreifen können.
-
Das erfindungsgemäße Verfahren lässt sich insbesondere für Softwareupdates in einem Flash-Speicher effizient nutzen. Es lässt sich prinzipiell jedoch auch auf alle anderen Arten von Daten, welche zumindest teilweise übereinstimmende Datenteile aufweisen, übertragen und auf allen beliebigen Arten von Speichern, also beispielsweise auch Festplatten oder dergleichen, anwenden. Ungeachtet dessen erfolgen die Erläuterungen und Beschreibungen des erfindungsgemäßen Verfahrens nun primär auf Basis des Beispiels von Softwareupdates in Flash-Speichern.
-
Durch die erfindungsgemäße gemeinsame Nutzung von identischen Datenteilen an demselben physikalischen Speicherort, was durch die MMU entsprechend verwaltet wird, ist es nun möglich, zwei Versionen einer Software gleichzeitig auf einem Flash-Speicher zu installieren und zu betreiben, auch wenn dieser Flash-Speicher mit einer Version der Software bereits zu mehr als der Hälfte voll ist. So kann beispielsweise ein Flash-Speicher mit 32 GBit eine Softwareversion A mit 20 GBit und eine Softwareversion B mit 21 GBit beinhalten, welche beide lauffähig sind, da sie gemeinsame Datenteile gemeinsam nutzen und so in der Summe eben nicht 41 GBit an Speicherplatz benötigen, sondern beispielsweise nur 31 GBit. Hierdurch entsteht ein ganz entscheidender Vorteil bezüglich des Speicherplatzes, was sich insbesondere bei Flash-Speichern in auf einem Chip integrierten Systemen, sogenannten SoCs, als entscheidender Vorteil darstellt.
-
Die Datenteile können dabei insbesondere Seiten oder Segmente umfassen. Die aktuelle Überlegung mit Seiten beinhaltet einen Aufbau des sogenannten Softwareimages aus mehreren Seiten. Diese lassen sich dann vor dem Aufspielen eines Softwareupdates oder ganz allgemein neuer Daten miteinander vergleichen. Identische Seiten werden dann eben nicht nochmals mit übertragen, was Übertragungsbandbreite einspart, und werden nicht nochmals gespeichert, sondern von mehreren Images gemeinsam genutzt, was den oben beschriebenen Effekt der außerordentlich effizienten Ausnutzung des physikalischen Speichers mit Hilfe der MMU ermöglicht. Die Seiten werden dabei in ihrer Größe anhand der Hardwarekomponenten entsprechend festgelegt, wobei typische Seitengrößen in der Praxis zwischen 4 kBit und 64 MBit liegen.
-
Alternativ dazu kann ein Datenteil auch durch ein sogenanntes Datensegment gebildet sein. Solche Datensegmente, wie sie vor allem bei älteren Systemen bekannt und üblich sind, können in diesem Zusammenhang dynamisch anhand der Dateninhalte in ihrer Größe angepasst werden. Das Verfahren ermöglicht damit eine größere Flexibilität, da beispielsweise mehrere aufeinanderfolgende identische Seiten in einem alten und einem neuen Image zu einem Datensegment zusammengefasst werden können, was dann hinsichtlich des Handlings in der MMU einfacher wird, beim Erstellen des entsprechenden Datenpakets zum Aufspielen des neuen Images jedoch geringfügig mehr Aufwand verursacht.
-
Die MMU selbst kann dabei gemäß einer sehr vorteilhaften Weiterbildung der Idee als Software ausgebildet sein. Eine solche Softwarelösung für die MMU ist prinzipiell immer denkbar und möglich und ist damit weitgehend unabhängig von dem System. Dies kann, vor allem bezüglich der Flexibilität der Systeme, ein entscheidender Vorteil sein. Die Integration kann dabei bevorzugt in die Software eines SoCs erfolgen.
-
Alternativ dazu wäre es auch denkbar, die MMU in die Hardware zu integrieren. Eine solche Integration in die Hardware ist schnell und effizient. Als eine Möglichkeit ließe sich hierzu die MMU beim Einsatz eines NAND-Flash-Speichers einfach in den Hardwarecontroller des NAND-Speichers integrieren. Dies ist entsprechend einfach und effizient. Bei anderen Speichertypen wie beispielsweise NOR-Speichern müsste die MMU dann durch ein initiales Booten softwareseitig initialisiert werden. Wie erwähnt lässt sie sich alternativ dazu auch gänzlich als Softwaresystem ausbauen.
-
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich auch aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die Figuren und anhand des Beispiels von Softwareupdates in einem Flash-Speicher näher dargestellt ist.
-
Dabei zeigen:
- 1 eine schematische Übersicht über die beteiligten Komponenten;
- 2 eine schematische Ansicht der entsprechenden Abbilder verschiedener Softwareversionen zu verschiedenen Zeitpunkten und der im Flash-Speicher tatsächlich vorliegenden Daten; und
- 3 ein exemplarischer Systemaufbau.
-
Das Ziel eines Verfahrens zur effizienten Nutzung von vorhandenem physikalischem Speicher ist es, ein sofortiges Umschalten zwischen verschiedenen Daten, insbesondere Softwareversionen, zu bieten und gleichzeitig eine Speicherüberbelegung zu realisieren, indem Datenteile, beispielsweise Seiten oder Segmente, gemeinsam genutzt werden. Das Verfahren kann beispielsweise für ein Fahrzeugsteuersystem eingesetzt werden. In den Steuersystemen sollen dabei Softwareupdates im Hintergrund ermöglicht werden. Dabei soll es möglich sein, einen Softwarestand zu haben, welcher mehr als 50 Prozent des vorhandenen Speichers benutzt, wobei dennoch ein Update und ein erneuter Start des Systems mit der neuen Software möglich sein soll. Dabei sollen so wenig Daten wie möglich übertragen und geschrieben werden müssen, um das System schlank und schnell zu machen.
-
Gegeben ist nun beispielsweise ein Softwareimage A und ein Softwareimage B, welches als Update des Softwareimages A fungiert. Sowohl das Image A als auch das Image B sind so kompiliert und/oder gebaut, dass Gleichteile möglichst an der gleichen Stelle innerhalb des jeweiligen Images stehen. Das geht beispielsweise dadurch, dass, wenn das Image A ein File-System ist, nur neue Dateien geschrieben werden, oder ein Bindelader (Linker), bei der Anordnung der Teile auch die Teile des jeweils alten Image entsprechend berücksichtigt und Dinge, die an die bisherige Position gemäß des alten Image nicht passen, an das Ende des neuen Softwareimages anhängt. Der Linker produziert dann einen von der Position unabhängigen Code und entsprechende Einstiegspunkte für die Funktionen der Software, welche beispielsweise über eine Jump-Tabelle am Ende des Images angesprungen werden können.
-
In der Darstellung der 1 sind die beiden beispielhaften Softwareimages A, B durch die beiden mit A und B bezeichneten Blöcke links unten in einem Build-System entsprechend dargestellt. Diese werden nun, wie es durch die Pfeile angedeutet ist, verarbeitet, um über ein mit DIFF bezeichnetes Differenztool aus den beiden Images einen Datenstrom zu erzeugen, der dann später an das Ziel, beispielsweise ein in der Darstellung der 1 rechts einer gestrichelten Linie dargestelltes Steuergerät ECU übertragen werden soll. Der Softwaredownload wird dann entsprechend auf diesem ECU-System ausgeführt und der Datenstrom wird entsprechend interpretiert. Das ECU-System kann dabei als System auf einem Chip (SoC) ausgebildet sein. Es umfasst eine Speicherverwaltungseinheit MMU, die zwischen dem physikalischen Speicher 1, z.B. einem Flash-Speicher, einerseits und dem vom Prozess genutzten Abbild der jeweiligen Softwareimages andererseits angeordnet ist. Dies lässt sich beispielsweise für XIP (Execute In Place) Code für einen NOR-Flash anwenden, was in 1 mit der Box 2 angedeutet ist. Für einen NAND-Flash wird die Übersetzung entweder in der Firmware des NAND-Controllers durch den Host festgelegt (Box 3) oder, wenn es hier keinen Hardwaresupport gibt, wird die MMU als eine Software-Übersetzungs-Schicht, gemäß der Box 4, eingezogen.
-
In der Darstellung der 1 gelangt die Software nun aus dem links unten dargestellten Build-System zu einem darüber angeordneten Test-System mit einem Tester TEST und dann in das eigentliche ECU-System auf der rechten Seite der Darstellung. In einer mit DIAG bezeichneten Box erfolgt eine Diagnose. Der eigentlichen Softwaredownload wird von der mit 5 bezeichneten Box dann an die nächste Ebene weitergegeben. Hier kann entweder softwareseitig eine Software-Flash Übersetzung 4 oder hardwareseitig eine NAND-Flash Übersetzung 3 bzw. eine hardwareimplementierte MMU 2 vorhanden sein. Die MMU kommuniziert dann entsprechend mit dem eigentlichen als Hardware realisierten Flash-Speicher 1, welcher beispielsweise als NAND, als NOR oder auch als eine Kombination dieser beiden Typen von Flash-Speicher ausgebildet sein kann. Innerhalb des Flash-Speichers ist in der Box A dann der bisherige Inhalt des Flash-Speichers, nämlich das Softwareimage A, entsprechend abgelegt.
-
Die einzelnen Datenteile, welche dabei verarbeitet werden, können beispielsweise Seiten mit einer fest auf die Hardware angepassten Seitengröße sein. Genausgut können dynamische Segmente als Datenteile dienen, welche bei der Ausbildung der Softwareupdates entsprechend ihrer Unterschiede gefiltert und verarbeitet werden.
-
In der Darstellung der 2 sind nun in vier Spalten vier verschiedene Versionen bzw. Zeitpunkte der Software dargestellt, wobei oben das Abbild der jeweiligen Software, wie es der Prozessor es sieht, und darunter die tatsächliche physikalische Ablage in dem physikalischen Speicher 1 des Flashs gezeigt ist. Dazwischen ist durch die Doppelpfeile die MMU angedeutet.
-
In der ganz linken Spalte ist das Softwareimage A zu erkennen, bei welchem das aktuelle Abbild und der Inhalt des Flash-Speichers 1 einander entsprechen. Gegenüber vorherigen Versionen sind hier bereits das Basisimage (querschraffiert) und verschiedene Unterschiede, welche hier mit Delta a, Delta b, Delta c beschrieben sind, vorhanden. Der freie Speicher des Flashs 1 ist dabei kreuzschraffiert dargestellt. Das Softwareimage B in der Spalte rechts daneben unterscheidet sich nun dadurch, dass der bisherige Unterschied Delta b weitergenutzt wird, die Unterschiede Delta a und Delta c nicht. Dafür kommen weitere Unterschiede Delta 1, Delta 2 und Delta 3 bei dem neuen Softwareimage B zum Tragen. Über das Build-System wird nun dafür gesorgt, dass lediglich die Inhalte Delta 1, Delta 2 und Delta 3 beim Softwareupdate übertragen werden müssen zusammen mit der Information, dass Delta b weiterverwendet wird und Delta a und Delta c entsprechend entfallen. Wird das neue Softwareimage B nun in den Flash-Speicher geschrieben, dann hängt die MMU diese Unterschiede Delta 1, Delta 2 und Delta 3 an den bisherigen Inhalt an, sodass diese in den freien Speicher geschrieben werden. Der Prozessor sieht nun das in der oberen Zeile dargestellte Abbild B, während im Flash-Speicher 1 tatsächlich die entsprechenden Seiten bzw. Datenteile an unterschiedlichen Stellen angeordnet sind.
-
Das Softwareimage A mit seinen drei Unterschieden gegenüber einem eventuellen vorherigen Softwareimage kann beispielsweise eine Größe von 20 GByte umfassen und kann nun zusätzlich zu der Softwareversion B mit einem Umfang von beispielsweise 21 GByte in den in Summe nur 32 GByte großen Flash-Speicher 1 geschrieben werden, da die gemeinsamen Inhalte wie das Grundsoftwareimage A, welches hier schraffiert angedeutet ist, sowie der verbleibende Unterschied Delta b nun von den beiden Softwareversionen Ab, B gemeinsam genutzt werden. Zu diesem Zeitpunkt liegen dann beide Softwareimages vor, sodass wahlweise entweder mit der Version A oder der Version B gearbeitet werden kann.
-
Kommt nun ein weiteres Softwareupdate C zum Tragen, dann kann in einem hier mit B' bezeichneten Zustand, welcher in der dritten Spalte von links entsprechend dargestellt ist, der Bereich für Delta a und Delta c entsprechend freigegeben werden, sodass in dem Flash-Speicher nun neue freie Bereiche entstehen, weil davon ausgegangen werden kann, dass nach der Installation des Softwareupdates C die Softwareversion A nicht mehr verwendet werden muss. Prinzipiell ließen sich auch hier die Unterschiede weiterhin unten anhängen, sodass frühere Versionen nur dann überschrieben werden, wenn ansonsten kein Speicherplatz mehr zur Verfügung steht, sodass dann jeweils mit jedem neuen Update die ältesten noch vorhandenen Unterschiede überschreiben werden würden.
-
Hier ist es nun so, dass der Unterschied zwischen der Version B und der Version C darin besteht, dass ein neuer Unterschied Delta x hinzukommt und der bisherige Unterschied Delta 3 nicht mehr genutzt wird. Die MMU schreibt nun den Unterschied Delta x in den durch das Löschen des Unterschieds Delta a freigewordenen Bereich und markiert seinerseits wieder den Unterschied Delta 3 als für die aktuelle Version nicht mehr notwendig, sodass dieser bei Bedarf an zusätzlichem Speicherplatz, beispielsweise bei einem weiteren Update, entsprechend gelöscht werden kann.
-
Zu dem in den Spalten A, B dargestellten Zeitpunkt lassen sich dann die beiden zusammen 41 GByte großen Softwareversionen in dem 32 GByte großen Flash-Speicher entsprechend ablegen und parallel nutzen, sodass hier eine sehr effiziente Nutzung des Speichers mit einer Überbelegung möglich wird, da ja virtuell Softwareversionen mit mehr als 40 GByte in dem nur 32 GByte großen Speicher liegen. Zu dem in den beiden rechten Spalten dargestellten Zeitpunkten B' und C gilt dann vergleichbares für die Softwareversionen B und C, wobei der Unterschied Delta x an eine der freigewordenen Stellen geschrieben wird.
-
Bei allen Softwareupdates ist dabei nur ein minimaler Aufwand bezüglich der Übertragung von Daten und des Schreibens von neuen Daten notwendig. Dies macht das System einfach und schnell und erlaubt es außerdem, den Speicher außerordentlich effizient durch eine Überbelegung zu nutzen. Das Differenztool DIF erzeugt dazu einen Datenstrom, der anschließend in einem Testsystem, wie es in der Darstellung der 1 zu erkennen ist, und dann über ein Diagnoseinterface DIAG zur Softwaredownloadkomponente 5 gesendet wird. Die Softwaredownloadkomponente 5 nutzt nun mindestens einen der Flash-Transition-Layer 2, 3, 4 der MMU zum Zugriff auf den eigentlichen Flash-Speicher 1. Auch die restliche Software des Prozessors greift durch den gleichen Flash-Transition-Layer 2, 3, 4 auf den Flash 1 zu und sieht dementsprechend das Image, so wie es im Original ursprünglich erzeugt worden ist, bevor es über das Differenztool DIFF lief.
-
Zum Erstellen des Datenstrom in dem Differenztool DIFF werden die längsten gemeinsamen Datenteile wie z.B. Sub-Sequenzen, pro Byte für das neue Abbild berechnet. Dieses Problem kann mit verschiedenen bekannten Problemen in O(n2log(n)) berechnet werden. Als Nebenprodukt ist dann für jedes Byte bekannt, wo die längste Sequenz in den Original-Daten existiert. Als weitere Optimierung wird das neue Image schrittweise verarbeitet und Teile des neuen Images in jedem Schritt auch als „altes“ Image betrachtet - dies ermöglicht, dass auch Verweise auf das neue Image bis zu diesem Punkt erzeugt werden können. Die Erstellung der Daten durch das Differenztool DIFF unterscheidet sich je nachdem ob das Zielsystem, z.B. die ECU gemäß 1 die MMU (Memory Management Unit) im SoC oder im NAND besitzt oder ob per Software Segmentweise der Flash 1 abgebildet wird.
-
Zunächst wird beschrieben, wenn das ECU eine MMU besitzt.
-
Es wird nun für das Input Image und Output Image jeweils je Seite eine zyklische Redundanzprüfung (CRC) berechnet. Bei Datenteilen, z.B. Seiten, die eine gleiche CRC haben werden die Seiten verglichen, um sicher zu stellen, dass sie wirklich gleich sind. Für diese gleichen neuen Seiten wird vermerkt, in welchen alten Seiten die Inhalte gefunden werden können. Es wird in diesem Schritt auch geprüft ob genügend freie Seiten im Flash 1 vorhanden sind, d.h. die Summe der gleichen Seiten, der alten ungleichen Seiten und der neuen ungleichen Seiten muss kleiner oder maximal gleich der Seiten des Flashs 1 sein.
-
Wenn nicht genügend freie Seiten vorhanden sind, muss klassisch ein Bootloader verwendet werden, der noch zusätzlich im Flash 1 liegt und das neue Image in den Flash schreibt. In diesem Fall wird das Image einfach komprimiert übertragen und herkömmlich installiert. Ansonsten wird für die die restlichen Seiten berechnet, wo für welche Byte Sequenz die längste gleiche Byte Sequenz im Original Image gefunden wird. Dabei werden Sequenzen, die kürzer als etwa 20 Byte sind verworfen und die Bytes als neu markiert, um das Differenz-Image nicht zu kleinteilig werden zu lassen.
-
Es wird nun in einem weiteren Schritt die Kommandos kodiert, die das Zielsystem ausführen muss, wofür Seite für Seite des neuen Images abgearbeitet wird. Die Kommandos sind durchnummeriert und werden in dem jeweiligen Fall erzeugt und entsprechend der Anweisung vom Zielsystem durch Speicher Mapping Operation der (MMU) und Schreiboperationen in den Flash 1 ausgeführt. Die MMU Konfiguration wird im Target persistent in einer oder mehreren Seiten des Flashs 1 gespeichert. Die Zuordnung kann anstatt in der MMU auch in Software des SoC implementiert werden oder in der Firmware von NAND Flashs oder als NAND-Flash ausgebildeten Teilen des Flashs 1.
- 1. Neue Seite ist gleich einer alten Seite:
- Operation: map(oldPage, newPage)
- Ausgabe 1 <32bit oldPage> <neue virtuelle Seitennummer>
- 2. Neue Seite ist nicht gleich
- Operation: allocatePage
- Ausgabe 0 <neue virtuelle Seitennummer>
- a. Sequenz gleicher Daten Ausgabe 0, offset im alten Image bzw. schon geschriebenen Seiten, Länge
- b. Sequenz neuer Daten Ausgabe 1, 16 Bit Zahl, Länge neuer Daten, die neuen Daten
-
Der Kommandostrom wird dann blockweise - wie es für die Datenübertragung passend ist, an einer Seitengrenze jeweils komprimiert, mit z.B. Izma oder einem anderen verlustfreien Kompressionsverfahren. Jedes dieser Blöcke wird mit einer Signatur versehen. Bei jeder Blockgrenze kann das Programmierverfahren wieder aufgesetzt werden. Durch die virtuellen Seitennummern ist bekannt, an welcher Stelle weitergeschrieben werden muss.
-
Im Zielsystem, hier der ECU, wird der Kommandostrom zunächst dekomprimiert. Dann werden entsprechend dem Kommandostrom
- • Seiten gemapped
- • Seien allokiert und neu geschrieben
- o mit Daten der vorhandenen Seiten
- o mit neuen Daten
-
Dabei entsteht für das neue Image eine neue Mapping Tabelle. Wird nun das System gebootet bzw. greift ein Datei-System darauf zu dann kann aufgrund der MMU in einer der oben schon beschriebenen Ausgestaltungen 2, 3, 4 das Abbild so wie von der Software erwartet gelesen werden. Seiten des alten Images, die nicht mehr vom neuen Image referenziert werden, können gesucht werden und wenn das alte Image gelöscht werden soll, werden diese nicht mehr referenzierten Seiten als frei markiert, wie oben beschreiben und in 2 durch die gestrichelten Schriftzüge Delta a, Delta c in der zweiten Spalte von links und Delta 3 in der ganz rechten Spalte angedeutet.
-
3 zeigt einen exemplarischen Systemaufbau. Links oben sind wieder die beiden Images A und B dargestellt. Daneben findet sich die CPU und darunter die MMU. Unter diesen ist der wieder mit 1 bezeichnete Flash-Speicher zu erkennen. Er kann als NOR-Flash, als NAND-Flash oder als Kombination hiervon ausgebildet sein. Die MMU kann z.B. bei einem NAND-Flash Teil dieses Flashs 1 sein, wie es mit der strichpunktierten Linie angedeutet ist. Daneben könnte die MMU auch Teil des SoCs mit der CPU sein, was durch die gestrichelte Linie symbolisiert ist. Der Flash 1 selbst umfasst dann die unterhalb desselben dargestellten Inhalte. Die mit 6 bezeichnete Box kann einen Bootloader darstellen. Die beiden mit 7 und 8 bezeichneten Boxen stellen die Seiten des neuen und des alten Images B, A dar, welche natürlich in einer sich von der Anordnung in dem jeweiligen Image abweichenden Reihenfolge in dem Flash 1 befinden können, wie erläutert. Die mit 9 bezeichnete Box umfasst das Mapping der Seiten, z.B. in einer Tabelle. Die mit 10 bezeichnete Box soll weitere Inhalte des Flashs 1 versinnbildlichen, die für das hier gezeigte Verfahren jedoch nicht weiter relevant sind, die aber typischerweise in dem Flash 1 vorliegen.
