On Mon, Mar 1, 2010 at 12:32 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Monday, March 01, 2010 12:00 PM To: Patrick Georgi Cc: Myles Watson; coreboot@coreboot.org Subject: Re: [coreboot] [patch] RE: Fam10 breakage
On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi patrick@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 least).
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.
Marc