On Wed, Jul 16, 2014 at 3:03 PM, Gupta, Pekon <pe...@ti.com> wrote: > Hi Jon, > > > > From: Jon Cormier [mailto:jcorm...@criticallink.com] > >> On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pe...@ti.com> wrote: > >>>From: Jon Cormier [mailto:jcorm...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
