This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: BCH16 calculation tool

Part Number: AM3352

Tool/software: Linux

Hello,

I am working on generating the binary file for factory pre-programming NAND. Is there any tool or source code to calc the BCH16 oob data?

Best Regards

  • Device tree bindings for GPMC connected NANDsGPMC connected NAND (found on OMAP boards) are represented as child nodes ofthe GPMC controller with a name of "nand".All timing relevant properties as well as generic gpmc child properties areexplained in a separate documents - please refer toDocumentation/devicetree/bindings/bus/ti-gpmc.txtFor NAND specific properties such as ECC modes or bus width, please refer toDocumentation/devicetree/bindings/mtd/nand.txtRequired properties: - reg: The CS line the peripheral is connected toOptional properties: - nand-bus-width: Set this numeric value to 16 if the hardware is wired that way. If not specified, a bus width of 8 is assumed. - ti,nand-ecc-opt: A string setting the ECC layout to use. One of: "sw" 1-bit Hamming ecc code via software "hw" <deprecated> use "ham1" instead "hw-romcode" <deprecated> use "ham1" instead "ham1" 1-bit Hamming ecc code "bch4" 4-bit BCH ecc code "bch8" 8-bit BCH ecc code "bch16" 16-bit BCH ECC code Refer below "How to select correct ECC scheme for your device ?" - ti,nand-xfer-type: A string setting the data transfer type. One of: "prefetch-polled" Prefetch polled mode (default) "polled" Polled mode, without prefetch "prefetch-dma" Prefetch enabled sDMA mode "prefetch-irq" Prefetch enabled irq mode - elm_id: <deprecated> use "ti,elm-id" instead - ti,elm-id: Specifies phandle of the ELM devicetree node. ELM is an on-chip hardware engine on TI SoC which is used for locating ECC errors for BCHx algorithms. SoC devices which have ELM hardware engines should specify this device node in .dtsi Using ELM for ECC error correction frees some CPU cycles.For inline partition table parsing (optional): - #address-cells: should be set to 1 - #size-cells: should be set to 1Example for an AM33xx board: gpmc: gpmc@50000000 { compatible = "ti,am3352-gpmc"; ti,hwmods = "gpmc"; reg = <0x50000000 0x1000000>; interrupts = <100>; gpmc,num-cs = <8>; gpmc,num-waitpins = <2>; #address-cells = <2>; #size-cells = <1>; ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */ elm_id = <&elm>; nand@0,0 { reg = <0 0 0>; /* CS0, offset 0 */ nand-bus-width = <16>; ti,nand-ecc-opt = "bch8"; ti,nand-xfer-type = "polled"; gpmc,sync-clk-ps = <0>; gpmc,cs-on-ns = <0>; gpmc,cs-rd-off-ns = <44>; gpmc,cs-wr-off-ns = <44>; gpmc,adv-on-ns = <6>; gpmc,adv-rd-off-ns = <34>; gpmc,adv-wr-off-ns = <44>; gpmc,we-off-ns = <40>; gpmc,oe-off-ns = <54>; gpmc,access-ns = <64>; gpmc,rd-cycle-ns = <82>; gpmc,wr-cycle-ns = <82>; gpmc,wr-access-ns = <40>; gpmc,wr-data-mux-bus-ns = <0>; #address-cells = <1>; #size-cells = <1>; /* partitions go here */ }; };How to select correct ECC scheme for your device ?--------------------------------------------------Higher ECC scheme usually means better protection against bit-flips andincreased system lifetime. However, selection of ECC scheme is dependenton various other factors also like;(1) support of built in hardware engines. Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot support ecc-schemes with hardware error-correction (BCHx_HW). However such SoC can use ecc-schemes with software library for error-correction (BCHx_HW_DETECTION_SW). The error correction capability with software library remains equivalent to their hardware counter-part, but there is slight CPU penalty when too many bit-flips are detected during reads.(2) Device parameters like OOBSIZE. Other factor which governs the selection of ecc-scheme is oob-size. Higher ECC schemes require more OOB/Spare area to store ECC syndrome, so the device should have enough free bytes available its OOB/Spare area to accommodate ECC for entire page. In general following expression helps in determining if given device can accommodate ECC syndrome: "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" where OOBSIZE number of bytes in OOB/spare area PAGESIZE number of bytes in main-area of device 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(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and trying to use BCH16 (ECC_BYTES=26) ecc-scheme. Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B which is greater than capacity of NAND device (OOBSIZE=64) Hence, BCH16 cannot be supported on given device. But it can probably use lower ecc-schemes like BCH8. Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and trying to use BCH16 (ECC_BYTES=26) ecc-scheme. Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B which can be accommodated in the OOB/Spare area of this device (OOBSIZE=128). So this device can use BCH16 ecc-scheme.

  • Hope that helps.
  • Here is specifically what you asked.
    Is it possible to use any ECC algorithm for any NAND?
    As strong or complex ECC schemes generate more number of bytes as ECC signature, which is stored in OOB/spare
    region of NAND. Hence choice of ECC scheme is limited by size of OOB/spare region available per page of the
    NAND.
    Apart from ECC signature, some OOB/spare region needs to be reserved for storing:
    • Bad-block marker(2-Bytes), And
    • File-system metadata.
    So if NAND device has OOB/spare region, which can accommodate all above, then it can use the given ECC
    scheme. As per general calculations [5]
    OOB Area (spare region) >= B * ( Page_Size / 512 ) + 2 + FileSystem_metadata
    where
    B = 8 bytes for BCH4
    B = 14 bytes for BCH8
    B = 26 bytes for BCH16
    Generally NAND pages are of size 2048 (with 64-bytes of OOB/spare region) or 4096 (with 224-bytes of OOB/spare
    region). Thus using BCH8 for 2048-byte page NAND device, using UBIFS File-system means:
    • 14*(2048/512) = 56bytes of ECC
    • 2 bytes for Bad-Block marker
    • 0 bytes for meta-data (as UBIFS does not uses OOB/spare region for storing its metadata).
    Total = 56 + 2 + 0 = 58-bytes which can be accommodated in 64-Bytes of OOB/spare region of NAND. Hence,
    BCH8 ECC scheme can be used with UBIFS on a 2048/64 NAND device
  • Mustapha,

    Did the information Brandon kindly provided answer your questions? If not, please let us know how we might be able to help further.