From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] env_mmc: avoid stack allocation for env
Date: Tue, 12 May 2015 11:14:42 -0400 [thread overview]
Message-ID: <20150512151442.GD5267@bill-the-cat> (raw)
In-Reply-To: <CAJ+vNU3qdv4tJu8qchO4ZuMaJx5q56uxVCirexFLpFN_6VD8mw@mail.gmail.com>
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@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).
> 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: <http://lists.denx.de/pipermail/u-boot/attachments/20150512/3a450df9/attachment.sig>
next prev parent reply other threads:[~2015-05-12 15:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 21:51 [U-Boot] [PATCH] env_mmc: avoid stack allocation for env Tim Harvey
2015-05-08 22:15 ` Marek Vasut
2015-05-08 23:14 ` Tom Rini
2015-05-11 19:08 ` Tim Harvey
2015-05-12 15:14 ` Tom Rini [this message]
2015-05-13 19:58 ` Tim Harvey
2015-05-13 22:40 ` Tim Harvey
2015-05-14 2:02 ` Simon Glass
2015-05-14 3:22 ` Simon Glass
2015-05-14 13:11 ` Tim Harvey
2015-08-02 21:29 ` Simon Glass
2015-05-11 19:02 ` Tim Harvey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150512151442.GD5267@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox