X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=doc%2FREADME.nand;h=ffcea9079990008350b452f3921fd7ad1139eb5b;hb=74337aa4506c76e790ab45ad4f4ab854f25d19da;hp=320d752952971a936e36b2cc654f630fa628aa07;hpb=f9860cf081efdf32c8a01b9fc271fe55e2a79f8d;p=platform%2Fkernel%2Fu-boot.git diff --git a/doc/README.nand b/doc/README.nand index 320d752..ffcea90 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0+ NAND FLASH commands and notes See NOTE below!!! @@ -5,7 +6,6 @@ See NOTE below!!! # (C) Copyright 2003 # Dave Ellis, SIXNET, dge@sixnetio.com # -# SPDX-License-Identifier: GPL-2.0+ Commands: @@ -94,17 +94,11 @@ Configuration Options: address of u-boot MTD partition in NAND. CONFIG_CMD_NAND - Enables NAND support and commmands. + Enables NAND support and commands. 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. - CONFIG_SYS_MAX_NAND_DEVICE The maximum number of NAND devices you want to support. @@ -122,7 +116,7 @@ Configuration Options: 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 + Traditionally, glue code in drivers/mtd/nand/raw/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. @@ -131,7 +125,7 @@ Configuration Options: 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 + If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/raw/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 @@ -142,15 +136,8 @@ Configuration Options: 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; + mtd = nand_to_mtd(&chip); /* * Fill in appropriate values if this driver uses these fields, @@ -171,7 +158,11 @@ Configuration Options: if (nand_scan_tail(mtd)) error out - if (nand_register(devnum)) + /* + * devnum is the device number to be used in nand commands + * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE. + */ + if (nand_register(devnum, mtd)) error out In addition to providing more flexibility to the driver, it reduces @@ -184,43 +175,8 @@ Configuration Options: 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_DENALI - Enables the denali.c driver. - - CONFIG_SYS_NAND_DENALI_64BIT - Indicates that the Denali NAND controller is the 64-bit variant. - 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 @@ -244,83 +200,16 @@ Platform specific options 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: ===== -The current NAND implementation is based on what is in recent -Linux kernels. The old legacy implementation has been removed. - -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 +There is a driver in drivers/mtd/nand/raw, taken from Linux, that works with the current NAND system but has not yet been adapted to the u-boot environment. @@ -341,7 +230,7 @@ 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 offset [size]" 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. @@ -358,6 +247,10 @@ Miscellaneous and testing commands: 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. + Optionally, a second parameter size can be given to test multiple blocks with + one call. If size is not a multiple of the NAND's erase size, then the block + that contains offset + size will be tested in full. If used with size, this + command returns 0 if all tested blocks have been found reliable, else 1. NAND locking command (for chips with active LOCKPRE pin)