On Wed, Jul 16, 2014 at 3:03 PM, Gupta, Pekon pekon@ti.com wrote:
Hi Jon,
From: Jon Cormier [mailto:jcormier@criticallink.com]
On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon pekon@ti.com wrote:
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?
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