Commit Graph

26 Commits

Author SHA1 Message Date
Adrian Bunk
59018b6d2a MTD/JFFS2: remove CVS keywords
Once upon a time, the MTD repository was using CVS.

This patch therefore removes all usages of the no longer updated CVS
keywords from the MTD code.

This also includes code that printed them to the user.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-06-04 17:50:17 +01:00
Justin Treon
e619a75ff6 [MTD] Unlocking all Intel flash that is locked on power up.
Patch for unlocking all Intel flash that has instant locking on power up.
The patch has been tested on Intel M18, P30 and J3D Strata Flash.
  1.    The automatic unlocking can be disabled for a particular partition
         in the map or the command line.
     a. For the bit mask in the map it should look like:
         .mask_flags   = MTD_POWERUP_LOCK,
     b. For the command line parsing it should look like:
         mtdparts=0x80000(bootloader)lk
  2.    This will only unlock parts with instant individual block locking.
         Intel parts with legacy unlocking will not be unlocked.

Signed-off-by: Justin Treon <justin_treon@yahoo.com>
Signed-off-by: Jared Hulbert <jaredeh@gmail.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 18:25:16 +11:00
Artem B. Bityutskiy
801c135ce7 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 at
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. Alexander
  Schmidt made some testing work as well as core functionality improvements.

Signed-off-by: Artem B. Bityutskiy <dedekind@linutronix.de>
Signed-off-by: Frank Haverkamp <haver@vnet.ibm.com>
2007-04-27 14:23:33 +03:00
Artem Bityutskiy
64f6071056 [MTD] remove unused ecctype,eccsize fields from struct mtd_info
Remove unused and broken mtd->ecctype and mtd->eccsize fields
from struct mtd_info. Do not remove them from userspace API
data structures (don't want to breake userspace) but mark them
as obsolete by a comment. Any userspace program which uses them
should be half-broken anyway, so this is more about saving
data structure size.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-02-09 15:27:12 +00:00
David Woodhouse
9663265626 [MTD] Remove #ifndef __KERNEL__ hack in <mtd/mtd-abi.h>
Now that we have headers_install, we don't need this crap.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-25 21:52:21 +01:00
Håvard Skinnemoen
187ef15268 [MTD] Unlock NOR flash automatically where necessary
Introduce the MTD_STUPID_LOCK flag which indicates that the flash chip is
always locked after power-up, so all sectors need to be unlocked before it
is usable.

If this flag is set, and the chip provides an unlock() operation,
mtd_add_device will unlock the whole MTD device if it's writeable.  This
means that non-writeable partitions will stay locked.

Set MTD_STUPID_LOCK in fixup_use_atmel_lock() so that these chips will work
as expected.

Signed-off-by: Håvard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-22 10:07:08 +01:00
Randy Dunlap
ea9b6dcc15 MTD: kernel-doc fixes + additions
Fix some kernel-doc typos/spellos.
Use kernel-doc syntax in places where it was almost used.
Correct/add struct, struct field, and function param names where needed.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-06-29 08:55:41 +01:00
Linus Torvalds
cee4cca740 Merge git://git.infradead.org/hdrcleanup-2.6
* git://git.infradead.org/hdrcleanup-2.6: (63 commits)
  [S390] __FD_foo definitions.
  Switch to __s32 types in joystick.h instead of C99 types for consistency.
  Add <sys/types.h> to headers included for userspace in <linux/input.h>
  Move inclusion of <linux/compat.h> out of user scope in asm-x86_64/mtrr.h
  Remove struct fddi_statistics from user view in <linux/if_fddi.h>
  Move user-visible parts of drivers/s390/crypto/z90crypt.h to include/asm-s390
  Revert include/media changes: Mauro says those ioctls are only used in-kernel(!)
  Include <linux/types.h> and use __uXX types in <linux/cramfs_fs.h>
  Use __uXX types in <linux/i2o_dev.h>, include <linux/ioctl.h> too
  Remove private struct dx_hash_info from public view in <linux/ext3_fs.h>
  Include <linux/types.h> and use __uXX types in <linux/affs_hardblocks.h>
  Use __uXX types in <linux/divert.h> for struct divert_blk et al.
  Use __u32 for elf_addr_t in <asm-powerpc/elf.h>, not u32. It's user-visible.
  Remove PPP_FCS from user view in <linux/ppp_defs.h>, remove __P mess entirely
  Use __uXX types in user-visible structures in <linux/nbd.h>
  Don't use 'u32' in user-visible struct ip_conntrack_old_tuple.
  Use __uXX types for S390 DASD volume label definitions which are user-visible
  S390 BIODASDREADCMB ioctl should use __u64 not u64 type.
  Remove unneeded inclusion of <linux/time.h> from <linux/ufs_fs.h>
  Fix private integer types used in V4L2 ioctls.
  ...

Manually resolve conflict in include/linux/mtd/physmap.h
2006-06-20 15:10:08 -07:00
David Woodhouse
21c8db9eff [MTD] Restore MTD_ROM and MTD_RAM types
Let's not attempt the abolition of mtd->type until/unless it's properly
thought through. And certainly, let's not do it by halves.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-06-14 21:39:48 +01:00
Joern Engel
92cbfdcc36 [MTD] replace MTD_RAM with MTD_GENERIC_TYPE
Ram devices get the extra capability of MTD_NO_ERASE - not requiring
an explicit erase before writing to it.  Currently only mtdblock uses
this capability.  Rest of the patch is a simple text replacement.

Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-30 14:25:24 +02:00
Joern Engel
e369d62e92 [MTD] replace MTD_ROM with MTD_GENERIC_TYPE
No mtd user should ever check for the device type.  Instead, device features
should be checked by the flags - if at all.
As a first step towards type removal, change MTD_ROM into MTD_GENERIC_TYPE.

Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-30 14:25:17 +02:00
Thomas Gleixner
f1a28c0284 [MTD] NAND Expose the new raw mode function and status info to userspace
The raw read/write access to NAND (without ECC) has been changed in the
NAND rework. Expose the new way - setting the file mode via ioctl - to
userspace. Also allow to read out the ecc statistics information so userspace
tools can see that bitflips happened and whether errors where correctable
or not. Also expose the number of bad blocks for the partition, so nandwrite
can check if the data fits into the parition before writing to it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-30 00:37:34 +02:00
Thomas Gleixner
5bd34c091a [MTD] NAND Replace oobinfo by ecclayout
The nand_oobinfo structure is not fitting the newer error correction
demands anymore. Replace it by struct nand_ecclayout and fixup the users
all over the place. Keep the nand_oobinfo based ioctl for user space
compability reasons.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 15:06:50 +02:00
Joern Engel
5fa433942b [MTD] Introduce MTD_BIT_WRITEABLE
o Add a flag MTD_BIT_WRITEABLE for devices that allow single bits to be
  cleared.
o Replace MTD_PROGRAM_REGIONS with a cleared MTD_BIT_WRITEABLE flag for
  STMicro and Intel Sibley flashes with internal ECC.  Those flashes
  disallow clearing of single bits, unlike regular NOR flashes, so the
  new flag models their behaviour better.
o Remove MTD_ECC.  After the STMicro/Sibley merge, this flag is only set
  and never checked.

Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:18:29 +02:00
Joern Engel
28318776a8 [MTD] Introduce writesize
At least two flashes exists that have the concept of a minimum write unit,
similar to NAND pages, but no other NAND characteristics.  Therefore, rename
the minimum write unit to "writesize" for all flashes, including NAND.

Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:18:05 +02:00
Joern Engel
8ca9ed5db3 [MTD] Use single flag to mark writeable devices.
Two flags exist to decide whether a device is writeable or not.  None of
those two flags is checked for independently, so they are clearly redundant,
if not an invitation to bugs.  This patch removed both of them, replacing
them with a single new flag.

Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:17:23 +02:00
David Woodhouse
c6e82e7236 Move comment in mtd-abi.h to stop confusing unifdef
Currently, unifdef removes the comment which starts on the same line as
the #ifdef __KERNEL__, but leaves the second line of the comment in place.

Move the comment onto a separate line.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-25 15:00:06 +01:00
Jörn Engel
cd2866faaa Remove unused MTD types
Three types are never set or checked for.  Remove.

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-17 15:48:17 +01:00
Jörn Engel
a6c591eda3 Remove unchecked MTD flags
Several flags are set by some devices, but never checked.  Remove them.

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-17 15:48:17 +01:00
Thomas Gleixner
e4f0648fb4 [MTD] user-abi: Clean up trailing white spaces
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 14:43:11 +01:00
Nicolas Pitre
638d983840 {MTD] add support for Intel's "Sibley" flash
This updates the Primary Vendor-Specific Extended Query parsing to
version 1.4 in order to get the information about the Configurable
Programming Mode regions implemented in the Sibley flash, as well as
selecting the appropriate write command code.

This flash does not behave like traditional NOR flash when writing data.
While mtdblock should just work, further changes are needed for JFFS2 use.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-06 20:12:17 +01:00
Thomas Gleixner
90e260c84f [MTD] NAND: Honour autoplacement schemes supplied by the caller
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23 13:20:45 +02:00
Andrew Victor
8f15fd55f9 [JFFS2] Add support for JFFS2-on-Dataflash devices.
For Dataflash, can_mark_obsolete = false and the NAND write buffering
code (wbuf.c) is used.

Since the DataFlash chip will automatically erase pages when writing,
the cleanmarkers are not needed - so cleanmarker_oob = false and
cleanmarker_size = 0

DataFlash page-sizes are not a power of two (they're multiples of 528
bytes).  The SECTOR_ADDR macro (added in the previous core patch) is
replaced with a (slower) div/mod version if CONFIG_JFFS2_FS_DATAFLASH is
selected.

Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23 12:28:03 +02:00
Nicolas Pitre
31f4233bae [MTD] User interface to Protection Registers
This is implemented using a ioctl to switch the MTD char device into
one of the different OTP "modes", at which point read/write/seek can
operate on the selected OTP area.  Also some extra ioctls to query
for size and lock protection segments or groups.  Some example user
space utilities are provided.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23 12:26:04 +02:00
Nicolas Pitre
f77814dd57 [MTD] Support for protection register support on Intel FLASH chips
This enables support for reading, writing and locking so called
"Protection Registers" present on some flash chips.
A subset of them are pre-programmed at the factory with a
unique set of values. The rest is user-programmable.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23 12:25:23 +02:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00