[U-Boot] [PATCH] omap3: igep00x0: fix NAND_BOOT for igep_0020 and igep_0030

[Gupta, Pekon]

Hi Tom,

>From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Rini, Tom
>>On Thu, Apr 03, 2014 at 09:12:56AM +0000, Gupta, Pekon wrote:
[...]
>> Sorry about noise, please ignore this patch. I'll merge these changes with my
>> other patch, where I move out board-specific configs from "ti_armv7_common.h"
>
>Well hold up.  Where things need to be in NAND depends on where the SoC
>is going to check for an initial loader, followed by where it's going to
>check for redundant copies (if applicable).  So you'll have a bit of a
>job convincing me that we don't want to default to a likely right
>location (I forget off-hand if bigger NAND pages would push the location
>higher or not or if we'd just sacrifice total number of possible
>redundant copies).
>
Some CONFIGS_SYS_NAND_xx like (CONFIG_SYS_NAND_U_BOOT_OFFS)
are dependent on:

(1) NAND device connected to the board.
 NAND partitions need to be multiple of block-sizes, so a NAND device having
 blocksize=128K _may_ have different offset than NAND device with blocksize=256k.
 Example: Both AM335x_beaglebone and AM335x_EVM use same NAND
 layout, but they use NAND devices with different block-sizes.

(2) Board users are free to use custom MTD NAND partition layout.
 And CONFIG_SYS_NAND_U_BOOF_OFFS is dependent on this partition table
 So, when 'MTDPARTS_DEFAULT' is defined in individual board configs, so this
 CONFIG_SYS_NAND_U_BOOT_OFFS should also be present in individual
 board configs.

For other configs which enable generic _driver_ features
(like CONFIG_CMD_NAND) can still remain in ti_arm_common.h
hope that makes sense ?


with regards, pekon