[U-Boot] Stack size

[U-Boot] Stack size

[Parimala Baggiri]

Hello,

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

[U-Boot] Stack size

[Wolfgang Denk]

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 at 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>

[U-Boot] Stack size

[Parimala Baggiri]

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 at 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 at 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>
>

[U-Boot] Stack size

[Wolfgang Denk]

Dear Parimala Baggiri,

please stop top-posting / full-quoting.  Thanks.

In message <CAD6P=4j2eGh16C6hB7Z8ahc8h6iPd+Na02Sn1NJEnbK+v+ntmA@mail.gmail.com> you wrote:
>
> 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 wrote: system RAM.  On most systems this is SDRAM (or rather DDR
these days).

> 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?

James Chargin already explained most of the details - note that his
explanation is pretty much genral; see also section "Memory Management" 
in the U-Boot README file.

Your SA application uses both the malloc arena and the stack that has
been set up by U-Boot, so stack size is really only limited by the
size of the 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 at denx.de
Minds are like parachutes - they only function when open.

[U-Boot] Stack size

[James Chargin]

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
-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com

On 12/24/2013 02:11 PM, Wolfgang Denk 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
>

[U-Boot] Stack size

[Parimala Baggiri]

Hello James,

Thank you for the detailed explanations

On Thu, Dec 26, 2013 at 8:13 PM, James Chargin <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.
>
> 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.

   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.


Regards,
Parimala

[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@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
-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com

>
> Regards,
> Parimala

[U-Boot] Stack size

[Wolfgang Denk]

Dear Parimala Baggiri,

In message <CAD6P=4jA7MvB+DaSXsmH=CW=ckPzAk5=UPcimJO-sxYniSZevw@mail.gmail.com> you wrote:
>
> 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?

Yes, upper RAM means the top end of the existing, usable RAM address
range.

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...

> 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?

> 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?


BTW - did you read the related FAQs?

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 at denx.de
When a stupid man is doing something he  is  ashamed  of,  he  always
declares that it is his duty                           - George Orwell

[U-Boot] Stack size

[Parimala Baggiri]

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

[U-Boot] Stack size

[Wolfgang Denk]

Dear Parimala Baggiri,

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.

> > Attach a debugger?
> 
> No debugger.

Buy one.  It will save you lots of time.


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 at denx.de
The first 90% of a project takes 90% of the time, the last 10%  takes
the other 90% of the time.

[U-Boot] Stack size

[Parimala Baggiri]

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

[U-Boot] Stack size

[Wolfgang Denk]

Dear Parimala Baggiri,

In message <CAD6P=4jLawHYxdrAaMYa1t=BJseDqk5=-+wTTAbFy+Btayt2rQ@mail.gmail.com> you wrote:
>
> Can you please suggest which tool chain would be better ?

We are using ELDK, but I'm obviously biased here.  In any case,
experience with all Yocto based tool chains is pretty good.

> --047d7b5db124442c9904eece2d9b
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

Please stop posting HTML.  Thanks.

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 at denx.de
Cogito cogito ergo cogito sum - "I think that I  think,  therefore  I
think that I am."          - Ambrose Bierce, "The Devil's Dictionary"