X-Git-Url: https://git.kernelconcepts.de/?p=karo-tx-uboot.git;a=blobdiff_plain;f=doc%2FREADME.nand;fp=doc%2FREADME.nand;h=2bc5b391f8011956d613a5671142e0cbeaf6dbe4;hp=b91f1985d183d0c3681567293cae7d666139a441;hb=b80a66033856cc89c62886ae3e5ba54a7faf31ae;hpb=6e1899e633c2ac3f6da7101d4990361c6ff2a9d2

diff --git a/doc/README.nand b/doc/README.nand
index b91f1985d1..2bc5b391f8 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -190,6 +190,24 @@ Configuration Options:
 	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
 =========================