Hello all!
In u-boot-dm mailinglist we had a discussion about implementation of early_malloc (not only) for U-Boot Driver Model. The intention is to have a simple malloc() function in the early stage of init before relocation and before RAM is up and running. There was an experimental patch that added the early heap to GD structure.
In the following discussion Graeme Russ pointed out that there is a pre-console buffer which does the similar thing. And we should not explode GD by adding the early heap (which is going to be few hundreds of bytes long) into it. He suggested to create an independent area locked in cache lines for early heap in order to allow split GD and early heap into more non-contiguous blocks.
Pavel Hermann said that we would have to copy data twice (first before the RAM is up and running and caches are still off and second after RAM and dlmalloc is initialized).
Marek Vasut said (earlier in the discussion) that we do not need to care about few hundred of bytes, especially after copying them into RAM. And Wolfgang Denk resisted. He also pointed out that there are other possibilities where early memory may be allocated - on-chip-memory, external SRAM and others and these should be kept in mind including existing size restrictions.
(I apologize for eventual misinterpretation and I am sorry that we do not have a link to the u-boot-dm mailinglist archive nor GMANE. But I can eventually Fwd. needed pieces of the discussion.)
We would like to hear opinions on the early_malloc idea to find a broadly acceptable solution.
Can/should we use some existing mechanism? Or would it be considered a viable option to choose different beginning address for early heap, use it (in architecture-specific way) and keep the pointer to the beginning in GD. Then copy the early heap to memory before caches are flushed and in case of DM copy again data from early heap to new destinations that has been obtained through malloc() when it is initialized?
Tomas