diff options
Diffstat (limited to 'ubi-utils/old-tools/README')
| -rw-r--r-- | ubi-utils/old-tools/README | 155 |
1 files changed, 0 insertions, 155 deletions
diff --git a/ubi-utils/old-tools/README b/ubi-utils/old-tools/README deleted file mode 100644 index 39ed0e9..0000000 --- a/ubi-utils/old-tools/README +++ /dev/null @@ -1,155 +0,0 @@ -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. |