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:
- gd = id;
- enable_caches();
- mem_malloc_init();
Proposed sequence for mallocator (in order no to loose any data from old and not-relocated part of GD):
- gd_old = gd;
- gd = id;
- mem_malloc_init();
- relocation of DM structures
- early_malloc_disab()
- 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