From: Tom Rini Date: Tue, 12 May 2015 11:14:42 -0400 Subject: [U-Boot] [PATCH] env_mmc: avoid stack allocation for env In-Reply-To: References: <1431121896-2677-1-git-send-email-tharvey@gateworks.com> <201505090015.37722.marex@denx.de> <20150508231443.GV5267@bill-the-cat> Message-ID: <20150512151442.GD5267@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 Mon, May 11, 2015 at 12:08:25PM -0700, Tim Harvey wrote: > On Fri, May 8, 2015 at 4:14 PM, Tom Rini wrote: > > On Sat, May 09, 2015 at 12:15:37AM +0200, Marek Vasut wrote: > >> On Friday, May 08, 2015 at 11:51:36 PM, Tim Harvey wrote: > >> > Allocating space for temporary env on the stack makes env_relocate_spec() > >> > unsuitable for SPL environments which have very little stack. > >> > >> Well yeah, but what if you don't have malloc area ? I'd expect that > >> the be the case in SPL quite often. > > > > OK, hold up. We went through this a while back which is why things are > > how they are today. First, we have things setup today such that you can > > throw stack (at the point we do env in SPL) into DDR. This means we can > > keep doing things the way they are. You can take a look at > > include/configs/am335x_evm.h and where CONFIG_EMMC_BOOT is set, that's > > how we do what it looks like you're trying to do on imx6 but on TI > > am335x. > > Yes, I'm doing this on Gateworks Ventana (board/gateworks/gw_ventana) > based on IMX6 which has a limmited stack size during SPL. I don't see > anything magic in include/configs/am335x_evm.h that catches my > attention. Do you know where the code is that lets you point the stack > to DDR? It sounds like that's what I need. Ah oops. Kconfig, we use Kconfig now :) configs/am335x_evm_defconfig:CONFIG_SPL_STACK_R=y configs/am335x_evm_defconfig:CONFIG_SPL_STACK_R_ADDR=0x82000000 That's moving stack to DDR and then grabbing 0x82000000 for stack (base + 0x02000000 which is not too high, not too low, not likely to stomp on the kernel). > This sounds like there could be some boards using nand that rely on > malloc (that's where I got the inspiration from for this) and others > using mmc that rely on a decent size stack. I wonder if there is a > #define that we can base off of to provide the best of both? Its not > that great having two env drivers that have opposite requirements but > I certainly don't want to change one to make them consistent it it > will break boards. My first guess is that NAND should also be converted to DDR not stack (I too found the NAND example, switched MMC to it, and then Wolfgang/others pointed out that really stack is where this kind of allocation should be, iirc, but then didn't get a chance to dig back at NAND). -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: