Hi, On 28 July 2014 06:16, Simon Glass <[email protected]> wrote: > Hi Tom, > > > On 23 July 2014 14:41, Tom Rini <[email protected]> wrote: >> On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote: >>> Hi, >>> >>> On 14 July 2014 18:16, Simon Glass <[email protected]> wrote: >>> > Hi Tom, >>> > >>> > On 14 July 2014 16:28, Tom Rini <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
