[coreboot] [patch] RE: Fam10 breakage

Marc Jones marcj303 at gmail.com
Mon Mar 1 21:51:37 CET 2010

On Mon, Mar 1, 2010 at 12:32 PM, Myles Watson <mylesgw at gmail.com> wrote:
>> -----Original Message-----
>> From: Marc Jones [mailto:marcj303 at gmail.com]
>> Sent: Monday, March 01, 2010 12:00 PM
>> To: Patrick Georgi
>> Cc: Myles Watson; coreboot at coreboot.org
>> Subject: Re: [coreboot] [patch] RE: Fam10 breakage
>> On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi <patrick at georgi-clan.de>
>> wrote:
>> > Am 01.03.2010 17:23, schrieb Myles Watson:
>> >>> However, this does not fix the bug in our stack size calculation.
>> >>> I'm not quite sure if the patch does the right thing, but it should be
>> >>> close.
>> >> I don't think we need to make the SMP check.  Can't we just put in an
>> assert
>> >> that checks for RAMBASE < 0xa0000 and eheap > 0xa0000?  One large stack
>> >> could just as easily break this.
>> > True. Attached patch might do this (only moderately tested)
>> >
>> > I think the only reason why we can't get rid of RAMBASE <1M completely
>> > is a couple of boards (Via based iirc) that have their own vgabios.c
>> > that breaks with RAMBASE >1M
>> >
>> > The other RAMBASE we sometimes use (mostly on AMD boards) is RAMBASE==2M
>> > - what was the rationale for that again?
>> >
>> > With those two gone, we could hide RAMBASE somewhere in Kconfig or
>> > eliminate it completely.
>> I'm coming to this discussion a bit late, but here is what I recall.
>> Maybe someone else can confirm this?
>> Each core needs a stack large enough for the sysinfo structure and its
>> own call stack. Stacks space was assigned starting at 0xC8000
> This looks like a CAR address.  Most of the boards have RAMBASE 1M now,
> right?
>> size of 0x2000 was enough pre-cbfs. When we switched to cbfs and lzma,
>> the stack requirement went to 0x8000. I'm not positive since things
>> have moved around, but I think that RAMBASE set to 2M is to leave room
>> for the nodes CAR stacks.
> Shouldn't CAR stacks be below 1M?
>> With the smaller 0x2000 stack 28 cores could
>> be supported. Although I don't know any machines with that many cores,
>>  that isn't the max possible 32 ( 8cpus x 4cores )( I'm not sure where
>> the 48 came from unless someone is already trying to support 6 core
>> cpus?).
> Yep.
>> So, RAMBASE was moved to 2M. This is more important with
>> stacks of 0x8000 for each core as only 7 cores could be supported
>> below 1M.
>> Now, does RAMBASE really need to be affected by the CAR stacks? I
>> don't think so since the BSP does the decompress and the move after
>> memory init and all the APs are halted. Also, how many stacks do we
>> really need? I think that core0 for each node is the only one that
>> must run to do HT and memory init on the node before coreboot_ram is
>> run.
> Do all the core0 processors have to do init?  I thought HT and memory init
> was all done by BSP core0.
> Maybe we should add specific memory areas for lzma and page tables so we can
> go back to having smaller stacks.  Otherwise, maybe we should have two sizes
> of stacks.

I had to go look at the code to remeber the details.  Each core does
fid/vid setup before HT reset. You are correct, the BSP handles the
memory init. I was thinking on msrs setup but that happens later in
coreboot_ram (each core has to write some of its own msrs,TOM, TOM2 at

You can see when core0 and coreN are started in romstage.c. Every core
runs init_cpus() which does different things depending on BSP, core0,
and coreN.  It looks like each core sets lapic and fid/vid. All cores
on a cpu will have the same fid/vid capability, so only core0 should
have to be setup, but currently every core is getting fid/vid setup
(#define FAM10_SET_FIDVID_CORE0_ONLY 0). I think the complexity comes
from what could be done and what is working today.



More information about the coreboot mailing list