Do not call mtd_ioctl for mtdraw devices. mtd_ioctl will derefence
the priv pointer to a struct mtd_info whereas with mtdraw devices it will be
a struct mtdraw pointer. We do not need ioctls for mtdraw devices, so drop
it instead of fixing it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Right now we do not support persistent names for mtd devices. The
base name can be passed to add_mtd_device, but this is always appended
with a dynamic number. With this patch add_mtd_device takes a device_id
argument which can be used to create a mtd device with an exact name.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The name of the raw device is mtdraw<num> which is inconsistent to other
mtd devices which are named mtd<num>.<partname>. Rename it to mtd<num>.raw.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
when the bootmode is different than NAND (USB for example), the
GPMI clock is not enabled thus we can't probe a NAND flash.
Tested on an i.MX28
Signed-off-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
print_hex_dump is a standard kernel function, so move it outside
the ubi header files to make it usable for other code derived from
the kernel aswell.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We do not have ubi_do_get_volume_info and ubi_do_get_device_info
and do not need them yet, so remove calls to these functions to fix
compilation.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This is a fresh UBI import from Linux v3.10
This is done mainly to get fastmap support.
This was tested with the i.MX nand driver, the MXS nand driver and
on CFI NOR flash.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
To update to the latest UBI support from the Kernel first remove
the old UBI support. Without it the update will be even less reviewable.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The i.MX6 uses the same GPMI NAND controller as i.MX23/28 do. This adds
i.MX6 support to the driver.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
As the apbh dma engine is also found on i.MX6 move the header file
out of MXS specific directories.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
MXS specific devices have some common infrastructure in the kernel
known as STMP devices. We have the same in barebox, but with a
mxs_ prefix instead of a stmp_ prefix. As some STMP devices are
also found on i.MX6 move the common infrastructure out of MXS
specific files and use the stmp_ prefix.
This is done in preparation for i.MX6 NAND support.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This updates the NAND stuff to Linux-3.11-rc1. It is synchronized
as best as we can get:
- locks removed
- The splitting in different files we had to better support different
features has been dropped. Instead this is now done mostly with the
use of __maybe_unused
Some barebox adjustments are forward ported, like:
- Allow partial page writes
- Optionally allow to erase bad blocks
- check for all_ff before writing a page
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This introduces the ecc stength fields in the structures and fills
them in, but leaves them unused right now.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
There is the same function name in the Kernel but with different
semantics. Rename to avoid naming conflicts when we update the
mtd support from the kernel.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This is based on Linux:
commit e2414f4c20bd4dc62186fbfd7bdec50bce6d2ead
Author: Brian Norris <computersforpeace@gmail.com>
Date: Mon Feb 6 13:44:00 2012 -0800
Currently, the flash-based BBT implementation writes bad block data only
to its flash-based table and not to the OOB marker area. Then, as new bad
blocks are marked over time, the OOB markers become incomplete and the
flash-based table becomes the only source of current bad block
information. This becomes an obvious problem when, for example:
* code accessing the flash cannot read the flash-based BBT format
* BBT is corrupted and the flash must be rescanned for bad
blocks; we want to remember bad blocks that were marked from Linux
So to keep the bad block markers in sync with the flash-based BBT, this
patch changes the default so that we write bad block markers to the proper
OOB area on each block in addition to flash-based BBT. Comments are
updated, expanded, and/or relocated as necessary.
The new flash-based BBT procedure for marking bad blocks:
(1) erase the affected block, to allow OOB marker to be written cleanly
(2) update in-memory BBT
(3) write bad block marker to OOB area of affected block
(4) update flash-based BBT
Note that we retain the first error encountered in (3) or (4), finish the
procedures, and dump the error in the end.
This should handle power cuts gracefully enough. (1) and (2) are mostly
harmless (note that (1) will not erase an already-recognized bad block).
The OOB and BBT may be "out of sync" if we experience power loss bewteen
(3) and (4), but we can reasonably expect that on next boot, subsequent
I/O operations will discover that the block should be marked bad again,
thus re-syncing the OOB and BBT.
Note that this is a change from the previous default flash-based BBT
behavior.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Chipsize didn't take number of LUNs into account. Sync chipsize calculation
to kernel commit 63795755
Tested with MT29F8G16ADBDAH4 on OMAP4
Signed-off-by: Jan Weitzel <j.weitzel@phytec.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Our erase command used to align to eraseblocks when necessary.
This worked well until recently when the m25p80, mtd_dataflash
and cfi flash were added / converted to mtd. This patch aligns
the input to the erase fileoperation to eraseblock boundaries.
Also tested with non uniform flashes with multiple eraseregions.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Since the info is device specific and not driver specific, attach
the callback to the device. This makes it possible to have a info
callback for a device which does not have a driver attached.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
If a device does not have bad blocks loop over the eraseblocks
in the driver instead of the core. This allows the mtd_dataflash
driver to erase blocks instead of pages to gain more speed during
erasing. Also the mtd_dataflash driver modifies the erase_info
struct which causes the outer loop in the core to never end.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
