[U-Boot] Stack size

[James Chargin]

Dear Parimala Baggiri,

I am able to provide a bit more information, based on your reply. Please 
forgive my assumption that you are even less familiar with U-Boot 
internals than I am.

Again, I'm writing about the Freescale SOCs, undoubtedly ARM processors 
do some things differently. I hope my comments about my processors might 
lead you to the appropriate code for yours. Also, I should mention that 
I'm referring to a fairly old version of U-Boot and it is possible that 
things related to DDR layout have changed for newer versions.

On 12/26/2013 09:37 PM, Parimala Baggiri wrote:
> Hello James,
>
> Thank you for the detailed explanations
>
> On Thu, Dec 26, 2013 at 8:13 PM, James Chargin <jimccrown at gmail.com
> <mailto:jimccrown at gmail.com>> wrote:
>
>
>     I work with Freescale e300 and e500 SOCs, other processors may do
>     things a bit differently.
>
>     U-Boot places several things in very high RAM. leaving the lower
>     areas of RAM available for loading the OS and/or application(s).
>
>     The stand alone application uses the U-Boot stack; it does not have
>     its own.
>
>     For Freescale processors, the stack grows from higher addresses to
>     lower.
>
>     Among the several things U-Boot places in upper RAM are the
>     RAM-based copy of U-Boot itself, the video display buffer (if used)
>     and the stack used by U-Boot and any stand alone application. This
>     will require around a few megabytes of RAM storage.
>
> In my case RAM-based copy of u-boot is mapped to
> 0x80E80000(CONFIG_SYS_TEXT_BASE),  which is not the upper RAM location.
> Is upper RAM means the last few megabytes of the total capacity?
>
>     The stack is located below all other items placed in RAM by U-Boot
>     and so is limited to the remaining size of RAM (less the amount of
>     space needed by the OS or the stand alone application, usually in
>     the very lowest address range). In my experience, this is an
>     unusually large area for a stack; I've never gotten anywhere close
>     to an overflow.

In my case, U-Boot sets up the SDRAM allocations in the function 
board_init_f(), found in .../u-boot/arch/powerpc/lib/board.c. I assume 
there is a similar file and function for ARM.

board_init_f() determines which things get put, and in which locations, 
in DDR. Following is a list, in decreasing address order, of things 
allocated in DDR

     "hidden" RAM
     kernel log buffer (optional)
     "protected" RAM (optional)
     video and/or LCD framebuffer (optional)
     U-Boot
     heap (for malloc)
     board info structure
     global data structure
     stack

A similar procedure must be followed for ARM but I haven't looked at the 
details. In my case, there is a debug message that can be enabled that 
displays the location at which the stack is installed (Enable debug 
messages by adding "#define DEBUG" at the top of the file containing the 
message of interest. Then rebuild U-Boot).

>
>     Can you supply more information about why you are asking about
>     increasing stack size? Have you encountered a situation which seems
>     to indicate a stack overflow?
>
> In my standalone application, some debugging messages(printfs) are
> added, which are not printing in one function and even the application
> is not terminating for any reason. Hence, suspecting the stack size.

It might be possible from the debug messages in board_init_f() and from 
knowing where the stand alone application is placed in DDR (and how big 
it is) to make a better determination about how likely an overflow is.

It might also be possible to do something like
   1) Clear the DDR where the stand alone app is to be placed with a 
known value (mw command). The cleared area should extend beyond where 
the stand alone app is location. You should be able to examine memory 
(md command) after the stand alone is loaded, but before it is run, and 
clearly see the end of the stand alone code and the start of the known 
value.
   2) Load and run the stand alone app. From what you've said, I presume 
this results in a reset being required. For me, when U-Boot starts, it 
doesn't clear DDR and if the DDR isn't power cycled, it should maintain 
its value through a reset.
   3) Reset the board.
   4) Examine DDR where the end of the stand alone is supposed to be (md 
command) and see if memory beyond this point has the known value in it. 
If not, this is a possible indication that overflow did occur.

>
>     What processor and board are you interested in?
>
>
> Here are my processor details,
> Panda board ES which uses OMAP4460 processor,
> 4GB SDRAM, starts at 0x80000000.
>

4 GiB is certainly enough RAM that you should be able to find a way to 
avoid any stack overflow.

One other thing you could consider doing, is changing 
CONFIG_SYS_TEXT_BASE. This could leave a bigger area between where the 
stack starts and where the stand alone application gets loaded. Good 
luck if you try this; I myself am a bit too timid to try changing a 
CONFIG_SYS_ constant.

Perhaps someone with more detailed knowledge of ARM can comment on 
moving CONFIG_SYS_TEXT_BASE, or maybe even moving the stand alone 
application to a larger free area of DDR.

Good luck.

Best regards,
Jim
-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com

>
> Regards,
> Parimala