Flash-memory: Extend presentations and handout

Extend presentations and handouts for MTD, UBI and Flashfilesystems.
Add ECC, YAFFS2, Fastmap and other items.

Signed-off-by: Holger Dengler <dengler@linutronix.de>

24 files changed, 477 insertions, 21 deletions

diff --git a/flash-memory/flash-filesystems/pres_flashfilesystems_en.tex b/flash-memory/flash-filesystems/pres_flashfilesystems_en.tex
index 718965d..1f027ef 100644
--- a/flash-memory/flash-filesystems/pres_flashfilesystems_en.tex
+++ b/flash-memory/flash-filesystems/pres_flashfilesystems_en.tex
@@ -87,6 +87,21 @@ root=/dev/mtdblock0 rootfstype=jffs2
 \end{verbatim}
 \end{frame}
 
+\subsubsection{yaffs}
+\begin{frame}
+\frametitle{yaffs - yet another flash file system}
+\begin{itemize}
+\item fast
+\item log-structured FS
+\item not in mainline kernel
+\item portable to other Operating Systems
+\item yaffs1 for small FLASH sizes
+\item yaffs2 for large FLASH sizes
+\item either use existing ECC or built-in ECC
+\item wear-leveling as side-effect
+\end{itemize}
+\end{frame}
+
 \subsubsection{UBI and UBIFS}
 \begin{frame}
 \frametitle{UBI: Unsorted Block Images}
@@ -98,6 +113,22 @@ root=/dev/mtdblock0 rootfstype=jffs2
 
 \begin{frame}
 \frametitle{UBIFS}
+\begin{itemize}
+\item journaling FS
+\item mainline since 2.6.27
+\item exploiting features of MTD and UBI
+\item scalability
+\item fast mount
+\item write-back support
+\item fast I/O
+\item tolerance to unclean reboots
+\item on-the-flight compression
+\item integrity
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBIFS}
 \begin{figure}[h]
 \centering
 \includegraphics[width=8cm]{images/ubifs.png}
diff --git a/flash-memory/mtd/pres_mtd_en.tex b/flash-memory/mtd/pres_mtd_en.tex
index 398a591..9cf294b 100644
--- a/flash-memory/mtd/pres_mtd_en.tex
+++ b/flash-memory/mtd/pres_mtd_en.tex
@@ -72,4 +72,111 @@
 \end{itemize}
 \end{frame}
 
+\subsubsection{MTD Error Correction}
+
+\begin{frame}
+\frametitle{Kernel Support}
+\begin{itemize}
+\item Software ECC
+\begin{itemize}
+\item single bitflips (Hamming code) \\ 3 byte ECC per 256/512 byte
+\item multiple bitflips (BCH code) \\ e.g. 7 byte ECC per 512 byte (4 bitflips)
+\end{itemize}
+\item Hardware ECC
+\begin{itemize}
+\item depends on NAND Hardware capabilities
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC variations}
+\begin{beamerboxesrounded}[shadow=true]{Software ECC}
+\begin{itemize}
+\item full flexibility
+\item performance on small CPUs
+\end{itemize}~\\
+\begin{figure}[h]
+\centering
+\includegraphics[scale=0.5]{images/nand_ecc_sw.png}
+\end{figure}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC variations}
+\begin{beamerboxesrounded}[shadow=true]{Hardware-assisted ECC}
+\begin{itemize}
+\item restricted to HW Algorithms
+\item good performance on small CPUs
+\end{itemize}~\\
+\begin{figure}[h]
+\centering
+\includegraphics[scale=0.5]{images/nand_ecc_hw_part.png}
+\end{figure}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC variations}
+\begin{beamerboxesrounded}[shadow=true]{Hardware ECC}
+\begin{itemize}
+\item restricted to HW Algorithms
+\item good performance on small CPUs
+\item transparent usage
+\item different layout requirements
+\end{itemize}~\\
+\begin{figure}[h]
+\centering
+\includegraphics[scale=0.5]{images/nand_ecc_hw_full.png}
+\end{figure}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC Layout}
+Software ECC
+\begin{itemize}
+\item read data in one step and store ECC in OOB area
+\end{itemize}
+\begin{beamerboxesrounded}[shadow=true]{Software ECC Layout}
+\begin{figure}[h]
+\centering
+\includegraphics[scale=0.5]{images/mtd_ecc_sw.png}
+\end{figure}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC Layout}
+Full Hardware ECC
+\begin{itemize}
+\item read data in chunks and store ECC aligned
+\item bad block marker in OOB are no longer usable
+\item requires badblock table (BBT)
+\end{itemize}
+\begin{beamerboxesrounded}[shadow=true]{Hardware ECC Layout}
+\begin{figure}[h]
+\centering
+\includegraphics[scale=0.5]{images/mtd_ecc_hw.png}
+\end{figure}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{ECC pitfalls}
+\begin{itemize}
+\item bootloader:
+\begin{itemize}
+\item algorithm
+\item layout
+\end{itemize}
+\item runtime:
+\begin{itemize}
+\item periodical reads of all UBI partitions
+\item UBI copy PEBs with bitflips to new PEBs
+\end{itemize}
+\end{itemize}
+\end{frame}
+
 \input{tailpres}
diff --git a/flash-memory/ubi/handout_ubi_de.tex b/flash-memory/ubi/handout_ubi_de.tex
index 15f0f8d..e8402aa 100644
--- a/flash-memory/ubi/handout_ubi_de.tex
+++ b/flash-memory/ubi/handout_ubi_de.tex
@@ -30,12 +30,12 @@ beim Wear-Leveling, das UBI ebenfalls durchführt. Ebenso können defekte
 Eraseblöcke durch andere Blöcke ersetzt werden.
 
 Durch den von UBI verwendeten Algorithmus ist es selbst beim Neuanlegen
-eines Volumes kaum vorhersagbar, welche physikalischen Eraseblöcke auf
-dem Flash es belegt. Während eine MTD-Partition immer in denselben
+eines Volumes kaum vorhersagbar, welche physikalischen Eraseblöcke es auf
+dem Flash belegt. Während eine MTD-Partition immer in denselben
 aufeinanderfolgenden Blöcken liegt, ändert sich die Zuordnung von
 physikalischen Eraseblöcken des Flash zu logischen Eraseblöcken des
 Volumes im laufenden Betrieb dynamisch. Ein UBI-Volume mit drei
-Eraseblöcken kann also durchaus die Blöcke 814, 27 und 1013 belegen.
+Eraseblöcken kann also durchaus die physikalischen Blöcke 814, 27 und 1013 belegen.
 
 Aus diesem Ansatz ergibt sich auch der Name \emph{Unsorted Block Images}.
 
@@ -67,7 +67,7 @@ in einem Vorgang geschrieben werden muss.
 
 Dynamische Volumes sind dafür gedacht, ein Dateisystem zu enthalten.
 Man verwendet sie also beispielsweise für ein Root-Filesystem oder für
-Volumes, die Nutzerdaten enthalten. 
+Volumes, die Nutzerdaten enthalten.
 
 Dynamische Volumes verwendet man am Besten mit dem Dateisystem ubifs.
 
@@ -85,6 +85,53 @@ gegenüber jffs2 hat, wird UBIGLUEBI in der Regel nicht mehr benötigt.
 
 \includegraphics[width=8cm]{images/ubi-big-picture.png}
 
+\paragraph{Fastmap}
+
+UBI legt in jedem Eraseblock einen Information Header an, der Metadaten wie
+z.b. die Zuordnung von physikalischem Eraseblock (PEB) zu logischem Eraseblock
+(LEB) beinhaltet. Diese Informationen müssen beim Hinzufügen eines UBI
+Devices (ubiattach) eingesammelt werden. Hierzu wird das entsprechende MDT
+Volume komplett gelesen und die Metadaten zusammengetragen. Der Aufwand für
+diesen Vorgang steigt damit linear zur Größe des Flash-Speichers.
+
+Um den Aufwand für das Zusammentragen der Metadaten beim Hinzufügen eines
+UBI Devices zu reduzieren, werden bei UBI Fastmap diese Metadaten persistent
+im Flash selbst abgelegt. Während des Vorgangs müssen dann nur noch die
+Speicherbereiche gelesen werden, in der die Metadaten abgelegt wurden. Die
+Zeitersparnis für ein Attach sinkt damit beträchtlich. Vor allem bei
+steigenden Flash Größen macht sich die Ersparnis deutlich bemerkbar.
+
+Hierzu legt UBI in den ersten 64 Eraseblocks einen Superblock an, der eine
+Referenz auf den Eraseblock enthält, in welchem die eigentliche Fastmap
+hinterlegt ist. Die Fastmap beinhaltet unter anderem statistische Informationen (belegte,
+freie und defekte PEBs), sogenannten Pools (Listen von belegten und freien
+PEBs), sowie den Metadaten der Volumes. Sowohl die Fastmap selbst, als auch
+die Pools können sich ihrerseits wiederum über mehrere verkettete PEBs
+erstrecken.
+
+Diese Referenzkette verhindert ein wear-out bestimmter Flash-Bereiche. So
+muss der Superblock nur dann schreibend modifiziert werden, wenn die
+Fastmap, z.B. Aufgrund eines Bit-Flips, in einem anderen PEB verlegt wird.
+Die Fastmap wiederum muss nur dann schreibend modifiziert werden, wenn sich
+die Lokation eines oder mehrerer Pools ändert.
+
+UBI Fastmap ist vollständig rückwärts kompatibel, d.h. ein mit UBI Fastmap
+generiertes UBI Volume ist auch mit einem älteren Kernel ohne UBI Fastmap
+problemlos verwendbar. Natürlich kommt hierbei der Geschwindigkeitszuwachs
+beim Attach nicht zum tragen. Ebenso ist es möglich ein bestehendes UBI
+Volume ohne Fastmap in ein UBI Volume mit Fastmap umzuwandeln,
+vorausgesetzt, es gibt genügend freie PEBs für das Ablegen der Fastmap.
+Ebenso ist es möglich, eine beschädigte oder unvollständige Fastmap zu
+rekonstruieren. In beiden Fällen muss dazu aber der gesamte Flashbereich des
+UBI Volumes gescannt werden. Die Geschwindigkeitsvorteile von Fastmap
+greifen dann erst wieder bei einem neuerlichen Attach (z.B. nach einem
+Reboot).
+
+UBI Fastmap ist so robust wie UBI selbst. Denn selbst wenn die Fastmap nicht
+gelesen werden kann oder wenn nicht genügend Platz auf dem UBI Volume
+vorhanden ist um die Fastmap zu speichern, so bleibt das UBI Volume trotzdem
+voll funktionsfähig.
+
 \subsubsection{UBI-Tools}
 
 Da UBI von den MTD-Entwicklern implementiert wurde, sind die UBI-Tools
diff --git a/flash-memory/ubi/pres_ubi_en.tex b/flash-memory/ubi/pres_ubi_en.tex
index fc5703f..f7f7a3b 100644
--- a/flash-memory/ubi/pres_ubi_en.tex
+++ b/flash-memory/ubi/pres_ubi_en.tex
@@ -6,34 +6,40 @@
 	\tableofcontents
 \end{frame}
 
+\subsubsection{Concepts}
+
 \begin{frame}
-\frametitle{UBI - Unsorted Block Images}
+\frametitle{UBI}
+\begin{beamerboxesrounded}[shadow=true]{Provides}
 \begin{itemize}
-\item scans list of eraseblocks
-\item generates a mapping between eraseblocks and ubi volumes
+\item Volume manager for FLASH
+\item Full device wear leveling
+\item Non-linear Logical to Physical Eraseblock mapping
+\item Bad block handling
+\item Data integrity mechanisms
 \end{itemize}
+\end{beamerboxesrounded}
 \end{frame}
 
 \begin{frame}
-\frametitle{UBI works on top of MTD}
-\includegraphics[width=8cm]{images/ubi-big-picture.png}
+\frametitle{Layers}
+\begin{beamerboxesrounded}[shadow=true]{UBI works on top of MTD}
+\includegraphics[scale=0.325]{images/ubi-big-picture.png}
+\end{beamerboxesrounded}
 \end{frame}
 
 \begin{frame}
-\frametitle{UBI Volumes}
-\begin{itemize}
-\item something like a partition in common systems
-\item but more flexible
-\item ubi exchanges eraseblocks between volumes (for bad block handling,
-wear-leveling)
-\item non-linear mapping of physical eraseblocks (peb) to logical eraseblocks
-(leb)
-\item e.g. a volume out of 3 blocks could use peb 813, 28, 1017
-\end{itemize}
+\frametitle{UBI Eraseblock mapping}
+\begin{beamerboxesrounded}[shadow=true]{Volume management}
+\begin{center}
+\includegraphics[scale=0.3]{images/ubi.png}
+\end{center}
+\end{beamerboxesrounded}
 \end{frame}
 
 \begin{frame}
-\frametitle{Volume type}
+\frametitle{UBI User interface}
+\begin{beamerboxesrounded}[shadow=true]{Volume type}
 \begin{itemize}
 \item static
 \begin{itemize}
@@ -41,12 +47,277 @@ wear-leveling)
 \item no filesystem
 \item easy readable e.g. by a bootloader
 \end{itemize}
-\pause
 \item dynamic
 \begin{itemize}
 \item used for filesystems
 \end{itemize}
 \end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\subsubsection{Flash Metadata}
+
+\begin{frame}
+\frametitle{UBI Metadata Storage}
+\begin{center}
+\includegraphics[scale=0.5]{images/ubi-block.png}
+\end{center}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI Headers}
+\begin{beamerboxesrounded}[shadow=true]{Metadata}
+\begin{itemize}
+\item Erasecount header
+\item Volume information header
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI Headers}
+\begin{beamerboxesrounded}[shadow=true]{Volume information header}
+\begin{itemize}
+\item Volume id
+\item Logical eraseblock number in volume
+\item Version counter
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI Device Scan}
+\begin{beamerboxesrounded}[shadow=true]{Metadata retrieval}
+\begin{center}
+\includegraphics[scale=0.4]{images/ubiscan.png}
+\end{center}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI}
+\begin{beamerboxesrounded}[shadow=true]{Attach time}
+\begin{itemize}
+\item O(N)
+\item Grows linear with FLASH size
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI}
+\begin{beamerboxesrounded}[shadow=true]{Attach time}
+\begin{semiverbatim}
+N  = number of eraseblocks
+
+Tp = time to read a single flash page
+
+Hp = number of header pages
+
+
+Ta = N * Tp * Hp
+\end{semiverbatim}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI attach time}
+\begin{beamerboxesrounded}[shadow=true]{Example I: NAND 64MB 1024PEBs 512B
+pagesize}
+\begin{semiverbatim}
+N  = 1024
+
+Tp = 50us
+
+Hp = 1
+
+
+Ta = 1024 * 50us * 1 = 51.2ms
+\end{semiverbatim}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI attach time}
+\begin{beamerboxesrounded}[shadow=true]{Example II: NAND 4GB 8192PEBs 4K
+pagesize}
+\begin{semiverbatim}
+N  = 8192
+
+Tp = 100us.
+
+Hp = 2
+
+
+\begin{alertenv}
+Ta = 8192 * 100us * 2 = 1.6384s
+\end{alertenv}
+\end{semiverbatim}
+\end{beamerboxesrounded}
+\end{frame}
+
+\subsubsection{UBI Fastmap}
+
+\begin{frame}
+\frametitle{UBI attach time}
+\begin{beamerboxesrounded}[shadow=true]{Can we be smarter?}
+\begin{itemize}
+\item Store metadata in a special volume
+\item but ...
+\pause
+\item Where to store metadata?
+\begin{itemize}
+\item No static storage space on NAND
+\item Metadata update needs to be rare
+\item No violation of UBI robustness
+\end{itemize}
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volume}
+\begin{beamerboxesrounded}[shadow=true]{How to find it?}
+\begin{itemize}
+\item Split into two volumes
+\begin{itemize}
+\item Reference volume
+\item Data volume
+\end{itemize}
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Reference volume}
+\begin{itemize}
+\item contains information about the metadata volume location
+\item is located within the first N physical erase blocks
+\item has to be found by scanning
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Data volume}
+\begin{itemize}
+\item contains information about all physical eraseblocks
+\item condenses UBI header data
+\end{itemize}
+\end{beamerboxesrounded}
 \end{frame}
 
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Avoid fast updates}
+\begin{itemize}
+\item by storing a pool list
+\item by scanning the erase blocks in the pool list
+\item by rewriting metadata only when pool list changes
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Pool list}
+\begin{itemize}
+\item Configurable number of erase blocks
+\item Used for current write operations
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Pool list changes}
+\begin{itemize}
+\item due to wear leveling
+\item due to client (e.g. UBIFS) requirements
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI metadata volumes}
+\begin{beamerboxesrounded}[shadow=true]{Preserve robustness}
+\begin{itemize}
+\item by preserving the UBI header semantics
+\item by fallback to full scanning mode
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{Device Scan}
+\begin{beamerboxesrounded}[shadow=true]{Attach mode scheme - w/o Fastmap}
+\begin{center}
+\includegraphics[scale=0.4]{images/ubiscan.png}
+\end{center}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{Device Scan}
+\begin{beamerboxesrounded}[shadow=true]{Attach mode scheme}
+\begin{center}
+\includegraphics[scale=0.4]{images/ubifast.png}
+\end{center}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{UBI fastmap attach time}
+\begin{beamerboxesrounded}[shadow=true]{Example I: NAND 64MB 1024PEBs 512B
+pagesize}
+\begin{itemize}
+\item 51.2ms (UBI)
+\item 17.6ms (UBI Fastmap)
+\end{itemize}
+\end{beamerboxesrounded}~\\
+\begin{beamerboxesrounded}[shadow=true]{Example II: NAND 4GB 8192PEBs 4K
+pagesize}
+\begin{itemize}
+\item 1.6384s (UBI)
+\item 96.0ms (UBI Fastmap)
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{Conclusion}
+\begin{beamerboxesrounded}[shadow=true]{Summary}
+\begin{itemize}
+\item Fastmap provides significant speedup
+\item Speedup grows with flash size
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{Future directions}
+\begin{beamerboxesrounded}[shadow=true]{Further possible optimizations}
+\begin{itemize}
+\item Compressed fastmap storage
+\item Let the bootloader hand the scan table to the kernel
+\item Implement supplementary NVRAM support
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\begin{frame}
+\frametitle{Mainline status}
+\begin{beamerboxesrounded}[shadow=true]{Code}
+\begin{itemize}
+\item Merged in Linux 3.7
+\item Sponsored by CE Linux Forum (CELF)
+\item Designed and implemented by linutronix
+\end{itemize}
+\end{beamerboxesrounded}
+\end{frame}
+
+\subsubsection{}
+
 \input{tailpres}
diff --git a/images/mtd_ecc_hw.dia b/images/mtd_ecc_hw.dia
new file mode 100644
index 0000000..976211b
--- /dev/null
+++ b/images/mtd_ecc_hw.dia
diff --git a/images/mtd_ecc_hw.png b/images/mtd_ecc_hw.png
new file mode 100644
index 0000000..189d7d6
--- /dev/null
+++ b/images/mtd_ecc_hw.png
diff --git a/images/mtd_ecc_sw.dia b/images/mtd_ecc_sw.dia
new file mode 100644
index 0000000..598e5b2
--- /dev/null
+++ b/images/mtd_ecc_sw.dia
diff --git a/images/mtd_ecc_sw.png b/images/mtd_ecc_sw.png
new file mode 100644
index 0000000..00b0724
--- /dev/null
+++ b/images/mtd_ecc_sw.png
diff --git a/images/nand_ecc_hw_full.dia b/images/nand_ecc_hw_full.dia
new file mode 100644
index 0000000..5a39fb9
--- /dev/null
+++ b/images/nand_ecc_hw_full.dia
diff --git a/images/nand_ecc_hw_full.png b/images/nand_ecc_hw_full.png
new file mode 100644
index 0000000..fd81261
--- /dev/null
+++ b/images/nand_ecc_hw_full.png
diff --git a/images/nand_ecc_hw_part.dia b/images/nand_ecc_hw_part.dia
new file mode 100644
index 0000000..bad0c6c
--- /dev/null
+++ b/images/nand_ecc_hw_part.dia
diff --git a/images/nand_ecc_hw_part.png b/images/nand_ecc_hw_part.png
new file mode 100644
index 0000000..3a2fa3f
--- /dev/null
+++ b/images/nand_ecc_hw_part.png
diff --git a/images/nand_ecc_sw.dia b/images/nand_ecc_sw.dia
new file mode 100644
index 0000000..1026590
--- /dev/null
+++ b/images/nand_ecc_sw.dia
diff --git a/images/nand_ecc_sw.png b/images/nand_ecc_sw.png
new file mode 100644
index 0000000..0041567
--- /dev/null
+++ b/images/nand_ecc_sw.png
diff --git a/images/ubi-big-picture.dia b/images/ubi-big-picture.dia
index 57a6fa5..8f205d4 100644
--- a/images/ubi-big-picture.dia
+++ b/images/ubi-big-picture.dia
diff --git a/images/ubi-big-picture.png b/images/ubi-big-picture.png
index c980e36..3670260 100644
--- a/images/ubi-big-picture.png
+++ b/images/ubi-big-picture.png
diff --git a/images/ubi-block.dia b/images/ubi-block.dia
new file mode 100644
index 0000000..11ecd80
--- /dev/null
+++ b/images/ubi-block.dia
diff --git a/images/ubi-block.png b/images/ubi-block.png
new file mode 100644
index 0000000..4037d0f
--- /dev/null
+++ b/images/ubi-block.png
diff --git a/images/ubi.dia b/images/ubi.dia
index 35eb9aa..04dc389 100644
--- a/images/ubi.dia
+++ b/images/ubi.dia
diff --git a/images/ubi.png b/images/ubi.png
index 0575579..90a58c1 100644
--- a/images/ubi.png
+++ b/images/ubi.png
diff --git a/images/ubifast.dia b/images/ubifast.dia
new file mode 100644
index 0000000..e55ac65
--- /dev/null
+++ b/images/ubifast.dia
diff --git a/images/ubifast.png b/images/ubifast.png
new file mode 100644
index 0000000..aa8bb4c
--- /dev/null
+++ b/images/ubifast.png
diff --git a/images/ubiscan.dia b/images/ubiscan.dia
new file mode 100644
index 0000000..8fc4914
--- /dev/null
+++ b/images/ubiscan.dia
diff --git a/images/ubiscan.png b/images/ubiscan.png
new file mode 100644
index 0000000..995264c
--- /dev/null
+++ b/images/ubiscan.png