10 Jan, 2012
1 commit
-
Recent BCM63XX devices support a variety of flash types (parallel, SPI,
NAND) and share the partition layout. To prevent code duplication make
the CFE partition parsing code a stand alone mtd parser to allow SPI or
NAND flash drivers to use it.Signed-off-by: Jonas Gorski
Acked-by: Florian Fainelli
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
11 Sep, 2011
1 commit
-
As ofpart now uses a standard mtd partitions parser interface, make it
buildable as a separate module. Also provide MODULE_DESCRIPTION and
MODULE_AUTHOR for this module.Signed-off-by: Dmitry Eremin-Solenikov
Acked-by: Randy Dunlap
Signed-off-by: Artem Bityutskiy
25 May, 2011
1 commit
-
Now that none of the drivers use CONFIG_MTD_PARTITIONS we can remove
it from Kconfig and the last remaining uses.Signed-off-by: Jamie Iles
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
11 Mar, 2011
2 commits
-
Add a driver for allowing an mtd device to be used as a block device for
swapping. The block device is volatile, and the mapping of swapped pages
is not stored on flash.Signed-off-by: Jarkko Lavinen
Tested-by: Artem Bityutskiy
Signed-off-by: David Woodhouse -
Move mtdconcat to be an integral part of the mtd core. It's a tiny bit
of code, which bears 'say Y if you don't know what to do' note in the
Kconfig. OTOH there are several ugly ifdefs depending on the MTD_CONCAT.
So, making MTD_CONCAT support mandatory will allow us to clean up code a
lot.Kconfig entry is changed to be a bool defaulting to Y, so all code
pieces depending on it, will have MTD_CONCAT Kconfig symbol and
CONFIG_MTD_CONCAT define. This will be removed in one of next patches.Signed-off-by: Dmitry Eremin-Solenikov
Acked-by: Stefan Roese
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
04 Dec, 2010
1 commit
-
MTD_OF_PARTS should be possible on all architectures, not just
powerpc and microblaze, and it probably should not be a user
selectable option. Neither does it need to be in a separate module.Also, rework MTD Kconfig to group options dependant on MTD_PARTITIONS
into a if/endif block. Do the same for MTD_REDBOOT_PARTS.Signed-off-by: Grant Likely
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
10 May, 2010
1 commit
-
Conflicts:
drivers/mtd/mtdcore.cPull in the bdi fixes and ARM platform changes that other outstanding
patches depend on.
27 Apr, 2010
1 commit
-
Removes one .h and one .c file that are never used outside of
mtdcore.c.Signed-off-by: Joern Engel
Edited to remove on leftover debug define.
Signed-off-by: Jens Axboe
27 Feb, 2010
1 commit
-
This implements new readwrite SmartMedia/xd FTL.
mtd driver must have support proper ECC and badblock verification
based on oob parts for 512 bytes nand.Also mtd driver must define read_oob and write_oob, which are used
to read and write both data and oob together.Signed-off-by: Maxim Levitsky
Signed-off-by: David Woodhouse
24 Mar, 2009
1 commit
-
Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.Signed-off-by: David Howells
Tested-by: Bernd Schmidt
Signed-off-by: David Woodhouse
06 Jan, 2009
1 commit
-
Conflicts:
drivers/mtd/Makefile
05 Jan, 2009
1 commit
-
We have two components to manage LPDDR flash memories in Linux.
1. It is a driver for chip probing and reading its capabilities
2. It is a device operations driver.Signed-off-by: Alexey Korolev
Acked-by: Jared Hulbert
Signed-off-by: David Woodhouse
10 Dec, 2008
1 commit
-
Add MTD tests to Kconfig and Makefiles.
Signed-off-by: Artem Bityutskiy
23 Apr, 2008
1 commit
-
Signed-off-by: Matteo Croce
Signed-off-by: Felix Fietkau
Signed-off-by: Eugene Konev
Signed-off-by: David Woodhouse
03 Feb, 2008
1 commit
-
Signed-off-by: Scott Wood
Signed-off-by: David Woodhouse
23 Aug, 2007
1 commit
03 Aug, 2007
1 commit
-
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.Signed-off-by: Satyam Sharma
Signed-off-by: David Woodhouse
29 Jun, 2007
1 commit
-
Kernel oops and panic messages are invaluable when debugging crashes.
These messages often don't make it to flash based logging methods (say a
syslog on jffs2) due to the overheads involved in writing to flash.This patch allows you to turn an MTD partition into a circular log
buffer where kernel oops and panic messages are written to. The messages
are obtained by registering a console driver and checking
oops_in_progress. Erases are performed in advance to maximise the
chances of a saving messages.To activate it, add console=ttyMTDx to the kernel commandline (where x
is the mtd device number to use).Signed-off-by: Richard Purdie
Signed-off-by: David Woodhouse
11 May, 2007
1 commit
-
Generalise the handling of MTD-specific superblocks so that JFFS2 and ROMFS
can both share it.Signed-off-by: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: David Woodhouse
27 Apr, 2007
1 commit
-
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.htmlPartitioning/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
Signed-off-by: Frank Haverkamp
29 Nov, 2006
1 commit
-
Add a MTD_BLKDEVS Kconfig option to cleanup the makefile a bit
Signed-off-by: Josh Boyer
Signed-off-by: Artem Bityutskiy
22 Sep, 2006
1 commit
-
Signed-off-by: Claudio Lanconelli
Signed-off-by: David Woodhouse
07 Nov, 2005
2 commits
-
OneNAND is a new flash technology from Samsung with integrated SRAM
buffers and logic interface.Signed-off-by: Kyungmin Park
Signed-off-by: Thomas Gleixner -
This type of flash translation layer (FTL) is used by the Embedded BIOS
by General Software. It is known as the Resident Flash Disk (RFD), see:http://www.gensw.com/pages/prod/bios/rfd.htm
Signed-off-by: Sean Young
Signed-off-by: Thomas Gleixner
17 Apr, 2005
1 commit
-
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!