public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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