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

[Gupta, Pekon]

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.

> 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.


>>(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.


>> (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

with regards, pekon