On 02/12/2014 06:43 AM, Tom Rini wrote:
On Wed, Feb 12, 2014 at 03:27:58PM +0100, Wolfgang Denk wrote:
Dear York,
In message 52FAA233.6090403@freescale.com you wrote:
Well, after relocation GD has also been relocated, so your SRAM would be comletely unused.
Sounds like you are OK with using GD for this patch. Let's wait to hear from Tom. He nacked this idea.
I don't say I think this is a good change. I just tried to explain to you that the SRAM will be unused after relocation completed. Tom probably has the same problem as I: I cannot understand why you are changing the code. If it's been working as is before, then why would it stop now?
I think I see it. We had been concerned with the SPL case, and the current driver work-around is how we do it (as to not litter gd->arch with lots of things just for drivers we need so very very early in SPL). York now has a different setup where this i2c block is being reused, where SRAM is big enough (apparently) to load the whole of U-Boot into and start execution from, but we still want to relocate into DDR. This is a problem over in TI-land we've avoided by simply saying "lets keep using SPL anyhow".
A minor correction, I am not putting u-boot in SRAM. I am reusing this mxc_i2c driver. It has been working, but my situation is different. I am not using SPL. U-boot runs in flash when the driver is called. I have SRAM to host stack and GD. This driver requires writable memory. Obviously I have only three options, use stack, GD, or make a special treatment to use SRAM. As we discussed and I tried, using linker script to link it to SRAM is messy and the relocation result is bad. I can't find a good way to use stack either. That leaves me the best option is to use GD.
York