U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] powerpc/83xx: increment malloc heap size for the MPC832x MDS boards
Date: Tue, 20 Mar 2012 13:40:48 -0500	[thread overview]
Message-ID: <4F68CF30.8000308@freescale.com> (raw)
In-Reply-To: <20120318090712.DDFE8202BB3@gemini.denx.de>

On 03/18/2012 04:07 AM, Wolfgang Denk wrote:
> Dear Tabi Timur-B04825,
> 
> In message <CAOZdJXUem_-mgDSqF+p4R0npZQ6qu14G1yexQCBUe2G=nr2-1Q@mail.gmail.com> you wrote:
>>
>>> Doubling it is kind of aggressive strategy.  You know exactly how much
>>> free room needs to be guaranteed, so why don't you auto-adjust the
>>> size?
>>>
>>>> -#define CONFIG_SYS_MALLOC_LEN        (128 * 1024)    /* Res=
>> erved for malloc */
>>>> +#define CONFIG_SYS_MALLOC_LEN        (256 * 1024)    /* Res=
>> erved for malloc */
>>>
>>> How about:
>>>
>>> #define CONFIG_SYS_MALLOC_LEN   (128 * 1024 + CONFIG_ENV_SECT_SIZE)
>>
>> That's the same thing.  CONFIG_ENV_SECT_SIZE is 128KB.  Plus, as you
> 
> No, it's not the same thing.

You really want CONFIG_SYS_MALLOC_LEN to be a list of everything that
could be mallocked -- or worse, a list of just the things that people
have noticed breaking in the past (even though other things could later
be depending on that increase in size)?  You want to answer questions
about why NAND breaks on a board with a smaller NOR sector size? :-P

> Your code is static an either wasted moemory on systems with smaller sector size,

Come on, you're worried about a 128K increase in memory reserved for the
use of the bootloader?  It's not "wasted".  The only thing that area
of memory could otherwise be used for is loading images and such, and it
is very unlikely that this small change is going to matter there.

> or needs to be readjusted on systems with bigger sectors.
> 
> Don;t just think about your current situation, but also what happens
> when you (or somebody else) copies that code for other systems.
> 
> Make your code more robust.

The robust thing to do would be to not be stingy with the malloc size,
and change all boards to have at least 1 MiB for malloc (except ones
with very small amounts of RAM).  Maybe have a debug command to print
max memory usage since boot, to see if a board is getting anywhere near
the limit.

-Scott

  reply	other threads:[~2012-03-20 18:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-17 22:44 [U-Boot] [PATCH] powerpc/83xx: increment malloc heap size for the MPC832x MDS boards Timur Tabi
2012-03-17 23:19 ` Wolfgang Denk
2012-03-17 23:28   ` Tabi Timur-B04825
2012-03-18  9:07     ` Wolfgang Denk
2012-03-20 18:40       ` Scott Wood [this message]
2012-03-20 19:03         ` Wolfgang Denk
2012-06-15 21:46 ` Kim Phillips

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=4F68CF30.8000308@freescale.com \
    --to=scottwood@freescale.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