[U-Boot] [RESEND:PATCH-V4] OMAP3EVM: Added NAND support

[Nishanth Menon]

On Thu, May 6, 2010 at 6:03 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Nishanth Menon,
>
> In message <j2h782515bb1005060354tc4574d80wb4a1aa3a2b40bc89 at mail.gmail.com> you wrote:
>>
>> your points are valid, two options as I see here:
>> a) build configurations - nand_boot, nor_boot etc..
>> b) IMHO, the better solution would be to allow the same u-boot to boot
>> from all devices (nand, nor, onenand, mmc) without needing a rebuild.
>
> b) is clearly the better and more user-friendly solution.
>
>> but the neccessity for that is to have environment variable which can
>> be moved around.. ...
>
> Hm... really? Assuming that all the storage devices are always
> present, you can decide to use one standard location for the
> environment independent of where the U-Boot image gets loaded from
> (that may actually be considered an advantage by some).
it is like
http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=blob;f=board/omap3430sdp/mem.c;h=a3dad962390b35501c83f8cde1dd2fd1f6d779d6;hb=HEAD#l107

Infact in some of the settings, one of the chips might even not be mapped :(..

yes, one option could have been to use a single flash for all env (in
fact some platforms like (if i recollect beagle booting off MMC uses
NAND for env) - but is not a nice idea if the usecase is to use that
entire flash for filesystem.. so the safe option in general has been
to expect the environment to stick to the memory u-boot booted off
from..

>
>>               ... TI has an implementation based on an ancient u-boot
>> which actually does this, it will be interesting to know if there are
>> others who may be interested in a similar feature in mainline u-boot.
>
> Sure - please post a patch (as RFC) so we can see what you have in
> mind.
Yep.. waiting for my next free cycle ;) i would have pointed as an RFC
to the git repo history, unfortunately the transition from clearcase
to git was done as a single blob :(

Regards,
Nishanth Menon