From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Mon, 24 Sep 2012 10:46:39 +1000 Subject: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added. In-Reply-To: References: <1346069529-27397-1-git-send-email-tmshlvck@gmail.com> <1348416940-20319-1-git-send-email-tmshlvck@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Thomas, On Mon, Sep 24, 2012 at 10:35 AM, Tomas Hlavacek wrote: > Hi Graeme! > > On Mon, Sep 24, 2012 at 2:00 AM, Graeme Russ wrote: >> Hi Tomas, >> >> On Mon, Sep 24, 2012 at 2:15 AM, Tomas Hlavacek 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 >>> --- >>> 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 >>> 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 >>> #include >>> >>> +#ifdef CONFIG_DM >>> +#include >>> +#endif >>> + >>> #ifdef CONFIG_BITBANGMII >>> #include >>> #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