This patch adds support for subpage (partial-page) writes when using
hardware based ECC schemes.
Advantages:
(1) reduces storage overhead when using file-systems like UBIFS, which
store LEB header at page-size granularity.
(2) allows independent subpage writes, thereby increasing NAND storage
efficiency for non-page aligned data.
+ updated cafe_nand and lpc32xx_mlc NAND drivers for change in
chip->write_page interface.
Signed-off-by: Gupta, Pekon <pekon@ti.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Notice that all the flashes belonging to the "legacy ID" class have 512 bytes
NAND page. This means we may simplify the 'LEGACY_ID_NAND()' macro as well as
the NAND ID table a little.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
As time goes on, we begin to meet the situation that we can not get enough
information from some nand chips's id data. Take some Toshiba's nand chips
for example. I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2
When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2 : 8192 + 640
TC58NVG6D2 : 8192 + 640
But we can not parse out the correct oob size for these chips from the id data.
This patch adds some new fields to the nand_flash_dev{}:
@id_len: the valid length of the id data. See the comments in
nand_id_has_period()
@oobsize: the oob size.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Reviewed-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Introduce a helpful macro for the maximum NAND ID sequence length instead of
using the "8" magic number.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Use 'unsigned int' instead of 'unsigned long' in the NAND chip description data
structure, because 32-bits is more than enough for our purposes. We do not need
64-bits, which is what we end up on 64-bit architectures. We declare many
instances of this data structure, so this should help saving some amount of
memory.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Up until now we identified NAND chips by the 'device ID' part of the full chip
ID array, which is the second full ID array byte. However, the newest flashes
use the same device ID for chips with identical page and eraseblock sizes, but
different OOB sizes. And unfortunately, it is not clear if there is a
"standard" way to fetch the OOB size from chip's full ID array. Here is an
example:
Toshiba TC58NVG2S0F: 0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08
Toshiba TC58NVG3S0F: 0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08
The first one is a 512MiB NAND chip with 4KiB NAND pages, 256KiB eraseblock
size and 224 bytes OOB. The second one is a 1GiB NAND chip with the same page
and eraseblock sizes, but with 232 bytes OOB.
This means that we have to store full ID in our NAND flashes table in order to
distinguish between these 2.
This patch adds the 'id[8]' field to the 'struct nand_flash_dev' structure, and
it makes it to be a part of anonymous union, where the second member is a
structure containing the 'mfr_id' and 'dev_id' bytes. The union makes sure that
'mfr_id' refers the same RAM address as 'id[0]' and 'dev_id' refers the same
RAM address as 'id[1]'. The only motivation for the union is an assumption that
'type->dev_id' is more readable than 'type->id[1]'.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Introduce helper macros for defining NAND chips. These macros do not really add
much value in the current code-base. However, we are going to add full ID
support which adds some more complexity to the table, and helper macros become
useful for readability.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The 'id' is a bit confusing name because NAND IDs are multi-byte. Re-name
it to 'dev_id' to make it clear that this is the "device ID" part (the second
byte).
While on it, clean-up the commentary for 'struct nand_flash_dev'.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
We have this unused macro, let's use it and justify its existence.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
It is unused.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
It is not used anywhere.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
We have only one AG-AND driver and it was not touched since 2005. It looks
like AG-AND was not really make it to mass-production and can be considered
a dead technology.
Along with the AG-AND support, this patch removes the BBT_AUTO_REFRESH feature,
because the only user of this feature is AG-AND. And even though it is
implemented as a generic feature, I prefer to remove it because NAND flashes do
not really need it in this form.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This partially reverts commit 1696e6bc2a
("mtd: nand: kill NAND_NO_READRDY").
In that patch I overlooked a few things.
The original documentation for NAND_NO_READRDY included "True for all
large page devices, as they do not support autoincrement." I was
conflating "not support autoincrement" with the NAND_NO_AUTOINCR option,
which was in fact doing nothing. So, when I dropped NAND_NO_AUTOINCR, I
concluded that I then could harmlessly drop NAND_NO_READRDY. But of
course the fact the NAND_NO_AUTOINCR was doing nothing didn't mean
NAND_NO_READRDY was doing nothing...
So, NAND_NO_READRDY is re-introduced as NAND_NEED_READRDY and applied
only to those few remaining small-page NAND which needed it in the first
place.
Cc: stable@kernel.org [3.5+]
Reported-by: Alexander Shiyan <shc_work@mail.ru>
Tested-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.
This work because readid and onfi are read work 8 byte mode.
Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID, NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.
[1]
3.3.2. Target Initialization
[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus.
The host shall not issue commands that use a word data width on x16 devices until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Add missing colons to fix kernel-doc generation warnings.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Some Hynix and Samsung MLC NAND have 640B OOB size. Sooner or later, we should
dynamically allocate the buffers that use these macros.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
add onfi_get_async_timing_mode() to get the supportted asynchronous
timing mode.
add onfi_get_sync_timing_mode() to get the supportted synchronous
timing mode.
Also add the neccessary macros : the timing modes.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Add the set-features(0xef)/get-features(0xee) helpers for ONFI nand.
Also add the necessary macros.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
In the absence of any formal documentation of the nand interface, I thought this
patch to the header file might be helpful.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Added a NAND device flag for subpage read support. Previously this was
hard coded based on large page and soft ECC.
Updated base NAND driver to use the new subpage read flag if the NAND is
large page and soft ECC.
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Fix kernel-doc warning in <linux/mtd/nand.h>:
Warning(include/linux/mtd/nand.h:659): No description found for parameter 'read_byte'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Just as Artem suggested:
"Both UBI and JFFS2 are able to read verify what they wrote already.
There are also MTD tests which do this verification. So I think there
is no reason to keep this in the NAND layer, let alone wasting RAM in
the driver to support this feature. Besides, it does not work for sub-pages
and many drivers have it broken. It hurts more than it provides benefits."
So kill MTD_NAND_VERIFY_WRITE entirely.
Signed-off-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
silently masks off at least one flag that might be set by the driver
(NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
others.
Really, as long as driver writers exercise a small amount of care with
NAND_* options, this mask is not necessary at all; it was only here to
prevent certain options from accidentally being set by the driver. But the
original thought turns out to be a bad idea occasionally. Thus, kill it.
Note, this patch fixes some major gpmi-nand breakage.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Huang Shijie <shijie8@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
There is an implemention of hardware ECC write page function which may return an
error indication.
For instance, using Atmel HW PMECC to write one page into a nand flash, the hardware
engine will compute the BCH ecc code for this page. so we need read a the
status register to theck whether the ecc code is generated.
But we cannot assume the status register always can be ready, for example,
incorrect hardware configuration or hardware issue, in such case we need
write_page() to return a error code.
Since the definition of 'write_page' function in struct nand_ecc_ctrl is 'void'.
So this patch will:
1. add return 'int' value for 'write_page' function.
2. to be consitent, add return 'int' value for 'write_page_raw' fuctions too.
3. add code to test the return value, and if negative, indicate an
error happend when write page with ECC.
4. fix the compile warning in all impacted nand flash driver.
Note: I couldn't compile-test all of these easily, as some had ARCH dependencies.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
According to its documentation, the NAND_NO_READRDY option is always used
when autoincrement is not supported. Autoincrement support was recently
dropped, so we can drop this options as well (defaulting to "no read ready
check").
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
As of [mtd: nand: remove autoincrement 'sndcmd' code], the
NAND_CMD_READ0 command is issued unconditionally.
Thus, read_oob/read_oob_raw's 'sndcmd' argument is no longer needed, as
well as their return code.
Remove the 'sndcmd' parameter, and set the return code to 0.
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
New NAND controllers can perform read/write via HW engines which don't expose
OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
data in the nand_chip.oob_poi buffer. A better interface includes a boolean
argument that explicitly tells the callee when OOB data is requested by the
calling layer (for reading/writing to/from nand_chip.oob_poi).
This patch adds the 'oob_required' parameter to each relevant {read,write}_page
interface; all 'oob_required' parameters are left unused for now. The next
patch will set the parameter properly in the nand_base.c callers, and follow-up
patches will make use of 'oob_required' in some of the callee functions.
Note that currently, there is no harm in ignoring the 'oob_required' parameter
and *always* utilizing nand_chip.oob_poi, but there can be
performance/complexity/design benefits from avoiding filling oob_poi in the
common case. I will try to implement this for some drivers which can be ported
easily.
Note: I couldn't compile-test all of these easily, as some had ARCH
dependencies.
[dwmw2: Merge later 1/0 vs. true/false cleanup]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: Jiandong Zheng <jdzheng@broadcom.com>
Acked-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Lantiq SoCs have a External Bus Unit (EBU) that is used to attach MTD media.
As we need to co-exist with PCI on the same bus, certain swapping settings must
be applied. Similar to the NOR map driver we need to apply a fix to make NAND
work. The easiest way is to use byte reads.
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
No drivers use auto-increment NAND, so kill the NO_AUTOINCR option entirely.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The drivers' _read() method, absent an error, returns a non-negative integer
indicating the maximum number of bit errors that were corrected in any one
region comprising an ecc step. MTD returns -EUCLEAN if this is >=
bitflip_threshold, 0 otherwise. If bitflip_threshold is zero, the comparison is
not made since these devices lack ECC and always return zero in the non-error
case (thanks Brian)¹. Note that this is a subtle change to the driver
interface.
This and the preceding patches in this set were tested with ubi on top of the
nandsim and docg4 devices, running the ubi test io_basic from mtd-utils.
¹ http://lists.infradead.org/pipermail/linux-mtd/2012-March/040468.html
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This adds 'ecc_strength' to struct mtd_info. This stores the maximum number of
bit errors that can be corrected in one writesize region.
For consistency with the nand code, 'strength' is similiarly added to struct
nand_ecc_ctrl. This stores the maximum number of bit errors that can be
corrected in one ecc step.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The description for badblockbits is incorrect. I think someone just made
up a false description on the spot to satisfy some kerneldoc warning.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Macronix is produing SLC NAND MX30LF1208AA, so add their manufacturer
code to the manufacturer lists.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The nand_chip.ops field is a struct that is passed around globally with
no particular reason. Every time it is used, it could just as easily be
replaced with a local struct that is updated on each operation. So make
it local.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
This fixes issues with `nanddump -n' and the MEMREADOOB[64] ioctls on
hardware that performs error correction when reading only OOB data. A
driver for such hardware needs to know when we're doing a RAW vs. a
normal write, but mtd_do_read_oob does not pass such information to the
lower layers (e.g., NAND). We should pass MTD_OOB_RAW or MTD_OOB_PLACE
based on the MTD file mode.
For now, most drivers can get away with just setting:
chip->ecc.read_oob_raw = chip->ecc.read_oob
This is done by default; but for systems that behave as described above,
you must supply your own replacement function.
This was tested with nandsim as well as on actual SLC NAND.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
This fixes issues with `nandwrite -n -o' and the MEMWRITEOOB[64] ioctls
on hardware that writes ECC when writing OOB. The problem arises as
follows: `nandwrite -n' can write page data to flash without applying
ECC, but when used with the `-o' option, ECC is applied (incorrectly),
contrary to the `--noecc' option.
I found that this is the case because my hardware computes and writes
ECC data to flash upon either OOB write or page write. Thus, to support
a proper "no ECC" write, my driver must know when we're performing a raw
OOB write vs. a normal ECC OOB write. However, MTD does not pass any raw
mode information to the write_oob functions. This patch addresses the
problems by:
1) Passing MTD_OOB_RAW down to lower layers, instead of just defaulting
to MTD_OOB_PLACE
2) Handling MTD_OOB_RAW within the NAND layer's `nand_do_write_oob'
3) Adding a new (replaceable) function pointer in struct ecc_ctrl; this
function should support writing OOB without ECC data. Current
hardware often can use the same OOB write function when writing
either with or without ECC
This was tested with nandsim as well as on actual SLC NAND.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
The set_parts and priv members of struct platform_nand_chip where
removed in commit c36a6ef3845262ade529afb9f458738b1f196f83 but the
kerneldoc wasn't updated.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Artem Bityutskiy <dedekind1@gmail.com>
Drop now unused set_parts from struct platform_nand_data. Also, while we are
at it, drop long unused priv field from platform_nand_data.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
After several steps of rearrangement and consolidation, it is probably
worth re-sequencing the numbers on some of our affected flags in nand.h
and bbm.h.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The NAND_CREATE_EMPTY_BBT flag was added by commit:
453281a973
mtd: nand: introduce NAND_CREATE_EMPTY_BBT
This flag is not used within the kernel and not explained well, so I
took the liberty to edit its comments.
Also, this is a BBT-related flag (and closely tied with NAND_BBT_CREATE)
so I'm moving it to bbm.h next to NAND_BBT_CREATE, thus requiring that
we use the flag in nand_chip.bbt_options, *not* in nand_chip.options.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch works with the following three flags from two headers (nand.h
and bbm.h):
(1) NAND_USE_FLASH_BBT (nand.h)
(2) NAND_USE_FLASH_BBT_NO_OOB (nand.h)
(3) NAND_BBT_NO_OOB (bbm.h)
These flags are all related and interdependent, yet they were in
different headers. Flag (2) is simply the combination of (1) and (3) and
can be eliminated.
This patch accomplishes the following:
* eliminate NAND_USE_FLASH_BBT_NO_OOB (i.e., flag (2))
* move NAND_USE_FLASH_BBT (i.e., flag (1)) to bbm.h
It's important to note that because (1) and (3) are now both found in
bbm.h, they should NOT be used in the "nand_chip.options" field.
I removed a small section from the mtdnand DocBook because it referes to
NAND_USE_FLASH_BBT in nand.h, which has been moved to bbm.h.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch handles the problems we've been having with using conflicting
flags from nand.h and bbm.h in the same nand_chip.options field. We
should try to separate these two spaces a little more clearly, and so I
have added a bbt_options field to nand_chip.
Important notes about nand_chip fields:
* bbt_options field should contain ONLY flags from bbm.h. They should be
able to pass safely to a nand_bbt_descr data structure.
- BBT option flags start with the "NAND_BBT_" prefix.
* options field should contian ONLY flags from nand.h. Ideally, they
should not be involved in any BBT related options.
- NAND chip option flags start with the "NAND_" prefix.
* Every flag should have a nice comment explaining what the flag is. While
this is not yet the case on all existing flags, please be sure to write
one for new flags. Even better, you can help document the code better
yourself!
Please try to follow these conventions to make everyone's lives easier.
Among the flags that are being moved to the new bbt_options field
throughout various drivers, etc. are:
* NAND_BBT_SCANLASTPAGE
* NAND_BBT_SCAN2NDPAGE
and there will be more to come.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The NAND_USE_FLASH_BBT_NO_OOB and NAND_CREATE_EMPTY_BBT flags conflict
with the NAND_BBT_SCANBYTE1AND6 and NAND_BBT_DYNAMICSTRUCT flags,
respectively. This change will allow us to utilize these options
independently.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
This patch adds software BCH ECC support to mtd, in order to handle recent
NAND device ecc requirements (4 bits or more).
It does so by adding a new ecc mode (NAND_ECC_SOFT_BCH) for use by board
drivers, and a new Kconfig option to enable BCH support. It relies on the
generic BCH library introduced in a previous patch.
When a board driver uses mode NAND_ECC_SOFT_BCH, it should also set fields
chip->ecc.size and chip->ecc.bytes to select BCH ecc data size and required
error correction capability. See nand_bch_init() documentation for details.
It has been tested on the following platforms using mtd-utils, UBI and
UBIFS: x86 (with nandsim), arm926ejs.
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
