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 <york...@freescale.com>
>>>> CC: Troy Kisky <troy.ki...@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 didn't like this change either. Let me explore the linker script to see if I
can do it the other way.
York
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
