Eric Lee / smarc-uboot

04 Feb, 2014

1 commit

22 Jan, 2014

1 commit

  • 6609916ef   powerpc:mpc85xx: Add ifc nand boot support for TPL/SPL ... Browse Code »

    Using the TPL method for nand boot by sram was already
    supported. Here add some code for mpc85xx ifc nand boot.

    - For ifc, elbc, esdhc, espi, all need the SPL without
    section .resetvec.
    - Use a clear function name for nand spl boot.
    - Add CONFIG_SPL_DRIVERS_MISC_SUPPORT to compile the fsl_ifc.c
    in spl/Makefile;

    Signed-off-by: Po Liu
    Acked-by: Scott Wood
    Reviewed-by: York Sun

    Po Liu
     

17 Jan, 2014

1 commit

  • 13fbde6e4   nand, gpmc: fix reading after switching ecc ... Browse Code »

    The omap_gpmc allows switching ecc at runtime. Since
    the NAND_SUBPAGE_READ flag is only set, it is kept when
    switching to hw ecc, which is not correct. This leads to
    calling chip->ecc.read_subpage which is not a valid
    pointer. Therefore clear the flag when switching ecc so
    reading in hw mode works again.

    Cc: Scott Wood
    Cc: Pekon Gupta
    Cc: Nikita Kiryanov
    Signed-off-by: Jeroen Hofstee

    Jeroen Hofstee
     

13 Jan, 2014

6 commits

11 Jan, 2014

11 commits

31 Dec, 2013

1 commit

  • 9b56942f7   mtd: onenand: Fix unaligned access ... Browse Code »

    Fix unaligned access in OneNAND core. The problem is that the ffchars[] array
    is an array of "unsigned char", but in onenand_write_ops_nolock() can be passed
    to the memcpy_16() function. The memcpy_16() function will treat the buffer as
    an array of "unsigned short", thus triggering unaligned access if the compiler
    decided ffchars[] to be not aligned.

    I managed to trigger the problem with regular ELDK 5.4 GCC compiler.

    Signed-off-by: Marek Vasut
    Cc: Albert Aribaud
    Cc: Scott Wood
    Cc: Tom Rini

    Marek Vasut
     

20 Dec, 2013

1 commit

19 Dec, 2013

3 commits

18 Dec, 2013

6 commits

  • fcd052457   mtd: nand: omap: fix ecc ops assignment when changing ecc ... Browse Code »

    If we change to software ecc and then back to hardware ecc, the nand ecc ops
    pointers are populated with incorrect function pointers. This is related to the
    way nand_scan_tail() handles assigning functions to ecc ops:

    If we are switching to software ecc/no ecc, it assigns default functions to the
    ecc ops pointers unconditionally, but if we are switching to hardware ecc,
    the default hardware ecc functions are assigned to ops pointers only if these
    pointers are NULL (so that drivers could set their own functions). In the case
    of omap_gpmc.c driver, when we switch to sw ecc, sw ecc functions are
    assigned to ecc ops by nand_scan_tail(), and when we later switch to hw ecc,
    the ecc ops pointers are not NULL, so nand_scan_tail() does not overwrite
    them with hw ecc functions.
    The result: sw ecc functions used to write hw ecc data.

    Clear the ecc ops pointers in omap_gpmc.c when switching ecc types, so that
    ops which were not assigned by the driver will get the correct default values
    from nand_scan_tail().

    Cc: Scott Wood
    Cc: Pekon Gupta
    Signed-off-by: Nikita Kiryanov

    Nikita Kiryanov
     
  • eb237a15b   mtd: nand: omap: fix sw->hw->sw ecc switch ... Browse Code »

    When switching ecc mode, omap_select_ecc_scheme() assigns the appropriate values
    into the current nand chip's ecc.layout struct. This is done under the
    assumption that the struct exists only to store values, so it is OK to overwrite
    it, but there is at least one situation where this assumption is incorrect:

    When switching to 1 bit hamming code sw ecc, the job of assigning layout data
    is outsourced to nand_scan_tail(), which simply assigns into ecc.layout a
    pointer to an existing struct prefilled with the appropriate values. This struct
    doubles as both data and layout definition, and therefore shouldn't be
    overwritten, but on the next switch to hardware ecc, this is exactly what's
    going to happen. The next time the user switches to software ecc, they're
    going to get a messed up ecc layout.

    Prevent this and possible similar bugs by explicitly using the
    private-to-omap_gpmc.c omap_ecclayout struct when switching ecc mode.

    Cc: Scott Wood
    Cc: Pekon Gupta
    Signed-off-by: Nikita Kiryanov

    Nikita Kiryanov
     
  • 3ef1eadb4   nand_util.c: Use '%zd' for length in nand_unlock debug print ... Browse Code »

    length is size_t so needs to be '%zd' not '%d' to avoid warnings.

    Cc: Scott Wood
    Signed-off-by: Tom Rini

    Tom Rini
     
  • 2528460c3   mtd: nand: omap: fix HAM1_SW ecc using default value for ecc.size ... Browse Code »

    Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic
    platform" (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way
    software ECC is configured, both during boot, and during ecc switch, in a way
    that is not backwards compatible with older systems:

    Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring
    for software ecc, relying on nand_scan_tail() to select a default for ecc.size
    (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize,
    which is likely to not be 256.

    Since 1 bit hamming sw ecc is only meant to be used by legacy devices, revert
    to the original behavior.

    Cc: Igor Grinberg
    Cc: Tom Rini
    Cc: Scott Wood
    Cc: Pekon Gupta
    Signed-off-by: Nikita Kiryanov
    Acked-by: Pekon Gupta

    Nikita Kiryanov
     
  • 5d7a49b93   mtd: nand: omap_gpmc: cosmetic: Fix indentation ... Browse Code »

    Signed-off-by: Stefan Roese
    Cc: Pekon Gupta
    Cc: Scott Wood
    [scottwood@freescale.com: wrap some long lines]
    Signed-off-by: Scott Wood

    Stefan Roese
     
  • 69cc97f8d   mtd: nand: omap: fix ecc-layout for HAM1 ecc-scheme ... Browse Code »

    As per OMAP3530 TRM referenced below [1]

    For large-page NAND, ROM code expects following ecc-layout for HAM1 ecc-scheme
    - OOB[1] (offset of 1 *byte* from start of OOB) for x8 NAND device
    - OOB[2] (offset of 1 *word* from start of OOB) for x16 NAND device

    Thus ecc-layout expected by ROM code for HAM1 ecc-scheme is:
    *for x8 NAND Device*
    +--------+---------+---------+---------+---------+---------+---------+
    | xxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] | ...
    +--------+---------+---------+---------+---------+---------+---------+

    *for x16 NAND Device*
    +--------+--------+---------+---------+---------+---------+---------+---------+
    | xxxxx | xxxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] |
    +--------+--------+---------+---------+---------+---------+---------+---------+

    This patch fixes ecc-layout *only* for HAM1, as required by ROM-code
    For other ecc-schemes like (BCH8) ecc-layout is same for x8 or x16 devices.

    [1] OMAP3530: http://www.ti.com/product/omap3530
    TRM: http://www.ti.com/litv/pdf/spruf98x
    Chapter-25: Initialization Sub-topic: Memory Booting
    Section: 25.4.7.4 NAND
    Figure 25-19. ECC Locations in NAND Spare Areas

    Reported-by: Stefan Roese
    Signed-off-by: Pekon Gupta
    Tested-by: Stefan Roese

    pekon gupta
     

13 Dec, 2013

1 commit

11 Dec, 2013

2 commits

10 Dec, 2013

3 commits

09 Dec, 2013

1 commit

05 Dec, 2013

1 commit

  • 7aa6c455c   powerpc: spiflash:Add corenet devices support in eSPI SPL ... Browse Code »

    Existing eSPI SPL framework assumes booting from spi-image
    with boot_format header which contains final u-boot Image
    offset and size. No such header is present in case of
    corenet devices like T1040 as corenet deivces use PBI-RCW
    based intialization.

    So, for corenet deives, SPL bootloader use values provided
    at compilation time. These values can be defined in board
    specific config file.

    Signed-off-by: Priyanka Jain
    Acked-by: York Sun

    Priyanka Jain
     

02 Dec, 2013

1 commit