[coreboot] [patch] RE: Fam10 breakage

Myles Watson mylesgw at gmail.com
Mon Mar 1 20:32:05 CET 2010



> -----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.

Thanks,
Myles





More information about the coreboot mailing list