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

[Tomas Hlavacek]

Hi Graeme,

On Sun, Jul 29, 2012 at 12:53 PM, Graeme Russ <graeme.russ at gmail.com> wrote:

> 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

Yes. Actually my intention is to create a wrapper for switching from
early_malloc()
to dlmalloc() based on gd->flags. I am going to do that when the concept of
early_malloc() is finished.

>
> 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

Thanks for explanation!

We have reconsidered relocation of DM structures. Perhaps we are going to
keep the structures on early_heap (in copied GD) and we are going to convert
pointers inside our structures and copy data after actual relocation when the
dlmalloc and caches are up and running. We think that this might be fastest
approach.

Tomas

-- 
Tomáš Hlaváček <tmshlvck at gmail.com>