u-boot.git/common/dlmalloc.c, branch v2020.10

common: Drop log.h from common header

2020-05-19T01:19:18+00:00

Move this header out of the common header.

Signed-off-by: Simon Glass

malloc: dlmalloc: add an ability for the malloc to be re-init/init multiple times

2020-05-01T15:34:01+00:00

Malloc gets initialized with a call to mem_malloc_init() with the address
the allocation starts to and its size. Currently it is not possible to
move the malloc from one memory area to another as the malloc would eventually
fail.

This patch adds in the ability to re-init the malloc with the updated
start address and the size.

One of the use cases of this feature is SPL U-Boot running from within
the static memory and calling to malloc init from within board_init_f():

	arch/arm/cpu/armv8/start.S:reset vector
	arch/arm/cpu/armv8/start.S:main()
	arch/arm/lib/crt0_64.S:board_init_f()
	board//common/spl.c:board_init_f()
        board//common/spl.c:mem_malloc_init((ulong)CONFIG_SYS_SPL_MALLOC_START,
                        CONFIG_SYS_SPL_MALLOC_SIZE);

Shortly after the DDR (main) memory is init and ready we call to malloc init
again but this time with the start address in the DDR memory and a much greater
size for moving the allocation off the static to the DDR memory:

	board//common/spl.c:mem_malloc_init((ulong)CONFIG_SPL_MALLOC_OFFSET,
			CONFIG_SPL_MALLOC_SIZE);

Where CONFIG_SYS_SPL_MALLOC_START and CONFIG_SPL_MALLOC_OFFSET are the start
addresses of the malloc in the static and DDR memories respectively and
CONFIG_SYS_SPL_MALLOC_SIZE=SZ_16K and CONFIG_SPL_MALLOC_SIZE=SZ_2M are
the sizes of the mallocs in these memories. Note, now we have a much greater
memory, enlarging from 16K to 2M, available for allocation.

There is an alternative approach already existing in U-Boot with the use of
an early (simplified) malloc and the proper (dlamalloc) malloc however
necessitating managing the two mallocs whereas this approach proposes using
a single dlmalloc.

Signed-off-by: Marek Bykowski

dlmalloc: remove unit test support in SPL

2020-04-24T14:51:32+00:00

We cannot run unit tests in SPL. So remove the unit test support.

Signed-off-by: Heinrich Schuchardt

dlmalloc: calloc: fix zeroing early allocations

2019-11-07T23:01:13+00:00

When full malloc is enabled and SYS_MALLOC_F is also enabled, the simple
pre-reloc heap is used before relocation. In this case, calloc() uses
the MALLOC_ZERO macro to zero out the allocated memory. However, since
this macro is specially crafted for the dlmalloc implementation, it
does not always work for simple malloc.

For example, when allocating 16 bytes via simple malloc, only the first
12 bytes get zeroed out. The last 4 bytes will remain untouched.

This is a problem for DM drivers that are allocated before relocation:
memory allocated via 'platdata_auto_alloc_size' might not be set to
zero, resulting in bogus behaviour.

To fix this, use 'memset' instead of 'MALLOC_ZERO' to zero out memory
that compes from simple malloc.

Signed-off-by: Simon Goldschmidt 
Reviewed-by: Tom Rini

malloc: Fix memalign not honoring alignment prior to full malloc init

2019-04-23T21:57:27+00:00

When using memalign() in a scenario where U-Boot is configured for full
malloc support with simple malloc not explicitly enabled and before the
full malloc support is initialized, a memory block is being allocated
and returned without the alignment parameter getting honored.

Fix this issue by replacing the existing memalign pre-full malloc init
logic with a call to memalign_simple() this way ensuring proper alignment
of the returned memory block.

Fixes: ee038c58d519 ("malloc: Use malloc simple before malloc is fully initialized in memalign()")
Signed-off-by: Andreas Dannenberg 
Reviewed-by: Lokesh Vutla

malloc: Use malloc simple before malloc is fully initialized in memalign()

2018-05-26T22:19:19+00:00

Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and use
malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the malloc bytes
to align with the requested alignment.

The original memalign() function will access mchunkptr struct to adjust the
alignment if there is misalignment happen, but mchunkptr struct is not being
initialized before full malloc is initialized. This cause the system crash.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marek Vasut

malloc: don't compare pointers to 0

2017-11-21T01:18:39+00:00

0 is not a pointer. So do not compare pointers to 0.

Do not return 0 from functions with a pointer return
type.

Problem identified with Coccinelle.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Bin Meng

spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN

2017-07-27T12:59:03+00:00

Some platforms have very limited SRAM to run SPL code, so there may
not be the same amount space for a malloc pool before relocation in
the SPL stage as the normal U-Boot stage.

Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN,
so the size of pre-relocation malloc pool can be configured memory
space independently.

Signed-off-by: Andy Yan 
Reviewed-by: Tom Rini 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
[fixed up commit-message:]
Signed-off-by: Philipp Tomsich

malloc: Turn on DEBUG when enabling unit tests

2017-06-05T18:13:11+00:00

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Pantelis Antoniou 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass

malloc: improve memalign fragmentation fix

2016-05-23T15:50:17+00:00

Commit 4f144a416469 "malloc: work around some memalign fragmentation
issues" enhanced memalign() so that it can succeed in more cases where
heap fragmentation is present. However, it did not solve as many cases
as it could. This patch enhances the code to cover more cases.

The alignment code works by allocating more space than the user requests,
then adjusting the returned pointer to achieve alignment. In general, one
must allocate "alignment" bytes more than the user requested in order to
guarantee that alignment is possible. This is what the original code does.
The previous enhancement attempted a second allocation if the padded
allocation failed, and succeeded if that allocation just happened to be
aligned; a fluke that happened often in practice. There are still cases
where this could fail, yet where it is still possible to honor the user's
allocation request. In particular, if the heap contains a free region that
is large enough for the user's request, and for leading padding to ensure
alignment, but has no or little space for any trailing padding. In this
case, we can make a third(!) allocation attempt after calculating exactly
the size of the leading padding required to achieve alignment, which is
the minimal over-allocation needed for the overall memalign() operation to
succeed if the third and second allocations end up at the same location.

This patch isn't checkpatch-clean, since it conforms to the existing
coding style in dlmalloc.c, which is different to the rest of U-Boot.

Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini