[U-Boot] Early malloc() summary

Marek Vasut marek.vasut at gmail.com
Thu Aug 16 16:52:01 CEST 2012


Dear 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

In uboot, not so much ... in uboot it'd be just a matter of making one memory 
are that's currently available to malloc() into list of memory areas and that's 
all. Not specific at all


Best regards,
Marek Vasut


More information about the U-Boot mailing list