[U-Boot] [PATCH 0/3] arm: reduce .bss section clear time

[Lukasz Majewski <l.majewski@samsung.com>]

Dear All,

> And the next is interesting.
>   odroid_defconfig has more than 80MB for malloc (we need about 64mb
> for the DFU now, to be able write 32MB file).
> 
> This is the CONFIG_SYS_MALLOC_LEN. And the memory area for malloc is
> set to 0 in function mem_malloc_init(). So for this config that
> function sets more than 80MB to zero.
> 
> This is not good, because we shouldn't expect zeroed memory returned
> by malloc pointer. This is a job for calloc.
> 
> Especially if some command expects zeroed memory after malloc,
> probably after few next calls - it can crash...

I think that the above excerpt is _really_ important and should be
discussed.

I've "cut" it from the original post, so it won't get lost between the
lines.

It seems really strange, that malloc() area is cleared after
relocation. Which means that all "first" malloc'ed buffers get
implicitly zeroed.

Przemek is right here that this zeroing shouldn't be performed.

I'm also concerned about potential bugs, which show up (or even worse -
won't show up soon) after this change.

Hence, I would like to ask directly the community about the possible
solutions.

Please look at: ./common/dlmalloc.c mem_alloc_init() function [1].

On the one hand removing memset() at [1] speeds up booting time and
makes malloc() doing what is is supposed to do.

On the other hand there might be in space some boards, which rely on
this memset and without it some wired things may start to happening.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group