On Tuesday, December 20, 2011 02:55:50 PM you wrote: > On Tue, Dec 20, 2011 at 4:20 AM, Igor Grinberg <grinb...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot