On 05/02/11 19:30, Wolfgang Denk wrote: > Dear Lei Wen, > > In message <aanlktin-ebt+pa0tmdlbpaqo3pbjwmbnldfuj2k-j...@mail.gmail.com> you > wrote: >> >>> In which way do you think this will save any memory? >> >> This patch is not intend to save memory... > > Then I don't understand at all what the benefit of that patch would > be. > >> One of our project need to confine the ddr usage of uboot in the smallest >> case, >> not to pollute other area. So for us, the small stack is good one... > > So it is still about saving memory... > >> For now the uboot is relocated to the end of the dram, and malloc area is >> almost a fix value, uboot would live happily in this area. But for env case, >> it allocate a range which could be large, due to the CONFIG_ENV_SIZE >> could be a big one, in the stack range. Because the stack is grown downwards, >> so it takes more memory range than it is allocated in the malloc method. >
Sounds like you have allocated too small a region for your stack - try increasing CONFIG_SYS_STACK_SIZE and decreasing CONFIG_SYS_MALLOC_LEN > malloc arena and stack are adjacent. If you have enough free room in > the malloc arena for the environment buffers, but cannot afford to > have them on your stack, then this means your malloc arena has lots of > unused space. Decrease the size of your malloc arena by the size of > the environment buffer, and you reach the same goal as with your > patch - actually you save more memory, as the code size of u-boot > shrinks. > > Can you please provide exact numbers? How big is your RAM? What is > the debug output of arch/*/lib/board.c without and with this patch on > your system? How big is your environment resp. the environment > sectors? > The only other thing I could think of that would make sense would be having the malloc heap in a completely different memory segment to the stack - odd, but possible Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
