On Thu, May 2, 2013 at 10:35 AM, Marc Jones marcj303@gmail.com wrote:
On Thu, May 2, 2013 at 9:25 AM, Aaron Durbin adurbin@chromium.org wrote:
On Thu, May 2, 2013 at 10:15 AM, Marc Jones marcj303@gmail.com wrote:
Hi Aaron,
On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin adurbin@chromium.org wrote:
Hi folks,
I am wondering why the ramstage stack size is so large on a lot of boards:
$ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{ print $NF }' | sort | uniq -c | sort -r -n 16 0x10000 2 0x2000 2 0x1000 1 0x20000
Is this just an artifact of copy-n-paste? What is driving the requirement for such large stack sizes?
I suspect that it is some copy and paste. Some of the AMD Fam10 and Fam15 have large stacks for stacks for each core (which may or maynot need to be as large as they are).
What do you mean by that? Did you mean the STACK_SIZE variable is being used preallocate stacks for all cores? If so what about the following? I admittedly changed the 2nd one, but that still followed the original intent.
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/stack.c;h=... http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/c...
-Aaron
Sorry, I am wrong about that being the total size. The BSP of the AMD code requires a large stack, but those sizes do seem excessive.
OK. Thanks for the info. That does make for some huge memory footprints on the AMD machines with a large number of CONFIG_MAX_CPUS. I'd be curious to know why the BSP for the AMD code requires so much while in ramstage.
-Aaron
-
Aaron Durbin