From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 23 Jul 2014 09:41:46 -0400 Subject: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation In-Reply-To: References: <1405052613-20987-1-git-send-email-sjg@chromium.org> <20140714222847.GL1847@bill-the-cat> Message-ID: <20140723134146.GD1847@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote: > Hi, > > On 14 July 2014 18:16, Simon Glass wrote: > > Hi Tom, > > > > On 14 July 2014 16:28, Tom Rini 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: