From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 11 Oct 2013 14:27:24 -0400 Subject: [U-Boot] [PATCH] env_mmc: fix buffer allocation for armv7 In-Reply-To: <20131008181701.C8181381188@gemini.denx.de> References: <1380894483-6754-1-git-send-email-list-09_u-boot@tqsc.de> <20131004170203.GL15917@bill-the-cat> <20131005195728.AE316380A3C@gemini.denx.de> <20131006204214.GO15917@bill-the-cat> <20131007053424.B4FAD380435@gemini.denx.de> <20131007122020.GT15917@bill-the-cat> <20131007135802.7D560380A63@gemini.denx.de> <20131008134456.GB15917@bill-the-cat> <20131008181701.C8181381188@gemini.denx.de> Message-ID: <20131011182724.GP15917@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 Tue, Oct 08, 2013 at 08:17:01PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20131008134456.GB15917@bill-the-cat> you wrote: > > > > > Well, if we have DDR such that we can use it for the malloc arena, we > > > also should use it for the stack. Or is there a good reason for not > > > doing this? It would solve all these issues at the root... > > > > Making SPL more complex for everyone? We would need to do a fairly > > good-sized re-jigger of SPL to setup and swap around stack pointers like > > we do in full U-Boot. > > Hm, I'm not convinced. As proposed, we make the code bigger, less > efficient, more error prone and more ugly for everyone, not only for > SPL users. Aslo, this might not be the only place where buffers or > such may be kept on the stack. I hope you don't want to change all > these? > > Really, if we have the resources, we should use them. If RAM is > abailable, it should also be used for the stack. Just using it for > malloc() is neither fish nor fowl. I'll ceed the point and re-work things on my series then. Markus, your patch is good as-is and I shall pick it up shortly. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: