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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox