From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Tue, 14 Aug 2012 15:08:15 +0200
Subject: [U-Boot] Early malloc() summary
In-Reply-To: <201208141437.29415.marex@denx.de>
References: <CALButCL9btmPEW3Uiv9=tU4Yk7fdTUruzpCcVqMLynpzWv6Pug@mail.gmail.com>
	<201208120116.07059.marex@denx.de>
	<CAEB7QLB5GHqvC_s7aPxeMe2hHOrgL4b9f4qq-2RAPesUiWpf=A@mail.gmail.com>
	<201208141437.29415.marex@denx.de>
Message-ID: <20120814150815.30522646@aari01-12>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Marek,

On Tue, 14 Aug 2012 14:37:29 +0200, Marek Vasut <marex@denx.de> wrote:
> Dear Tomas Hlavacek,
> 
> > Hello Marek,
> > 
> > On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <marex@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.

... or not; for instance, orion5x / edminiv2 does not have such SRAM. So
how do we handle this there?

Amicalement,
-- 
Albert.