[U-Boot] [U-Boot-DM] early_malloc() vs. enable_caches()

[Graeme Russ <graeme.russ@gmail.com>]

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
5) Early malloc() init
6) Console init
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...

> 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

Regards,

Graeme