Pekon,

Thanks for the response.

On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon pekon@ti.com wrote:

Hi Jon,

...

From: Jon Cormier [mailto:jcormier@criticallink.com]

...

We have a product based on the 335x that has several different models

where the only difference is the nand part. We would like to have a unified u-boot that can dynamically configure the nand's ECC, page size, block size, etc using a spi eeprom containing a model number. Both the UBL and u-boot image are stored in nand. We already do this in the kernel. Currently in the UBL all the nand information is setup in #defines during compile time which makes it hard to change at runtime. I am unsure how to go about changing this. Has anyone tried doing this dynamic setup?

(1) For NAND device parameters (like Block-size, Page-size, data-width) These parameter are anyways dynamically determined by reading on chip ONFI page during omap_board_init(). But that's only for u-boot (second-stage).

• For SPL these are still #defined based to keep the code-footprint small.

Sure makes sense. Could this be an area where I could experiment to see

if adding ONFI support makes the SPL too large? Alternatively without ONFI support could I fallback to using a nand flash table like in the kernel for older nand parts. This could allow me to switch between a few parts after either reading the eeprom or reading the nand part number.

(2) For dynamically selection of ecc-scheme, you need to re-add 'nandecc' command which is kind of deprecated now. Though its driver side support is still present in omap_gpmc.c.

• But again, this is not supported for SPL.

If everyone agrees, we should add this to main NAND framework instead of cluttering individual board-files.

---

File: arch/arm/cpu/armv7/omap3/board.c

#if defined(CONFIG_NAND_OMAP_GPMC) & !defined(CONFIG_SPL_BUILD)

/******************************************************************************

• OMAP3 specific command to switch between NAND HW and SW ecc

*****************************************************************************/ static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) { if (argc < 2 || argc > 3) goto usage;

    if (strncmp(argv[1], "hw", 2) == 0) {
            if (argc == 2) {
                    omap_nand_switch_ecc(1, 1);
            } else {
                    if (strncmp(argv[2], "hamming", 7) == 0)
                            omap_nand_switch_ecc(1, 1);
                    else if (strncmp(argv[2], "bch8", 4) == 0)
                            omap_nand_switch_ecc(1, 8);
                    else
                            goto usage;
            }
    } else if (strncmp(argv[1], "sw", 2) == 0) {
            omap_nand_switch_ecc(0, 0);
    } else {
            goto usage;
    }

    return 0;

usage: printf ("Usage: nandecc %s\n", cmdtp->usage); return 1; }

U_BOOT_CMD( nandecc, 3, 1, do_switch_ecc, "switch OMAP3 NAND ECC calculation algorithm", "hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming and" " 8-bit BCH\n" " ecc calculation (second parameter may" " be omitted).\n" "nandecc sw - Switch to NAND software ecc algorithm." );

#endif /* CONFIG_NAND_OMAP_GPMC & !CONFIG_SPL_BUILD */

Ok I would probably just call the omap_nand_switch_ecc function directly

after determining which part was in use.

(3) If you need to have generic SPL too, then you might need to try NANDI2C boot-mode of AM335x. (please refer AM335x TRM).

According to the TRM this is to setup the ROM when it can't autodetect the

nands setup. Currently the ROM auto discovers each of the nands without problems. Since the ROM is already setting up the gpmc and ecc for the nand, would it be possible to setup the SPL to use the already setup hardware as is?

...

We are currently based off of the 2013.10 tag but will move forward if

needed. Yes, I would suggest to move to latest u-boot which has support for BCH16 ecc-scheme, as higher ecc-scheme work better with newer technology NAND and MLC NAND devices which are more prone to bit-flips.

Thanks. We've already got BCH16 support in our u-boot. It was needed to

program the 4k page size nands so the ROM would boot them.

with regards, pekon

...

-- Jonathan Cormier CriticalLink

I noticed this commit when looking for nand changes in the latest u-boot but I'm not sure how this actually affects the SPL nand support. And whether it helps me move towards my goal. (6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL