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