From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Tue, 11 Feb 2014 13:46:08 -0800 Subject: [U-Boot] [PATCH] driver/mxc_i2c: Move static data structure to global_data In-Reply-To: <52FA6584.6070100@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> Message-ID: <52FA9A20.60704@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? > 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