On Tuesday, December 20, 2011 02:55:50 PM you wrote:
On Tue, Dec 20, 2011 at 4:20 AM, Igor Grinberg grinberg@compulab.co.ilwrote:
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