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

[York Sun <yorksun@freescale.com>]

On 02/11/2014 10:01 AM, York Sun wrote:
> On 02/10/2014 02:45 PM, Tom Rini wrote:
>> On Mon, Feb 10, 2014 at 02:28:01PM -0800, York Sun wrote:
>>> On 02/10/2014 02:10 PM, Tom Rini wrote:
>>>> On Mon, Feb 10, 2014 at 02:02:52PM -0800, York Sun wrote:
>>>>
>>>>> This driver needs a data structure in SRAM before SDRAM is available.
>>>>> This is not alway the case using .data section. Moving this data
>>>>> structure to global_data guarantees it is writable.
>>>>>
>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>> CC: Troy Kisky <troy.kisky@boundarydevices.com>
>>>>
>>>> If you need something in SRAM then you need to place it in that section,
>>>> see arch/arm/cpu/armv7/am33xx/u-boot-spl.lds for example
>>>>
>>>
>>> I am not sure if it is a similar situation. But anyway, I am open to
>>> suggestions.
>>>
>>> For this driver, the variable needs to be writable. I guess it wasn't
>>> a problem for existing platforms which probably call this driver after
>>> relocation.
>>>
>>> Does the SRAM code/data relocate to SDRAM? I don't want this variable
>>> to stay in SRAM once u-boot relocates to normal memory.
>>
>> So in this case the problem is still within SPL right?  You would put
>> the parts you need to have in SRAM during SPL and DDR in full U-Boot
>> with __attribute__((section(".data.srdata"))) and in the SoC's linker
>> scripts make sure that drivers/i2c/built-in.o(.data.srdata) ends up in
>> the appropriate place for each case.
>>
>> I say all of this as I think we really want to avoid expanding on
>> gd->arch-> stuff if we can (which reminds me, your patch expands on main
>> gd not gd->arch so NAK on that either way).
>>
> 
> I tried the linker script and made it work. But it is not what I want. I expect
> this variable relocates to DDR, but the offset is not right.
> I am not using SPL. This is full u-boot, which boots from flash, calls i2c
> driver, initializes DDR, then relocates. Putting this variable into stack might
> be the solution. Suggestions?
> 

Tom,

I haven't found an easy way to put this variable into stack. Would you
reconsider global data, as I originally proposed in the patch?

York