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.