06 May, 2020

4 commits

  • Add more BCH setting mode and remove the unnecessary platform constrain

    Signed-off-by: Han Xu
    (cherry picked from commit eb97412a839ce7a27267beee2dc0ab264d7fa131)

    Han Xu
     
  • gf_13/14 mask was not set correctly in register definition.

    Signed-off-by: Han Xu
    (cherry picked from commit b8aed98b2ecfb0def64c474e1ae171930da4c9fc)

    Han Xu
     
  • Provide an option in DT to use legacy bch geometry, which compatible
    with the 3.10 kernel bch setting. To enable the feature, adding
    "fsl,legacy-bch-geometry" under gpmi-nand node.

    NOTICE: The feature must be enabled/disabled in both u-boot and kernel.

    Signed-off-by: Han Xu
    Signed-off-by: Ye Li
    (cherry picked from commit 71253252c6652a845df15d6288e49d37cdab3383)

    Ye Li
     
  • The code change updated the NAND driver BCH ECC layout algorithm to
    support large oob size NAND chips(oob > 1024 bytes) and proposed a new
    way to set ECC layout.

    Current implementation requires each chunk size larger than oob size so
    the bad block marker (BBM) can be guaranteed located in data chunk. The
    ECC layout always using the unbalanced layout(Ecc for both meta and
    Data0 chunk), but for the NAND chips with oob larger than 1k, the driver
    cannot support because BCH doesn’t support GF 15 for 2K chunk.

    The change keeps the data chunk no larger than 1k and adjust the ECC
    strength or ECC layout to locate the BBM in data chunk. General idea for
    large oob NAND chips is

    1.Try all ECC strength from the minimum value required by NAND spec to
    the maximum one that works, any ECC makes the BBM locate in data chunk
    can be chosen.

    2.If none of them works, using separate ECC for meta, which will add one
    extra ecc with the same ECC strength as other data chunks. This extra
    ECC can guarantee BBM located in data chunk, of course, we need to check
    if oob can afford it.

    Previous code has two methods for ECC layout setting, the
    legacy_calc_ecc_layout and calc_ecc_layout_by_info, the difference
    between these two methods is, legacy_calc_ecc_layout set the chunk size
    larger chan oob size and then set the maximum ECC strength that oob can
    afford. While the calc_ecc_layout_by_info set chunk size and ECC
    strength according to NAND spec. It has been proved that the first
    method cannot provide safe ECC strength for some modern NAND chips, so
    in current code,

    1. Driver read NAND parameters first and then chose the proper ECC
    layout setting method.

    2. If the oob is large or NAND required data chunk larger than oob size,
    chose calc_ecc_for_large_oob, otherwise use calc_ecc_layout_by_info

    3. legacy_calc_ecc_layout only used for some NAND chips does not contains
    necessary information. So this is only a backup plan, it is NOT
    recommended to use these NAND chips.

    Signed-off-by: Han Xu
    Signed-off-by: Ye Li
    (cherry picked from commit 71fe512f8fe173001a295399758d20a16a866a56)

    Ye Li
     

04 Nov, 2019

1 commit

  • On i.MX7 in a sake of reducing the disturbances caused by a neighboring
    cells in the FCB page in the NAND chip, a randomizer is enabled when
    reading the FCB page by ROM bootloader.

    Add API for setting BCH to specific layout (and restoring it back) used by
    ROM bootloader to be able to burn it in a proper way to NAND using
    nandbcb command.

    Signed-off-by: Igor Opaniuk
    Signed-off-by: Anti Sullin
    Tested-by: Max Krummenacher
    Reviewed-by: Oleksandr Suvorov

    Igor Opaniuk
     

19 Jul, 2019

1 commit

  • Writing/updating boot image in nand device is not
    straight forward in i.MX6 platform and it requires
    boot control block(BCB) to be configured.

    It becomes difficult to use uboot 'nand' command to
    write BCB since it requires platform specific attributes
    need to be taken care of.

    It is even difficult to use existing msx-nand.c driver by
    incorporating BCB attributes like mxs_dma_desc does
    because it requires change in mtd and nand command.

    So, cmd_nandbcb implemented in arch/arm/mach-imx

    BCB contains two data structures, Firmware Configuration Block(FCB)
    and Discovered Bad Block Table(DBBT). FCB has nand timings,
    DBBT search area, page address of firmware.

    On summary, nandbcb update will
    - erase the entire partition
    - create BCB by creating 2 FCB/DBBT block followed by
    1 FW block based on partition size and erasesize.
    - fill FCB/DBBT structures
    - write FW/SPL on FW1
    - write FCB/DBBT in first 2 blocks

    for nand boot, up on reset bootrom look for FCB structure in
    first block's if FCB found the nand timings are loaded for
    further reads. once FCB read done, DTTB will load and finally
    firmware will be loaded which is boot image.

    Refer section "NAND Boot" from doc/imx/common/imx6.txt for more usage
    information.

    Reviewed-by: Stefano Babic
    Signed-off-by: Jagan Teki
    Signed-off-by: Sergey Kubushyn
    Signed-off-by: Shyam Saini

    Shyam Saini