[U-Boot] Early malloc() summary

[Graeme Russ]

Hi Marek,

On 08/15/2012 12:00 AM, Marek Vasut wrote:
> Dear Graeme Russ,
> 
>> Hi Marek,
>>
>> On Tue, Aug 14, 2012 at 10:37 PM, Marek Vasut <marex at denx.de> wrote:
>>> 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.
>>
>> OK, stop right there (please) - This gets into a highly architecturally
>> specific implementations of malloc. Let's not go there OK :)
> 
> Not really, today you give the mallocator one slab of memory on which it 
> operates ... making it so it'd operate on a list of such slabs shouldn't be 
> _that_ hard.

When you start throwing around "discontigmem", "sparsemem" and "nifty
memory-management/model features" you are talking architecture specifics

Regards,

Graeme