[coreboot] Question about STACK_SIZE

Aaron Durbin adurbin at google.com
Thu May 2 17:39:03 CEST 2013


On Thu, May 2, 2013 at 10:35 AM, Marc Jones <marcj303 at gmail.com> wrote:
> On Thu, May 2, 2013 at 9:25 AM, Aaron Durbin <adurbin at chromium.org> wrote:
>> On Thu, May 2, 2013 at 10:15 AM, Marc Jones <marcj303 at gmail.com> wrote:
>>> Hi Aaron,
>>>
>>> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin at 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=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



More information about the coreboot mailing list