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

[Simon Glass]

Hi,

On 28 July 2014 06:16, Simon Glass <sjg at chromium.org> wrote:
> Hi Tom,
>
>
> On 23 July 2014 14:41, Tom Rini <trini at 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 at chromium.org> wrote:
>>> > Hi Tom,
>>> >
>>> > On 14 July 2014 16:28, Tom Rini <trini at 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