From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Early malloc() summary
Date: Thu, 16 Aug 2012 16:52:01 +0200 [thread overview]
Message-ID: <201208161652.01179.marex@denx.de> (raw)
In-Reply-To: <502CD8B3.4070104@gmail.com>
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@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.
> >>>
> >>>> 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
next prev parent reply other threads:[~2012-08-16 14:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-09 0:55 [U-Boot] Early malloc() summary Graeme Russ
2012-08-09 12:48 ` Wolfgang Denk
2012-08-11 23:16 ` Marek Vasut
2012-08-14 8:11 ` Tomas Hlavacek
2012-08-14 12:37 ` Marek Vasut
2012-08-14 13:08 ` Albert ARIBAUD
2012-08-14 14:40 ` Marek Vasut
2012-08-14 13:54 ` Graeme Russ
2012-08-14 14:00 ` Marek Vasut
2012-08-16 11:25 ` Graeme Russ
2012-08-16 14:52 ` Marek Vasut [this message]
2012-08-16 23:05 ` Graeme Russ
2012-08-14 23:56 ` Marek Vasut
2012-08-16 11:39 ` Graeme Russ
2012-08-15 12:00 ` Tomas Hlavacek
2012-08-16 11:56 ` Graeme Russ
2012-08-16 14:50 ` Marek Vasut
2012-08-16 23:03 ` Graeme Russ
2012-08-16 23:32 ` Marek Vasut
2012-08-16 23:50 ` Graeme Russ
2012-08-17 0:34 ` Marek Vasut
2012-08-17 1:15 ` Graeme Russ
2012-08-19 13:21 ` Tomas Hlavacek
2012-08-19 23:47 ` Graeme Russ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201208161652.01179.marex@denx.de \
--to=marek.vasut@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox