On Tue, Feb 11, 2014 at 01:46:08PM -0800, York Sun wrote:
> 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 <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 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?
>
> 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?Since we've gone around and looked at the other possibilities, yeah, OK, we can put this into gd->arch (not just top level gd). Thanks for looking! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
