Commit graph

59 commits

Author SHA1 Message Date
Masahiro Yamada
1221ce459d treewide: replace #include <asm/errno.h> with <linux/errno.h>
Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content.  (both just wrap <asm-generic/errno.h>)

Replace all include directives for <asm/errno.h> with <linux/errno.h>.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Fixup include/clk.]
Signed-off-by: Tom Rini <trini@konsulko.com>
2016-09-23 17:55:42 -04:00
Scott Wood
8b7d51249e nand: Fix some more NULL name tests
Now that nand_info[] is an array of pointers we need to test the
pointer itself rather than using name as a proxy for NULLness.

Fixes: b616d9b0a7 ("nand: Embed mtd_info in struct nand_chip")
Signed-off-by: Scott Wood <oss@buserror.net>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2016-09-01 20:08:48 -05:00
Ladislav Michl
0568dd0663 armv7: make gpmc_cfg const
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
[trini: Adapt am33xx, duovero, omap_zoom1]
Signed-off-by: Tom Rini <trini@konsulko.com>

Signed-off-by: Tom Rini <trini@konsulko.com>
2016-07-22 14:46:00 -04:00
Heiko Schocher
3a504d9639 mtd: nand: omap: allow to switch to BCH16
support in omap_nand_switch_ecc() also an eccstrength
from 16.

Signed-off-by: Heiko Schocher <hs@denx.de>
2016-06-09 13:53:12 -04:00
Scott Wood
ceee07b658 mtd: nand: Sync with Linux v4.6
Updates the NAND code to match Linux v4.6.  The previous sync was from
Linux v4.1 in commit d3963721d9.

Note that none of the individual NAND drivers tracked Linux closely
enough to be synced themselves, other than manually applying a few
cross-tree changes.

Signed-off-by: Scott Wood <oss@buserror.net>
Tested-by: Heiko Schocher <hs@denx.de>
2016-06-03 20:27:48 -05:00
Scott Wood
17cb4b8f32 mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_data
These functions are part of the Linux 4.6 sync.  They are being added
before the main sync patch in order to make it easier to address the
issue across all NAND drivers (many/most of which do not closely track
their Linux counterparts) separately from other merge issues.

Signed-off-by: Scott Wood <oss@buserror.net>
2016-06-03 20:27:48 -05:00
Scott Wood
b616d9b0a7 nand: Embed mtd_info in struct nand_chip
nand_info[] is now an array of pointers, with the actual mtd_info
instance embedded in struct nand_chip.

This is in preparation for syncing the NAND code with Linux 4.6,
which makes the same change to struct nand_chip.  It's in a separate
commit due to the large amount of changes required to accommodate the
change to nand_info[].

Signed-off-by: Scott Wood <oss@buserror.net>
2016-06-03 20:27:48 -05:00
Vagrant Cascadian
eae4b2b67b Fix spelling of "occurred".
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-02 18:37:09 -04:00
Ezequiel García
d1d0167663 nand: omap_gpmc: Change correctable bit-flips messages to debug()
Messages on corrected bit-flips are not really useful,
as bit-flips are perfectly normal. Let's avoid cluttering
the console and make them debug.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
2015-10-11 17:12:13 -04:00
Jeroen Hofstee
cb2fc338f8 mtd: OMAP: Enable GPMC prefetch mode for 16 bit access
commit c316f57 "mtd: OMAP: Enable GPMC prefetch mode" only enabled
prefetch mode for 8 bit nand access, this adds 16 bit as well.

Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Daniel Mack <zonque@gmail.com>

Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-06-18 11:23:45 -04:00
Jeroen Hofstee
c07361145f omap_gpmc: move prefetch out of CONFIG_NAND_OMAP_ELM
The prefech mode is a feature of the gpmc, not the ELM. An am3517
does not have an elm, but can do prefeches, so move the code out
of the CONFIG_NAND_OMAP_ELM ifdef.

Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Daniel Mack <zonque@gmail.com>

Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-06-18 11:23:45 -04:00
Ash Charles
b050898efa omap: gpmc: 'nandecc sw' can use HAM1 or BCH8
The 'nandecc sw' command selects a software-based error correction
algorithm.  By default, this is OMAP_ECC_HAM1_CODE_SW but some
platforms use OMAP_ECC_BCH8_CODE_HW_DETECTION_SW as their
software-based correction algorithm.  Allow a user to be specific e.g.
 # nandecc sw <hamming|bch8>
where 'hamming' is still the default.

Note: we don't just use CONFIG_NAND_OMAP_ECCSCHEME as it might be set
      to a hardware-based ECC scheme---a little strange when the user
      has requested 'sw' ECC.

Signed-off-by: Ash Charles <ashcharles@gmail.com>
2015-03-05 20:49:43 -05:00
Michal Sojka
d8af39337e mtd: nand: omap_gpmc: Make ready/busy pins configurable
Commit fb384c4720 introduced the use of
WAIT0 pin for determining whether the NAND is ready or not. This only
works if all NAND chips are connected to WAIT0. If some chips are
connected to the other available pin WAIT1, nand_wait() does not really
wait and prints a WARN_ON message.

This patch allows the board to provide configuration of which chip is
connected to which WAITx signal. For example, one can define in
include/configs/foo.h:

    #define CONFIG_NAND_OMAP_GPMC_WSCFG     0,0,1,1

This would mean that chips using to CS0 and 1 are connected to WAIT0 and
chips with CS2 and 3 are connected to WAIT1.

Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Stefan Roese <sr@denx.de>
Tested-by: Michal Vokáč <michal.vokac@comap.cz>

Cc: Tom Rini <trini@ti.com>
2015-03-05 20:49:42 -05:00
Egli, Samuel
89831112d4 mtd, omap: fix case NAND_OMAP_GPMC_PREFETCH not defined
The patch c316f577b4 breaks
siemens boards because prefetch mode is not enabled.
I assume it breaks other boards as well that don't use
prefetch.

This patch sets read_buf to nand_read_buf if
NAND_OMAP_GPMC_PREFETCH is not defined.

Signed-off-by: Samuel Egli <samuel.egli@siemens.com>
CC: Daniel Mack <zonque@gmail.com>
CC: Guido Martínez <guido@vanguardiasur.com.ar>
CC: Tom Rini <trini@ti.com>
CC: Heiko Schocher <hs@denx.de>
2015-02-16 12:41:40 -05:00
Daniel Mack
c316f577b4 mtd: OMAP: Enable GPMC prefetch mode
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read
access a lot by pre-fetching contents in the background and reading them
through the FIFO address.

The current implementation has two limitations:

 a) it only works in 8-bit mode
 b) it only supports read access

Both is easily fixable by someone who has hardware to implement it.

Note that U-Boot code uses non word-aligned buffers to read data into, and
request read lengths that are not multiples of 4, so both partial buffers
(head and tail) have to be addressed.

Tested on AM335x hardware.

Tested-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: Daniel Mack <zonque@gmail.com>
[trini: Make apply again, use 'cs' fix pointed out by Guido]
Signed-off-by: Tom Rini <trini@ti.com>
2015-01-13 11:51:23 -05:00
Guido Martínez
eb54d2c70c mtd: nand: omap_gpmc: fix error handling
"err" was an unsigned variable, causing negative error codes to turn
into positive values, which are interpreted as an amount of succesfully
corrected bitflips (and thus not an error).

In particular, this resulted in that if the elm reports uncorrectable
errors (-EBADMSG), the MTD layer (and UBI) falsely succeeded.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: Stefan Roese <sr@denx.de>
2015-01-05 16:40:18 -05:00
Stefan Roese
fb384c4720 mtd: nand: omap_gpmc: Always use ready/busy pin
The functions to detect the state of the ready / busy signal is already
available but only used in the SPL case. Lets use it always, also for the
main U-Boot. As all boards should have this HW connection.

Testing on Siemens Draco (am335x) showed a small perfomance gain by using
this ready pin to detect the NAND chip state. Here the values tested on
Draco with Hynix 4GBit NAND:

Without NAND ready pin:

U-Boot# time nand read 80400000 0 400000

NAND read: device 0 offset 0x0, size 0x400000
4194304 bytes read: OK

time: 2.947 seconds, 2947 ticks

With NAND ready pin:

U-Boot# time nand read 80400000 0 400000

NAND read: device 0 offset 0x0, size 0x400000
4194304 bytes read: OK

time: 2.795 seconds, 2795 ticks

So an increase of approx. 5%.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
2014-12-04 21:28:31 -05:00
Jeroen Hofstee
441529795c omap_gpmc: fix warnigs with W=1
- make omap_spl_dev_ready static
- make omap_reverse_list static, move to under CONFIG_NAND_OMAP_ELM

Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Signed-off-by: Tom Rini <trini@ti.com>
2014-10-25 07:02:02 -04:00
Rostislav Lisovy
cc81a52919 mtd: nand: omap_gpmc: Fix 'bit-flip' errors
OMAP GPMC driver used with some NAND Flash devices (e.g. Spansion
S34ML08G1) causes that U-boot shows hundreds of 'nand: bit-flip
corrected' error messages. Possible cause was discussed in the
mailinglist thread:
http://lists.denx.de/pipermail/u-boot/2014-April/177508.html

Quote (Author: Pekon Gupta <pekon@ti.com>): "The issue is mainly
due to a NAND protocol violation in the omap driver since the
Random Data Output command (05h-E0h) expects to see only the
column address that should be addressed within the already loaded
read page into the read buffer. Only 2 address cycles with ALE
active should be provided between the 05h and E0h commands. The
Page read command expects the full address footprint (2bytes for
column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used
with only 2bytes for column address."

This patch combines the solution proposed in the mailinglist and
the patch provided by the Spansion company (GPLv2 code, source:
http://www.spansion.com/Support/Software/u-boot-psp-04.04.00.01-NAND.zip)

Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
2014-09-04 13:06:00 -04:00
Rostislav Lisovy
5c3f7e0ead mtd: nand: omap_gpmc: Enable multiple NAND flash devices
Since the CS of a device connected to the GPMC was
stored in the global variable, it was not possible to
use multiple devices. In this patch the CS is stored per
device in its 'struct omap_nand_info'. This makes it
possible to use up to 'GPMC_MAX_CS' NAND Flash devices
connected to U-boot.

Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
2014-09-04 13:06:00 -04:00
pekon gupta
46840f66ca mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
This patch add support for BCH16_ECC to omap_gpmc driver.

*need to BCH16 ECC scheme*
With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes
Flash devices have become more suspectible to bit-flips. Thus stronger
ECC schemes are required for protecting the data.
But stronger ECC schemes have come with larger-sized ECC syndromes which require
more space in OOB/Spare. This puts constrains like;
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page >= 26 * (page-size / 512)

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-06-06 17:46:10 -04:00
pekon gupta
b80a660338 mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width
GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL:    SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
        which is called before probing for devices, hence any ONFI parameter
        information is not available during GPMC initialization.

Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.

This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-06-06 17:46:06 -04:00
pekon gupta
3f990dc83b mtd: nand: omap: fix error-codes returned from omap-elm driver
This patch
 omap-elm.c: replaces -ve integer value returned during errorneous condition,
             with proper error-codes.
 omap-gpmc.c: updates omap-gpmc driver to pass error-codes returned from
             omap-elm driver to upper layers

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2014-06-06 17:46:00 -04:00
pekon gupta
a09431da38 mtd: nand: omap_gpmc: minor cleanup of omap_correct_data_bch
This patch tries to avoid some local pointer dereferences, by using common
local variables in omap_correct_data_bch()

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2014-06-06 17:45:57 -04:00
pekon gupta
9233279f8e mtd: nand: omap_gpmc: rename struct nand_bch_priv to struct omap_nand_info
This patch renames 'struct nand_bch_priv' which currently holds private data only
for BCH ECC schemes, into 'struct omap_nand_info' so that same can be used for
all ECC schemes

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2014-06-06 17:45:55 -04:00
pekon gupta
d21e77ff84 mtd: nand: omap_gpmc: remove unused members of 'struct nand_bch_priv'
This patch prepares to refactor 'struct nand_bch_priv' -> 'struct omap_nand_info'
And thus performs following clean-ups:
 - remove nand_bch_priv.type: use nand_bch_priv.ecc_scheme instead
 - remove nand_bch_priv.mode: <unused>

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2014-06-06 17:45:51 -04:00
pekon gupta
41bbe4dd49 mtd: nand: omap_elm: use bch_type instead of nibble count to differentiate between BCH4/BCH8/BCH16
ELM hardware engine support ECC error detection for multiple ECC strengths like
 +------+------------------------+
 |Type  | ECC syndrome length    |
 +------+------------------------+
 |BCH4  | 6.5 bytes = 13 nibbles |
 |BCH8  | 13 byte = 26 nibbles   |
 |BCH16 | 26 bytes = 52 nibbles  |
 +------+------------------------+

Current implementation of omap_elm driver uses ECC syndrom length (in 'nibbles')
to differentiate between BCH4/BCH8/BCH16. This patch replaces it with 'bch_type'

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
2014-06-06 17:45:48 -04:00
Belisko Marek
97eeae1a07 mtd: nand: omap_gpmc: Fix update of read_ecc in oob
We need to flip only one bit not assign.

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
Acked-by: Pekon Gupta <pekon@ti.com>
2014-05-13 19:48:17 -04:00
pekon gupta
2eda892f00 mtd: nand: omap: move omap_elm.h from arch/arm/include/asm to drivers/mtd/nand
omap_elm.h is a generic header used by OMAP ELM driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-04 17:23:54 -06:00
pekon gupta
6aff050988 mtd: nand: omap: move omap_gpmc.h from arch/arm/include/asm to drivers/mtd/nand
omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-04 17:23:54 -06:00
pekon gupta
51d192c40d mtd: nand: omap: merge duplicate GPMC data from different arch-xx headers into common omap_gpmc.h
Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related
defines and declarations scattered in SoC platform specific header files
like include/asm/arch-xx/cpu.h
However, GPMC hardware remains same across all platforms thus this patch merges
GPMC data scattered across different arch-xx specific header files into single
header file include/asm/arch/omap_gpmc.h

Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-04 17:23:54 -06:00
pekon gupta
6e562b1106 mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes
chip->ecc.correct() is used for detecting and correcting bit-flips during read
operations. In omap-nand driver it implemented as:
(a) omap_correct_data(): for h/w based ECC_HAM1 scheme
(b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
	for ECC_BCH8 scheme using GPMC and software lib/bch.c
(c) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW
	for ECC_BCH8 scheme using GPMC and ELM

This patch updates (c)
- checks for calc_ecc[]==0x00 so that error_correction is not required for
  known good pages.
- adds scalability for other ECC_BCHx scheme by merging following
  omap_rotate_ecc_bch() + omap_fix_errors_bch() => omap_correct_data_bch()
- fixing logic for bit-flip correction based on error_loc[count]

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-03 20:09:03 -06:00
pekon gupta
71a7f95600 mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes
chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by
processing the data passed during Read/Write accesses.

All H/W based ECC schemes use GPMC controller to calculate ECC syndrome.
But each BCHx_ECC scheme has its own implemetation of post-processing and
fetching ECC syndrome from GPMC controller.

This patch updates OMAP_ECC_BCH8_CODE_HW ECC scheme in following way:
- merges multiple chip->calculate API for different ECC schemes
  omap_calculate_ecc() + omap_calculate_ecc_bch() + omap_calculate_ecc_bch_sw()
				==> omap_calculate_ecc()
- removes omap_ecc_disable() and instead uses it as inline.

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-03 20:09:03 -06:00
pekon gupta
f5f1f614bd mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemes
chip->ecc.hwctl() is used for preparing the H/W controller before read/write
NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.)

Though all ECC schemes in OMAP NAND driver use GPMC controller for generating
ECC syndrome (for both Read/Write accesses). But but in current code
HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this.
This patch
(1) removes omap_hwecc_init() and omap_hwecc_init_bch()
as chip->ecc.hwctl will re-initializeGPMC before every read/write call.
omap_hwecc_init_bch() -> omap_enable_ecc_bch()

(2) merges the GPMC configuration code for all ECC schemes into
single omap_enable_hwecc(), thus adding scalability for future ECC schemes.
omap_enable_hwecc() + omap_enable_ecc_bch() -> omap_enable_hwecc()

Signed-off-by: Pekon Gupta <pekon@ti.com>
2014-03-03 20:09:03 -06:00
Jeroen Hofstee
13fbde6e4f nand, gpmc: fix reading after switching ecc
The omap_gpmc allows switching ecc at runtime. Since
the NAND_SUBPAGE_READ flag is only set, it is kept when
switching to hw ecc, which is not correct. This leads to
calling chip->ecc.read_subpage which is not a valid
pointer. Therefore clear the flag when switching ecc so
reading in hw mode works again.

Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
2014-01-17 08:04:32 -05:00
Nikita Kiryanov
fcd0524574 mtd: nand: omap: fix ecc ops assignment when changing ecc
If we change to software ecc and then back to hardware ecc, the nand ecc ops
pointers are populated with incorrect function pointers. This is related to the
way nand_scan_tail() handles assigning functions to ecc ops:

If we are switching to software ecc/no ecc, it assigns default functions to the
ecc ops pointers unconditionally, but if we are switching to hardware ecc,
the default hardware ecc functions are assigned to ops pointers only if these
pointers are NULL (so that drivers could set their own functions). In the case
of omap_gpmc.c driver, when we switch to sw ecc, sw ecc functions are
assigned to ecc ops by nand_scan_tail(), and when we later switch to hw ecc,
the ecc ops pointers are not NULL, so nand_scan_tail() does not overwrite
them with hw ecc functions.
The result: sw ecc functions used to write hw ecc data.

Clear the ecc ops pointers in omap_gpmc.c when switching ecc types, so that
ops which were not assigned by the driver will get the correct default values
from nand_scan_tail().

Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
2013-12-17 17:47:47 -06:00
Nikita Kiryanov
eb237a15bd mtd: nand: omap: fix sw->hw->sw ecc switch
When switching ecc mode, omap_select_ecc_scheme() assigns the appropriate values
into the current nand chip's ecc.layout struct. This is done under the
assumption that the struct exists only to store values, so it is OK to overwrite
it, but there is at least one situation where this assumption is incorrect:

When switching to 1 bit hamming code sw ecc, the job of assigning layout data
is outsourced to nand_scan_tail(), which simply assigns into ecc.layout a
pointer to an existing struct prefilled with the appropriate values. This struct
doubles as both data and layout definition, and therefore shouldn't be
overwritten, but on the next switch to hardware ecc, this is exactly what's
going to happen. The next time the user switches to software ecc, they're
going to get a messed up ecc layout.

Prevent this and possible similar bugs by explicitly using the
private-to-omap_gpmc.c omap_ecclayout struct when switching ecc mode.

Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
2013-12-17 17:46:53 -06:00
Nikita Kiryanov
2528460c38 mtd: nand: omap: fix HAM1_SW ecc using default value for ecc.size
Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic
platform" (d016dc42ce) changed the way
software ECC is configured, both during boot, and during ecc switch, in a way
that is not backwards compatible with older systems:

Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring
for software ecc, relying on nand_scan_tail() to select a default for ecc.size
(256), while the new version of omap_gpmc.c assigns ecc.size = pagesize,
which is likely to not be 256.

Since 1 bit hamming sw ecc is only meant to be used by legacy devices, revert
to the original behavior.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Pekon Gupta <pekon@ti.com>
2013-12-17 17:41:25 -06:00
Stefan Roese
5d7a49b930 mtd: nand: omap_gpmc: cosmetic: Fix indentation
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
[scottwood@freescale.com: wrap some long lines]
Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-12-17 17:31:14 -06:00
pekon gupta
69cc97f8db mtd: nand: omap: fix ecc-layout for HAM1 ecc-scheme
As per OMAP3530 TRM referenced below [1]

For large-page NAND, ROM code expects following ecc-layout for HAM1 ecc-scheme
 - OOB[1] (offset of 1 *byte* from start of OOB) for x8 NAND device
 - OOB[2] (offset of 1 *word* from start of OOB) for x16 NAND device

Thus ecc-layout expected by ROM code for HAM1 ecc-scheme is:
 *for x8 NAND Device*
 +--------+---------+---------+---------+---------+---------+---------+
 | xxxx   | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] | ...
 +--------+---------+---------+---------+---------+---------+---------+

 *for x16 NAND Device*
 +--------+--------+---------+---------+---------+---------+---------+---------+
 | xxxxx  | xxxxx  | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] |
 +--------+--------+---------+---------+---------+---------+---------+---------+

This patch fixes ecc-layout *only* for HAM1, as required by ROM-code
For other ecc-schemes like (BCH8) ecc-layout is same for x8 or x16 devices.

[1] OMAP3530: http://www.ti.com/product/omap3530
    TRM: http://www.ti.com/litv/pdf/spruf98x
		Chapter-25: Initialization Sub-topic: Memory Booting
		Section: 25.4.7.4 NAND
		Figure 25-19. ECC Locations in NAND Spare Areas

Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Tested-by: Stefan Roese <sr@denx.de>
2013-12-17 17:28:41 -06:00
pekon gupta
3f719069c8 mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme
This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed
CONFIG_xx used for selecting NAND ecc-schemes.
This patch aims at solving following issues.

1) Currently ecc-scheme is tied to SoC platform, which prevents user to select
   other ecc-schemes also supported in hardware. like;
 - most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite
   the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with
   software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW).
 - most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware
   supports BCH16 ecc-scheme also.

2) Different platforms use different CONFIG_xx to select ecc-schemes, which
   adds confusion for user while migrating platforms.
 - *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only
    8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW)
    whereas ELM hardware engine supports other ecc-schemes also like; BCH4,
    and BCH16 (in future).
 - *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error
    correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW).
 - *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library

Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency
on SoC platform and NAND driver. And user can select ecc-scheme independently
foreach board.
However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still
depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand)

Signed-off-by: Pekon Gupta <pekon@ti.com>
2013-11-21 13:33:41 -06:00
pekon gupta
d016dc42ce mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
+-----------------------------------+-----------------+-----------------+
|ECC Scheme                         | ECC Calculation | Error Detection |
+-----------------------------------+-----------------+-----------------+
|OMAP_ECC_BCH8_CODE_HW              |GPMC             |ELM H/W engine   |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC             |S/W BCH library  |
+-----------------------------------+-----------------+-----------------+

Current implementation limits the BCH8_CODE_HW only for AM33xx device family.
(using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have
ELM hardware module, and can support ECC error detection using ELM.

This patch
- removes CONFIG_AM33xx
	Thus this driver can be reused by all devices having ELM h/w engine.
- adds omap_select_ecc_scheme()
	A common function to handle ecc-scheme related configurations. This
	can be used both during device-probe and via user-space u-boot commads
	to change ecc-scheme. During device probe ecc-scheme is selected based
	on CONFIG_NAND_OMAP_ELM or CONFIG_NAND_OMAP_BCH8
- enables CONFIG_BCH
	S/W library (lib/bch.c) required by OMAP_ECC_BCHx_CODE_HW_DETECTION_SW
  	is enabled by CONFIG_BCH.
- enables CONFIG_SYS_NAND_ONFI_DETECTION
	for auto-detection of ONFI compliant NAND devices
- updates following README doc
	doc/README.nand
	board/ti/am335x/README
	doc/README.omap3

Signed-off-by: Pekon Gupta <pekon@ti.com>
[scottwood@freescale.com: fixed unused variable warning]
Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-11-21 13:33:41 -06:00
pekon gupta
beba5f04f2 mtd: nand: omap: make am33xx/elm.c as common driver for all OMAPx and AMxxxx platforms
ELM hardware engine which is used for ECC error detection, is present on all
latest OMAP SoC (like OMAP4xxx, OMAP5xxx, DRA7xxx, AM33xx, AM43xx). Thus ELM
driver should be moved to common drivers/mtd/nand/ folder so that all SoC
having on-chip ELM hardware engine can re-use it.
This patch has following changes:
- mv arch/arm/include/asm/arch-am33xx/elm.h arch/arm/include/asm/omap_elm.h
- mv arch/arm/cpu/armv7/am33xx/elm.c drivers/mtd/nand/omap_elm.c
- update Makefiles
- update #include <asm/elm.h>
- add CONFIG_NAND_OMAP_ELM to compile driver/mtd/nand/omap_elm.c
	and include in all board configs using AM33xx SoC platform.

Signed-off-by: Pekon Gupta <pekon@ti.com>
2013-11-21 13:33:41 -06:00
Wolfgang Denk
1a4596601f Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24 09:44:38 -04:00
Sergey Lapin
4bfd0002b6 bug, nand, am33xx: nand->ecc.strength not set in board_nand_init()
commit dfe64e2c89
Author: Sergey Lapin <slapin@ossfans.org>
Date:   Mon Jan 14 03:46:50 2013 +0000

    mtd: resync with Linux-3.7.1

Introduced runtime bug:

U-Boot 2013.04-00499-g46567df-dirty (Jun 04 2013 - 08:17:08)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  BUG: failure at nand_base.c:3214/nand_scan_tail()!
BUG!
resetting ...

on boards using drivers/mtd/nand/omap_gpmc.c as in board_nand_init()
nand->ecc.strength is not set. Fix this!

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>
2013-06-04 11:50:04 -05:00
Sergey Lapin
dfe64e2c89 mtd: resync with Linux-3.7.1
This patch is essentially an update of u-boot MTD subsystem to
the state of Linux-3.7.1 with exclusion of some bits:

- the update is concentrated on NAND, no onenand or CFI/NOR/SPI
flashes interfaces are updated EXCEPT for API changes.

- new large NAND chips support is there, though some updates
have got in Linux-3.8.-rc1, (which will follow on top of this patch).

To produce this update I used tag v3.7.1 of linux-stable repository.

The update was made using application of relevant patches,
with changes relevant to U-Boot-only stuff sticked together
to keep bisectability. Then all changes were grouped together
to this patch.

Signed-off-by: Sergey Lapin <slapin@ossfans.org>
[scottwood@freescale.com: some eccstrength and build fixes]
Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-05-31 17:12:03 -05:00
Andreas Bießmann
4a0930069b omap_gpmc: add support for hw assisted BCH8
The kernel states:

---8<---
The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not
provide automatic error location and correction: this step is implemented using
the BCH library.
--->8---

And we do so in u-boot.

This implementation uses the same layout for BCH8 but it is fix. The current
provided layout does only work with 64 Byte OOB.

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Mansoor Ahamed <mansoor.ahamed@ti.com>
Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
2013-04-08 11:29:05 -04:00
Andreas Bießmann
da634ae356 omap_gpmc: change nandecc command
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine.  Currently we support 1-bit hammign
and 8-bit BCH on HW backend.

In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
2013-04-08 11:29:05 -04:00
Andreas Bießmann
5bf299bc4f asm/omap_gpmc.h: consolidate common defines
arch/arm/include/asm/arch-am33xx/omap_gpmc.h and
arch/arm/include/asm/arch-omap3/omap_gpmc.h are almost the same, consolidate
the common parts into a new header.

Introduce a new asm/omap_gpmc.h which defines the command part and pulls in
the architecture specific one.

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
2013-04-08 11:29:05 -04:00
Tom Rini
98f92001b3 am33xx: Add required includes to some omap/am33xx code
- In arch/arm/cpu/armv7/omap-common/timer.c,
  drivers/mtd/nand/omap_gpmc.c and drivers/net/cpsw.c add #include files
  that the driver needs but had been relying on <config.h> to bring in.
- In arch/arm/cpu/armv7/omap-common/lowlevel_init.S add <config.h>
- In am335x_evm.h and pcm051.h don't globally include
  <asm/arch/hardware.h> and <asm/arch/cpu.h> but just <asm/arch/omap.h>
  as that is the only include which defines things the config uses.

Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Tom Rini <trini@ti.com>
2013-03-24 12:49:11 -04:00