* Marc Jones <marcj303(a)gmail.com> [130502 20:24]:
> On Thu, May 2, 2013 at 12:22 PM, Stefan Reinauer
> <stefan.reinauer(a)coreboot.org> wrote:
> > * Aaron Durbin <adurbin(a)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