[U-Boot] [U-Boot-DM] [PATCH 1/1] early_malloc() introduced to ARM architecture

[Tomas Hlavacek]

Hello Marek,

On Sat, Jul 28, 2012 at 10:36 PM, Marek Vasut <marex at denx.de> wrote:
> I think we should still mark early patches as RFC.

Sure...

> > +#include <earlymalloc.h>
>
> Do we need early_malloc.h at all? malloc.h won't cut it?

My intention was to keep the early_malloc in separate instance from
real malloc. Although this is proof-of-concept / RFC for early_malloc,
it does not contain adaptation layer for switching
malloc/early_malloc, because it seriously break things. I wanted
comments on the basic idea first.


> +    early_malloc_init();
> So this basically flips a bit, do it the other way and you don't need it.

Well yes. I was told to support more stages of early_mallocator
deactivation during DM core relocation. So this is why I have plenty
of flags (currently using one). Now I know at least about two stages
and three states. Actually intended lifecycle of the early_malloc is:

1) init: malloc() calls are switched to early_malloc(), other calls (=
free(), realloc()...) are switched to dummy.
2) relocation done, real malloc initialized, before core relocation:
malloc() switched to dlmalloc, other calls to dummy (this is special
mode for core relocation, which prevents calling dlmaloc free() on
space allocated by early_malloc().
3) Full switch to dlmalloc.

Sure we can make it simpler, if it is OK with prospective core
relocation function.

>
> No, we want this wrapped into malloc() call, so the drivers can be inited
> indifferent of time.

Sure. My intention was not to hack current malloc but rather create
adaptation layer. Maybe not a good idea... Anyway I can put simple
switches like

if(!(gd->flags & GD_FLG_RELOC))
	return early_malloc();

directly into malloc() functions.

>
> > +
> > +typedef struct early_malloc_spc {
> > +        char            flags;
> > +        short           size;
> > +        char            heap[EARLY_HEAP_SIZE];
> > +} em_spc_t;
>
> Drop the typedef please.

Actually I don't follow what is the problem here with the typedef?

> > diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
> > index c88f5d4..6e39826 100644
> > --- a/lib/asm-offsets.c
> > +++ b/lib/asm-offsets.c
> > @@ -23,7 +23,7 @@ int main(void)
> >  {
> >      /* Round up to make sure size gives nice stack alignment */
> >      DEFINE(GENERATED_GBL_DATA_SIZE,
> > -        (sizeof(struct global_data) + 15) & ~15);
> > +        (sizeof(struct global_data_extended) + 15) & ~15);
>
> And if you adjusted the global data to be the "container of both, you
> won't need
> this here either.

Sure. My intention was to keep early_malloc heap in separate structure
(containing the GD structure) in order not to relocate it but rather
relocate cores by ourselves, which was our plan. It would be simpler
to have it in the end of standard GD structure, because we can drop
multi-stage early_malloc turn-off and perhaps we are not going to need
to do relocation of DM structures by hand.

Tomas


--
Tomáš Hlaváček <tmshlvck at gmail.com>