[U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
Graeme Russ
graeme.russ at gmail.com
Mon Sep 24 02:46:39 CEST 2012
Hi Thomas,
On Mon, Sep 24, 2012 at 10:35 AM, Tomas Hlavacek <tmshlvck at gmail.com> wrote:
> Hi Graeme!
>
> On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Tomas,
>>
>> On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek <tmshlvck at gmail.com> wrote:
>>> early_malloc for DM with support for more heaps and lightweight
>>> first heap in the same memory as an early stack.
>>>
>>> Adaptation layer for seamless calling of early_malloc or dlmalloc from
>>> DM based on init stage added (dmmalloc() and related functions).
>>>
>>> Signed-off-by: Tomas Hlavacek <tmshlvck at gmail.com>
>>> ---
>>> Changelog since v5:
>>> dmmalloc() and all dm* functions has been moved to header, made static
>>> inline and preprocessor-dependent blocks are reworked.
>>> early_malloc_active() corrected and made not static.
>>> s/CONFIG_SYS_DM/CONFIG_DM/ applied.
>>>
>>> Changelog sice v6:
>>> Check of first heap emptyness in early_brk() has been simplified.
>>>
>>> Changelog since v7:
>>> dmcalloc() implmentation added.
>>> Comments added to header.
>>>
>>> arch/arm/include/asm/global_data.h | 3 +
>>> arch/arm/lib/board.c | 8 ++
>>> arch/avr32/include/asm/global_data.h | 3 +
>>> arch/avr32/lib/board.c | 9 +++
>>> arch/blackfin/include/asm/global_data.h | 3 +
>>> arch/blackfin/lib/board.c | 8 ++
>>> arch/m68k/include/asm/global_data.h | 3 +
>>> arch/m68k/lib/board.c | 8 ++
>>> arch/microblaze/include/asm/global_data.h | 3 +
>>> arch/microblaze/lib/board.c | 9 +++
>>> arch/mips/include/asm/global_data.h | 3 +
>>> arch/mips/lib/board.c | 8 ++
>>> arch/nds32/include/asm/global_data.h | 3 +
>>> arch/nds32/lib/board.c | 8 ++
>>> arch/nios2/include/asm/global_data.h | 3 +
>>> arch/nios2/lib/board.c | 8 ++
>>> arch/openrisc/include/asm/global_data.h | 3 +
>>> arch/openrisc/lib/board.c | 8 ++
>>> arch/powerpc/include/asm/global_data.h | 3 +
>>> arch/powerpc/lib/board.c | 8 ++
>>> arch/sandbox/include/asm/global_data.h | 3 +
>>> arch/sandbox/lib/board.c | 8 ++
>>> arch/sh/include/asm/global_data.h | 3 +
>>> arch/sh/lib/board.c | 8 ++
>>> arch/sparc/include/asm/global_data.h | 3 +
>>> arch/sparc/lib/board.c | 8 ++
>>> arch/x86/include/asm/global_data.h | 3 +
>>> arch/x86/lib/board.c | 18 +++++
>>> common/Makefile | 1 +
>>> common/dmmalloc.c | 88 ++++++++++++++++++++++
>>> include/dmmalloc.h | 117 +++++++++++++++++++++++++++++
>>> 31 files changed, 372 insertions(+)
>>> create mode 100644 common/dmmalloc.c
>>> create mode 100644 include/dmmalloc.h
>>>
>>> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
>>> index f8088fe..ef727b0 100644
>>> --- a/arch/arm/include/asm/global_data.h
>>> +++ b/arch/arm/include/asm/global_data.h
>>> @@ -82,6 +82,9 @@ typedef struct global_data {
>>> unsigned long post_log_res; /* success of POST test */
>>> unsigned long post_init_f_time; /* When post_init_f started */
>>> #endif
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + void *early_heap_first; /* heap for early_malloc */
>>> +#endif
>>> } gd_t;
>>>
>>> #include <asm-generic/global_data_flags.h>
>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>> index f1951e8..f73d8b2 100644
>>> --- a/arch/arm/lib/board.c
>>> +++ b/arch/arm/lib/board.c
>>> @@ -53,6 +53,10 @@
>>> #include <post.h>
>>> #include <logbuff.h>
>>>
>>> +#ifdef CONFIG_DM
>>> +#include <dmmalloc.h>
>>> +#endif
>>> +
>>> #ifdef CONFIG_BITBANGMII
>>> #include <miiphy.h>
>>> #endif
>>> @@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)
>>>
>>> memset((void *)gd, 0, sizeof(gd_t));
>>>
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + gd->early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
>>> +#endif /* CONFIG_SYS_EARLY_MALLOC */
>>> +
>>
>> I just realised that all these initialisers can be dumped - early_brk()
>> will be called when early_malloc() is first called
>>
>
> Yes, but how can I determine the size of the new heap which the
> early_brk gives out? When I have CONFIG_SYS_EARLY_HEAP_SIZE macro in
> board configuration I can ignore the size passed to the "default"
> early_brk and return the full-sized heap as configuration says (when
> the requested size is lower than configured heap size and NULL
default early_brk() should always use CONFIG_SYS_EARLY_HEAP_SIZE
> otherwise). But what if somebody implements at some point a dynamic
> early_brk capable of returning multiple heaps? Should I safely assume
> that the future dynamic early_brk would give out multiples of page
> size or so?
Very good point. I would assume early_brk() will always return the
largest possible chunk of memory it can. These sizes might be
specified as multiple #defines in the board config or may be
dynamically determined via hardware probing. Either way, that is a
problem for the implementer to deal with :)
Regards,
Graeme
More information about the U-Boot
mailing list