Hi Tom,
On 14 July 2014 16:28, Tom Rini trini@ti.com wrote:
On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.
A previous implementation was sent in a v1 series.
This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.
No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.
After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.
Implementations are provided for sandbox and arm (32-bit only).
A related change is made to the early init for each arch to make this work.
My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.
One option would be to split this new code out into a separate file, and have two malloc() implementations:
- big one - falls back to small one pre-relocation - small one - used for SPL
Regards, Simon