[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Jon Cormier]

On Wed, Jul 16, 2014 at 3:03 PM, Gupta, Pekon <pekon at ti.com> wrote:

> Hi Jon,
>
>
> > From: Jon Cormier [mailto:jcormier at criticallink.com]
> >> On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pekon at ti.com> wrote:
> >>>From: Jon Cormier [mailto:jcormier at 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?
>
> Yes, And this should be fairly easy. You have to just replicate the
> code under  #ifdef CONFIG_SYS_NAND_ONFI_DETECTION ... #endif
> from nand_base.c. And make appropriate call to it in
> $U-BOOT/drivers/mtd/nand/am335x_spl_bch.c @@ nand_init(...)
> after board_nand_init() call.
>

Worth a shot.

>
> > 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.
> Yes, Look-up table approach is also possible, but ONFI is more flexible
> and scalable.
>
Understood.

>
> >>(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.
> [...]
> > Ok I would probably just call the omap_nand_switch_ecc function directly
> after determining which part was in use.
> You choice, but still suggest you to do it cleanly and contribute it back
> to community for everyone's benefit.
>
> Yeah, I think the community contributable part would be adding this
functionality to the SPL though I fear it may become a bit of a hack.

>
> >> (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?
> AFAIK, NANDI2C is a separate independent boot mode, in addition to NAND
> boot mode
> in which you can custom specify NAND parameters (even if its detectable
> NAND).
> And you can select NANDI2C boot mode directly via SYSBOOT pins.
>
> >>> 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.
> > --
> > 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
>
> This may help you.
> But I don't have much knowledge on use of MTD framework in SPL.
> + Tom Rini
>

Good call.

Tom, What was the reason for this patch?  Can it help by allowing SPL
access to ONFI or omap_nand_switch_ecc?


> with regards, pekon
>



-- 
Jonathan Cormier
CriticalLink