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... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: Do you know what the death rate around here is? A: One per person. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot