On Mon, Mar 1, 2010 at 12:32 PM, Myles Watson <[email protected]> wrote: > > >> -----Original Message----- >> From: Marc Jones [mailto:[email protected]] >> Sent: Monday, March 01, 2010 12:00 PM >> To: Patrick Georgi >> Cc: Myles Watson; [email protected] >> Subject: Re: [coreboot] [patch] RE: Fam10 breakage >> >> On Mon, Mar 1, 2010 at 9:48 AM, Patrick Georgi <[email protected]> >> 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 -- http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
