X-Git-Url: https://git.karo-electronics.de/?a=blobdiff_plain;f=doc%2FREADME.nand;h=46d7edd179f139bb9688bfe1557bd5cbbcc53daf;hb=4bdc27a1dca624fe74b58cd32074a3c2d2fd38a3;hp=b91f1985d183d0c3681567293cae7d666139a441;hpb=3f719069c884284b2457448a7afe32b02bd4f782;p=karo-tx-uboot.git diff --git a/doc/README.nand b/doc/README.nand index b91f1985d1..46d7edd179 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -89,18 +89,16 @@ Commands: Configuration Options: + CONFIG_SYS_NAND_U_BOOT_OFFS + NAND Offset from where SPL will read u-boot image. This is the starting + address of u-boot MTD partition in NAND. + 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. - CONFIG_SYS_MAX_NAND_DEVICE The maximum number of NAND devices you want to support. @@ -190,6 +188,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 ========================= @@ -208,6 +224,14 @@ Platform specific options detection. However ECC calculation on such plaforms would still be done by GPMC controller. + CONFIG_SPL_NAND_AM33XX_BCH + Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based + hardware ECC correction. This is useful for platforms which have ELM + hardware engine and use NAND boot mode. + Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine, + 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: @@ -231,16 +255,57 @@ Platform specific options 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 the current NAND system but has not yet been adapted to the u-boot