[U-Boot] [PATCH] overo: add SPL support

[Andreas Müller]

On Tuesday, December 20, 2011 02:55:50 PM you wrote:
> On Tue, Dec 20, 2011 at 4:20 AM, Igor Grinberg <grinberg at compulab.co.il>wrote:
> > What about forging some very not optimized default DRAM settings,
> > that suit any assembled DRAM and then when you have I2C access,
> > reconfigure it - is it possible?
> 
> The board ID is used to determine some fairly fundamental things like how
> the address bits are multiplexed, bank size, number of banks, and timing.
> 
> Perhaps it might be possible to determine some non-optimal settings that
> can work with the current set of POP memories used, and also a scheme to
> modify the above on the fly while executing from said ram, but then one
> would have to revisit this every time a new vendor/type of POP was used.
> 
> That seems a lot more complex than the current method.
> 
> I suppose we could just drop support for the old boards in u-boot.  Those
> folks could continue to use the current x-load solution. 
I am afraid you are right. It seems that the current U-boot/OMAP/SPL environment 
it is not designed to have i2c in early state when SDRAM is set up. 
My experience:
* After moving the i2c variables to SDRAM, i2c_set_bus_num (and thereby 
i2c_init) work but i2c_write hangs when calling udelay because timer is not yet 
running.
* This can be worked around by calling timer_init() within s_init(). With this 
setup booting is possible but I get MMC timeout messages from u-boot although 
kernel is loaded properly.
* I don't know if this is the reason for timeout but I think successful booting 
is just by accident because the register pointer to global data is not yet set 
(i2c and timer use global data). I tried to setup global data earlier but up to 
now without success. Even if successful I think the number of friends for such a 
deep change is limited...
Not to be misunderstood: This is no criticism to anybody. The experince that a 
design does not fit for a (corner case) request I have had in several projects :)
> Or perhaps someone will come up with a more clever idea!
> 
My suggestion: 

* Soon: Clean up the patch already sent as reviewed and leave i2c TWL4030 shut-
up out. As fallback for old boards leave x-load in oe meta-gumstix  (maybe just 
create a different machine configuration).
* Later: Think about a 'more probing' approach as suggested in this thread (or a 
combination e.g if revision 1 detected, check size of SDRAM and with the result 
deciding if this is a revision 1/0).

Anyway: The informations regarding SDRAM I copied from x-load. Since this is a 
bit fishing in the dark: Are there documents from gumstix available, describing 
which memories were used (with which revision :) or are these secret IP?

Regards

Andreas