# (C) Copyright 2003
#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
+# SPDX-License-Identifier: GPL-2.0+
Commands:
should work well, but loading an image copied from another flash is
going to be trouble if there are any bad blocks.
+ nand write.trimffs addr ofs|partition size
+ Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to
+ the NAND flash in a manner identical to the 'nand write' command
+ described above -- with the additional check that all pages at the end
+ of eraseblocks which contain only 0xff data will not be written to the
+ NAND flash. This behaviour is required when flashing UBI images
+ containing UBIFS volumes as per the UBI FAQ[1].
+
+ [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
+
nand write.oob addr ofs|partition size
Write `size' bytes from `addr' to the out-of-band data area
corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
of data for one 512-byte page or 2 256-byte pages. There is no check
for bad blocks.
+ nand read.raw addr ofs|partition [count]
+ nand write.raw addr ofs|partition [count]
+ Read or write one or more pages at "ofs" in NAND flash, from or to
+ "addr" in memory. This is a raw access, so ECC is avoided and the
+ OOB area is transferred as well. If count is absent, it is assumed
+ to be one page. As with .yaffs2 accesses, the data is formatted as
+ a packed sequence of "data, oob, data, oob, ..." -- no alignment of
+ individual pages is maintained.
+
Configuration Options:
+ CONFIG_SYS_NAND_U_BOOT_OFFS
+ NAND Offset from where SPL will read u-boot image. This is the starting
+ address of u-boot MTD partition in NAND.
+
CONFIG_CMD_NAND
Enables NAND support and commmands.
+ CONFIG_CMD_NAND_TORTURE
+ Enables the torture command (see description of this command below).
+
CONFIG_MTD_NAND_ECC_JFFS2
Define this if you want the Error Correction Code information in
the out-of-band data to be formatted to match the JFFS2 file system.
CONFIG_SYS_MAX_NAND_DEVICE
The maximum number of NAND devices you want to support.
-NAND Interface:
-
- #define NAND_WAIT_READY(nand)
- Wait until the NAND flash is ready. Typically this would be a
- loop waiting for the READY/BUSY line from the flash to indicate it
- it is ready.
-
- #define WRITE_NAND_COMMAND(d, adr)
- Write the command byte `d' to the flash at `adr' with the
- CLE (command latch enable) line true. If your board uses writes to
- different addresses to control CLE and ALE, you can modify `adr'
- to be the appropriate address here. If your board uses I/O registers
- to control them, it is probably better to let NAND_CTL_SETCLE()
- and company do it.
-
- #define WRITE_NAND_ADDRESS(d, adr)
- Write the address byte `d' to the flash at `adr' with the
- ALE (address latch enable) line true. If your board uses writes to
- different addresses to control CLE and ALE, you can modify `adr'
- to be the appropriate address here. If your board uses I/O registers
- to control them, it is probably better to let NAND_CTL_SETALE()
- and company do it.
-
- #define WRITE_NAND(d, adr)
- Write the data byte `d' to the flash at `adr' with the
- ALE and CLE lines false. If your board uses writes to
- different addresses to control CLE and ALE, you can modify `adr'
- to be the appropriate address here. If your board uses I/O registers
- to control them, it is probably better to let NAND_CTL_CLRALE()
- and company do it.
-
- #define READ_NAND(adr)
- Read a data byte from the flash at `adr' with the
- ALE and CLE lines false. If your board uses reads from
- different addresses to control CLE and ALE, you can modify `adr'
- to be the appropriate address here. If your board uses I/O registers
- to control them, it is probably better to let NAND_CTL_CLRALE()
- and company do it.
-
- #define NAND_DISABLE_CE(nand)
- Set CE (Chip Enable) low to enable the NAND flash.
-
- #define NAND_ENABLE_CE(nand)
- Set CE (Chip Enable) high to disable the NAND flash.
-
- #define NAND_CTL_CLRALE(nandptr)
- Set ALE (address latch enable) low. If ALE control is handled by
- WRITE_NAND_ADDRESS() this can be empty.
-
- #define NAND_CTL_SETALE(nandptr)
- Set ALE (address latch enable) high. If ALE control is handled by
- WRITE_NAND_ADDRESS() this can be empty.
-
- #define NAND_CTL_CLRCLE(nandptr)
- Set CLE (command latch enable) low. If CLE control is handled by
- WRITE_NAND_ADDRESS() this can be empty.
-
- #define NAND_CTL_SETCLE(nandptr)
- Set CLE (command latch enable) high. If CLE control is handled by
- WRITE_NAND_ADDRESS() this can be empty.
-
-More Definitions:
-
- These definitions are needed in the board configuration for now, but
- may really belong in a header file.
- TODO: Figure which ones are truly configuration settings and rename
- them to CONFIG_SYS_NAND_... and move the rest somewhere appropriate.
-
- #define SECTORSIZE 512
- #define ADDR_COLUMN 1
- #define ADDR_PAGE 2
- #define ADDR_COLUMN_PAGE 3
- #define NAND_ChipID_UNKNOWN 0x00
- #define NAND_MAX_FLOORS 1
- #define CONFIG_SYS_NAND_MAX_CHIPS 1
-
- #define CONFIG_SYS_DAVINCI_BROKEN_ECC
- Versions of U-Boot <= 1.3.3 and Montavista Linux kernels
- generated bogus ECCs on large-page NAND. Both large and small page
- NAND ECCs were incompatible with the Linux davinci git tree (since
- NAND was integrated in 2.6.24).
- Turn this ON if you want backwards compatibility.
- Turn this OFF if you want U-Boot and the Linux davinci git kernel
- to use the same ECC format.
+ CONFIG_SYS_NAND_MAX_ECCPOS
+ If specified, overrides the maximum number of ECC bytes
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 48 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_OOBFREE
+ If specified, overrides the maximum number of free OOB regions
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 2 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_CHIPS
+ The maximum number of NAND chips per device to be supported.
+
+ CONFIG_SYS_NAND_SELF_INIT
+ Traditionally, glue code in drivers/mtd/nand/nand.c has driven
+ the initialization process -- it provides the mtd and nand
+ structs, calls a board init function for a specific device,
+ calls nand_scan(), and registers with mtd.
+
+ This arrangement does not provide drivers with the flexibility to
+ run code between nand_scan_ident() and nand_scan_tail(), or other
+ deviations from the "normal" flow.
+
+ If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/nand.c
+ will make one call to board_nand_init(), with no arguments. That
+ function is responsible for calling a driver init function for
+ each NAND device on the board, that performs all initialization
+ tasks except setting mtd->name, and registering with the rest of
+ U-Boot. Those last tasks are accomplished by calling nand_register()
+ on the new mtd device.
+
+ Example of new init to be added to the end of an existing driver
+ init:
+
+ /*
+ * devnum is the device number to be used in nand commands
+ * and in mtd->name. Must be less than
+ * CONFIG_SYS_NAND_MAX_DEVICE.
+ */
+ mtd = &nand_info[devnum];
+
+ /* chip is struct nand_chip, and is now provided by the driver. */
+ mtd->priv = &chip;
+
+ /*
+ * Fill in appropriate values if this driver uses these fields,
+ * or uses the standard read_byte/write_buf/etc. functions from
+ * nand_base.c that use these fields.
+ */
+ chip.IO_ADDR_R = ...;
+ chip.IO_ADDR_W = ...;
+
+ if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
+ error out
+
+ /*
+ * Insert here any code you wish to run after the chip has been
+ * identified, but before any other I/O is done.
+ */
+
+ if (nand_scan_tail(mtd))
+ error out
+
+ if (nand_register(devnum))
+ error out
+
+ In addition to providing more flexibility to the driver, it reduces
+ the difference between a U-Boot driver and its Linux counterpart.
+ nand_init() is now reduced to calling board_nand_init() once, and
+ printing a size summary. This should also make it easier to
+ transition to delayed NAND initialization.
+
+ Please convert your driver even if you don't need the extra
+ flexibility, so that one day we can eliminate the old mechanism.
+
+
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
+
+ CONFIG_BCH
+ Enables software based BCH ECC algorithm present in lib/bch.c
+ This is used by SoC platforms which do not have built-in ELM
+ hardware engine required for BCH ECC correction.
+
+ CONFIG_SYS_NAND_BUSWIDTH_16BIT
+ Indicates that NAND device has 16-bit wide data-bus. In absence of this
+ config, bus-width of NAND device is assumed to be either 8-bit and later
+ determined by reading ONFI params.
+ Above config is useful when NAND device's bus-width information cannot
+ be determined from on-chip ONFI params, like in following scenarios:
+ - SPL boot does not support reading of ONFI parameters. This is done to
+ keep SPL code foot-print small.
+ - In current U-Boot flow using nand_init(), driver initialization
+ happens in board_nand_init() which is called before any device probe
+ (nand_scan_ident + nand_scan_tail), thus device's ONFI parameters are
+ not available while configuring controller. So a static CONFIG_NAND_xx
+ is needed to know the device's bus-width in advance.
+ Some drivers using above config are:
+ drivers/mtd/nand/mxc_nand.c
+ drivers/mtd/nand/ndfc.c
+ drivers/mtd/nand/omap_gpmc.c
+
+
+Platform specific options
+=========================
+ CONFIG_NAND_OMAP_GPMC
+ Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms.
+ GPMC controller is used for parallel NAND flash devices, and can
+ do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8
+ and BCH16 ECC algorithms.
+
+ CONFIG_NAND_OMAP_ELM
+ Enables omap_elm.c driver for OMAPx and AMxxxx platforms.
+ ELM controller is used for ECC error detection (not ECC calculation)
+ of BCH4, BCH8 and BCH16 ECC algorithms.
+ Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
+ thus such SoC platforms need to depend on software library for ECC error
+ detection. However ECC calculation on such plaforms would still be
+ done by GPMC controller.
+
+ CONFIG_SPL_NAND_AM33XX_BCH
+ Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based
+ hardware ECC correction. This is useful for platforms which have ELM
+ hardware engine and use NAND boot mode.
+ Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
+ so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling
+ SPL-NAND driver with software ECC correction support.
+
+ CONFIG_NAND_OMAP_ECCSCHEME
+ On OMAP platforms, this CONFIG specifies NAND ECC scheme.
+ It can take following values:
+ OMAP_ECC_HAM1_CODE_SW
+ 1-bit Hamming code using software lib.
+ (for legacy devices only)
+ OMAP_ECC_HAM1_CODE_HW
+ 1-bit Hamming code using GPMC hardware.
+ (for legacy devices only)
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH4_CODE_HW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using software library.
+ - requires CONFIG_BCH to enable software BCH library
+ (For legacy device which do not have ELM h/w engine)
+ OMAP_ECC_BCH8_CODE_HW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using ELM hardware engine.
+ OMAP_ECC_BCH16_CODE_HW
+ 16-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using ELM hardware engine.
+
+ How to select ECC scheme on OMAP and AMxx platforms ?
+ -----------------------------------------------------
+ Though higher ECC schemes have more capability to detect and correct
+ bit-flips, but still selection of ECC scheme is dependent on following
+ - hardware engines present in SoC.
+ Some legacy OMAP SoC do not have ELM h/w engine thus such
+ SoC cannot support BCHx_HW ECC schemes.
+ - size of OOB/Spare region
+ With higher ECC schemes, more OOB/Spare area is required to
+ store ECC. So choice of ECC scheme is limited by NAND oobsize.
+
+ In general following expression can help:
+ NAND_OOBSIZE >= 2 + (NAND_PAGESIZE / 512) * ECC_BYTES
+ where
+ NAND_OOBSIZE = number of bytes available in
+ OOB/spare area per NAND page.
+ NAND_PAGESIZE = bytes in main-area of NAND page.
+ ECC_BYTES = number of ECC bytes generated to
+ protect 512 bytes of data, which is:
+ 3 for HAM1_xx ecc schemes
+ 7 for BCH4_xx ecc schemes
+ 14 for BCH8_xx ecc schemes
+ 26 for BCH16_xx ecc schemes
+
+ example to check for BCH16 on 2K page NAND
+ NAND_PAGESIZE = 2048
+ NAND_OOBSIZE = 64
+ 2 + (2048 / 512) * 26 = 106 > NAND_OOBSIZE
+ Thus BCH16 cannot be supported on 2K page NAND.
+
+ However, for 4K pagesize NAND
+ NAND_PAGESIZE = 4096
+ NAND_OOBSIZE = 64
+ ECC_BYTES = 26
+ 2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE
+ Thus BCH16 can be supported on 4K page NAND.
+
+
+ CONFIG_NAND_OMAP_GPMC_PREFETCH
+ On OMAP platforms that use the GPMC controller
+ (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that
+ uses the prefetch mode to speed up read operations.
NOTE:
=====
-We now use a complete rewrite of the NAND code based on what is in
-2.6.12 Linux kernel.
-
-The old NAND handling code has been re-factored and is now confined
-to only board-specific files and - unfortunately - to the DoC code
-(see below). A new configuration variable has been introduced:
-CONFIG_NAND_LEGACY, which has to be defined in the board config file if
-that board uses legacy code.
+The current NAND implementation is based on what is in recent
+Linux kernels. The old legacy implementation has been removed.
-The necessary changes have been made to all affected boards, and no
-build breakage has been introduced, except for NETTA and NETTA_ISDN
-targets from MAKEALL. This is due to the fact that these two boards
-use JFFS, which has been adopted to use the new NAND, and at the same
-time use NAND in legacy mode. The breakage will disappear when the
-board-specific code is changed to the new NAND.
-
-As mentioned above, the legacy code is still used by the DoC subsystem.
-The consequence of this is that the legacy NAND can't be removed from
-the tree until the DoC is ported to use the new NAND support (or boards
-with DoC will break).
+If you have board code which used CONFIG_NAND_LEGACY, you'll need
+to convert to the current NAND interface for it to continue to work.
+The Disk On Chip driver is currently broken and has been for some time.
+There is a driver in drivers/mtd/nand, taken from Linux, that works with
+the current NAND system but has not yet been adapted to the u-boot
+environment.
Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
DANGEROUS!!! Factory set bad blocks will be lost. Use only
to remove artificial bad blocks created with the "markbad" command.
+ "torture offset"
+ Torture block to determine if it is still reliable.
+ Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
+ This command returns 0 if the block is still reliable, else 1.
+ If the block is detected as unreliable, it is up to the user to decide to
+ mark this block as bad.
+ The analyzed block is put through 3 erase / write cycles (or less if the block
+ is detected as unreliable earlier).
+ This command can be used in scripts, e.g. together with the markbad command to
+ automate retries and handling of possibly newly detected bad blocks if the
+ nand write command fails.
+ It can also be used manually by users having seen some NAND errors in logs to
+ search the root cause of these errors.
+ The underlying nand_torture() function is also useful for code willing to
+ automate actions following a nand->write() error. This would e.g. be required
+ in order to program or update safely firmware to NAND, especially for the UBI
+ part of such firmware.
+
NAND locking command (for chips with active LOCKPRE pin)
"nand unlock [offset] [size]"
unlock consecutive area (can be called multiple times for different areas)
+ "nand unlock.allexcept [offset] [size]"
+ unlock all except specified consecutive area
I have tested the code with board containing 128MiB NAND large page chips
and 32MiB small page chips.
projects / u-boot.git / blobdiff