From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 12 Feb 2014 09:41:19 -0500 Subject: [U-Boot] [PATCH] driver/mxc_i2c: Move static data structure to global_data In-Reply-To: <52FA9A20.60704@freescale.com> References: <1392069772-24742-1-git-send-email-yorksun@freescale.com> <20140210221031.GD7049@bill-the-cat> <52F95271.6030006@freescale.com> <20140210224558.GF7049@bill-the-cat> <52FA6584.6070100@freescale.com> <52FA9A20.60704@freescale.com> Message-ID: <20140212144119.GC15819@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > >>>>> CC: Troy Kisky > >>>> > >>>> 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: