1*4882a593SmuzhiyunNAND FLASH commands and notes 2*4882a593Smuzhiyun 3*4882a593SmuzhiyunSee NOTE below!!! 4*4882a593Smuzhiyun 5*4882a593Smuzhiyun# (C) Copyright 2003 6*4882a593Smuzhiyun# Dave Ellis, SIXNET, dge@sixnetio.com 7*4882a593Smuzhiyun# 8*4882a593Smuzhiyun# SPDX-License-Identifier: GPL-2.0+ 9*4882a593Smuzhiyun 10*4882a593SmuzhiyunCommands: 11*4882a593Smuzhiyun 12*4882a593Smuzhiyun nand bad 13*4882a593Smuzhiyun Print a list of all of the bad blocks in the current device. 14*4882a593Smuzhiyun 15*4882a593Smuzhiyun nand device 16*4882a593Smuzhiyun Print information about the current NAND device. 17*4882a593Smuzhiyun 18*4882a593Smuzhiyun nand device num 19*4882a593Smuzhiyun Make device `num' the current device and print information about it. 20*4882a593Smuzhiyun 21*4882a593Smuzhiyun nand erase off|partition size 22*4882a593Smuzhiyun nand erase clean [off|partition size] 23*4882a593Smuzhiyun Erase `size' bytes starting at offset `off'. Alternatively partition 24*4882a593Smuzhiyun name can be specified, in this case size will be eventually limited 25*4882a593Smuzhiyun to not exceed partition size (this behaviour applies also to read 26*4882a593Smuzhiyun and write commands). Only complete erase blocks can be erased. 27*4882a593Smuzhiyun 28*4882a593Smuzhiyun If `erase' is specified without an offset or size, the entire flash 29*4882a593Smuzhiyun is erased. If `erase' is specified with partition but without an 30*4882a593Smuzhiyun size, the entire partition is erased. 31*4882a593Smuzhiyun 32*4882a593Smuzhiyun If `clean' is specified, a JFFS2-style clean marker is written to 33*4882a593Smuzhiyun each block after it is erased. 34*4882a593Smuzhiyun 35*4882a593Smuzhiyun This command will not erase blocks that are marked bad. There is 36*4882a593Smuzhiyun a debug option in cmd_nand.c to allow bad blocks to be erased. 37*4882a593Smuzhiyun Please read the warning there before using it, as blocks marked 38*4882a593Smuzhiyun bad by the manufacturer must _NEVER_ be erased. 39*4882a593Smuzhiyun 40*4882a593Smuzhiyun nand info 41*4882a593Smuzhiyun Print information about all of the NAND devices found. 42*4882a593Smuzhiyun 43*4882a593Smuzhiyun nand read addr ofs|partition size 44*4882a593Smuzhiyun Read `size' bytes from `ofs' in NAND flash to `addr'. Blocks that 45*4882a593Smuzhiyun are marked bad are skipped. If a page cannot be read because an 46*4882a593Smuzhiyun uncorrectable data error is found, the command stops with an error. 47*4882a593Smuzhiyun 48*4882a593Smuzhiyun nand read.oob addr ofs|partition size 49*4882a593Smuzhiyun Read `size' bytes from the out-of-band data area corresponding to 50*4882a593Smuzhiyun `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of 51*4882a593Smuzhiyun data for one 512-byte page or 2 256-byte pages. There is no check 52*4882a593Smuzhiyun for bad blocks or ECC errors. 53*4882a593Smuzhiyun 54*4882a593Smuzhiyun nand write addr ofs|partition size 55*4882a593Smuzhiyun Write `size' bytes from `addr' to `ofs' in NAND flash. Blocks that 56*4882a593Smuzhiyun are marked bad are skipped. If a page cannot be read because an 57*4882a593Smuzhiyun uncorrectable data error is found, the command stops with an error. 58*4882a593Smuzhiyun 59*4882a593Smuzhiyun As JFFS2 skips blocks similarly, this allows writing a JFFS2 image, 60*4882a593Smuzhiyun as long as the image is short enough to fit even after skipping the 61*4882a593Smuzhiyun bad blocks. Compact images, such as those produced by mkfs.jffs2 62*4882a593Smuzhiyun should work well, but loading an image copied from another flash is 63*4882a593Smuzhiyun going to be trouble if there are any bad blocks. 64*4882a593Smuzhiyun 65*4882a593Smuzhiyun nand write.trimffs addr ofs|partition size 66*4882a593Smuzhiyun Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to 67*4882a593Smuzhiyun the NAND flash in a manner identical to the 'nand write' command 68*4882a593Smuzhiyun described above -- with the additional check that all pages at the end 69*4882a593Smuzhiyun of eraseblocks which contain only 0xff data will not be written to the 70*4882a593Smuzhiyun NAND flash. This behaviour is required when flashing UBI images 71*4882a593Smuzhiyun containing UBIFS volumes as per the UBI FAQ[1]. 72*4882a593Smuzhiyun 73*4882a593Smuzhiyun [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo 74*4882a593Smuzhiyun 75*4882a593Smuzhiyun nand write.oob addr ofs|partition size 76*4882a593Smuzhiyun Write `size' bytes from `addr' to the out-of-band data area 77*4882a593Smuzhiyun corresponding to `ofs' in NAND flash. This is limited to the 16 bytes 78*4882a593Smuzhiyun of data for one 512-byte page or 2 256-byte pages. There is no check 79*4882a593Smuzhiyun for bad blocks. 80*4882a593Smuzhiyun 81*4882a593Smuzhiyun nand read.raw addr ofs|partition [count] 82*4882a593Smuzhiyun nand write.raw addr ofs|partition [count] 83*4882a593Smuzhiyun Read or write one or more pages at "ofs" in NAND flash, from or to 84*4882a593Smuzhiyun "addr" in memory. This is a raw access, so ECC is avoided and the 85*4882a593Smuzhiyun OOB area is transferred as well. If count is absent, it is assumed 86*4882a593Smuzhiyun to be one page. As with .yaffs2 accesses, the data is formatted as 87*4882a593Smuzhiyun a packed sequence of "data, oob, data, oob, ..." -- no alignment of 88*4882a593Smuzhiyun individual pages is maintained. 89*4882a593Smuzhiyun 90*4882a593SmuzhiyunConfiguration Options: 91*4882a593Smuzhiyun 92*4882a593Smuzhiyun CONFIG_SYS_NAND_U_BOOT_OFFS 93*4882a593Smuzhiyun NAND Offset from where SPL will read u-boot image. This is the starting 94*4882a593Smuzhiyun address of u-boot MTD partition in NAND. 95*4882a593Smuzhiyun 96*4882a593Smuzhiyun CONFIG_CMD_NAND 97*4882a593Smuzhiyun Enables NAND support and commands. 98*4882a593Smuzhiyun 99*4882a593Smuzhiyun CONFIG_CMD_NAND_TORTURE 100*4882a593Smuzhiyun Enables the torture command (see description of this command below). 101*4882a593Smuzhiyun 102*4882a593Smuzhiyun CONFIG_SYS_MAX_NAND_DEVICE 103*4882a593Smuzhiyun The maximum number of NAND devices you want to support. 104*4882a593Smuzhiyun 105*4882a593Smuzhiyun CONFIG_SYS_NAND_MAX_ECCPOS 106*4882a593Smuzhiyun If specified, overrides the maximum number of ECC bytes 107*4882a593Smuzhiyun supported. Useful for reducing image size, especially with SPL. 108*4882a593Smuzhiyun This must be at least 48 if nand_base.c is used. 109*4882a593Smuzhiyun 110*4882a593Smuzhiyun CONFIG_SYS_NAND_MAX_OOBFREE 111*4882a593Smuzhiyun If specified, overrides the maximum number of free OOB regions 112*4882a593Smuzhiyun supported. Useful for reducing image size, especially with SPL. 113*4882a593Smuzhiyun This must be at least 2 if nand_base.c is used. 114*4882a593Smuzhiyun 115*4882a593Smuzhiyun CONFIG_SYS_NAND_MAX_CHIPS 116*4882a593Smuzhiyun The maximum number of NAND chips per device to be supported. 117*4882a593Smuzhiyun 118*4882a593Smuzhiyun CONFIG_SYS_NAND_SELF_INIT 119*4882a593Smuzhiyun Traditionally, glue code in drivers/mtd/nand/raw/nand.c has driven 120*4882a593Smuzhiyun the initialization process -- it provides the mtd and nand 121*4882a593Smuzhiyun structs, calls a board init function for a specific device, 122*4882a593Smuzhiyun calls nand_scan(), and registers with mtd. 123*4882a593Smuzhiyun 124*4882a593Smuzhiyun This arrangement does not provide drivers with the flexibility to 125*4882a593Smuzhiyun run code between nand_scan_ident() and nand_scan_tail(), or other 126*4882a593Smuzhiyun deviations from the "normal" flow. 127*4882a593Smuzhiyun 128*4882a593Smuzhiyun If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/raw/nand.c 129*4882a593Smuzhiyun will make one call to board_nand_init(), with no arguments. That 130*4882a593Smuzhiyun function is responsible for calling a driver init function for 131*4882a593Smuzhiyun each NAND device on the board, that performs all initialization 132*4882a593Smuzhiyun tasks except setting mtd->name, and registering with the rest of 133*4882a593Smuzhiyun U-Boot. Those last tasks are accomplished by calling nand_register() 134*4882a593Smuzhiyun on the new mtd device. 135*4882a593Smuzhiyun 136*4882a593Smuzhiyun Example of new init to be added to the end of an existing driver 137*4882a593Smuzhiyun init: 138*4882a593Smuzhiyun 139*4882a593Smuzhiyun /* chip is struct nand_chip, and is now provided by the driver. */ 140*4882a593Smuzhiyun mtd = nand_to_mtd(&chip); 141*4882a593Smuzhiyun 142*4882a593Smuzhiyun /* 143*4882a593Smuzhiyun * Fill in appropriate values if this driver uses these fields, 144*4882a593Smuzhiyun * or uses the standard read_byte/write_buf/etc. functions from 145*4882a593Smuzhiyun * nand_base.c that use these fields. 146*4882a593Smuzhiyun */ 147*4882a593Smuzhiyun chip.IO_ADDR_R = ...; 148*4882a593Smuzhiyun chip.IO_ADDR_W = ...; 149*4882a593Smuzhiyun 150*4882a593Smuzhiyun if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL)) 151*4882a593Smuzhiyun error out 152*4882a593Smuzhiyun 153*4882a593Smuzhiyun /* 154*4882a593Smuzhiyun * Insert here any code you wish to run after the chip has been 155*4882a593Smuzhiyun * identified, but before any other I/O is done. 156*4882a593Smuzhiyun */ 157*4882a593Smuzhiyun 158*4882a593Smuzhiyun if (nand_scan_tail(mtd)) 159*4882a593Smuzhiyun error out 160*4882a593Smuzhiyun 161*4882a593Smuzhiyun /* 162*4882a593Smuzhiyun * devnum is the device number to be used in nand commands 163*4882a593Smuzhiyun * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE. 164*4882a593Smuzhiyun */ 165*4882a593Smuzhiyun if (nand_register(devnum, mtd)) 166*4882a593Smuzhiyun error out 167*4882a593Smuzhiyun 168*4882a593Smuzhiyun In addition to providing more flexibility to the driver, it reduces 169*4882a593Smuzhiyun the difference between a U-Boot driver and its Linux counterpart. 170*4882a593Smuzhiyun nand_init() is now reduced to calling board_nand_init() once, and 171*4882a593Smuzhiyun printing a size summary. This should also make it easier to 172*4882a593Smuzhiyun transition to delayed NAND initialization. 173*4882a593Smuzhiyun 174*4882a593Smuzhiyun Please convert your driver even if you don't need the extra 175*4882a593Smuzhiyun flexibility, so that one day we can eliminate the old mechanism. 176*4882a593Smuzhiyun 177*4882a593Smuzhiyun 178*4882a593Smuzhiyun CONFIG_SYS_NAND_ONFI_DETECTION 179*4882a593Smuzhiyun Enables detection of ONFI compliant devices during probe. 180*4882a593Smuzhiyun And fetching device parameters flashed on device, by parsing 181*4882a593Smuzhiyun ONFI parameter page. 182*4882a593Smuzhiyun 183*4882a593SmuzhiyunPlatform specific options 184*4882a593Smuzhiyun========================= 185*4882a593Smuzhiyun CONFIG_NAND_OMAP_GPMC 186*4882a593Smuzhiyun Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms. 187*4882a593Smuzhiyun GPMC controller is used for parallel NAND flash devices, and can 188*4882a593Smuzhiyun do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8 189*4882a593Smuzhiyun and BCH16 ECC algorithms. 190*4882a593Smuzhiyun 191*4882a593Smuzhiyun CONFIG_NAND_OMAP_ELM 192*4882a593Smuzhiyun Enables omap_elm.c driver for OMAPx and AMxxxx platforms. 193*4882a593Smuzhiyun ELM controller is used for ECC error detection (not ECC calculation) 194*4882a593Smuzhiyun of BCH4, BCH8 and BCH16 ECC algorithms. 195*4882a593Smuzhiyun Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine, 196*4882a593Smuzhiyun thus such SoC platforms need to depend on software library for ECC error 197*4882a593Smuzhiyun detection. However ECC calculation on such plaforms would still be 198*4882a593Smuzhiyun done by GPMC controller. 199*4882a593Smuzhiyun 200*4882a593Smuzhiyun CONFIG_SPL_NAND_AM33XX_BCH 201*4882a593Smuzhiyun Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based 202*4882a593Smuzhiyun hardware ECC correction. This is useful for platforms which have ELM 203*4882a593Smuzhiyun hardware engine and use NAND boot mode. 204*4882a593Smuzhiyun Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine, 205*4882a593Smuzhiyun so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling 206*4882a593Smuzhiyun SPL-NAND driver with software ECC correction support. 207*4882a593Smuzhiyun 208*4882a593Smuzhiyun CONFIG_NAND_OMAP_ECCSCHEME 209*4882a593Smuzhiyun On OMAP platforms, this CONFIG specifies NAND ECC scheme. 210*4882a593Smuzhiyun It can take following values: 211*4882a593Smuzhiyun OMAP_ECC_HAM1_CODE_SW 212*4882a593Smuzhiyun 1-bit Hamming code using software lib. 213*4882a593Smuzhiyun (for legacy devices only) 214*4882a593Smuzhiyun OMAP_ECC_HAM1_CODE_HW 215*4882a593Smuzhiyun 1-bit Hamming code using GPMC hardware. 216*4882a593Smuzhiyun (for legacy devices only) 217*4882a593Smuzhiyun OMAP_ECC_BCH4_CODE_HW_DETECTION_SW 218*4882a593Smuzhiyun 4-bit BCH code (unsupported) 219*4882a593Smuzhiyun OMAP_ECC_BCH4_CODE_HW 220*4882a593Smuzhiyun 4-bit BCH code (unsupported) 221*4882a593Smuzhiyun OMAP_ECC_BCH8_CODE_HW_DETECTION_SW 222*4882a593Smuzhiyun 8-bit BCH code with 223*4882a593Smuzhiyun - ecc calculation using GPMC hardware engine, 224*4882a593Smuzhiyun - error detection using software library. 225*4882a593Smuzhiyun - requires CONFIG_BCH to enable software BCH library 226*4882a593Smuzhiyun (For legacy device which do not have ELM h/w engine) 227*4882a593Smuzhiyun OMAP_ECC_BCH8_CODE_HW 228*4882a593Smuzhiyun 8-bit BCH code with 229*4882a593Smuzhiyun - ecc calculation using GPMC hardware engine, 230*4882a593Smuzhiyun - error detection using ELM hardware engine. 231*4882a593Smuzhiyun OMAP_ECC_BCH16_CODE_HW 232*4882a593Smuzhiyun 16-bit BCH code with 233*4882a593Smuzhiyun - ecc calculation using GPMC hardware engine, 234*4882a593Smuzhiyun - error detection using ELM hardware engine. 235*4882a593Smuzhiyun 236*4882a593Smuzhiyun How to select ECC scheme on OMAP and AMxx platforms ? 237*4882a593Smuzhiyun ----------------------------------------------------- 238*4882a593Smuzhiyun Though higher ECC schemes have more capability to detect and correct 239*4882a593Smuzhiyun bit-flips, but still selection of ECC scheme is dependent on following 240*4882a593Smuzhiyun - hardware engines present in SoC. 241*4882a593Smuzhiyun Some legacy OMAP SoC do not have ELM h/w engine thus such 242*4882a593Smuzhiyun SoC cannot support BCHx_HW ECC schemes. 243*4882a593Smuzhiyun - size of OOB/Spare region 244*4882a593Smuzhiyun With higher ECC schemes, more OOB/Spare area is required to 245*4882a593Smuzhiyun store ECC. So choice of ECC scheme is limited by NAND oobsize. 246*4882a593Smuzhiyun 247*4882a593Smuzhiyun In general following expression can help: 248*4882a593Smuzhiyun NAND_OOBSIZE >= 2 + (NAND_PAGESIZE / 512) * ECC_BYTES 249*4882a593Smuzhiyun where 250*4882a593Smuzhiyun NAND_OOBSIZE = number of bytes available in 251*4882a593Smuzhiyun OOB/spare area per NAND page. 252*4882a593Smuzhiyun NAND_PAGESIZE = bytes in main-area of NAND page. 253*4882a593Smuzhiyun ECC_BYTES = number of ECC bytes generated to 254*4882a593Smuzhiyun protect 512 bytes of data, which is: 255*4882a593Smuzhiyun 3 for HAM1_xx ecc schemes 256*4882a593Smuzhiyun 7 for BCH4_xx ecc schemes 257*4882a593Smuzhiyun 14 for BCH8_xx ecc schemes 258*4882a593Smuzhiyun 26 for BCH16_xx ecc schemes 259*4882a593Smuzhiyun 260*4882a593Smuzhiyun example to check for BCH16 on 2K page NAND 261*4882a593Smuzhiyun NAND_PAGESIZE = 2048 262*4882a593Smuzhiyun NAND_OOBSIZE = 64 263*4882a593Smuzhiyun 2 + (2048 / 512) * 26 = 106 > NAND_OOBSIZE 264*4882a593Smuzhiyun Thus BCH16 cannot be supported on 2K page NAND. 265*4882a593Smuzhiyun 266*4882a593Smuzhiyun However, for 4K pagesize NAND 267*4882a593Smuzhiyun NAND_PAGESIZE = 4096 268*4882a593Smuzhiyun NAND_OOBSIZE = 224 269*4882a593Smuzhiyun ECC_BYTES = 26 270*4882a593Smuzhiyun 2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE 271*4882a593Smuzhiyun Thus BCH16 can be supported on 4K page NAND. 272*4882a593Smuzhiyun 273*4882a593Smuzhiyun 274*4882a593Smuzhiyun CONFIG_NAND_OMAP_GPMC_PREFETCH 275*4882a593Smuzhiyun On OMAP platforms that use the GPMC controller 276*4882a593Smuzhiyun (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that 277*4882a593Smuzhiyun uses the prefetch mode to speed up read operations. 278*4882a593Smuzhiyun 279*4882a593SmuzhiyunNOTE: 280*4882a593Smuzhiyun===== 281*4882a593Smuzhiyun 282*4882a593SmuzhiyunThe Disk On Chip driver is currently broken and has been for some time. 283*4882a593SmuzhiyunThere is a driver in drivers/mtd/nand/raw, taken from Linux, that works with 284*4882a593Smuzhiyunthe current NAND system but has not yet been adapted to the u-boot 285*4882a593Smuzhiyunenvironment. 286*4882a593Smuzhiyun 287*4882a593SmuzhiyunAdditional improvements to the NAND subsystem by Guido Classen, 10-10-2006 288*4882a593Smuzhiyun 289*4882a593SmuzhiyunJFFS2 related commands: 290*4882a593Smuzhiyun 291*4882a593Smuzhiyun implement "nand erase clean" and old "nand erase" 292*4882a593Smuzhiyun using both the new code which is able to skip bad blocks 293*4882a593Smuzhiyun "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob. 294*4882a593Smuzhiyun 295*4882a593SmuzhiyunMiscellaneous and testing commands: 296*4882a593Smuzhiyun "markbad [offset]" 297*4882a593Smuzhiyun create an artificial bad block (for testing bad block handling) 298*4882a593Smuzhiyun 299*4882a593Smuzhiyun "scrub [offset length]" 300*4882a593Smuzhiyun like "erase" but don't skip bad block. Instead erase them. 301*4882a593Smuzhiyun DANGEROUS!!! Factory set bad blocks will be lost. Use only 302*4882a593Smuzhiyun to remove artificial bad blocks created with the "markbad" command. 303*4882a593Smuzhiyun 304*4882a593Smuzhiyun "torture offset [size]" 305*4882a593Smuzhiyun Torture block to determine if it is still reliable. 306*4882a593Smuzhiyun Enabled by the CONFIG_CMD_NAND_TORTURE configuration option. 307*4882a593Smuzhiyun This command returns 0 if the block is still reliable, else 1. 308*4882a593Smuzhiyun If the block is detected as unreliable, it is up to the user to decide to 309*4882a593Smuzhiyun mark this block as bad. 310*4882a593Smuzhiyun The analyzed block is put through 3 erase / write cycles (or less if the block 311*4882a593Smuzhiyun is detected as unreliable earlier). 312*4882a593Smuzhiyun This command can be used in scripts, e.g. together with the markbad command to 313*4882a593Smuzhiyun automate retries and handling of possibly newly detected bad blocks if the 314*4882a593Smuzhiyun nand write command fails. 315*4882a593Smuzhiyun It can also be used manually by users having seen some NAND errors in logs to 316*4882a593Smuzhiyun search the root cause of these errors. 317*4882a593Smuzhiyun The underlying nand_torture() function is also useful for code willing to 318*4882a593Smuzhiyun automate actions following a nand->write() error. This would e.g. be required 319*4882a593Smuzhiyun in order to program or update safely firmware to NAND, especially for the UBI 320*4882a593Smuzhiyun part of such firmware. 321*4882a593Smuzhiyun Optionally, a second parameter size can be given to test multiple blocks with 322*4882a593Smuzhiyun one call. If size is not a multiple of the NAND's erase size, then the block 323*4882a593Smuzhiyun that contains offset + size will be tested in full. If used with size, this 324*4882a593Smuzhiyun command returns 0 if all tested blocks have been found reliable, else 1. 325*4882a593Smuzhiyun 326*4882a593Smuzhiyun 327*4882a593SmuzhiyunNAND locking command (for chips with active LOCKPRE pin) 328*4882a593Smuzhiyun 329*4882a593Smuzhiyun "nand lock" 330*4882a593Smuzhiyun set NAND chip to lock state (all pages locked) 331*4882a593Smuzhiyun 332*4882a593Smuzhiyun "nand lock tight" 333*4882a593Smuzhiyun set NAND chip to lock tight state (software can't change locking anymore) 334*4882a593Smuzhiyun 335*4882a593Smuzhiyun "nand lock status" 336*4882a593Smuzhiyun displays current locking status of all pages 337*4882a593Smuzhiyun 338*4882a593Smuzhiyun "nand unlock [offset] [size]" 339*4882a593Smuzhiyun unlock consecutive area (can be called multiple times for different areas) 340*4882a593Smuzhiyun 341*4882a593Smuzhiyun "nand unlock.allexcept [offset] [size]" 342*4882a593Smuzhiyun unlock all except specified consecutive area 343*4882a593Smuzhiyun 344*4882a593SmuzhiyunI have tested the code with board containing 128MiB NAND large page chips 345*4882a593Smuzhiyunand 32MiB small page chips. 346