Hi,
On 28 July 2014 06:16, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On 23 July 2014 14:41, Tom Rini trini@ti.com wrote:
On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
Hi,
On 14 July 2014 18:16, Simon Glass sjg@chromium.org wrote:
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
I'm thinking of applying this to the dm repo now, except for the arm patches where I would like to get Albert's ack (so I'll wait a few more days).
Any objections?
I think we'll be OK. I checked over the callpath again on OMAP parts and we setup DDR prior to _main (in SPL) so we'll be fine.
OK, I'll prepare a pull request for the ARM-related malloc() patches soon, along with the GPIO things (sandbox only at this stage as we need to make progress on applying exynos patches first).
I haven't heard from Albert or Minkyu so will go ahead with this plan.
Regards, Simon