From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot-DM] early_malloc() vs. enable_caches()
Date: Sun, 29 Jul 2012 14:15:41 +0200 [thread overview]
Message-ID: <201207291415.41866.marek.vasut@gmail.com> (raw)
In-Reply-To: <50151642.4090301@gmail.com>
Dear Graeme Russ,
> Hi Thomas,
>
> P.S. I dropped the DM list...
>
> It took a couple of other emails to get what is going on here...
>
> On 07/29/2012 01:46 AM, Tomas Hlavacek wrote:
> > Hello!
> >
> > I am working on early_malloc() for U-Boot Driver Model (this malloc is
> > going to serve for internal DM structures during early init and it has
> > it's minimalistic heap in global data).
>
> Not exactly on-topic, but I really hope that everything is wrapped so a
> simple call to malloc() will work pre-relocation. Of course, everything you
> malloc pre-relocation will have to be re-malloc'd and relocated after
> relocation. Point is, early malloc should not be restricted to the driver
> framework
>
> > My question is how to correctly switch from early allocator to full-scale
> > malloc and when to enable caches.
> >
> > The current state (on ARM) is:
> > 1) gd = id;
> > 3) enable_caches();
> > 3) mem_malloc_init();
> >
> > Proposed sequence for mallocator (in order no to loose any data from old
> > and not-relocated part of GD):
> >
> > 1) gd_old = gd;
> > 2) gd = id;
> > 3) mem_malloc_init();
> > 4) relocation of DM structures
> > 5) early_malloc_disab()
> > 6) enable_caches();
>
> I'm thinking:
>
> 1) Low-level CPU init
> 2) 'Cache-As-RAM' init
> 3) Global Data init
> 4) Pre-console buffer init
Buffer?
> 5) Early malloc() init
> 6) Console init
You don't need console here ... probably, on some systems.
> 7) ...blah, blah, blah...
> 8) SDRAM init
> 9) Relocate Global Data
> 10) malloc() init
> 11) 'Disable' early malloc (i.e. malloc() now allocates from SDRAM)
> 12) Relocate from early_malloc_pool to malloc_pool [1]
> 13) enable_caches()
>
> [1] I'm thinking possibly compile-time registered hooks...
Gurr ... you mean like INIT-something framework?
> > Does it make sense? It actually boils down to one fundamental question:
> > When I have not-rellocated data locked in cache-lines, do I loose them
> > once enable_caches() is called?
>
> I believe that yes, as soon as you enable caching, everything already in
> cache (gd, pre-console buffer, early malloc pool etc) is as good as gone
Right ... that's why now it's copied to a safe location alongside other GD
(global data)
> Regards,
>
> Graeme
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-07-29 12:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-28 15:46 [U-Boot] early_malloc() vs. enable_caches() Tomas Hlavacek
2012-07-29 9:42 ` Albert ARIBAUD
2012-07-29 10:25 ` [U-Boot] [U-Boot-DM] " Marek Vasut
2012-07-29 10:53 ` Graeme Russ
2012-07-29 12:15 ` Marek Vasut [this message]
2012-07-29 13:19 ` Tomas Hlavacek
2012-07-29 22:34 ` 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=201207291415.41866.marek.vasut@gmail.com \
--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