[coreboot] [patch] RE: Fam10 breakage

[Marc Jones]

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  and
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. 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?). 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. The other cores can be setup later.

I think Patrick and Myles mentioned that we need to understand the
bootblock while each cpu core initializing and walking the cbfs while
not stepping on each others stacks. Has that been resolved?

I hope this made some sense and helps understand the problem.

Marc

-- 
http://se-eng.com