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

Tim Harvey tharvey at gateworks.com
Mon May 11 21:08:25 CEST 2015


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

Tom,

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.

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.

Tim


More information about the U-Boot mailing list