summaryrefslogtreecommitdiff
path: root/ubi-utils/README
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-01-23 19:42:44 +0200
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-01-23 20:01:03 +0200
commit45941c0018cc0937beeb9d4aa8e6a6070c7a3466 (patch)
treee65cad8bac744151b047136e9643abf1e343dd97 /ubi-utils/README
parent3ad29ab55ad71d706152781b70a43d9f6be407b9 (diff)
ubi-utils: return old tools
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'ubi-utils/README')
-rw-r--r--ubi-utils/README146
1 files changed, 0 insertions, 146 deletions
diff --git a/ubi-utils/README b/ubi-utils/README
deleted file mode 100644
index 5c7f9db..0000000
--- a/ubi-utils/README
+++ /dev/null
@@ -1,146 +0,0 @@
-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
-ubimkvol - UBI volume creation utility
-ubirmvol - UBI volume removal utility
-ubiupdatevol - UBI volume update utility
-
-
-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.