1 files changed, 155 insertions, 0 deletions
diff --git a/ubi-utils/old-tools/README b/ubi-utils/old-tools/README
new file mode 100644
index 0000000..39ed0e9
--- /dev/null
+++ b/ubi-utils/old-tools/README
@@ -0,0 +1,155 @@
+This directory contains old UBI tools which I cannot maintain
+because they are too messy and vague for me and the original authors
+do not seem to have much time for them. Some of the utilities are
+just not of general interest because they are oriented to specific
+tasks of the guys from IBM.
+
+But the "unubi" utility must be very useful but it fails when I
+try to feed an image to it, so it should be looked at and fixed,
+then moved to the main "main" place.
+
+Artem Bityutskiy
+
+README
+======
+
+The programs and libraries in this directory provide a tool-chain to
+generate binary data for embedded systems which can be flashed either
+by a hardware flash programmer, e.g. JTAG debugger, or on the target
+system directly using pfiflash, or ubimkvol, ubirmvol, ubiupdatevol.
+
+The latter is the case when there is already Linux running which has
+build in UBI support.
+
+Authors: Oliver Lohmann
+         Frank Haverkamp
+	 Andreas Arnez
+	 Artem Bityutskiy
+
+mkpfi           - tool for flash content generation in PFI
+                  format
+pfi2bin         - conversion tool to transfer a PFI file into a
+                  binary image
+pfiflash        - tool to update the embedded systems flash using
+                  pfi files created by mkpfi
+libbootenv      - library for boot-parameter processing
+libpfi          - library for partial flash image (PFI) creation
+                  and handling
+ubigen          - tool to create binary UBI images e.g. for a
+                  jtag flashing tool
+nandimg         - tool to add OOB data to binary images intended
+                  for NAND flash systems
+ubilib          - UBI library
+
+
+The following text is from original UBI announcement
+====================================================
+
+UBI - Unsorted Block Images
+
+UBI (Latin: "where?") manages multiple logical volumes on a single
+flash device, specifically supporting NAND flash devices. UBI provides
+a flexible partitioning concept which still allows for wear-levelling
+across the whole flash device.
+
+In a sense, UBI may be compared to the Logical Volume Manager
+(LVM). Whereas LVM maps logical sector numbers to physical HDD sector
+numbers, UBI maps logical eraseblocks to physical eraseblocks.
+
+More information may be found in the UBI design documentation:
+ubidesign.pdf. Which can be found here:
+http://www.linux-mtd.infradead.org/doc/ubi.html
+
+Partitioning/Re-partitioning
+
+  An UBI volume occupies a certain number of erase blocks. This is
+  limited by a configured maximum volume size, which could also be
+  viewed as the partition size. Each individual UBI volume's size can
+  be changed independently of the other UBI volumes, provided that the
+  sum of all volume sizes doesn't exceed a certain limit.
+
+  UBI supports dynamic volumes and static volumes. Static volumes are
+  read-only and their contents are protected by CRC check sums.
+
+Bad eraseblocks handling
+
+  UBI transparently handles bad eraseblocks. When a physical
+  eraseblock becomes bad, it is substituted by a good physical
+  eraseblock, and the user does not even notice this.
+
+Scrubbing
+
+  On a NAND flash bit flips can occur on any write operation,
+  sometimes also on read. If bit flips persist on the device, at first
+  they can still be corrected by ECC, but once they accumulate,
+  correction will become impossible. Thus it is best to actively scrub
+  the affected eraseblock, by first copying it to a free eraseblock
+  and then erasing the original. The UBI layer performs this type of
+  scrubbing under the covers, transparently to the UBI volume users.
+
+Erase Counts
+
+  UBI maintains an erase count header per eraseblock. This frees
+  higher-level layers (like file systems) from doing this and allows
+  for centralized erase count management instead. The erase counts are
+  used by the wear-levelling algorithm in the UBI layer. The algorithm
+  itself is exchangeable.
+
+Booting from NAND
+
+  For booting directly from NAND flash the hardware must at least be
+  capable of fetching and executing a small portion of the NAND
+  flash. Some NAND flash controllers have this kind of support. They
+  usually limit the window to a few kilobytes in erase block 0. This
+  "initial program loader" (IPL) must then contain sufficient logic to
+  load and execute the next boot phase.
+
+  Due to bad eraseblocks, which may be randomly scattered over the
+  flash device, it is problematic to store the "secondary program
+  loader" (SPL) statically. Also, due to bit-flips it may become
+  corrupted over time. UBI allows to solve this problem gracefully by
+  storing the SPL in a small static UBI volume.
+
+UBI volumes vs. static partitions
+
+  UBI volumes are still very similar to static MTD partitions:
+
+    * both consist of eraseblocks (logical eraseblocks in case of UBI
+      volumes, and physical eraseblocks in case of static partitions;
+    * both support three basic operations - read, write, erase.
+
+  But UBI volumes have the following advantages over traditional
+  static MTD partitions:
+
+    * there are no eraseblock wear-leveling constraints in case of UBI
+      volumes, so the user should not care about this;
+    * there are no bit-flips and bad eraseblocks in case of UBI volumes.
+
+  So, UBI volumes may be considered as flash devices with relaxed
+  restrictions.
+
+Where can it be found?
+
+  Documentation, kernel code and applications can be found in the MTD
+  gits.
+
+What are the applications for?
+
+  The applications help to create binary flash images for two
+  purposes: pfi files (partial flash images) for in-system update of
+  UBI volumes, and plain binary images, with or without OOB data in
+  case of NAND, for a manufacturing step. Furthermore some tools
+  are/and will be created that allow flash content analysis after a
+  system has crashed.
+
+Who did UBI?
+
+  The original ideas, where UBI is based on, were developed by Andreas
+  Arnez, Frank Haverkamp and Thomas Gleixner. Josh W. Boyer and
+  some others were involved too. The implementation of the kernel
+  layer was done by Artem B. Bityutskiy. The user-space applications
+  and tools were written by Oliver Lohmann with contributions from
+  Frank Haverkamp, Andreas Arnez, and Artem. Joern Engel contributed a
+  patch which modifies JFFS2 so that it can be run on a UBI
+  volume. Thomas Gleixner did modifications to the NAND layer and also
+  some to JFFS2 to make it work.