Hi Graeme,
On Sun, Jul 29, 2012 at 12:53 PM, Graeme Russ graeme.russ@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.
- Low-level CPU init
- 'Cache-As-RAM' init
- Global Data init
- Pre-console buffer init
- Early malloc() init
- Console init
- ...blah, blah, blah...
- SDRAM init
- Relocate Global Data
- malloc() init
- 'Disable' early malloc (i.e. malloc() now allocates from SDRAM)
- Relocate from early_malloc_pool to malloc_pool [1]
- 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