[U-Boot] Early malloc() summary

[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. 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 and being seamless to users is really
tempting. But do we need/want to introduce such deep rewrites? 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.

>> 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?

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


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