X-Git-Url: https://git.kernelconcepts.de/?p=karo-tx-uboot.git;a=blobdiff_plain;f=doc%2FREADME.nand;h=b91f1985d183d0c3681567293cae7d666139a441;hp=6dac24cd90adcfb0eb8e73892882ce27ea8cd955;hb=3f719069c884284b2457448a7afe32b02bd4f782;hpb=508eb85db7065e34948c189c83f7e348c1cfd61e diff --git a/doc/README.nand b/doc/README.nand index 6dac24cd90..b91f1985d1 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -5,23 +5,7 @@ See NOTE below!!! # (C) Copyright 2003 # Dave Ellis, SIXNET, dge@sixnetio.com # -# 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: @@ -78,135 +62,189 @@ 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_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_MTD_NAND_ECC_YAFFS would be another useful choice for someone to implement. - CFG_MAX_NAND_DEVICE + 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 CFG_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 NAND_MAX_CHIPS 1 - - #define CFG_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. + + +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_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. 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 @@ -225,6 +263,24 @@ Miscellaneous and testing commands: 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) @@ -240,6 +296,8 @@ 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.