On Thu, May 2, 2013 at 10:35 AM, Marc Jones <[email protected]> wrote: > On Thu, May 2, 2013 at 9:25 AM, Aaron Durbin <[email protected]> wrote: >> On Thu, May 2, 2013 at 10:15 AM, Marc Jones <[email protected]> wrote: >>> Hi Aaron, >>> >>> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <[email protected]> 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=1f9e0099445b5b9f14a367e958dfec1713e15703;hb=refs/heads/master >> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/c_start.S;h=32af0ccdf94614fd4a0b0fffe99f27f2a6ce6294;hb=refs/heads/master#l9 >> >> -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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
