Re: [U-Boot] Stack size

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@gmail.com mailto:jimccrown@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