On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
> Hi,
>
> On 14 July 2014 18:16, Simon Glass <s...@chromium.org> wrote:
> > Hi Tom,
> >
> > On 14 July 2014 16:28, Tom Rini <tr...@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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
