Hi Thomas,
On Mon, Sep 24, 2012 at 10:35 AM, Tomas Hlavacek tmshlvck@gmail.com wrote:
Hi Graeme!
On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Tomas,
On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek tmshlvck@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@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