[U-Boot] Early malloc() summary

[Marek Vasut]

Dear Tomas Hlavacek,

> Hello Marek,
> 
> On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <marex at denx.de> wrote:
> > So ... we should aim for firing up the real mallocator as soon as
> > possible and maybe implement discontigmem (sparsemem) into it, so we
> > don't have to bother with relocating pointers maybe?
> > 
> > The only problem I see is platforms where the memory disappears.
> 
> I doubt that on ARM for instance you can set off real mallocator that
> early without completely rewriting it.

Esp. on ARM, I won't see much of a problem. You usually have some small SRAM 
where such allocator could run.

> The idea of having one complex
> mallocator working in the same manner in board_init_f and board_init_r
> stages, being able to operate on all platforms using their nifty
> memory-management/model features

Do you need them? You usually need only a piece of RW memory.

> and being seamless to users is really
> tempting. But do we need/want to introduce such deep rewrites?

Deep rewrites? You'd only need to implement sparsemem into it, which might be 
list of RW memory areas instead of one memory area.

> What
> would be the justification? I would say we should stick with the
> Wolfgang's opinion: Create small and efficient early_malloc for DM and
> prepare it for future extensions and possible reuses.

dm_malloc you mean? I'm not happy about it, maybe Graeme can pour in some crazy 
juice in our direction again?

> >> Switching the focus back to DM, I really would like to ask to delay
> >> alls uch activities until DM has been done (or at least has stabilized
> >> so far that we can affort the luxury of thinking about the next
> >> version with fancy extensions).
> > 
> > We still need to handle the pre-reloc drivers somehow, you know ... but I
> > still believe we can pull the DM internals in three people and leave
> > Thomas to do proper malloc stuff ...
> 
> Yes, this is the main question: Should I hack malloc() function or
> does it make sense to have both early_malloc() and malloc() exposed to
> DM cores/drivers?

This is indeed the main question -- ideas ?

> The first is better from the point of view of drivers - when you ask
> for memory, you get it. But you have to check yourself whether you
> need to relocate your pointers or not, though we can provide
> "relocation chain" you can register your relocation routine into to
> facilitate it. The later makes sense because this makes it explicit
> that whenever you use early_malloc() you are responsible for
> relocating your data on your own (again, we can provide some facility
> for ir).
> 
> There is a third path possible: We can provide early_malloc() and say
> wrapped_malloc() which can be the third function "give me memory, I do
> not care whether it is early or not". So drivers and/or DM can choose
> to use malloc routines working in early-only, late-only or both.
> 
> Tomas

Best regards,
Marek Vasut