[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

Tom Rini trini at ti.com
Tue Jul 15 00:28:47 CEST 2014


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140714/b900d0ee/attachment.pgp>


More information about the U-Boot mailing list