[U-Boot] [PATCH] env_mmc: avoid stack allocation for env

[Tim Harvey]

On Tue, May 12, 2015 at 8:14 AM, Tom Rini <trini at konsulko.com> wrote:
> On Mon, May 11, 2015 at 12:08:25PM -0700, Tim Harvey wrote:
>> On Fri, May 8, 2015 at 4:14 PM, Tom Rini <trini at konsulko.com> 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).

thats strange... common/spl/spl.c uses CONFIG_SPL_STACK_R as the
address not CONFIG_SPL_STACK_R_ADDR - how can that even compile?

http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;#l324

>
>> 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).

You said that backwards right? You mean nand env should be converted
to stack not dram.

How do we do that without risking the chance of breaking boards that
don't have CONFIG_SPL_STACK_R? Wouldn't you need to implement both
around a #define to not cause breakage?

Tim