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.6090...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
