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