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.
--
Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
