Hello Wolfgang Denk,

Thank you for the reply. Could you please clarify me the following things about u-boot? To add more system RAM where should I change and whether it is SDRAM or SRAM? I am using panda es board(omap4460), whose SDRAM starts at 0x80000000, after the boot, u-boot relocates to 0x80E80000, how can we know from where stack starts in SDRAM, to allocate the space for my standalone application? Is the Stacksize common for u-boot and standalone application?

Regards, Parimala

On Wed, Dec 25, 2013 at 3:41 AM, Wolfgang Denk wd@denx.de wrote:

Dear Parimala Baggiri,

In message <CAD6P= 4hWjGozdwZhbk00fVGyPry63sM4ErEXgpUFsJpihD9kWA@mail.gmail.com> you wrote:

...

How to increase the user mode stack size which will be used by the standalone application in u-boot?

Add more system RAM.

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: wd@denx.de It's certainly convenient the way the crime (or condition) of stupidity carries with it its own punishment, automatically admisistered without remorse, pity, or prejudice. :-) -- Tom Christiansen in 559seq$ag1$1@csnews.cs.colorado.edu

Dear Parimala Baggiri,

To add a bit of context to Wolfgang Denk's reply...

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.

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.

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?

What processor and board are you interested in?

Best regards, Jim

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

Hello Wolfgang, James,

Thanks for the information. Yes, James your assumption about my knowledge on U-Boot internals is correct. I have used u-boot to bring up the OS, but this time I had to run a SA from u-boot, which requires more understanding of U-Boot internals.

Any chance that you are using an older and/or out-of-tree version of

U-Boot? We can only help you with mainline code...

I am using u-boot-linaro-stable version from linaro.

...

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.

Attach a debugger?

No debugger.

...

Here are my processor details, Panda board ES which uses OMAP4460 processor, 4GB SDRAM, starts at 0x80000000.

4 GB RAM is special, as mapping the whole RAM would consume the whole 32 bit address space. What is the exact version of U-Boot (git commit ID) you are running? And which exact board configuration?

I am using omap4_panda_config configuration, sorry only 1GB SDRAM is available by default.

I found that the THUMB mode and the optimization level(-O2) were creating the problem. My application executes fine with ARM mode and optimization level -O1.

Even the simple hello_world application running in thumb mode generates "undefined instruction" exception. By default CONFIG_SYS_THUMB_BUILD is enabled, any extra settings are required for smooth operation of THUMB mode?

Regards, Parimala

In message <CAD6P=4jO2BhCCU10227a_N3rUMK1aWU_C= BPYdtitFE0E4drfg@mail.gmail.com> you wrote:

...

Any chance that you are using an older and/or out-of-tree version of

...

U-Boot? We can only help you with mainline code...

I am using u-boot-linaro-stable version from linaro.

Sorry, Linaro has an unknown number of unknown patches in their tree, we cannot help you with that.

Also note that several people have repeatedly reported problems with the Linaro tool chain, so be careful about that, too.

Can you please suggest which tool chain would be better ?

Regards, Parimala