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 didn't like this change either. Let me explore the linker script to see if I can do it the other way.
York