[U-Boot] [PATCH] driver/mxc_i2c: Move static data structure to global_data

[York Sun]

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 at 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