u-boot: Update yaffs2 file system

This patch updates the yaffs2 in u-boot to correspond to
git://www.aleph1.co.uk/yaffs2
commit id 9ee5d0643e559568dbe62215f76e0a7bd5a63d93

Signed-off-by: Charles Manning <cdhmanning@gmail.com>

1 files changed, 0 insertions, 201 deletions

diff --git a/fs/yaffs2/README-linux b/fs/yaffs2/README-linux
deleted file mode 100644
index 3851e36..0000000
--- a/fs/yaffs2/README-linux
+++ /dev/null
@@ -1,201 +0,0 @@
-Welcome to YAFFS, the first file system developed specifically for NAND flash.
-
-It is now YAFFS2 - original YAFFS (AYFFS1) only supports 512-byte page
-NAND and is now deprectated. YAFFS2 supports 512b page in 'YAFFS1
-compatibility' mode (CONFIG_YAFFS_YAFFS1) and 2K or larger page NAND
-in YAFFS2 mode (CONFIG_YAFFS_YAFFS2).
-
-
-A note on licencing
--------------------
-YAFFS is available under the GPL and via alternative licensing
-arrangements with Aleph One. If you're using YAFFS as a Linux kernel
-file system then it will be under the GPL. For use in other situations
-you should discuss licensing issues with Aleph One.
-
-
-Terminology
------------
-Page -  NAND addressable unit (normally 512b or 2Kbyte size) - can
-	be read, written, marked bad. Has associated OOB.
-Block - Eraseable unit. 64 Pages. (128K on 2K NAND, 32K on 512b NAND)
-OOB -   'spare area' of each page for ECC, bad block marked and YAFFS
-	tags. 16 bytes per 512b - 64 bytes for 2K page size.
-Chunk - Basic YAFFS addressable unit. Same size as Page.
-Object - YAFFS Object: File, Directory, Link, Device etc.
-
-YAFFS design
-------------
-
-YAFFS is a log-structured filesystem. It is designed particularly for
-NAND (as opposed to NOR) flash, to be flash-friendly, robust due to
-journalling, and to have low RAM and boot time overheads. File data is
-stored in 'chunks'. Chunks are the same size as NAND pages. Each page
-is marked with file id and chunk number. These marking 'tags' are
-stored in the OOB (or 'spare') region of the flash. The chunk number
-is determined by dividing the file position by the chunk size. Each
-chunk has a number of valid bytes, which equals the page size for all
-except the last chunk in a file.
-
-File 'headers' are stored as the first page in a file, marked as a
-different type to data pages. The same mechanism is used to store
-directories, device files, links etc. The first page describes which
-type of object it is.
-
-YAFFS2 never re-writes a page, because the spec of NAND chips does not
-allow it. (YAFFS1 used to mark a block 'deleted' in the OOB). Deletion
-is managed by moving deleted objects to the special, hidden 'unlinked'
-directory. These records are preserved until all the pages containing
-the object have been erased (We know when this happen by keeping a
-count of chunks remaining on the system for each object - when it
-reaches zero the object really is gone).
-
-When data in a file is overwritten, the relevant chunks are replaced
-by writing new pages to flash containing the new data but the same
-tags.
-
-Pages are also marked with a short (2 bit) serial number that
-increments each time the page at this position is incremented. The
-reason for this is that if power loss/crash/other act of demonic
-forces happens before the replaced page is marked as discarded, it is
-possible to have two pages with the same tags. The serial number is
-used to arbitrate.
-
-A block containing only discarded pages (termed a dirty block) is an
-obvious candidate for garbage collection. Otherwise valid pages can be
-copied off a block thus rendering the whole block discarded and ready
-for garbage collection.
-
-In theory you don't need to hold the file structure in RAM... you
-could just scan the whole flash looking for pages when you need them.
-In practice though you'd want better file access times than that! The
-mechanism proposed here is to have a list of __u16 page addresses
-associated with each file. Since there are 2^18 pages in a 128MB NAND,
-a __u16 is insufficient to uniquely identify a page but is does
-identify a group of 4 pages - a small enough region to search
-exhaustively. This mechanism is clearly expandable to larger NAND
-devices - within reason. The RAM overhead with this approach is approx
-2 bytes per page - 512kB of RAM for a whole 128MB NAND.
-
-Boot-time scanning to build the file structure lists only requires
-one pass reading NAND. If proper shutdowns happen the current RAM
-summary of the filesystem status is saved to flash, called
-'checkpointing'. This saves re-scanning the flash on startup, and gives
-huge boot/mount time savings.
-
-YAFFS regenerates its state by 'replaying the tape'  - i.e. by
-scanning the chunks in their allocation order (i.e. block sequence ID
-order), which is usually different form the media block order. Each
-block is still only read once - starting from the end of the media and
-working back.
-
-YAFFS tags in YAFFS1 mode:
-
-18-bit Object ID (2^18 files, i.e. > 260,000 files). File id 0- is not
-       valid and indicates a deleted page. File od 0x3ffff is also not valid.
-       Synonymous with inode.
-2-bit  serial number
-20-bit Chunk ID within file. Limit of 2^20 chunks/pages per file (i.e.
-       > 500MB max file size). Chunk ID 0 is the file header for the file.
-10-bit counter of the number of bytes used in the page.
-12 bit ECC on tags
-
-YAFFS tags in YAFFS2 mode:
-  4 bytes 32-bit chunk ID
-  4 bytes 32-bit object ID
-  2 bytes Number of data bytes in this chunk
-  4 bytes Sequence number for this block
-  3 bytes ECC on tags
- 12 bytes ECC on data (3 bytes per 256 bytes of data)
-
-
-Page allocation and garbage collection
-
-Pages are allocated sequentially from the currently selected block.
-When all the pages in the block are filled, another clean block is
-selected for allocation. At least two or three clean blocks are
-reserved for garbage collection purposes. If there are insufficient
-clean blocks available, then a dirty block ( ie one containing only
-discarded pages) is erased to free it up as a clean block. If no dirty
-blocks are available, then the dirtiest block is selected for garbage
-collection.
-
-Garbage collection is performed by copying the valid data pages into
-new data pages thus rendering all the pages in this block dirty and
-freeing it up for erasure. I also like the idea of selecting a block
-at random some small percentage of the time - thus reducing the chance
-of wear differences.
-
-YAFFS is single-threaded. Garbage-collection is done as a parasitic
-task of writing data. So each time some data is written, a bit of
-pending garbage collection is done. More pages are garbage-collected
-when free space is tight.
-
-
-Flash writing
-
-YAFFS only ever writes each page once, complying with the requirements
-of the most restricitve NAND devices.
-
-Wear levelling
-
-This comes as a side-effect of the block-allocation strategy. Data is
-always written on the next free block, so they are all used equally.
-Blocks containing data that is written but never erased will not get
-back into the free list, so wear is levelled over only blocks which
-are free or become free, not blocks which never change.
-
-
-
-Some helpful info
------------------
-
-Formatting a YAFFS device is simply done by erasing it.
-
-Making an initial filesystem can be tricky because YAFFS uses the OOB
-and thus the bytes that get written depend on the YAFFS data (tags),
-and the ECC bytes and bad block markers which are dictated by the
-hardware and/or the MTD subsystem. The data layout also depends on the
-device page size (512b or 2K). Because YAFFS is only responsible for
-some of the OOB data, generating a filesystem offline requires
-detailed knowledge of what the other parts (MTD and NAND
-driver/hardware) are going to do.
-
-To make a YAFFS filesystem you have 3 options:
-
-1) Boot the system with an empty NAND device mounted as YAFFS and copy
-   stuff on.
-
-2) Make a filesystem image offline, then boot the system and use
-   MTDutils to write an image to flash.
-
-3) Make a filesystem image offline and use some tool like a bootloader to
-   write it to flash.
-
-Option 1 avoids a lot of issues because all the parts
-(YAFFS/MTD/hardware) all take care of their own bits and (if you have
-put things together properly) it will 'just work'. YAFFS just needs to
-know how many bytes of the OOB it can use. However sometimes it is not
-practical.
-
-Option 2 lets MTD/hardware take care of the ECC so the filesystem
-image just had to know which bytes to use for YAFFS Tags.
-
-Option 3 is hardest as the image creator needs to know exactly what
-ECC bytes, endianness and algorithm to use as well as which bytes are
-available to YAFFS.
-
-mkyaffs2image creates an image suitable for option 3 for the
-particular case of yaffs2 on 2K page NAND with default MTD layout.
-
-mkyaffsimage creates an equivalent image for 512b page NAND (i.e.
-yaffs1 format).
-
-Bootloaders
------------
-
-A bootloader using YAFFS needs to know how MTD is laying out the OOB
-so that it can skip bad blocks.
-
-YAFFS Tracing
--------------