New subject: Question about STACK_SIZE

2 May 2013


      * Marc Jones marcj303@gmail.com [130502 20:24]:
...
On Thu, May 2, 2013 at 12:22 PM, Stefan Reinauer
stefan.reinauer@coreboot.org wrote:
...

Aaron Durbin adurbin@google.com [130502 17:39]:

...
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
One of the majore things needed on the BSP used to be lzma decompression
which put a 16K array on the stack. We fixed this a while ago, bringing
down stack usage on our Intel based boards to about 1K (and giving each
core a 4K stack)
We fixed the issue by putting that big array in the heap instead. Maybe
we can fix the AMD code in the same way.
I would like to see some actual stack usage data first though
Stefan
I agree. Can we get a list of boards (I am busy and lazy). We probably
have some of the systems at Sage.
Asrock E350M1 (using Agesa)
CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes
CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes
So it would work just fine with the default 4K stack size, even if it
took almost twice of the above measurement due to more complex hardware
in the system (extremely unlikely)
Boards with custom stack size:
* asrock/e350m1
* asus/f2a85-m
* technexion/tim5690
* msi/ms9652_fam10
* tyan/s8226
* supermicro/h8scm
* supermicro/h8qgi
* supermicro/h8qme_fam10
* amd/inagua
* amd/parmer
* amd/south_station
* amd/thatcher
* amd/dinar
* amd/torpedo
* amd/persimmon
* amd/union_station
* lippert/frontrunner-af
* lippert/toucan-af
Regards,
Stefan

Re: [coreboot] Question about STACK_SIZE