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

[Tom Rini <trini@ti.com>]

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 <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?
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140212/4c04fd7a/attachment.pgp>