From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Date: Sat, 05 Feb 2011 20:33:59 +1100 [thread overview]
Message-ID: <4D4D1987.5010405@gmail.com> (raw)
In-Reply-To: <20110205083050.89C7B1B921A3@gemini.denx.de>
On 05/02/11 19:30, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message <AANLkTin-EBt+PA0TmdLBPAqo3pBjwmbNLdFUj2K-JOnX@mail.gmail.com> you wrote:
>>
>>> In which way do you think this will save any memory?
>>
>> This patch is not intend to save memory...
>
> Then I don't understand at all what the benefit of that patch would
> be.
>
>> One of our project need to confine the ddr usage of uboot in the smallest case,
>> not to pollute other area. So for us, the small stack is good one...
>
> So it is still about saving memory...
>
>> For now the uboot is relocated to the end of the dram, and malloc area is
>> almost a fix value, uboot would live happily in this area. But for env case,
>> it allocate a range which could be large, due to the CONFIG_ENV_SIZE
>> could be a big one, in the stack range. Because the stack is grown downwards,
>> so it takes more memory range than it is allocated in the malloc method.
>
Sounds like you have allocated too small a region for your stack - try
increasing CONFIG_SYS_STACK_SIZE and decreasing CONFIG_SYS_MALLOC_LEN
> malloc arena and stack are adjacent. If you have enough free room in
> the malloc arena for the environment buffers, but cannot afford to
> have them on your stack, then this means your malloc arena has lots of
> unused space. Decrease the size of your malloc arena by the size of
> the environment buffer, and you reach the same goal as with your
> patch - actually you save more memory, as the code size of u-boot
> shrinks.
>
> Can you please provide exact numbers? How big is your RAM? What is
> the debug output of arch/*/lib/board.c without and with this patch on
> your system? How big is your environment resp. the environment
> sectors?
>
The only other thing I could think of that would make sense would be having
the malloc heap in a completely different memory segment to the stack -
odd, but possible
Regards,
Graeme
next prev parent reply other threads:[~2011-02-05 9:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 3:08 [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf Lei Wen
2011-02-04 20:31 ` Scott Wood
2011-02-04 21:18 ` Wolfgang Denk
2011-02-05 1:21 ` Lei Wen
2011-02-05 8:30 ` Wolfgang Denk
2011-02-05 9:33 ` Graeme Russ [this message]
2011-02-05 14:11 ` Wolfgang Denk
2011-02-06 15:25 ` Lei Wen
2011-02-06 16:08 ` Wolfgang Denk
2011-02-07 4:38 ` Lei Wen
2011-02-07 5:04 ` Graeme Russ
2011-02-07 7:06 ` Wolfgang Denk
2011-02-07 6:58 ` Wolfgang Denk
2011-02-07 8:17 ` Lei Wen
2011-02-07 8:59 ` Wolfgang Denk
2011-02-07 9:01 ` Lei Wen
2011-02-07 9:43 ` [U-Boot] Compiler Question Maik Hänig
2011-02-07 10:17 ` Wolfgang Denk
2011-02-07 10:24 ` Maik Hänig
2011-02-07 11:41 ` Wolfgang Denk
2011-02-07 12:03 ` Maik Hänig
2011-02-07 13:10 ` Wolfgang Denk
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=4D4D1987.5010405@gmail.com \
--to=graeme.russ@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.