On Mon, Oct 07, 2013 at 03:58:02PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20131007122020.GT15917@bill-the-cat> you wrote: > > > > > But malloc() is drawing from the very same resource as the stack, even > > > more so: with a buffer on the stack, the memory isfreed completeky > > > upon return from the fucntion, with no reminders left. With malloc() > > > you need to statically allocate the malloc pool size for the whole > > > runtime, and allocating the buffers may fragment tha area, so even > > > after freeing the buffers there is less space left for other purposes. > > > > > > Especially in memory-tight situations you want to avoid malloc(). > > > > Ah, but in these cases we don't have stack room, period. We have a > > malloc pool. So unless we make SPL move its stack pointer into DDR from > > wherever we set the initial one to, the other option here is to just > > restrict real env support to NOR (and we already don't allow embedded > > env, since that's embedded within U-Boot, not SPL). > > 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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
